This symbol is not used outside of dc_link_dp.c, so marks it static.
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5230:16: warning: no
previous prototype for function 'wake_up_aux_channel'.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2581
Reported-by: Abaci Robot
Signed-o
No functional modification involved.
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:615: warning: expecting
prototype for setup_subvp_dmub_command(). Prototype was for
populate_subvp_cmd_pipe_info() instead.
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2587
Reported-by: Abaci Ro
struct cdit_header was never used across any of the amd drivers nor
this is exposed to UAPI so it can be removed.
This patch removes struct cdit_header and refactor code accordingly
Signed-off-by: Paulo Miguel Almeida
---
At some point, removing this structure was suggested during a review for
kfd_pm4_headers_diq.h header is a leftover from the old H/W debugger
module support added on commit . That implementation
was removed after a while and the last file that included that header
was removed on commit <5bdd3eb253544b1>.
This patch removes the unused header file kfd_pm4_headers_diq.h
Ping?
On 2022-09-26 22:37, Aurelien Jarno wrote:
> When the avdd-0v9 or avdd-1v8 supply are not yet available, EPROBE_DEFER
> is returned by rockchip_hdmi_parse_dt(). This causes the following error
> message to be printed multiple times:
>
> dwhdmi-rockchip fe0a.hdmi: [drm:dw_hdmi_rockch
On Tue, Oct 25, 2022 at 03:48:33PM -0400, Felix Kuehling wrote:
> Am 2022-10-25 um 05:12 schrieb Paulo Miguel Almeida:
> > kfd_pm4_headers_diq.h header is a leftover from the old H/W debugger
> > module support added on commit . That implementation
> > was removed after a while and the last file th
If drm_sysfs_minor_alloc() fail in drm_minor_alloc() we can end up
freeing invalid minor->kdev pointer and drm_minor_alloc_release()
will crash like below:
RIP: 0010:kobject_put+0x19/0x1c0
RSP: 0018:bc7001637c38 EFLAGS: 00010282
RAX: a8d6deb0 RBX: RCX: 9cb5912d4540
Attached is the original test patch rebased on current amd-staging-drm-next.
Can you test if this is enough to make sure that the games start without
crashing by fetching the userptrs?
Thanks in advance,
Christian.
Am 21.10.22 um 14:36 schrieb Mikhail Gavrilov:
On Fri, Oct 21, 2022 at 1:33 P
Hi Rob,
On Mon, Oct 24, 2022 at 08:48:15AM -0700, Rob Clark wrote:
> On Mon, Oct 24, 2022 at 5:43 AM wrote:
> > I've discussing the idea for the past year to add an IGT test suite that
> > all well-behaved KMS drivers must pass.
> >
> > The main idea behind it comes from v4l2-compliance and cec-c
On Mon, 24 Oct 2022, Jani Nikula wrote:
> v2 of drm/edid: EDID override refactoring and fixes
>
> Address review comments, add patch 15.
Thanks for the reviews, pushed the series to drm-misc-next.
BR,
Jani.
>
> BR,
> Jani.
>
>
> Jani Nikula (16):
> drm/i915/hdmi: do dual mode detect only if
Commit d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
introduced a regression as it may undo the clk_names setting in case
the optional regulator is missing. This resulted in test and performance
regressions with lima.
Restore the old behavior where clk_names is set separately so it
On 26-10-22, 10:39, Erico Nunes wrote:
> Commit d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()")
> introduced a regression as it may undo the clk_names setting in case
> the optional regulator is missing. This resulted in test and performance
> regressions with lima.
>
> Restore the o
Hi,
On 10/26/22 01:40, Matthew Garrett wrote:
> On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote:
>
>> this code should actually set the ACPI_VIDEO_BACKLIGHT flag:
>> drivers/acpi/scan.c:
>>
>> static acpi_status
>> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *contex
Hello Noralf Trønnes,
The patch b39b5394fabc: "drm/gem: Add drm_gem_object_funcs" from Nov
10, 2018, leads to the following Smatch static checker warning:
drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
warn: variable dereferenced before check 'buffer->gem' (see line 2
On 24/10/2022 18:39, Dmitry Baryshkov wrote:
Intruct two drm_connector_helper_funcs: enable_hpd() and disable_hpd().
"Introduce"?
They are called by drm_kms_helper_poll_enable() and
drm_kms_helper_poll_disable() (and thus drm_kms_helper_poll_init() and
drm_kms_helper_poll_fini()) respectively
On 24/10/2022 18:39, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver how to properly handle
drm_bridge_connector
On 26/10/2022 14:21, Tomi Valkeinen wrote:
On 24/10/2022 18:39, Dmitry Baryshkov wrote:
From all the drivers using drm_bridge_connector only iMX/dcss and OMAP
DRM driver do a proper work of calling
drm_bridge_connector_en/disable_hpd() in right places. Rather than
teaching each and every driver
On 10/26/22 12:59, Dan Carpenter wrote:
> Hello Noralf Trønnes,
>
> The patch b39b5394fabc: "drm/gem: Add drm_gem_object_funcs" from Nov
> 10, 2018, leads to the following Smatch static checker warning:
>
> drivers/gpu/drm/drm_client.c:240 drm_client_buffer_delete()
> warn: variable d
Hi,
On 10/25/2022 2:41 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz:
>> Adds four types of GEM-based BOs for the VPU:
>> - shmem
>> - userptr
>> - internal
>> - prime
>>
>> All types are implemented as struct ivpu_bo, based on
>> struct drm_gem_
On Tue, Oct 25, 2022 at 08:26:24PM -0700, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> The SA8295P ADP has, among other interfaces, six MiniDP connectors which
> are connected to MDSS0 DP2 and DP3, and MDSS1 DP0 through DP3.
>
> Enable Display Clock controllers, MDSS instanced, MDPs, DP co
On Tue, Oct 25, 2022 at 08:26:22PM -0700, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> Define the display clock controllers, the MDSS instances, the DP phys
> and connect these together.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
> -
(cc: Thomas, Christian, intel-gfx)
Hi
Am 26.10.22 um 13:26 schrieb Jacek Lawrynowicz:
Hi,
On 10/25/2022 2:41 PM, Thomas Zimmermann wrote:
Hi
Am 24.09.22 um 17:11 schrieb Jacek Lawrynowicz:
Adds four types of GEM-based BOs for the VPU:
- shmem
- userptr
- internal
- prime
All
Hi,
On 10/25/2022 1:57 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 25.10.22 um 13:42 schrieb Jacek Lawrynowicz:
>> Hi, thanks for detailed review. My responses inline.
>>
>> On 10/25/2022 1:00 AM, Jeffrey Hugo wrote:
>>> On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote:
VPU stands for Versatile Pr
Hi
Am 26.10.22 um 14:07 schrieb Jacek Lawrynowicz:
Hi,
On 10/25/2022 1:57 PM, Thomas Zimmermann wrote:
Hi
Am 25.10.22 um 13:42 schrieb Jacek Lawrynowicz:
Hi, thanks for detailed review. My responses inline.
On 10/25/2022 1:00 AM, Jeffrey Hugo wrote:
On 9/24/2022 9:11 AM, Jacek Lawrynowicz
On 10/25/2022 4:08 PM, Jeffrey Hugo wrote:
> On 10/25/2022 5:42 AM, Jacek Lawrynowicz wrote:
>> Hi, thanks for detailed review. My responses inline.
>>
>> On 10/25/2022 1:00 AM, Jeffrey Hugo wrote:
>>> On 9/24/2022 9:11 AM, Jacek Lawrynowicz wrote:
VPU stands for Versatile Processing Unit and
On 9/26/22 23:37, Aurelien Jarno wrote:
> When the avdd-0v9 or avdd-1v8 supply are not yet available, EPROBE_DEFER
> is returned by rockchip_hdmi_parse_dt(). This causes the following error
> message to be printed multiple times:
>
> dwhdmi-rockchip fe0a.hdmi: [drm:dw_hdmi_rockchip_bind [r
On Tue, 25 Oct 2022 20:26:13 -0700, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> Add binding for the display subsystem and display processing unit in the
> Qualcomm SC8280XP platform.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
> - Cle
adv7511 probe may need to be attempted multiple times before no
-EPROBE_DEFER is returned. Currently, every such probe results in
an error message:
[4.534229] adv7511 1-003d: failed to find dsi host
[4.580288] adv7511 1-003d: failed to find dsi host
This is misleading, as there is no erro
Hello,
On Wed, Oct 26, 2022 at 11:36 AM Viresh Kumar wrote:
> You can directly call devm_pm_opp_set_clkname() and
> devm_pm_opp_set_regulators(), like it was done before my patch, for
> single configurations. So basically a simple revert of my commit, with
> additional comments you added above.
On Mon, Sep 26, 2022 at 10:37:52PM +0200, Aurelien Jarno wrote:
> When the avdd-0v9 or avdd-1v8 supply are not yet available, EPROBE_DEFER
> is returned by rockchip_hdmi_parse_dt(). This causes the following error
> message to be printed multiple times:
>
> dwhdmi-rockchip fe0a.hdmi: [drm:
There's Intel Arc now which is what most folks will be looking for.
Signed-off-by: Adam Borowski
---
drivers/gpu/drm/tiny/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 565957264875..51b60c1a2bea 1
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
Only support vm_bind mode with non-recoverable contexts.
With new vm_bind mode with eb3 submission path, we need not
support older recoverable contexts.
Signed-off-by: Niranjana Vishwanathapura
Reviewed-by: Matthew Auld
Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
before removing PCI devices. Without, simpledrm can still bind to
simple-framebuffer devices after the hardware driver has taken over
the hardware. Both drivers interfere with each other and results are
undefined.
Reported modeset
This is a note to let you know that I've just added the patch titled
[PATCH v2] video/aperture: Call sysfb_disable() before removing PCI devices
to the 6.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename o
On Wed, Oct 26, 2022 at 04:44:48PM +0200, Thomas Zimmermann wrote:
> Call sysfb_disable() from aperture_remove_conflicting_pci_devices()
> before removing PCI devices. Without, simpledrm can still bind to
> simple-framebuffer devices after the hardware driver has taken over
> the hardware. Both dri
On 25/10/2022 11:37, Diogo Ivo wrote:
> The LPM102A188A is a 10.2" 2560x1800 IPS panel found in
> the Google Pixel C.
>
> Signed-off-by: Diogo Ivo
> ---
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> In order to support higher HDMI frequencies, users have to set the
> hdmi_enable_4kp60 parameter in their config.txt file.
>
> We were detecting this so far by calling clk_round_rate() on the core
> clock with the frequency we're supposed to run at when one
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Reviewed-by: No
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
* The
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that fu
The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.
Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display usual
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by: Maxime Ripard
---
Change
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_connector.h | 7 +++
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though, the
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes and
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Renamed the tests to follow DRM test naming convention
Changes in v5:
- S
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
Signed-off-by
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/
Most of the TV connectors will need a similar get_modes implementation
that will, depending on the drivers' capabilities, register the 480i and
576i modes.
That implementation will also need to set the preferred flag and order
the modes based on the driver and users preferrence.
This is especiall
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
Sig
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV atomic_check
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by: Mate
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the count var
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
broadcas
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Changes in v2:
- drop patch "drm/arm/hdlcd: crtc: use drmm_crtc_init_with_planes()"
Changes in v3:
- Fix a
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
drm_mode_config_init() simply calls drmm_mode_config_init(), hence
cleanup is automatically handled through registering
drm_mode_config_cleanup() with drmm_add_action_or_reset().
While at it, get rid of the deprecated drm_mode_config_init() and
replace it with drmm_mode_config_init() directly.
Si
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
hdlcd_drm_private, hence we can use container_of() to get the struct
drm_device instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_c
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --gi
Remove some not implemented function define
Signed-off-by: Christian König
---
include/drm/gpu_scheduler.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index c564be29c5ae..d646ff2fd557 100644
--- a/include/drm/gpu_scheduler.h
+++ b/
Add the ability to pass DSI HS clock frequency constraints between
neighboring DSI bridges via struct drm_bridge_state . This way the
DSI HS clock frequency negotiation can be implemented instead of
the current ad-hoc method where each bridge attempts to guess the
neighbor HS clock frequency settin
On Wed, 26 Oct 2022 at 16:27, Dave Stevenson
wrote:
>
> On Thu, 20 Oct 2022 at 10:14, wrote:
> >
> > In order to support higher HDMI frequencies, users have to set the
> > hdmi_enable_4kp60 parameter in their config.txt file.
> >
> > We were detecting this so far by calling clk_round_rate() on th
This reverts commit e6c6338f393b74ac0b303d567bb918b44ae7ad75.
This feature basically re-submits one job after another to
figure out which one was the one causing a hang.
This is obviously incompatible with gang-submit which requires
that multiple jobs run at the same time. It's also absolutely
no
Re-submitting IBs by the kernel has many problems because pre-
requisite state is not automatically re-created as well. In
other words neither binary semaphores nor things like ring
buffer pointers are in the state they should be when the
hardware starts to work on the IBs again.
Additional to tha
This interface is not working as it should.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index bb28f31bf
In case TC358767 operates in DSI-to-DPI mode and its clock are supplied
from XTal connected to RefClk, the range of supported input DSI HS clock
is limited.
Expose this limitation to the upstream bridge by providing minimum and
maximum accepted DSI HS clock frequency via bridge state.
Signed-off-
In case the downstream bridge state reports DSI HS clock minimum and
maximum limits, find the most suitable DSI HS clock rate and use it
for the DSI link.
Signed-off-by: Marek Vasut
---
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
---
drivers/gpu/d
As far as I can see this is not really recoverable since a PCI reset
clears VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_dev
Hi,
This patch series converts the driver to use drm managed resources to prevent
potential use-after-free issues on driver unbind/rebind and to get rid of the
usage of deprecated APIs.
Changes in v2:
- While protecting critical sections with drm_dev_{enter,exit} I forgot to
handle alternat
Using drm_device->dev_private is deprecated. Since we've switched to
devm_drm_dev_alloc(), struct drm_device is now embedded in struct
malidp_drm, hence we can use container_of() to get the struct drm_device
instance instead.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c
Use drm managed resource allocation (drmm_universal_plane_alloc()) in
order to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_planes.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(
drm_mode_config_init() simply calls drmm_mode_config_init(), hence
cleanup is automatically handled through registering
drm_mode_config_cleanup() with drmm_add_action_or_reset().
While at it, get rid of the deprecated drm_mode_config_init() and
replace it with drmm_mode_config_init() directly.
Si
Use drm managed resources to allocate driver structures and get rid of
the deprecated drm_dev_alloc() call and replace it with
devm_drm_dev_alloc().
This also serves as preparation to get rid of drm_device->dev_private
and to fix use-after-free issues on driver unload.
Signed-off-by: Danilo Krumm
Use drmm_crtc_init_with_planes() instead of drm_crtc_init_with_planes()
to get rid of the explicit destroy hook in struct drm_plane_funcs.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/arm/malidp_crtc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/dr
Hi Maxime
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> In order to support higher HDMI frequencies, users have to set the
> hdmi_enable_4kp60 parameter in their config.txt file.
>
> This will have the side-effect of raising the maximum of the core clock,
> tied to the HVS, and managed by the HVS driv
I knew there was something else
On Wed, 26 Oct 2022 at 17:00, Dave Stevenson
wrote:
>
> Hi Maxime
>
> On Thu, 20 Oct 2022 at 10:14, wrote:
> >
> > In order to support higher HDMI frequencies, users have to set the
> > hdmi_enable_4kp60 parameter in their config.txt file.
> >
> > This will have t
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> From: Dom Cobley
>
> At least the 4096x2160@60Hz mode requires some overclocking that isn't
> available by default, even if hdmi_enable_4kp60 is enabled.
>
> Let's add some logic to detect whether we can satisfy the core clock
> requirements for that mode,
On Thu, 20 Oct 2022 at 10:14, wrote:
>
> Following the clock rate range improvements to the clock framework,
> trying to set a disjoint range on a clock will now result in an error.
>
> Thus, we can't set a minimum rate higher than the maximum reported by
> the firmware, or clk_set_min_rate() will
[AMD Official Use Only - General]
The user space shouldn't care about SRIOV or not , I don't think we need to
keep the re-submission for SRIOV as well. The reset from SRIOV could trigger
the host do a whole GPU reset which will have the same issue as bare metal.
Regards
Shaoyun.liu
-
Hi Dave,
Thanks for your review
On Wed, Oct 26, 2022 at 04:36:04PM +0100, Dave Stevenson wrote:
> On Wed, 26 Oct 2022 at 16:27, Dave Stevenson
> wrote:
> >
> > On Thu, 20 Oct 2022 at 10:14, wrote:
> > >
> > > In order to support higher HDMI frequencies, users have to set the
> > > hdmi_enable_4
Hi Dave,
On Wed, Oct 26, 2022 at 05:00:25PM +0100, Dave Stevenson wrote:
> > +
> > + node = rpi_firmware_find_node();
> > + if (!node)
> > + return -EINVAL;
> > +
> > + firmware = rpi_firmware_get(node);
> > + of_node_pu
Most Kconfig options to enable a driver are in the Kconfig file
inside the relevant directory, move these two to the same.
Signed-off-by: Andrew Davis
Reviewed-by: Christian König
---
Changes from v2:
- Rebased on latest
Changes from v1:
- Fix whitespace issue pointed out by Randy
drivers/
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
For persistent (vm_bind) vmas of userptr BOs, handle the user
page pinning by using the i915_gem_object_userptr_submit_init()
/done() functions
v2: Do not double add vma to vm->userptr_invalidated_list
Signed-off-by: Niranjana Vishwanathapur
On 25/10/2022 07:58, Niranjana Vishwanathapura wrote:
Add support for handling out fence for vm_bind call.
v2: Reset vma->vm_bind_fence.syncobj to NULL at the end
of vm_bind call.
v3: Remove vm_unbind out fence uapi which is not supported yet.
v4: Return error if I915_TIMELINE_FENCE_WAIT fe
On 25/10/2022 07:59, Niranjana Vishwanathapura wrote:
Update i915 documentation to include VM_BIND changes
and render all VM_BIND related documentation.
Signed-off-by: Niranjana Vishwanathapura
Thanks for adding this,
Reviewed-by: Matthew Auld
The problem is that this re-submitting is currently an integral part of
how SRIOV works.
The host can send a function level reset request to the clients when it
sees that some schedule switching didn't worked as expected and in this
case (and only this case) the hardware has actually never sta
On Tue, Oct 25, 2022 at 08:26:13PM -0700, Bjorn Andersson wrote:
> From: Bjorn Andersson
>
> Add binding for the display subsystem and display processing unit in the
> Qualcomm SC8280XP platform.
>
> Signed-off-by: Bjorn Andersson
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v2:
>
[AMD Official Use Only - General]
The SRIOV already has its own reset routine amdgpu_device_reset_sriov, we try
to put the sriov specific sequence inside this function. For the rest
part(re-submitting etc ) we should try to have the same behavior as bare-metal.
Can we just don't do the re-su
Various removals of complex yet unnecessary math, fixing all uses of
drm_dsc_config::bits_per_pixel to deal with the fact that this field
includes four fractional bits, and finally making sure that
range_bpg_offset contains values 6-bits wide to prevent overflows in
drm_dsc_pps_payload_pack().
Alt
slice_per_intf is already computed for intf_width, which holds the same
value as hdisplay.
Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration")
Reviewed-by: Bjorn Andersson
Reviewed-by: Konrad Dybcio
Reviewed-by: Abhinav Kumar
Reviewed-by: Vinod Koul
Reviewed-by: Dmitry Barys
Multiplying a value by 2 and adding 1 to it always results in a value
that is uneven, and that 1 gets truncated immediately when performing
integer division by 2 again. There is no "rounding" possible here.
After that target_bpp_x16 is used to store a multiplication of
bits_per_pixel by 16 which
According to the `/* bpc 8 */` comment below only values for a
bits_per_component of 8 are currently hardcoded in place. This is
further confirmed by downstream sources [1] containing different
constants for other BPC values (and different initial_offset too,
with an extra dependency on bits_per_p
As per the FIXME this code is entirely duplicate with what is already
provided inside drm_dsc_compute_rc_parameters(), supposedly because that
function was yielding "incorrect" results while in reality the panel
driver(s?) used for testing were providing incorrect parameters.
For example, this cod
1 - 100 of 143 matches
Mail list logo
