[PATCH] drm/amdgpu: modify system reference clock source for navi+

Starting from Navi+, the rlc reference clock is used for system clock from vbios gfx_info table. It is incorrect to use core_refclk_10khz of vbios smu_info table as system clock. Signed-off-by: Aaron Liu --- drivers/gpu/drm/amd/amdgpu/amdgpu_atomfirmware.c | 15 +++ 1 file changed, 1

RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[Public] Hi all, Then the struct looks like: > +struct drm_amdgpu_info_vbios { > + __u8 name[64]; > + __u8 vbios_pn[64]; > + __u32 version; > + __u8 vbios_ver_str[32]; > + __u8 date[32]; > +}; Sample output: vbios name : NAVI12 A0 XT D30501 8GB EVAL 1150e/334m HYN/SAM vbios

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[Public] Yes, let's remove that too, Thanks, David From: Gu, JiaWei (Will) Sent: Monday, May 17, 2021 8:07 PM To: Nieto, David M ; Koenig, Christian ; amd-gfx@lists.freedesktop.org ; mar...@gmail.com ; Deucher, Alexander Cc: Deng, Emily Subject: RE: [PATCH]

[PATCH 2/3] drm/amdgpu/pm: add new fields for Navi1x

Fill voltage fields in metrics table Signed-off-by: David M Nieto --- .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 62 ++- 1 file changed, 45 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi

[PATCH 3/3] drm/amdgpu/pm: display vcn pp dpm

Enable displaying DPM levels for VCN clocks in swsmu supported ASICs Signed-off-by: David M Nieto --- .../gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 46 ++ .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 4 ++ .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 8 .../gpu/drm

[PATCH 1/3] drm/amdgpu/pm: Update metrics table

expand metrics table with voltages and frequency ranges Signed-off-by: David M Nieto --- .../gpu/drm/amd/include/kgd_pp_interface.h| 69 +++ drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c| 3 + 2 files changed, 72 insertions(+) diff --git a/drivers/gpu/drm/amd/include/kgd_p

RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[AMD Official Use Only - Internal Distribution Only] OK let's remove serial. dbdf comes from this: vbios_info.dbdf = PCI_DEVID(adev->pdev->bus->number, adev->pdev->devfn); I think we can remove dbdf as well. Best regards, Jiawei From: Nieto, David M Sent: Tuesday, May 18, 2021 10:45 AM To: Gu

[PATCH] drm/amdgpu: Fix a use-after-free

looks like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b7b4b: [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.862186] CPU: 5 PID: 25180 Comm: kfdtest Tainted: GW 5.11.0+ #114 [ 1235.870633]

RE: [PATCH] drm/amd/pm: correct MGpuFanBoost setting

[AMD Official Use Only] Reviewed-by: Kenneth Feng -Original Message- From: Quan, Evan Sent: Tuesday, May 18, 2021 10:05 AM To: amd-gfx@lists.freedesktop.org Cc: Deucher, Alexander ; Feng, Kenneth ; Quan, Evan Subject: [PATCH] drm/amd/pm: correct MGpuFanBoost setting No MGpuFanBoost

RE: [PATCH 1/2] drm/amdgpu: update gc golden setting for Navi12

[AMD Official Use Only] Series are Reviewed-by: Kenneth Feng -Original Message- From: Chen, Guchun Sent: Tuesday, May 18, 2021 10:01 AM To: amd-gfx@lists.freedesktop.org; Deucher, Alexander ; Zhang, Hawking ; Feng, Kenneth ; Chen, Jiansong (Simon) ; Xiao, Jack ; Quan, Evan Cc: Che

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[AMD Official Use Only - Internal Distribution Only] The serial number is ASIC information, not VBIOS information, and it is still available as a sysfs node... I don't think we should put it there. Not sure what dbdf stands for. From: Gu, JiaWei (Will) Sent: Mon

RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[AMD Official Use Only - Internal Distribution Only] So I guess the dbdf is also needed to be removed? And how about serial? > +struct drm_amdgpu_info_vbios { > + __u8 name[64]; > + __u32 dbdf; // do we need this? > + __u8 vbios_pn[64]; > + __u32 version; > + __u8 vbios_ver_st

[PATCH] drm/amd/pm: correct MGpuFanBoost setting

No MGpuFanBoost setting for those ASICs which do not support it. Otherwise, it may breaks their fan control feature. Change-Id: Ifa9c87ac537a07937a0f0f6a670f21368eb29218 Signed-off-by: Evan Quan --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c| 9 + .../gpu/drm/amd/pm/swsmu/s

[PATCH 2/2] drm/amdgpu: update sdma golden setting for Navi12

Current golden setting is out of date. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c index 04c68a79eca4..75d7310f8439 100644 --- a/driv

[PATCH 1/2] drm/amdgpu: update gc golden setting for Navi12

Current golden setting is out of date. Signed-off-by: Guchun Chen --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c index 2a3427e5020f..7edd0c0eed8e

[PATCH] drm/amdgpu: add cancel_delayed_work_sync before power gate

Add cancel_delayed_work_sync before set power gating state to avoid race condition issue when power gating. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v

Re: [PATCH] drm/amdgpu: Expose rfc4122 compliant UUID

[AMD Official Use Only] It is for unique identification of the GPU in system management applications, the 64 bit asic number is only available in Vega10 and later and not compliant with RFC4122. David From: Christian König Sent: Sunday, May 16, 2021 11:52 PM To

Re: [PATCH 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

On 2021-05-17 3:43 p.m., Christian König wrote: Am 17.05.21 um 16:57 schrieb James Zhu: During vcn suspends, stop ring continue to receive new requests, and try to wait for all vcn jobs to finish gracefully. Signed-off-by: James Zhu ---   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 20 +

Re: [PATCH 2/2] drm/amdgpu/pm: add new fields for Navi1x

[AMD Public Use] I dont think the pp_nodes expose the vclk dclk nodes, but it might be better to rework this patch to expose those instead, and just add the voltages... From: Lazar, Lijo Sent: Sunday, May 16, 2021 11:28 PM To: Nieto, David M ; amd-gfx@lists.freed

Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.

Ok, then putting that on my TODO list for tomorrow. I've already found a problem with how we finish of fences, going to write more on this tomorrow. Christian. Am 17.05.21 um 21:46 schrieb Andrey Grodzovsky: Yep, you can take a look. Andrey On 2021-05-17 3:39 p.m., Christian König wrote:

Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.

Yep, you can take a look. Andrey On 2021-05-17 3:39 p.m., Christian König wrote: You need to note who you are pinging here. I'm still assuming you wait for feedback from Daniel. Or should I take a look? Christian. Am 17.05.21 um 16:40 schrieb Andrey Grodzovsky: Ping Andrey On 2021-05-14

Re: [PATCH 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

Am 17.05.21 um 16:57 schrieb James Zhu: During vcn suspends, stop ring continue to receive new requests, and try to wait for all vcn jobs to finish gracefully. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 20 +++- 1 file changed, 19 insertions(+), 1

Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.

You need to note who you are pinging here. I'm still assuming you wait for feedback from Daniel. Or should I take a look? Christian. Am 17.05.21 um 16:40 schrieb Andrey Grodzovsky: Ping Andrey On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote: Ping Andrey On 2021-05-12 10:26 a.m., Andre

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On 2021-05-17 12:48 p.m., Sebastian Wick wrote: On 2021-05-17 10:57, Pekka Paalanen wrote: On Fri, 14 May 2021 17:05:11 -0400 Harry Wentland wrote: On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > On Mon, 26 Apr 2021 13:38:49 -0400 > Harry Wentland wrote: ... >> ## Mastering Luminances

[PATCH] drm/amdgpu: Unmap all MMIO mappings

Access to those must be prevented post pci_remove v6: Drop BOs list, unampping VRAM BAR is enough. v8: Add condition of xgmi.connected_to_cpu to MTTR handling and remove MTTR handling from the old place. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 26 ++

Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings

On 2021-05-17 2:56 p.m., Alex Deucher wrote: On Mon, May 17, 2021 at 2:46 PM Andrey Grodzovsky wrote: On 2021-05-17 1:43 p.m., Alex Deucher wrote: On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky wrote: Access to those must be prevented post pci_remove v6: Drop BOs list, unampping VRA

[PATCH 2/2] drm/amdgpu/display/dc: drop un used variables

Unused so remove them. Fixes: 5791d219561cb6 ("drm/amd/display: Refactor and add visual confirm for HW Flip Queue") Signed-off-by: Alex Deucher Cc: Wyatt Wood --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 1 - drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c| 1 - 2

[PATCH 1/2] drm/amdgpu/display: revert random whitespace changes

Commit 458ef68e972878 ("drm/amd/display: Add get_current_time interface to dmub_srv") introduced a bunch of random whitespace changes which lead to compiler warnings. Revert those changes to fix the warning and keep the code readable. No intended functional change. Fixes: 458ef68e972878 ("drm/a

Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings

On Mon, May 17, 2021 at 2:46 PM Andrey Grodzovsky wrote: > > > > On 2021-05-17 1:43 p.m., Alex Deucher wrote: > > On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky > > wrote: > >> > >> Access to those must be prevented post pci_remove > >> > >> v6: Drop BOs list, unampping VRAM BAR is enough. >

Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings

On 2021-05-17 1:43 p.m., Alex Deucher wrote: On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky wrote: Access to those must be prevented post pci_remove v6: Drop BOs list, unampping VRAM BAR is enough. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

To be accurate, the Bo is mapped to engine cache window, and the runtime of engine stacks, so we should save it before the poweroff. On 2021-05-17 2:15 p.m., Leo Liu wrote: The saved data are from the engine cache, it's the runtime of engine before suspend, it might be different after you ha

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

The saved data are from the engine cache, it's the runtime of engine before suspend, it might be different after you have the engine powered off. Regards, Leo On 2021-05-17 2:11 p.m., Zhu, James wrote: [AMD Official Use Only - Internal Distribution Only] save_bo needn't ungate vcn,  it

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

[AMD Official Use Only - Internal Distribution Only] save_bo needn't ungate vcn, it just keeps data in memory. Thanks & Best Regards! James Zhu From: Liu, Leo Sent: Monday, May 17, 2021 2:07 PM To: Zhu, James ; Zhu, James ; amd-gfx@lists.freedesktop.org Su

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

Definitely, we need to move cancel_delayed_work_sync moved to before power gate. Should "save_bo" be step 4 before power gate ? Regards, Leo On 2021-05-17 1:59 p.m., James Zhu wrote: Then we forgot the proposal I provided before. I think the below seq may fixed the race condition issue th

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

Then we forgot the proposal I provided before. I think the below seq may fixed the race condition issue that we are facing. 1. stop scheduling new jobs     for (i = 0; i < adev->vcn.num_vcn_inst; ++i) {         if (adev->vcn.harvest_config & (1 << i))             continue;         ring = &adev

Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings

On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky wrote: > > Access to those must be prevented post pci_remove > > v6: Drop BOs list, unampping VRAM BAR is enough. > > Signed-off-by: Andrey Grodzovsky > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 24 +++--- > drivers/gpu/

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

On 2021-05-17 12:54 p.m., James Zhu wrote: I am wondering if there are still some jobs kept in the queue, it is lucky to check Yes it's possible, in this case delayed handler is set, so cancelling once is enough. UVD_POWER_STATUS done, but after, fw start a new job that list in the queu

Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.

Reviewed-by: Alex Deucher On Mon, May 17, 2021 at 10:40 AM Andrey Grodzovsky wrote: > > Ping > > Andrey > > On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote: > > Ping > > > > Andrey > > > > On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote: > >> If removing while commands in flight you cannot w

Re: [PATCH 1/2] drm/amdgpu/display: add helper functions to get/set backlight (v2)

Ping on this series. Alex On Tue, May 11, 2021 at 11:44 AM Alex Deucher wrote: > > And cache the value. These can be used by the backlight callbacks > and modesetting functions. > > v2: rebase on latest backlight changes. > > Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1337 > Signed-of

Re: [RFC PATCH v2 1/6] drm/doc: Color Management and HDR10 RFC

On 2021-05-14 23:07, Harry Wentland wrote: Use the new DRM RFC doc section to capture the RFC previously only described in the cover letter at https://patchwork.freedesktop.org/series/89506/ Update the RFC based on feedback received: * don't use color_encoding property to define color space *

Re: [PATCH] drm/amd/amdgpu: fix refcount leak

On Mon, May 17, 2021 at 4:47 AM Christian König wrote: > > Am 17.05.21 um 10:26 schrieb Jingwen Chen: > > [Why] > > the gem object rfb->base.obj[0] is get according to num_planes > > in amdgpufb_create, but is not put according to num_planes > > > > [How] > > put rfb->base.obj[0] in amdgpu_fbdev_d

Re: [trivial PATCH] drm/amd/display: Fix typo of format termination newline

On Sat, May 15, 2021 at 1:01 PM Joe Perches wrote: > > /n should be \n > > Signed-off-by: Joe Perches Applied. Thanks! Alex > --- > drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +- > drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +- > drivers/gpu/drm/amd/display/

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On 2021-05-17 10:57, Pekka Paalanen wrote: On Fri, 14 May 2021 17:05:11 -0400 Harry Wentland wrote: On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > On Mon, 26 Apr 2021 13:38:49 -0400 > Harry Wentland wrote: ... >> ## Mastering Luminances >> >> Now we are able to use the PQ 2084 EOTF to

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

I am wondering if there are still some jobs kept in the queue, it is lucky to check UVD_POWER_STATUS done, but after, fw start a new job that list in the queue. To handle this situation perfectly, we need add mechanism to suspend fw first. Another case, if it is unlucky, that  vcn fw hung at

Re: [PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

On 2021-05-17 11:52 a.m., James Zhu wrote: During vcn suspends, stop ring continue to receive new requests, and try to wait for all vcn jobs to finish gracefully. v2: Forced powering gate vcn hardware after few wainting retry. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_v

[PATCH v2 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

During vcn suspends, stop ring continue to receive new requests, and try to wait for all vcn jobs to finish gracefully. v2: Forced powering gate vcn hardware after few wainting retry. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 22 +- 1 file change

[PATCH 2/2] drm/amdgpu: remove unsued vcn_v3_0_hw_fini

Removed unsued vcn_v3_0_hw_fini when enhanced common amdgpu_vicn_suspend is applied. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c b/drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c index cf16

[PATCH 1/2] drm/amdgpu: enhance amdgpu_vcn_suspend

During vcn suspends, stop ring continue to receive new requests, and try to wait for all vcn jobs to finish gracefully. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 20 +++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/am

RE: [PATCH v5 01/10] drm/amdgpu: Indirect register access for Navi12 sriov

[AMD Official Use Only - Internal Distribution Only] Hi Alex About your comment: "I think patches 1-4, 16 need to be squashed together to avoid breaking the build. Please also provide a description of how the new macros work in the patch description. Describe how the reworked macros properly h

Re: [PATCH] drm/amdgpu: Handle IOMMU enabled case.

Am 2021-05-17 um 10:38 a.m. schrieb Andrey Grodzovsky: > Problem: > Handle all DMA IOMMU group related dependencies before the > group is removed. Those manifest themself in that when IOMMU > enabled DMA map/unmap is dependent on the presence of IOMMU > group the device belongs to but, this group i

Re: [PATCH v7 16/16] drm/amdgpu: Unmap all MMIO mappings

Ping Andrey On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote: Ping Andrey On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote: Access to those must be prevented post pci_remove v6: Drop BOs list, unampping VRAM BAR is enough. Signed-off-by: Andrey Grodzovsky ---   drivers/gpu/drm/amd/amdgp

Re: [PATCH v7 12/16] drm/amdgpu: Fix hang on device removal.

Ping Andrey On 2021-05-14 10:42 a.m., Andrey Grodzovsky wrote: Ping Andrey On 2021-05-12 10:26 a.m., Andrey Grodzovsky wrote: If removing while commands in flight you cannot wait to flush the HW fences on a ring since the device is gone. Signed-off-by: Andrey Grodzovsky ---   drivers/gpu/d

[PATCH] drm/amdgpu: Handle IOMMU enabled case.

Problem: Handle all DMA IOMMU group related dependencies before the group is removed. Those manifest themself in that when IOMMU enabled DMA map/unmap is dependent on the presence of IOMMU group the device belongs to but, this group is released once the device is removed from PCI topology. Fix: Ex

Re: [PATCH 1/3] drm/amdkfd: classify and map mixed svm range pages in GPU

Am 2021-05-17 um 9:44 a.m. schrieb Felix Kuehling: > A few more comments inline. Sorry I took so long. > > Am 2021-05-12 um 1:34 p.m. schrieb Alex Sierra: > >> [Why] >> svm ranges can have mixed pages from device or system memory. >> A good example is, after a prange has been allocated in VRAM and

[PATCH v5 09/10] drm/amdgpu: Use PSP to program IH_RB_CNTL* registers

use psp to program IH_RB_CNTL* if indirect access for ih enabled in SRIOV environment. Signed-off-by: Victor Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/navi10_ih.c | 19 +-- drivers/gpu/drm/amd/amdgpu/nv.c| 2 +- 2 files changed, 18 insertions(+), 3 dele

[PATCH v5 10/10] drm/amdgpu: Skip the program of MMMC_VM_AGP_* in SRIOV

KMD should not program these registers, the value were defined in the host, so skip them in the SRIOV environment. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/mmh

[PATCH v5 08/10] drm/amdgpu: Modify MMHUB register access from MMIO to RLCG in file mmhub_v2*

From: pengzhou In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: pengzhou --- drivers/gpu/drm/amd/amdgpu/mmhub_v2_0.c | 37 + 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/

[PATCH v5 07/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file amdgpu_gmc.c

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 9 +++-- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 25 + 2 files changed, 24 insertions(+), 10

[PATCH v5 06/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file nv.c

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/nv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c

[PATCH v5 05/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file sdma_v5*

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 78 ++ 1 file changed, 42 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/sd

[PATCH v5 03/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file kfd_v10*

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 42 +-- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/am

[PATCH v5 04/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file soc15.c

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/soc15.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/a

[PATCH v5 01/10] drm/amdgpu: Indirect register access for Navi12 sriov

This patch series are used for GC/MMHUB(part)/IH_RB_CNTL indirect access in the SRIOV environment. There are 4 bits, controlled by host, to control if GC/MMHUB(part)/IH_RB_CNTL indirect access enabled. (one bit is master bit controls other 3 bits) For GC registers, changing all the register acces

[PATCH v5 02/10] drm/amdgpu: Modify GC register access from MMIO to RLCG in file gfx_v10*

In SRIOV environment, KMD should access GC registers with RLCG if GC indirect access flag enabled. Signed-off-by: Peng Ju Zhou --- drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 32 +- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gf

Re: [PATCH 3/3] drm/amdkfd: add invalid pages debug at vram migration

Am 2021-05-12 um 1:34 p.m. schrieb Alex Sierra: > This is for debug purposes only. > It conditionally generates partial migrations to test mixed > CPU/GPU memory domain pages in a prange easily. > > Signed-off-by: Alex Sierra > --- > drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 14 ++

Re: New uAPI for color management proposal and feedback request

Am 12.05.21 um 14:06 schrieb Werner Sembach: > Hello, > > In addition to the existing "max bpc", and "Broadcast RGB/output_csc" drm > properties I propose 4 new properties: > "preferred pixel encoding", "active color depth", "active color range", and > "active pixel encoding" As an alternative/a

Re: [PATCH] ACPI: PM: s2idle: Add missing LPS0 functions for AMD

On Wed, May 5, 2021 at 3:21 PM Alex Deucher wrote: > > These are supposedly not required for AMD platforms, > but at least some HP laptops seem to require it to > properly turn off the keyboard backlight. > > Based on a patch from Marcin Bachry . > > Bug: https://gitlab.freedesktop.org/drm/amd/-/i

Re: [PATCH 2/3] drm/amdkfd: skip invalid pages during migrations

Am 2021-05-12 um 1:34 p.m. schrieb Alex Sierra: > Invalid pages can be the result of pages that have been migrated > already due to copy-on-write procedure or pages that were never > migrated to VRAM in first place. This is not an issue anymore, > as pranges now support mixed memory domains (CPU/GP

Re: [PATCH 1/3] drm/amdkfd: classify and map mixed svm range pages in GPU

A few more comments inline. Sorry I took so long. Am 2021-05-12 um 1:34 p.m. schrieb Alex Sierra: > [Why] > svm ranges can have mixed pages from device or system memory. > A good example is, after a prange has been allocated in VRAM and a > copy-on-write is triggered by a fork. This invalidates s

Re: [5.13-rc1][bug] often hangs for no reason

On Mon, May 17, 2021 at 03:27:23AM +0500, Mikhail Gavrilov wrote: > Hi folks. > 5.13-rc1 after 5.13-rc0 is a disaster because it hangs and hangs again > after reboot. > All hang's have in common is that they all happens in > smp_call_function_many_cond function (I compared all trace [1], [2], > [3]

[PATCH] drm/amdgpu: fix PM reference leak in amdgpu_debugfs_gfxoff_rea()

pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot Signed-off-by: Yu Kuai --- drivers/gpu/drm/amd/am

Re: [PATCH] drm/amdgpu: Add vbios info ioctl interface

I'm not very familiar with the technical background why we have the fields here once more. But of hand we should at least remove everything which is also available from the PCI information. E.g. dev_id, rev_id, sub_dev_id, sub_ved_id. Regards, Christian. Am 17.05.21 um 14:17 schrieb Gu, Jia

RE: [PATCH] drm/amdgpu: Add vbios info ioctl interface

[AMD Official Use Only - Internal Distribution Only] Hi all, Thanks Christian's suggestion. I reverted the previous patches and squash them into this single one. As this patch shows, the current uapi change looks like this: +struct drm_amdgpu_info_vbios { + __u8 name[64]; + __u32 db

[PATCH] drm/amdgpu: Add vbios info ioctl interface

Add AMDGPU_INFO_VBIOS_INFO subquery id for detailed vbios info. Provides a way for the user application to get the VBIOS information without having to parse the binary. It is useful for the user to be able to display in a simple way the VBIOS version in their system if they happen to encounter an

Re: [PATCH] drm/amdgpu: Revert vbios info ioctl patches

Am 17.05.21 um 13:38 schrieb Jiawei Gu: Revert "drm/amdgpu: Add vbios info ioctl interface" Revert "drm/amdgpu: Field type update in drm_amdgpu_info_vbios" This reverts commits: d75a789ace808b738081322f27dcb1abe5cc9aa9. 50c70d479041e2d8a6a22b2ee4d76cfea1327576. Reason for revert: Step back to u

[PATCH] drm/amdgpu: Revert vbios info ioctl patches

Revert "drm/amdgpu: Add vbios info ioctl interface" Revert "drm/amdgpu: Field type update in drm_amdgpu_info_vbios" This reverts commits: d75a789ace808b738081322f27dcb1abe5cc9aa9. 50c70d479041e2d8a6a22b2ee4d76cfea1327576. Reason for revert: Step back to update uapi in a single patch Signed-off-b

Re: [PATCH] drm/amd/amdgpu: fix a potential deadlock in gpu reset

Am 17.05.21 um 12:52 schrieb Lang Yu: When amdgpu_ib_ring_tests failed, the reset logic called amdgpu_device_ip_suspend twice, then deadlock occurred. Deadlock log: [ 805.655192] amdgpu :04:00.0: amdgpu: ib ring test failed (-110). [ 806.011571] [drm] Register(0) [mmUVD_POWER_STATUS] faile

[PATCH] drm/amd/amdgpu: fix a potential deadlock in gpu reset

When amdgpu_ib_ring_tests failed, the reset logic called amdgpu_device_ip_suspend twice, then deadlock occurred. Deadlock log: [ 805.655192] amdgpu :04:00.0: amdgpu: ib ring test failed (-110). [ 806.011571] [drm] Register(0) [mmUVD_POWER_STATUS] failed to reach value 0x0001 != 0x00

Re: [PATCH] drm/amdgpu: Add vbios version string

Hi Jiawei, yes agree and additional to that we need to go a step back here. First of all once uAPI headers are added you are not allowed to change them again. So this iterative approach where more and more fields to the structure is really a NO-GO. Instead please revert all patches already

RE: [PATCH] drm/amdgpu: Add vbios version string

[AMD Official Use Only - Internal Distribution Only] Hi all, I know the vbios ioctl discussion is not settled down yet. Please just regard this patch as a proposal to include vbios version string info into discussion. Best regards, Jiawei -Original Message- From: Jiawei Gu Sent: Mond

[PATCH] drm/amdgpu: Add vbios version string

Expose XXX.XXX.XXX.XXX.XX vbios version string in AMDGPU_INFO_VBIOS_INFO ioctl Signed-off-by: Jiawei Gu --- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 2 ++ drivers/gpu/drm/amd/amdgpu/atom.c | 16 drivers/gpu/drm/amd/amdgpu/atom.h | 1 + drivers/gpu/drm

Re: [PATCH v2 2/3] drm/amd/pm: Fix showing incorrect frequencies on aldebaran

[AMD Public Use] ok, it is fine for me, and some code blocks need to have a blank line to match kernel coding style. with that fixes, Series is Reviewed-by: Kevin Wang Best Regards, Kevin From: Lazar, Lijo Sent: Monday, May 17, 2021 5:04 PM To: Wang, Kevin(Yan

RE: [PATCH v2 2/3] drm/amd/pm: Fix showing incorrect frequencies on aldebaran

[AMD Public Use] Hi Kevin, This case is for determinism mode - there it uses the max frequency passed and min_clk is the default min clock. Thanks, Lijo From: Wang, Kevin(Yang) Sent: Monday, May 17, 2021 2:32 PM To: Lazar, Lijo ; amd-gfx@lists.freedesktop.org Cc: Zhang, Hawking ; Chen, Guchu

Re: [PATCH v2 2/3] drm/amd/pm: Fix showing incorrect frequencies on aldebaran

[AMD Public Use] Hi Lijo, + pstate_table->gfxclk_pstate.curr.min = min_clk; + pstate_table->gfxclk_pstate.curr.max = max; min_clk and max, it seems it is coding error, i

Re: [RFC PATCH 0/3] A drm_plane API to support HDR planes

On Fri, 14 May 2021 17:05:11 -0400 Harry Wentland wrote: > On 2021-04-27 10:50 a.m., Pekka Paalanen wrote: > > On Mon, 26 Apr 2021 13:38:49 -0400 > > Harry Wentland wrote: ... > >> ## Mastering Luminances > >> > >> Now we are able to use the PQ 2084 EOTF to define the luminance of > >> pixels

Re: [PATCH] drm/amd/amdgpu: fix refcount leak

Am 17.05.21 um 10:26 schrieb Jingwen Chen: [Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes [How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes Signed-off-by: Jingwen Chen Looks sane to me,

[PATCH v2 3/3] drm/amd/pm: Reset max GFX clock after disabling determinism

[AMD Public Use] When determinism mode is disabled on aldebaran, max GFX clock will be reset to default max frequency value. Signed-off-by: Lijo Lazar lijo.la...@amd.com --- drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 11 --- 1 file changed, 8 insertions

[PATCH v2 2/3] drm/amd/pm: Fix showing incorrect frequencies on aldebaran

[AMD Public Use] v1: Use the current and custom pstate frequencies to track the current and user-set min/max values in manual and determinism mode. Previously, only actual_* value was used to track the currrent and user requested value. The value will get reassigned whenever user requests a new va

[PATCH v2 1/3] drm/amd/pm: Add custom/current freq to pstates

[AMD Public Use] Add custom member for user requested custom frequency, level mask or min/max frequencies. Add curr member to keep track of the current active values. Signed-off-by: Lijo Lazar --- drivers/gpu/drm/amd/pm/inc/amdgpu_smu.h | 8 1 file changed, 8 insertions(+) diff --git

Re: [RFC PATCH 1/3] drm/color: Add RGB Color encodings

On Fri, 14 May 2021 17:04:51 -0400 Harry Wentland wrote: > On 2021-04-30 8:53 p.m., Sebastian Wick wrote: > > On 2021-04-26 20:56, Harry Wentland wrote: ... > >> Another reason I'm proposing to define the color space (and gamma) of > >> a plane is to make this explicit. Up until the color spa

[PATCH] drm/amd/amdgpu: fix refcount leak

[Why] the gem object rfb->base.obj[0] is get according to num_planes in amdgpufb_create, but is not put according to num_planes [How] put rfb->base.obj[0] in amdgpu_fbdev_destroy according to num_planes Signed-off-by: Jingwen Chen --- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 3 +++ 1 file chang

回复: [PATCH] drm/amdgpu: fix PM reference leak in amdgpu_debugfs_gfxoff_rea()

[AMD Official Use Only] thanks Kuai. But code below matches the other code block in this file. r = pm_runtime_get_sync(dev->dev); if (r < 0) { pm_runtime_put_autosuspend(dev->dev); return r; } 发件人: Y

RE: [PATCH] drm/amdgpu: disable 3DCGCG on picasso/raven1 to avoid compute hang

[AMD Official Use Only - Internal Distribution Only] Hi Ray and Alex, I have confirmed it can enable the additional compute queues with this patch: [ 41.823013] This is ring mec 1, pipe 0, queue 0, value 1 [ 41.823028] This is ring mec 1, pipe 1, queue 0, value 1 [ 41.823042] This is ring

[trivial PATCH] drm/amd/display: Fix typo of format termination newline

/n should be \n Signed-off-by: Joe Perches --- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn302/dcn302_resource.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --

Re: [PATCH] drm/amdgpu: optimize to drop preamble IB for old GPUs

Yes and exactly that is the total mess I was talking about :) The backend should be given clear orders which it act on. In other words "load_global_*", "load_ce_ram" etc... The middle layer in amdgpu_ib_schedule()  then decides based of the flags if the what orders the backend should execute.

RE: [PATCH] drm/amdgpu: optimize to drop preamble IB for old GPUs

[AMD Official Use Only] Does't the below code in gfx_v8_ring_emit_cntxcntl do almost the same thing as dropping the preamble ib. I cannot understand why bother to duplicate the optimization and cause a mess In the common code. /* set load_ce_ram if preamble presented */

Re: [PATCH] drm/amd/amdgpu: destroy pinned gem obj according to refcount

Am 17.05.21 um 09:11 schrieb Jingwen Chen: [Why] the fb gem object is get for 4 times when amdgpu_display_framebuffer_init, while this object is put for less than 4 times. This can lead to warning trace when unloading amdgpu [How] put gem object according to refcount in amdgpufb_destroy_pinned_o

[PATCH] drm/amd/amdgpu: destroy pinned gem obj according to refcount

[Why] the fb gem object is get for 4 times when amdgpu_display_framebuffer_init, while this object is put for less than 4 times. This can lead to warning trace when unloading amdgpu [How] put gem object according to refcount in amdgpufb_destroy_pinned_object Warning trace attached: [324584.505752