Am 2021-04-23 um 12:28 p.m. schrieb Christian König:
>
>
> Am 23.04.21 um 17:35 schrieb Philip Yang:
>> Add interface to remove address from fault filter ring by resetting
>> fault ring entry key, then future vm fault on the address will be
>> processed to recover.
>>
>> Use spinlock to protect fau
Am 2021-04-23 um 5:39 p.m. schrieb Souptick Joarder:
> Kernel test robot throws below warning ->
>
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
>>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>>> [-Wmissing-prototypes]
> 125 | int kgd_arcturus_hqd_sdma_loa
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit af8352f1ff54c4fecf84e36315fd1928809a580b:
Merge tag 'drm-msm-next-2021-04-11' of https://gitlab.freedesktop.org/drm/msm
into drm-next (2021-04-13 23:35:54 +0200)
are available in the Git repository at:
https://gitlab.free
Kernel test robot throws below warning ->
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>> [-Wmissing-prototypes]
125 | int kgd_arcturus_hqd_sdma_load(struct kgd_dev *kgd, void
*mqd,
>> drivers/gpu/drm/amd/amd
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
Thanks for adding this.
Reviewed-by: Leo (Hanghong) Ma
Thanks,
-Leo
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Friday, April 23, 2021 4:50 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
S
Reviewed-by: Alex Deucher
On Fri, Apr 23, 2021 at 3:02 PM Harish Kasiviswanathan
wrote:
>
> Signed-off-by: Harish Kasiviswanathan
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/s
Kernel test robot throws below warning ->
>> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:3015:53:
>> warning: address of 'aconnector->mst_port->mst_mgr' will always
>> evaluate to 'true' [-Wpointer-bool-conversion]
if (!(aconnector->port &&
&aconn
Some trivia, no comment on the real logic of the changes:
On Fri, Apr 23, 2021 at 2:43 PM Lyude Paul wrote:
>
> Since AUX adapters on nouveau have their respective DRM connectors as
> parents, we need to make sure that we register then after their connectors.
then -> them
>
> Signed-off-by: Lyu
Add missing structure elements.
Fixes: 1ace37b873c2 ("drm/amdgpu/display: Implement functions to let DC
allocate GPU memory")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amd
Was missing when this structure was updated.
Fixes: 4057828a1283 ("drm/amd/display: Add debugfs to control DMUB trace buffer
events")
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display
[why]
Two conditions that were part of this fix did not go through:
1. DPCD revision has to be v1.4 and up
This was because wrong DPCD space was used to get the values
2. Downstream port must not be VGA converter
This was because for MST the topology manager AUX has to be used,
due to th
[AMD Public Use]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, on the following display types:
eDP 1080p 60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to
DP/HDMI), 1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index dcbe3a72da09..1f02e4ee2
On Wed, Apr 21, 2021 at 1:43 PM Kai-Heng Feng
wrote:
>
> When an amdgpu device fails to init, it makes another VGA device cause
> kernel splat:
> kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
> kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
> kernel: amdgpu: p
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.
v2:
* Fix line-wrapping in drm_dp_mst_atomic_che
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
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,
While this shouldn't really be something that happens all that often, since
we're going to be using the drm_dbg_* log helpers in DRM helpers it's
technically possible that a driver could use an AUX adapter before it's
been associated with it's respective drm_device. While drivers should take
care t
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
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
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
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c
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
So that we can start using drm_dbg_*() in
drm_dp_link_train_clock_recovery_delay().
Signed-off-by: Lyude Paul
Reviewed-by: Laurent Pinchart
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
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
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
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 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 | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
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
Applied. Thanks!
Alex
On Thu, Apr 8, 2021 at 9:01 PM wrote:
>
> From: Yingjie Wang
>
> In dm_dp_mst_detect(), We should check whether or not @connector
> has been unregistered from userspace. If the connector is unregistered,
> we should return disconnected status.
>
> Fixes: 4562236b3bc0 ("dr
On Fri, 2021-04-23 at 14:39 +0200, Thierry Reding wrote:
>
> I'm curious: how is a DP AUX adapter reference count going to solve the
> issue of potentially registering devices too early (i.e. before the DRM
> is registered)?
>
> Is it because registering too early could cause a reference count
>
Am 23.04.21 um 17:35 schrieb Philip Yang:
Add interface to remove address from fault filter ring by resetting
fault ring entry key, then future vm fault on the address will be
processed to recover.
Use spinlock to protect fault hash ring access by interrupt handler and
interrupt scheduled def
Add a quirk DW_I2S_QUIRK_STOP_ON_SHUTDOWN for Stoney/CZ
platforms.
For CZ/StoneyRidge platforms, ACP DMA between ACP SRAM and
I2S FIFO should be stopped before stopping I2S Controller DMA.
When DMA is progressing and stop request received, while DMA
transfer ongoing between ACP SRAM and I2S FIFO,
After draining the stale retry fault, or failed to validate the range
to recover, have to remove the fault address from fault filter ring, to
be able to handle subsequent retry interrupt on same address. Otherwise
the retry fault will not be processed to recover until timeout passed.
Signed-off-by
Add interface to remove address from fault filter ring by resetting
fault ring entry key, then future vm fault on the address will be
processed to recover.
Use spinlock to protect fault hash ring access by interrupt handler and
interrupt scheduled deferred work for vg20.
Signed-off-by: Philip Yan
On 2021-04-23 2:03 a.m., Felix Kuehling
wrote:
Am 2021-04-22 um 10:03 p.m. schrieb Philip Yang:
Add interface to remove address from fault filter ring by resetting
fault ring entry of the fault address timestamp to 0, then future vm
fault on t
On Thu, Apr 22, 2021 at 01:18:09PM -0400, Lyude Paul wrote:
> On Tue, 2021-04-20 at 02:16 +0300, Ville Syrjälä wrote:
> >
> > The init vs. register split is intentional. Registering the thing
> > and allowing userspace access to it before the rest of the driver
> > is ready isn't particularly grea
On Fri, Apr 23, 2021 at 12:11:06AM -0400, Lyude Paul wrote:
> On Thu, 2021-04-22 at 18:33 -0400, Lyude Paul wrote:
> > OK - talked with Ville a bit on this and did some of my own research, I
> > actually think that moving i2c to drm_dp_aux_init() is the right decision
> > for
> > the time being. Th
On Tue, 20 Apr 2021, Alex Deucher wrote:
> Applied. thanks!
Lovely. Thanks for these Alex.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
amd-
On Thu, Apr 22, 2021 at 06:33:44PM -0400, Lyude Paul wrote:
> OK - talked with Ville a bit on this and did some of my own research, I
> actually think that moving i2c to drm_dp_aux_init() is the right decision for
> the time being. The reasoning behind this being that as shown by my previous
> work
On 2021-04-23 10:18 a.m., Christian König wrote:
Good that this has been found. Just a curious guess, but have you guys
checked if the src_x and src_y are a multiple of 2?
That was one of my first guesses but I still observed the hang after
forcing src_x and src_y to be multiples of 2.
Might
Good that this has been found. Just a curious guess, but have you guys
checked if the src_x and src_y are a multiple of 2?
Might cause problems to try to access a subsampled surface if the
coordinates doesn't make much sense.
Anyway patch is Acked-by: Christian König
Regards,
Christian.
Am
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Hersen Wu
-Original Message-
From: Harry Wentland
Sent: Friday, April 23, 2021 10:12 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; sta...@vger.kernel.org;
Kazlauskas, Nicholas ; Deucher, Alexander
; Li, Ro
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full screen.
[How]
Reject atomic commits with non-zero drm_plane_state.src_x or src_y
[Why]
This hasn't been well tested and leads to complete system hangs on DCN1
based systems, possibly others.
The system hang can be reproduced by gesturing the video on the YouTube
Android app on ChromeOS into full screen.
[How]
Reject atomic commits with non-zero drm_plane_state.src_x or src_y
Reviewed-by: James Zhu
Tested-by: James Zhu
James
On 2021-04-23 5:29 a.m., Christian König wrote:
Starting with Vega the hardware supports concurrent flushes
of VMID which can be used to implement per process VMID
allocation.
But concurrent flushes are mutual exclusive with back to
back VMID
Am 23.04.21 um 12:55 schrieb Roy Sun:
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgp
Reviewed-by: Christian König for the series.
Am 23.04.21 um 13:17 schrieb Nirmoy Das:
Exposed amdgpu_bo_create_shadow() will be needed
for amdgpu_vm handling.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3
Remove unused AMDGPU_GEM_CREATE_SHADOW flag.
Userspace is never allowed to use this.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
include/uapi/drm/amdgpu_drm.h | 2 --
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/dr
Remove shadow bo related code as vm code is creating shadow bo
using proper API. Without shadow bo code, amdgpu_bo_create() is basically
a wrapper around amdgpu_bo_do_create(). So rename amdgpu_bo_do_create()
to amdgpu_bo_create().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
Remove unused AMDGPU_VM_CONTEXT_GFX and AMDGPU_VM_CONTEXT_COMPUTE
flags.
Signed-off-by: Nirmoy Das
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/am
Shadow BOs are only needed for vm code so call amdgpu_bo_create_shadow()
directly instead of depending on amdgpu_bo_create().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 69 +-
1 file changed, 45 insertions(+), 24 deletions(-)
diff --git a/driv
Currently only way to create compute vm is through
amdgpu_vm_make_compute(). So vm_context isn't required
anymore for amdgpu_vm_init().
Signed-off-by: Nirmoy Das
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 16 +++---
Exposed amdgpu_bo_create_shadow() will be needed
for amdgpu_vm handling.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amd
[AMD Official Use Only - Internal Distribution Only]
From: amd-gfx on behalf of Roy Sun
Sent: Friday, April 23, 2021 6:55 PM
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Roy ; Nieto, David M
Subject: [PATCH 1/2] drm/scheduler: Change scheduled fence track
Upd
Update the timestamp of scheduled fence on HW
completion of the previous fences
This allow more accurate tracking of the fence
execution in HW
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 del
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 61 ++
driv
Am 23.04.21 um 11:19 schrieb Roy Sun:
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/am
On 4/23/21 9:55 AM, Christian König wrote:
Am 22.04.21 um 17:40 schrieb Nirmoy Das:
Shadow BOs are only needed for vm code so call amdgpu_bo_create_shadow()
directly instead of depending on amdgpu_bo_create().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 70 +++
Starting with Vega the hardware supports concurrent flushes
of VMID which can be used to implement per process VMID
allocation.
But concurrent flushes are mutual exclusive with back to
back VMID allocations, fix this to avoid a VMID used in
two ways at the same time.
v2: don't set ring to NULL
S
Tracking devices, process info and fence info using
/proc/pid/fdinfo
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c| 61 ++
driv
Update the timestamp of scheduled fence on HW
completion of the previous fences
This allow more accurate tracking of the fence
execution in HW
Signed-off-by: David M Nieto
Signed-off-by: Roy Sun
---
This is the patch that just return the memory size.
drivers/gpu/drm/scheduler/sched_main.c |
On Fri, Apr 23, 2021 at 04:30:10PM +0800, Su, Jinzhou (Joe) wrote:
> Add flags AMD_CG_SUPPORT_SDMA_LS for Vangogh.
> Start to open sdma ls from firmware version 70.
>
> Signed-off-by: Jinzhou Su
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/nv.c| 1 +
> drivers/gpu/drm/amd
Add flags AMD_CG_SUPPORT_SDMA_LS for Vangogh.
Start to open sdma ls from firmware version 70.
Signed-off-by: Jinzhou Su
---
drivers/gpu/drm/amd/amdgpu/nv.c| 1 +
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.
Am 22.04.21 um 17:40 schrieb Nirmoy Das:
Remove unused AMDGPU_GEM_CREATE_SHADOW flag.
Please add "Userspace as never allowed to use this." to the commit message.
Christian.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +
include/uapi/drm/amdgpu_drm.h
Am 22.04.21 um 17:40 schrieb Nirmoy Das:
Shadow BOs are only needed for vm code so call amdgpu_bo_create_shadow()
directly instead of depending on amdgpu_bo_create().
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 70 +-
1 file changed, 47 inse
Am 2021-04-22 um 9:33 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
>
> wrote:
>
> Do AQL queue double-mapping with a single attach call. That will make it
> easier to create per-GPU BOs later, to be shared between the
70 matches
Mail list logo
