Hi Xinhui,
you also need to CC dri-devel for TTM patches, but apart from that it is
a really good catch.
Am 19.02.21 um 05:25 schrieb xinhui pan:
Free the memory on failure.
Also no need to re-alloc memory on retry.
Signed-off-by: xinhui pan
Reviewed-by: Christian König
CC: sta...@vger.k
Fix the following sparse warnings:
drivers/gpu/drm/radeon/rv6xx_dpm.c:1798:21: warning: cast to restricted
__le32
drivers/gpu/drm/radeon/rv6xx_dpm.c:1799:22: warning: cast to restricted
__le16
drivers/gpu/drm/radeon/rv6xx_dpm.c:1800:23: warning: cast to restricted
__le16
Reported-by: Abaci Robot
On Thu, Feb 18, 2021 at 9:03 PM Andrey Grodzovsky
wrote:
>
> Looked a bit into it, I want to export sync_object to FD and import from
> that FD
> such that I will wait on the imported sync object handle from one thread while
> signaling the exported sync object handle from another (post device u
[AMD Official Use Only - Internal Distribution Only]
Hi Jiapeng,
/* 0 - Fine grained DPM, 1 - Discrete DPM */
- return dpm_desc->SnapToDiscrete == 0 ? true : false;
+ return !(dpm_desc->SnapToDiscrete == 0);
the code logic is wrong, the '!' is not needed.
Best Regards,
Kevi
Most drivers call the argument to the plane atomic_check hook simply
state, which is going to conflict with the global atomic state in a
later rework. Let's rename it to new_plane_state (or new_state depending
on the convention used in the driver).
This was done using the coccinelle script below,
Now that atomic_check takes the global atomic state as a parameter, we
don't need to go through the pointer in the plane state.
This was done using the following coccinelle script:
@ plane_atomic_func @
identifier helpers;
identifier func;
@@
static struct drm_plane_helper_funcs helpers = {
Fix the following coccicheck warnings:
./drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:900:47-52: WARNING:
conversion to bool not needed here.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +-
1 file changed, 1 insertion(+), 1 d
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Let's convert all the remaining helpers to provide a consistent
int
The current atomic helpers have either their object state being passed as
an argument or the full atomic state.
The former is the pattern that was done at first, before switching to the
latter for new hooks or when it was needed.
Let's start convert all the remaining helpers to provide a consiste
Am 19.02.21 um 13:00 schrieb Maxime Ripard:
Most drivers call the argument to the plane atomic_check hook simply
state, which is going to conflict with the global atomic state in a
later rework. Let's rename it to new_plane_state (or new_state depending
on the convention used in the driver).
T
Hi Thomas,
Thanks for your review!
On Fri, Feb 19, 2021 at 03:49:22PM +0100, Thomas Zimmermann wrote:
> > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
> > b/drivers/gpu/drm/imx/ipuv3-plane.c
> > index 075508051b5f..1873a155bb26 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-plane.c
> > +++ b/drive
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/displ
The cursor plane can't be displayed if the primary plane isn't
using an RGB format. Reject such atomic commits so that user-space
can have a fallback instead of an invisible cursor.
In theory we could support YUV if the cursor is also YUV, but at the
moment only ARGB cursors are supported.
Si
On 2021-02-19 11:19 a.m., Simon Ser wrote:
The cursor plane can't be displayed if the primary plane isn't
using an RGB format. Reject such atomic commits so that user-space
can have a fallback instead of an invisible cursor.
In theory we could support YUV if the cursor is also YUV, but at the
mo
On Friday, February 19th, 2021 at 6:22 PM, Kazlauskas, Nicholas
wrote:
> We can support cursor plane, but only if we have an overlay plane
> enabled that's using XRGB/ARGB.
>
> This is what we do on Chrome OS for video playback:
>
> Cursor Plane - ARGB
> Overlay Plane - ARGB Desktop/UI w
On 2021-02-19 12:29 p.m., Simon Ser wrote:
On Friday, February 19th, 2021 at 6:22 PM, Kazlauskas, Nicholas
wrote:
We can support cursor plane, but only if we have an overlay plane
enabled that's using XRGB/ARGB.
This is what we do on Chrome OS for video playback:
Cursor Plane - ARGB
Ove
On Friday, February 19th, 2021 at 6:41 PM, Kazlauskas, Nicholas
wrote:
> > Related: how does this affect scaling? Right now there is a check that makes
> > sure the cursor plane scaling matches the primary plane's. Should we instead
> > check that the cursor plane scaling matches the top-most XR
This allows to tie the log message to a specific DRM device.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/displ
The current logic checks whether the cursor plane blending
properties match the primary plane's. However that's wrong,
because the cursor uses the topmost pipe.
Instead, grab the topmost enabled plane, and check that the
cursor plane blending properties matches it.
Fixes: 12f4849a1cfd ("drm/amd/d
Make sure there's an underlying pipe that can be used for the
cursor.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gp
The cursor plane can't be displayed if the underlying pipe isn't
using an RGB format. Reject such atomic commits so that user-space
can have a fallback instead of an invisible cursor.
In theory we could support YUV if the cursor is also YUV, but at the
moment only ARGB cursors are supported.
We don't want a semi-transparent overlay to make the cursor plane
semi-transparent as well. Same for the pixel blend mode.
Signed-off-by: Simon Ser
Cc: Alex Deucher
Cc: Harry Wentland
Cc: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 ++
1 file changed
The commit 1347385fe187 ("drm/amd/display: don't expose rotation
prop for cursor plane") removed the rotation property for the
cursor plane, assuming the cursor would always be displayed without
any rotation. However the rotation is inherited from the underlying
plane.
As a result, if the primary
Ping
Andrey
On 2/18/21 11:41 AM, Andrey Grodzovsky wrote:
On 2/18/21 10:15 AM, Christian König wrote:
Am 18.02.21 um 16:05 schrieb Andrey Grodzovsky:
On 2/18/21 3:07 AM, Christian König wrote:
Am 17.02.21 um 22:59 schrieb Andrey Grodzovsky:
Problem: If scheduler is already stopped by th
Hi,
On Wednesday, December 23rd, 2020 at 6:48 AM, Cornij, Nikola
wrote:
> Another interim update: so far to me it looks like this is an issue if there's
> fewer than 24 pixels left on the screen when moving the FB outside of the left
> edge (e.g. with 300x300 FB size, it repros with X = -280).
Since we're about to be adding some more fields and update this
documentation, let's rewrap it to the new column limit of 100 beforehand.
No actual doc or functional changes are made here.
Signed-off-by: Lyude Paul
---
include/drm/drm_dp_helper.h | 42 -
1 fil
* Make sure that struct members are referred to using @, otherwise they
won't be formatted as such
* Make sure to refer to other struct types using & so they link back to
each struct's definition
* Make sure to precede constant values with % so they're formatted
correctly
Signed-off-by: Lyud
Just adds some missing calls to
drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the
bridge.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/br
Since this is a bridge, we don't start out with a respective DRM device.
Likewise this means we don't have a connector, which also means that we
should be following drm_dp_aux_register()'s documentation advice and not
call drm_dp_aux_register() until we have a matching connector. Instead,
call drm_
Surprisingly, this bridge actually registers it's AUX adapter at the
correct time already. Nice job! However, it does forget to actually
unregister the AUX adapter, so let's add a bridge function to handle that.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 6
Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's
move the AUX adapter registration to the first point where we know which
DRM device we'll be working with - when the drm_bridge is attached.
Likewise, we unregister the AUX adapter on bridge detachment by adding a
ti_sn_bridge_
As pointed out by the documentation for drm_dp_aux_register(),
drm_dp_aux_init() should be used in situations where the AUX channel for a
display driver can potentially be registered before it's respective DRM
driver. This is the case with Tegra, since the DP aux channel exists as a
platform device
Since encoder mappings for connectors are exposed to userspace, we should
be attaching the encoder before exposing the connector to userspace. Just a
drive-by fix for an issue I noticed while fixing up usages of
drm_dp_aux_init()/drm_dp_aux_register() across the tree.
Signed-off-by: Lyude Paul
--
Another driver I found that seems to forget to unregister it's DP AUX
device. Let's fix this by adding anx6345_bridge_detach().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analog
Another case of linking an encoder to a connector after the connector's
been registered. The proper place to do this is before connector
registration, so let's fix that.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++--
1 file changed, 6 insertio
Since AUX adapters on nouveau have their respective DRM connectors as
parents, we need to make sure that we register then after their connectors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++---
1 file changed, 18 insertions(+), 8 deletions(-)
Another drive-by fix I found when fixing DP AUX adapter across the kernel
tree - make sure we don't leak resources (and by proxy-AUX adapters) on
failures in anx6345_bridge_attach() by unrolling on errors.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11
Just another drive-by fix I noticed while going through the tree to cleanup
DP aux adapter registration - make sure we unregister the DP AUX dev if
analogix_dp_probe() fails.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
1 file changed, 1 insertion(+)
d
We're about to make a correction to these, so let's rewrap the kernel docs
for these while we're at it.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_helper.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers
The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly
correct, except for the fact that they made the assumption that all AUX
devices were grandchildren of their respective DRM devices. This is the
case for most normal GPUs, but is almost never the case with SoCs and
display b
Since it's been asked quite a few times on some of the various DP
related patch series I've submitted to use the new DRM printk helpers,
and it technically wasn't really trivial to do this before due to the
lack of a consistent way to find a drm_device for an AUX channel, this
patch series aims to
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for d
Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want
to make sure that we can also add ratelimited versions of these macros in
order to retain some of the previous debugging output behavior we had.
However, as I was preparing to do this I noticed that the current
rate limited
So that we can start using drm_dbg_*() for
drm_dp_link_train_channel_eq_delay() and
drm_dp_lttpr_link_train_channel_eq_delay().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c| 14 +-
.../gp
Since we're about to convert everything in drm_dp_helper.c over to using
drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c
while we're at it to ensure that we always print the name of the AUX
channel in question.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_help
Another function that we'll need to pass a drm_device (and not drm_dp_aux)
down to so that we can move over to using drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--
include/drm/drm_dp_dual_mode_helpe
Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll
need to be able to access the DRM device in the dual mode DP helpers as
well. Note however that since drm_dp_dual_mode_detect() can be called with
DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down
th
Just another issue I noticed while correcting usages of
drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the
steps in anx78xx_bridge_attach() fail, we end up leaking resources. So,
let's fix that (and fix leaking a DP AUX adapter in the process) by
unrolling on errors.
Signed-off
Another function to pass drm_device * down to so we can start using the
drm_dbg_*() in the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++--
include/drm/drm_dp_dual_mode_helper.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff -
Another function we need to pass drm_device down to in order to start using
drm_dbg_*().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +-
include/drm/drm_dp_dual_mode_helper.h | 2 +-
3 files changed, 4 inserti
So that we can start using drm_dbg_*() throughout the DRM DP helpers.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +---
drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++-
include/drm/drm_dp_dual_mode_helper.h | 4 ++--
3 files changed, 14
Since this is one of the few functions in drm_dp_mst_topology.c that
doesn't have any way of getting access to a drm_device, let's pass the
drm_dp_mst_topology_mgr down to this function so that it can use
drm_dbg_kms().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c |
Next step in the conversion, move everything in drm_dp_dual_mode_helper.c
over to using drm_err() and drm_dbg_kms(). This was done using the
following cocci script:
@@
expression list expr;
@@
(
- DRM_DEBUG_KMS(expr);
+ drm_dbg_kms(dev, expr);
|
- DRM_ERROR(expr);
+ drm_err(dev,
And finally, convert all of the code in drm_dp_mst_topology.c over to using
drm_err() and drm_dbg*(). Note that this refactor would have been a lot
more complicated to have tried writing a coccinelle script for, so this
whole thing was done by hand.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/
Now that we've added a back-pointer to drm_device to drm_dp_aux, made
drm_dp_aux available to any functions in drm_dp_helper.c which need to
print to the kernel log, and ensured all of our logging uses a consistent
format, let's do the final step of the conversion and actually move
everything over
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* Firmware release 0.0.53.
* Addition of interrupts for DCN2.1
* Refractor debugfs entries for connectors.
* Enable display audio when seamless booting with an external monitor over DP.
* Fixes for System hang afte
From: Eric Bernstein
[Why]
In some cases, this function is called when DIG BE is not
connected to DIG FE, in which case a value of zero isn't
invalid and assert should not be hit.
[How]
Remove assert and handle ENGINE_ID_UNKNOWN result in calling
function.
Signed-off-by: Eric Bernstein
Acked-b
From: Stylon Wang
[Why]
Debugfs entries being moved from DP/eDP only to be available
on all connectors are cluttering the code.
[How]
Refactor the registration of these debugfs entries.
Signed-off-by: Stylon Wang
Acked-by: Bindu Ramamurthy
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c |
From: Rodrigo Siqueira
When run igt@kms_vrr in a device that uses DCN2.1 architecture, we
noticed multiple failures. Furthermore, when we tested a VRR demo, we
noticed a system hang where the mouse pointer still works, but the
entire system freezes; in this case, we don't see any dmesg warning or
From: Anthony Wang
[Why]
Seamless boot over DP MST is not POR, but is not explicitly disabled.
[How]
Add check for DP MST and return false in
dc_validate_seamless_boot_timing.
Signed-off-by: Anthony Wang
Acked-by: Bindu Ramamurthy
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 5 +++--
1 fil
From: Anthony Wang
[Why]
Some external displays with DP can use seamless boot, but their audio endpoints
are
only enabled after hotplug.
On boot, these displays inherit UEFI timings without properly initializing
audio.
[How]
Enable display audio when seamless booting with an external monitor o
From: Eryk Brol
[why]
This check for ASIC revision is no longer useful and causes
lightup issues after a topology change in MST DSC scenario.
In this case, DSC configs should be recalculated for the new
topology. This check prevented that from happening on certain
ASICs that do, in fact, support
From: Yongqiang Sun
[Why & How]
Move dmub trace buffer to uncached memory.
Signed-off-by: Yongqiang Sun
Acked-by: Bindu Ramamurthy
---
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn20.c | 7 +++
drivers/gpu/drm/amd/display/dmub/src/dmub_dcn20.h | 7 +++
drivers/gpu/drm/amd/display/dmub
From: Vladimir Stempen
[why]
Vendor based fan noise improvement
[how]
Report timing synchronizable when DP streams time frame
difference is less than 0.05 percent. Adjust DP DTOs and
sync displays using MASTER_UPDATE_LOCK_DB_X_Y
Signed-off-by: Vladimir Stempen
Acked-by: Bindu Ramamurthy
--
From: Aric Cyr
[Why]
There is a window of time where we optimize bandwidth due to no streams
enabled will enable PSTATE changing but HUBPs are not disabled yet.
This results in underflow counter increasing in some hotplug scenarios.
[How]
Set the optimize-bandwidth flag for later processing once
From: Aric Cyr
Signed-off-by: Aric Cyr
Acked-by: Bindu Ramamurthy
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index 9e631980fa1b..bd1cb665a585 100644
--- a
From: Anthony Koo
Signed-off-by: Anthony Koo
Acked-by: Bindu Ramamurthy
---
drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
From: Qingqing Zhuo
[Why]
mutex_lock() was introduced in dm_disable_vblank(), which could
be called in an IRQ context. Waiting in IRQ would cause issues
like kernel lockup, etc.
[How]
Handle code that requires mutex lock on a different thread.
Signed-off-by: Qingqing Zhuo
Acked-by: Bindu Ramam
From: Aric Cyr
[Why]
No reason to have uninitialized var at top of function
[How]
Move it to minimum scope where it's actuallty used
Signed-off-by: Aric Cyr
Acked-by: Bindu Ramamurthy
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff -
[AMD Public Use]
Hi all,
This week this patchset was tested on a HP Envy 360, with Ryzen 5 4500U, on the
following display types (via usb-c to dp/dvi/hdmi/vga):
4k 60z, 1440p 144hz, 1680*1050 60hz, internal eDP 1080p 60hz
Tested on a Reference AMD RX6800 on the following display types (via DP):
[AMD Official Use Only - Internal Distribution Only]
Ping .
-Original Message-
From: Liu, Shaoyun
Sent: Thursday, February 18, 2021 8:19 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Shaoyun
Subject: [PATCH 1/4] drm/amdgpu: Reset the devices in the XGMI hive duirng probe
In passthroug
On 2/19/21 1:52 PM, Lyude Paul wrote:
> * Make sure that struct members are referred to using @, otherwise they
> won't be formatted as such
> * Make sure to refer to other struct types using & so they link back to
> each struct's definition
> * Make sure to precede constant values with % so th
On 2/19/21 1:52 PM, Lyude Paul wrote:
> Since we're about to be adding some more fields and update this
> documentation, let's rewrap it to the new column limit of 100 beforehand.
> No actual doc or functional changes are made here.
>
The preferred column limit is still 80.
For some (exceptional)
74 matches
Mail list logo
