> SMU_11_0_ODFEATURE_COUNT= 14,
This seems a little weird.
Maybe it should be "SMU_11_0_ODFEATURE_COUNT = 1 << SMU_11_0_ODCAP_COUNT, "
With above confirmed, the patch series is reviewed-by: Evan Quan
>-Original Message-
>From: amd-gfx On Behalf Of Alex
>Deucher
On Thu, Jan 16, 2020 at 11:15 PM Alex Deucher wrote:
> It's just papering over the problem. It would be better from a power
> perspective for the driver to just not suspend and keep running like
> normal. When the driver is not suspended runtime things like clock
> and power gating are active
So far the kfd driver implemented same routines for runtime and system
wide suspend and resume (s2idle or mem). During system wide suspend the
kfd aquires an atomic lock that prevents any more user processes to
create queues and interact with kfd driver and amd gpu. This mechanism
created problem
amdgpu_device_suspend might return an error code since it can be called
from both runtime and system suspend flows. Add the missing return code
in case of a failure.
Reviewed-by: Oak Zeng
Reviewed-by: Felix Kuehling
Reviewed-by: Alex Deucher
Signed-off-by: Rajneesh Bhardwaj
---
Changes in v3:
* Addressed review comments.
* Rebased to latest amd-staging-drm-next.
* Slightly modified patch 4 to avoid runpm on devices where baco is not
yet fully supported for runtime pm but still is used for gpu reset.
Changes in v2:
* Rebased on latest amd-staging-drm-next
*
During system suspend the kfd driver aquires a lock that prohibits
further kfd actions unless the gpu is resumed. This adds some info which
can be useful while debugging.
Reviewed-by: Oak Zeng
Reviewed-by: Felix Kuehling
Signed-off-by: Rajneesh Bhardwaj
---
From: Alex Deucher
Seems to work reliably on VI+ except for a few so enable runpm barring
those where baco for runtime power management is not supported.
[rajneesh] Picked https://patchwork.freedesktop.org/patch/335402/ to
enable runtime pm with baco for kfd. Also fixed a checkpatch warning and
From: Wenjing Liu
[why]
HDCP DTM needs to be aware of the upto date display topology
information in order to validate hardware consistency.
[how]
update HDCP DTM on update_stream_config call.
Signed-off-by: Wenjing Liu
Reviewed-by: Jun Lei
---
.../gpu/drm/amd/display/modules/hdcp/hdcp.c |
-msg_in is not needed for enabling encryption.
-Use hdcp2_set_encryption instead of hdcp1_enable_encryption for hdcp2.2
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/modules/hdcp/hdcp_psp.c | 7 +--
1 file changed, 1 insertion(+), 6
Summary of changes
*handle revoked receivers
*don't retry if revoked
*fix rx_caps check typo
*fix enable encryption call to psp for 2.2
*update DTM right after HW programming
Bhawanpreet Lakha (3):
drm/amd/display: Handle revoked receivers
drm/amd/display: fix backwards byte order in
[Why]
PSP added a new return code for revoked receivers (SRM). We need to
handle that so we don't retry hdcp
This is already being handled on windows
[How]
Add the enums to psp interface header and handle them.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Nicholas Kazlauskas
---
We were using incorrect byte order after we started using the drm_defines
So fix it.
Fixes: 02837a91ae75 ("drm/amd/display: add and use defines from drm_hdcp.h")
Signed-off-by: JinZe.Xu
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Wenjing Liu
---
From: Wenjing Liu
[why]
According to the specs when bksv or ksv list fails SRM check,
HDCP TX should abort hdcp immediately.
However with the current code HDCP will be reattampt upto 4 times.
[how]
Add the logic that stop HDCP retry if bksv or ksv list
is revoked.
Signed-off-by: Wenjing Liu
[AMD Official Use Only - Approved for External Use]
Thanks for pointing that out Felix. I'll append that as well to the comments
for the commit.
Jon
-Original Message-
From: Kuehling, Felix
Sent: Thursday, February 6, 2020 3:08 PM
To: Kim, Jonathan ; amd-gfx@lists.freedesktop.org
On 2020-02-06 12:08, Jonathan Kim wrote:
hwc->conf was designated specifically for AMD APU IOMMU purposes. This
could cause problems in performance and/or function since APU IOMMU
implementation is elsewhere.
It's actually worse than that. hwc is a union of anonymous structures.
hwc->conf
On Thu, Feb 6, 2020 at 3:00 PM Samir Dhume wrote:
>
> Ported from Vega10. SDMA stress tests sometimes see IRQ lost.
>
> Signed-off-by: Samir Dhume
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 36 ++
> 1 file changed, 36 insertions(+)
>
>
Ported from Vega10. SDMA stress tests sometimes see IRQ lost.
Signed-off-by: Samir Dhume
---
drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 36 ++
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
b/drivers/gpu/drm/amd/amdgpu/navi10_ih.c
Update to the latest changes.
Signed-off-by: Alex Deucher
---
.../drm/amd/powerplay/inc/smu_v11_0_pptable.h | 46 +--
1 file changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/inc/smu_v11_0_pptable.h
Rather than the FEATURE_ID flags. Avoids a possible reading past
the end of the array.
Reported-by: Aleksandr Mezin
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
On Thu, Feb 6, 2020 at 2:21 PM Daniel Kolesa wrote:
>
> On PowerPC, the compiler will tag object files with whether they
> use hard or soft float FP ABI and whether they use 64 or 128-bit
> long double ABI. On systems with 64-bit long double ABI, a tag
> will get emitted whenever a double is
On PowerPC, the compiler will tag object files with whether they
use hard or soft float FP ABI and whether they use 64 or 128-bit
long double ABI. On systems with 64-bit long double ABI, a tag
will get emitted whenever a double is used, as on those systems
a long double is the same as a double.
On 2/5/20 8:09 PM, Stephen Rothwell wrote:
> Hi all,
>
> Please do not add any v5.7 material to your linux-next included
> branches until after v5.6-rc1 has been released.
>
> Changes since 20200205:
>
on i386:
ERROR: "dtn_debugfs_init" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Full
On Thu, Feb 6, 2020 at 1:00 PM Tawfik, Aly wrote:
>
>
> ***Reattached patch with corrections***
>
> From b828a2b3df3057461dfceb4d1394fe858ced9d03 Mon Sep 17 00:00:00 2001
> From: Ali-Tawfik
> Date: Thu, 6 Feb 2020 12:53:02 -0500
> Subject: [PATCH] drm/amdgpu: [DALI] Dali Variant Detection
>
>
***Reattached patch with corrections***
From b828a2b3df3057461dfceb4d1394fe858ced9d03 Mon Sep 17 00:00:00 2001
From: Ali-Tawfik
Date: Thu, 6 Feb 2020 12:53:02 -0500
Subject: [PATCH] drm/amdgpu: [DALI] Dali Variant Detection
Problem Description:
Currently we are checking internal fused rev id
hwc->conf was designated specifically for AMD APU IOMMU purposes. This
could cause problems in performance and/or function since APU IOMMU
implementation is elsewhere.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c | 15 ---
1 file changed, 8 insertions(+),
On 2020-02-06 11:54 a.m., Bhawanpreet Lakha wrote:
From: Harry Wentland
[Why]
Hubp needs to know whether a buffer is being scanned out from the trusted
memory zone or not.
[How]
Check for the TMZ flag on the amdgpu_bo and set the tmz_surface flag in
dc_plane_address accordingly.
From: Harry Wentland
[Why]
Hubp needs to know whether a buffer is being scanned out from the trusted
memory zone or not.
[How]
Check for the TMZ flag on the amdgpu_bo and set the tmz_surface flag in
dc_plane_address accordingly.
Signed-off-by: Harry Wentland
Signed-off-by: Bhawanpreet Lakha
On 2/6/20 9:51 AM, Christian König wrote:
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers,
On 2020-02-06 9:30, Christian König wrote:
Make use of the better performance here as well.
This patch is only compile tested!
v2: fix calculation bug pointed out by Felix
Signed-off-by: Christian König
Acked-by: Jonathan Kim
The series is
Reviewed-by: Felix Kuehling
---
[AMD Official Use Only - Internal Distribution Only]
Hi Alex,
I am trying to understand why prevent runtime pm when xgmi is active. Is it
because other device's accessing suspended device's HBM? Here is my
understanding: after device is suspend, the DF and HBM will still be alive. So
as long
Am 06.02.20 um 15:49 schrieb Alex Deucher:
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as
On Thu, Feb 6, 2020 at 6:50 AM Christian König
wrote:
>
> Am 06.02.20 um 12:10 schrieb Lucas Stach:
> > Hi all,
> >
> > On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> >> Hi Andrey,
> >>
> >> This commit breaks all drivers, which may bail out of the timeout
> >> processing as they wish to
Make use of the better performance here as well.
This patch is only compile tested!
v2: fix calculation bug pointed out by Felix
Signed-off-by: Christian König
Acked-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 38 +++--
1 file changed, 23 insertions(+),
Only write the _HI register when necessary.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Acked-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git
This should speed up debugging VRAM access a lot.
v2: add HDP flush/invalidate
Signed-off-by: Christian König
Acked-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 ++
1 file changed, 26 insertions(+)
diff --git
This speeds up the access quite a bit from 2.2 MB/s to
2.9 MB/s on 32bit and 12,8 MB/s on 64bit.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Acked-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 27 ++---
1 file changed, 11 insertions(+), 16
On Tue, Feb 4, 2020 at 11:46 PM Alex Deucher wrote:
>
> On Tue, Feb 4, 2020 at 4:28 PM Felix Kuehling wrote:
> >
> > On 2020-01-31 10:37 p.m., Rajneesh Bhardwaj wrote:
> > > So far the kfd driver implemented same routines for runtime and system
> > > wide suspend and resume (s2idle or mem).
On Thu, Feb 6, 2020 at 3:19 AM Evan Quan wrote:
>
> SMU FW will handle the features disablement for baco reset
> on Arcturus.
>
> Change-Id: Ifd87a09de2fca0c67c041afbd5e711973769119a
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 53 +-
> 1
navi10_od_feature_is_supported() function uses enum values as array index. But
the enum values are defined like bit flags.
Starting from SMU_11_0_ODFEATURE_FAN_SPEED_MIN the function would read past the
end of 'cap' array.
I've been unable to find any uses of this enum except in the
Am 06.02.20 um 12:10 schrieb Lucas Stach:
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
Hi Andrey,
This commit breaks all drivers, which may bail out of the timeout
processing as they wish to extend the timeout (etnaviv, v3d).
Those drivers currently just return from the
Hi all,
On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote:
> Hi Andrey,
>
> This commit breaks all drivers, which may bail out of the timeout
> processing as they wish to extend the timeout (etnaviv, v3d).
>
> Those drivers currently just return from the timeout handler before
> calling
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Quan, Evan
Sent: Thursday, February 6, 2020 16:19
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: handle
SMU FW will handle the features disablement for baco reset
on Arcturus.
Change-Id: Ifd87a09de2fca0c67c041afbd5e711973769119a
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 53 +-
1 file changed, 42 insertions(+), 11 deletions(-)
diff --git
43 matches
Mail list logo
