[PATCH] drm/amd/powerplay: hint and error out when prerequisite not meet

Do not ignore the error silently. Otherwise user may thought it was executed successfully. Change-Id: I4ac0cff5918d53d1d737f1c2fb1a4f81917dbf56 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c| 14 ++ drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 4 +++-

[PATCH] drm/amdgpu/sriov: For finishing routine send rel event after init failed

When init fail, sendsend rel init, req_fini and rel_fini to host for the finishing routine. Signed-off-by: Emily Deng --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git

Re: [PATCH] drm/amdkfd: Allow building KFD on ARM64

On Wed, Jan 2, 2019 at 5:26 PM Kuehling, Felix wrote: > > ifdef x86_64 specific code. > Allow enabling CONFIG_HSA_AMD on ARM64. > > CC: Mark Nutter > Signed-off-by: Felix Kuehling Acked-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdkfd/Kconfig| 4 ++-- >

[PATCH v3 15/16] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()

It occurred to me that we never actually check this! So let's start doing that. Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li --- drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++- 1 file changed, 7 insertions(+), 1

[PATCH v3 14/16] drm/dp_mst: Start tracking per-port VCPI allocations

There has been a TODO waiting for quite a long time in drm_dp_mst_topology.c: /* We cannot rely on port->vcpi.num_slots to update * topology_state->avail_slots as the port may not exist if the parent * branch device was unplugged. This should be fixed by tracking

[PATCH v3 16/16] drm/nouveau: Use atomic VCPI helpers for MST

Currently, nouveau uses the yolo method of setting up MST displays: it uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the display configuration. These helpers don't take care to make sure they take a reference to the mstb port that they're checking, and additionally don't

[PATCH v3 05/16] drm/dp_mst: Fix payload deallocation on hotplugs using malloc refs

Up until now, freeing payloads on remote MST hubs that just had ports removed has almost never worked because we've been relying on port validation in order to stop us from accessing ports that have already been freed from memory, but ports which need their payloads released due to being removed

[PATCH v3 06/16] drm/i915: Keep malloc references to MST ports

So that the ports stay around until we've destroyed the connectors, in order to ensure that we don't pass an invalid pointer to any MST helpers once we introduce the new MST VCPI helpers. Changes since v1: * Move drm_dp_mst_get_port_malloc() to where we assign intel_connector->port - danvet

[PATCH v3 01/16] drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends

s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/ s/drm_dp_put_port/drm_dp_mst_topology_put_port/ s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/ s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/ This is a much more consistent naming

[PATCH v3 09/16] drm/nouveau: Remove unnecessary VCPI checks in nv50_msto_cleanup()

There is no need to look at the port's VCPI allocation before calling drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let us avoid cleaning up an msto more then once. The DP MST core will never call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what these checks

[PATCH v3 00/16] MST refcounting/atomic helpers cleanup

This is the series I've been working on for a while now to get all of the atomic DRM drivers in the tree to use the atomic MST helpers, and to make the atomic MST helpers actually idempotent. Turns out it's a lot more difficult to do that without also fixing how port and branch device refcounting

[PATCH v3 10/16] drm/nouveau: Keep malloc references to MST ports

Now that we finally have a sane way to keep port allocations around, use it to fix the potential unchecked ->port accesses that nouveau makes by making sure we keep the mst port allocated for as long as it's drm_connector is accessible. Additionally, now that we've guaranteed that mstc->port is

[PATCH v3 11/16] drm/nouveau: Stop unsetting mstc->port, use malloc refs

Same as we did for i915, but for nouveau this time. Additionally, we grab a malloc reference to the port that lasts for the entire lifetime of nv50_mstc, which gives us the guarantee that mstc->port will always point to valid memory for as long as the mstc stays around. Signed-off-by: Lyude Paul

[PATCH v3 13/16] drm/dp_mst: Add some atomic state iterator macros

Changes since v6: - Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this commit - Document __drm_dp_mst_state_iter_get() and note that it shouldn't be called directly Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland

[PATCH v3 12/16] drm/nouveau: Grab payload lock in nv50_msto_payload()

Going through the currently programmed payloads isn't safe without holding mgr->payload_lock, so actually do that and warn if anyone tries calling nv50_msto_payload() in the future without grabbing the right locks. Signed-off-by: Lyude Paul Cc: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc:

[PATCH v3 08/16] drm/nouveau: Remove bogus cleanup in nv50_mstm_add_connector()

Trying to destroy the connector using mstc->connector.funcs->destroy() if connector initialization fails is wrong: there is no possible codepath in nv50_mstc_new where nv50_mstm_add_connector() would return <0 and mstc would be non-NULL. Signed-off-by: Lyude Paul Cc: Daniel Vetter Cc: David

[PATCH v3 07/16] drm/amdgpu/display: Keep malloc ref to MST port

Just like i915 and nouveau, it's a good idea for us to hold a malloc reference to the port here so that we never pass a freed pointer to any of the DP MST helper functions. Also, we stop unsetting aconnector->port in dm_dp_destroy_mst_connector(). There's literally no point to that assignment

[PATCH v3 04/16] drm/dp_mst: Stop releasing VCPI when removing ports from topology

This has never actually worked, and isn't needed anyway: the driver's always going to try to deallocate VCPI when it tears down the display that the VCPI belongs to. Signed-off-by: Lyude Paul Cc: Daniel Vetter Cc: David Airlie Cc: Jerry Zuo Cc: Harry Wentland Cc: Juston Li ---

[PATCH v3 03/16] drm/dp_mst: Restart last_connected_port_and_mstb() if topology ref fails

While this isn't a complete fix, this will improve the reliability of drm_dp_get_last_connected_port_and_mstb() pretty significantly during hotplug events, since there's a chance that the in-memory topology tree may not be fully updated when drm_dp_get_last_connected_port_and_mstb() is called and

[PATCH] drm/amdkfd: Allow building KFD on ARM64

ifdef x86_64 specific code. Allow enabling CONFIG_HSA_AMD on ARM64. CC: Mark Nutter Signed-off-by: Felix Kuehling --- drivers/gpu/drm/amd/amdkfd/Kconfig| 4 ++-- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 8 drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 8 +--- 3 files

Re: [PATCH] drm/amd/display: Set requested plane state DCC params for GFX9

On 2019-01-02 3:15 p.m., Nicholas Kazlauskas wrote: > [Why] > Hardware support for Delta Color Compression (DCC) decompression is > available in DC for GFX9 but there's no way for userspace to enable > the feature. > > Enabling the feature can provide improved GFX performance and > power savings

[PATCH] drm/amd/display: Set requested plane state DCC params for GFX9

[Why] Hardware support for Delta Color Compression (DCC) decompression is available in DC for GFX9 but there's no way for userspace to enable the feature. Enabling the feature can provide improved GFX performance and power savings in many situations. [How] The GFX9 DCC parameters are passed to

Re: [PATCH 3/3] drm/amdgpu: replace get_user_pages with HMM address mirror helpers v5

Hi Christian, May you help review the CS parts related changes? I tested it using libdrm Userptr Test under X. Do you know other test applications which can stress the CS userptr path? Thanks, Philip On 2018-12-14 4:25 p.m., Kuehling, Felix wrote: > Except for the GEM and CS parts, the series

Re: [PATCH 2/2] drm/amdgpu: set the executable flag on unused Vega10 PTEs

Series is: Acked-by: Alex Deucher From: amd-gfx on behalf of Christian König Sent: Wednesday, January 2, 2019 8:35:06 AM To: amd-gfx@lists.freedesktop.org Subject: [PATCH 2/2] drm/amdgpu: set the executable flag on unused Vega10 PTEs Otherwise we run into a

Re: [PATCH] drm/amdgpu: distinguish early and late re-init log in sriov

Acked-by: Alex Deucher From: amd-gfx on behalf of wentalou Sent: Wednesday, January 2, 2019 3:03:56 AM To: amd-gfx@lists.freedesktop.org Cc: Lou, Wentao Subject: [PATCH] drm/amdgpu: distinguish early and late re-init log in sriov distinguish

RE: [PATCH] drm/amdgpu: make gfx9 enter into rlc safe mode when set MGCG

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of likun Gao > Sent: Wednesday, January 02, 2019 4:57 PM > To: amd-gfx@lists.freedesktop.org > Cc: Gao, Likun > Subject: [PATCH] drm/amdgpu: make gfx9 enter into rlc safe mode when set > MGCG >

Re: [PATCH 1/3] drm/amdgpu: Relocate kgd2kfd function declaration

Am 14.12.18 um 16:22 schrieb Lin, Amber: Since amdkfd is merged into amdgpu module and amdgpu can access amdkfd directly, move declaration of kgd2kfd functions from kfd_priv.h to amdgpu_amdkfd.h Signed-off-by: Amber Lin Yes, please. If it's not committed yet Acked-by: Christian König for

[PATCH 2/2] drm/amdgpu: set the executable flag on unused Vega10 PTEs

Otherwise we run into a non-retry fault on access. It seems to be a hardware bug that the executable bit has higher priority than the valid bit. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff

[PATCH 1/2] drm/amdgpu: improve GMC v9 page fault message

Note if this is a retry fault or not and cleanup the message a bit. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c

RE: [PATCH 0/9] PSP cleanup

Yep, We are in progress to move IP specific code into common interfaces. For instance, psp_vXX_get_fw_type/psp_vXX_prep_cmd_buf should be common interfaces, instead of IP specific ones. We’ll see that soon. And I agree with you that we should stick with the existing naming style. And that’s

Re: Regression with kernel 4.20 on armhf

Hi Luis, mhm, sounds like a timing issue. We have probably made something faster during bootup in 4.20 and because of this you now see this issue more often. If the bisection doesn't show any result can you try adding some msleep(10) call at critical places in the driver code to narrow this

Re: [PATCH 0/9] PSP cleanup

I'd prefer to keep the old structures: common interfaces in amdgpu_psp.c/.h, and IP specific ones in IP specific file. That works for me as well. Key take away from the change overview is this: >   drivers/gpu/drm/amd/amdgpu/psp_v10_0.c  | 381 + >  

Re: [PATCH 0/9] PSP cleanup

I'd prefer to keep the old structures: common interfaces in amdgpu_psp.c/.h, and IP specific ones in IP specific file. No matter it's something related to ASD,TMR, or XGMI.etc, all of these are just communication/handshake jobs between driver and psp fw. Driver plays messenger role with

Re: [PATCH 0/9] PSP cleanup

The general idea looks good, but can we change the file and symbol naming a bit? So far we have named all non-ip version related functions amdgpu_* and ip related functions ip_version. E.g. following this xgmi functions should go into amdgpu_xgmi.c and not psp_xgmi.c Christian. Am

Re: [PATCH 1/2] drm/amdgpu/virtual_dce: No need to pin the fb's bo

Am 27.12.18 um 15:30 schrieb Michel Dänzer: On 2018-12-24 7:08 a.m., Emily Deng wrote: For virtual display, no need to pin the fb's bo. Signed-off-by: Emily Deng [...] diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c index

[PATCH 5/9] drm/amdgpu: separate the asd related APIs

As they are logic independently from other APIs of amdgpu_psp.c. Change-Id: If10aa695214f8df0744a67ee9eb0524d2c5a1ec1 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 62 +-

[PATCH 4/9] drm/amdgpu: separate the tmr related APIs

As they are logic independently from other APIs of amdgpu_psp.c. Change-Id: I3c8014caca8250bef6439e857bea1b64b6c1930a Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 60 +-

[PATCH 0/9] PSP cleanup

*** BLURB HERE *** Evan Quan (9): drm/amdgpu: separate the PSP ring related APIs drm/amdgpu: separate commonly used PSP APIs drm/amdgpu: separate the xgmi related APIs drm/amdgpu: separate the tmr related APIs drm/amdgpu: separate the asd related APIs drm/amdgpu: drop useless PSP APIs

[PATCH 1/9] drm/amdgpu: separate the PSP ring related APIs

So that they can be shared among different PSP generations. And there is no need to have one copy for each PSP generation. Change-Id: I7a97f410ef5993b25f0ec3cfac4a293073d697c3 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

[PATCH 2/9] drm/amdgpu: separate commonly used PSP APIs

So that they can be shared in PSP widely. Change-Id: Icec5d23db2c1f8241f6bdff371e6cde65ffdb101 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 36 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 16 --

[PATCH 3/9] drm/amdgpu: separate the xgmi related APIs

As they are logic independently from other APIs of amdgpu_psp.c. Change-Id: Idb9d81e15ad4d37e93b95682a07194a94c4849d6 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/Makefile | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 182 +

[PATCH 6/9] drm/amdgpu: drop useless PSP APIs and structures

Drop those useless APIs and structures. Change-Id: I1350c0e7ec0b990a1178a0ce92f61e56dc8851b5 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 66 + drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 5 -- 2 files changed, 22 insertions(+), 49 deletions(-)

[PATCH 7/9] drm/amdgpu: check PSP support before adding the ip block

So that we do not need to check this in every internal function. Change-Id: I5f2665cf60a57b6ae8d04a645f633daf377ae28c Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 24 drivers/gpu/drm/amd/amdgpu/soc15.c | 13 - 2 files changed,

[PATCH 8/9] drm/amdgpu: make PSP sub modules(ASD/XGMI/TMR) support configurable

As not every generation can support all these PSP sub modules. Change-Id: I866884e6453a37ff844427eb2d6fd56a91058ebe Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 41 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 14 -