Re: Ryzen 5 2400G Stuttering since 2018-03-07

Got it. Attachments next time. I started a git bisect but noticed there were updates pushed to the tree, so I built HEAD instead (d1eeebbd78fd185988c3c90e3dab304cc8b86c4e). The stuttering is now gone! -Dawson Dias On Fri, Mar 9, 2018 at 7:36 PM, Michel Dänzer wrote: > On

Re: [PATCH 4/5] drm/amdgpu/soc15: always load the psp module

Reviewed-by: Rex Zhu Best Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, March 10, 2018 4:25 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject:

Re: [PATCH 5/5] drm/amdgpu: move getting pcie info to common code

Reviewed-by: Rex Zhu Best Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, March 10, 2018 4:25 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject:

Re: [PATCH 3/5] drm/amdgpu: use adev->firmware to determine whether to load the PSP module

Reviewed-by: Rex Zhu Best Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, March 10, 2018 4:25 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject:

Re: [PATCH 1/5] drm/amdgpu/psp: add a few more fw load type checks

Reviewed-by: Rex Zhu Best Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, March 10, 2018 4:25 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject:

Re: [PATCH 2/5] drm/amdgpu: move firmware loading type setup to common code

Reviewed-by: Rex Zhu Best Regards Rex From: amd-gfx on behalf of Alex Deucher Sent: Saturday, March 10, 2018 4:25 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander Subject:

Re: [PATCH 1/5] drm/amdgpu/psp: add a few more fw load type checks

Am 09.03.2018 um 21:25 schrieb Alex Deucher: We already checked and returned early in most of the IP functions, fill in the rest as well. Signed-off-by: Alex Deucher Acked-by: Christian König for the series. ---

Re: [PATCH] drm/amdgpu/dce: Don't turn off DP sink when disconnected

On Fri, Mar 9, 2018 at 12:27 PM, Michel Dänzer wrote: > From: Michel Dänzer > > Turning off the sink in this case causes various issues, because > userspace expects it to stay on until it turns it off explicitly. > > Instead, turn the sink off and back

[PATCH 4/5] drm/amdgpu/soc15: always load the psp module

Regardless of whether the user has selected psp fw loading or not. It's still needed for GPU reset among other things. There are already guards in place to avoid setting up the full psp if PSP fw loading is not enabled. Signed-off-by: Alex Deucher ---

[PATCH 1/5] drm/amdgpu/psp: add a few more fw load type checks

We already checked and returned early in most of the IP functions, fill in the rest as well. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c

[PATCH 2/5] drm/amdgpu: move firmware loading type setup to common code

No need to replicate it in several places. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++ drivers/gpu/drm/amd/amdgpu/cik.c | 2 -- drivers/gpu/drm/amd/amdgpu/soc15.c | 2 -- drivers/gpu/drm/amd/amdgpu/vi.c

[PATCH 5/5] drm/amdgpu: move getting pcie info to common code

No need to replicate it in several places. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +- drivers/gpu/drm/amd/amdgpu/cik.c | 2 -- drivers/gpu/drm/amd/amdgpu/soc15.c

[PATCH 3/5] drm/amdgpu: use adev->firmware to determine whether to load the PSP module

The per device firmware load method is limited to what makes sense for that asic rather than whatever arbitrary value may have been set by the user. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/soc15.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/4] drm/ttm: keep a reference to transfer pipelined BOs

Make sure the transfered BO is never destroy before the transfer BO. Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++ 1 file changed, 30 insertions(+), 20 deletions(-) diff --git

[PATCH 3/4] drm/amdgpu: add independent DMA-buf export

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|

[PATCH 4/4] drm/amdgpu: add independent DMA-buf import

Instead of relying on the DRM functions just implement our own import functions. This adds support for taking care of unpinned DMA-buf. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 64 +--

RFC: unpinned DMA-buf exporting

This set of patches adds an option invalidate_mappings callback to each DMA-buf attachment which can be filled in by the importer. This callback allows the exporter to provided the DMA-buf content without pinning it. The reservation objects lock acts as synchronization point for buffer moves

[PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Each importer can now provide an invalidate_mappings callback. This allows the exporter to provide the mappings without the need to pin the backing store. Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 25 +

Re: [PATCH 2/2] drm/amdgpu/soc15: always load the psp IP module

That still leaves us with the issue that we need the PSP for the GPU reset independent if it is used for firmware loading or not. Additional to that the PSP is present in the hardware no matter if we use it or not. So I think we should always at least add it. Regards, Christian. Am

Re: [PATCH 2/2] drm/amdgpu/soc15: always load the psp IP module

>I also don't really like the fact that we use the module parameter directly >to determine whether to load the >PSP module or not, we should be using >adev->firmware.load_type, but that doesn't get set until later. we can move function amdgpu_ucode_get_load_type to

Re: [PATCH] drm/amdgpu: Move IH clientid defs to separate file

SOC15 refers to the SOC design we started with vega10. It differs from previous SOC design from previous asics. I think it was designed in ~2015, so SOC15. The soc15 name is fine with me. Alex From: amd-gfx on behalf

[PATCH] drm/amdgpu/dce: Don't turn off DP sink when disconnected

From: Michel Dänzer Turning off the sink in this case causes various issues, because userspace expects it to stay on until it turns it off explicitly. Instead, turn the sink off and back on when a display is connected again. This dance seems necessary for link training

Re: [PATCH 1/8] drm/amd/pp: Refine code for smu7 in powerplay

Nice cleanup. Patch is: Reviewed-by: Alex Deucher On Fri, Mar 9, 2018 at 5:55 AM, Zhu, Rex wrote: > Hi Alex, > > > The avfs btc state is only used in driver and not interact with HW. > > and we only need to know whether this feature is supported or

Re: [PATCH] drm/amdgpu: save/restore backlight level in legacy dce code

On 2018-03-09 03:44 AM, Michel Dänzer wrote: > On 2018-03-08 09:21 PM, Alex Deucher wrote: >> Save/restore the backlight level scratch register in S3/S4 so the >> backlight level comes back at the previously requested level. >> >> Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199047 >> Fixes:

Re: [PATCH 1/2] drm/amdgpu: fix prime teardown order

Am 09.03.2018 um 15:05 schrieb Michel Dänzer: On 2018-03-09 02:46 PM, Christian König wrote: We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Good catch! I guess that explains some oddities I sometimes saw with PRIME. Both patches

Re: Ryzen 5 2400G Stuttering since 2018-03-07

On 2018-03-09 12:30 PM, Dawson Dias wrote: > Hello > > I'm experiencing extreme stuttering in X on my Ryzen 2400G. This > stuttering can be noticed even while only moving the mouse. > Said stuttering does not exist under Wayland. > > This constant stuttering started on 2018-03-07 with the

[PATCH 2/2] drm/radeon: fix prime teardown order

We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Signed-off-by: Christian König CC: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_gem.c| 2 -- drivers/gpu/drm/radeon/radeon_object.c | 2 ++ 2

[PATCH 1/2] drm/amdgpu: fix prime teardown order

We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Signed-off-by: Christian König CC: sta...@vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |

[PATCH] drm/amd/pp: Move helper functions to smu_help.c

Change-Id: I4b1fe130631c67aedf8d9565a528edd087a4158c Signed-off-by: Rex Zhu --- drivers/gpu/drm/amd/powerplay/hwmgr/Makefile | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c | 509 - drivers/gpu/drm/amd/powerplay/hwmgr/smu_helper.c | 536

Ryzen 5 2400G Stuttering since 2018-03-07

Hello I'm experiencing extreme stuttering in X on my Ryzen 2400G. This stuttering can be noticed even while only moving the mouse. Said stuttering does not exist under Wayland. This constant stuttering started on 2018-03-07 with the patches that were pushed on that day. Stuttering occurs on both

Re: [PATCH] drm/amd/amdgpu: Add missing "DDR4" label

Am 09.03.2018 um 12:19 schrieb Tom St Denis: The commit d296278fd372003fc69588acfd0c0c5edbdf4874 added support for detecting DDR4 but omitted the label that is printed out in amdgpu_bo_init() resulting in a KASAN error. Signed-off-by: Tom St Denis Reviewed-by: Christian

[PATCH] drm/amd/amdgpu: Add missing "DDR4" label

The commit d296278fd372003fc69588acfd0c0c5edbdf4874 added support for detecting DDR4 but omitted the label that is printed out in amdgpu_bo_init() resulting in a KASAN error. Signed-off-by: Tom St Denis --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++- 1 file changed,

Re: [PATCH 1/8] drm/amd/pp: Refine code for smu7 in powerplay

Hi Alex, The avfs btc state is only used in driver and not interact with HW. and we only need to know whether this feature is supported or not by HW. so delete the complex define of avfs btc state and simplify related code. Please review the attached patch. Best Regards Rex

RE: deprecated register issues

Yeah, that’s what I am thinking as well, but we need to figure out how many registers are like this cc_rb_backend_disable, and put all of them in GIM to read the initial value The only limitation is those registers are read only (or only need to read once after GPU powered on) /Monk From:

Re: [PATCH] drm/amdgpu: save/restore backlight level in legacy dce code

On 2018-03-08 09:21 PM, Alex Deucher wrote: > Save/restore the backlight level scratch register in S3/S4 so the > backlight level comes back at the previously requested level. > > Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199047 > Fixes: 4ec6ecf48c64d (drm/amdgpu: drop scratch regs save