RE: [PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

You can put my RB. _ Monk Liu|GPU Virtualization Team |AMD -Original Message- From: Zhao, Jiange Sent: Wednesday, March 4, 2020 1:39 PM To: amd-gfx@lists.freedesktop.org Cc: Deng, Emily ; Liu, Monk ; Deucher, Alexander ; Zhao, Jiange Subject:

[PATCH] drm/amdgpu/sriov: Use VF-accessible register for gpu_clock_count

Navi12 VK CTS subtest timestamp.calibrated.dev_domain_test failed because mmRLC_CAPTURE_GPU_CLOCK_COUNT register cannot be written in VF due to security policy. Solution: use a VF-accessible timestamp register pair mmGOLDEN_TSC_COUNT_LOWER/UPPER for SRIOV case. v2: according to Deucher

[PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

SPM access the video memory according to SPM_VMID. It should be updated with the job's vmid right before the job is scheduled. SPM_VMID is a global resource Change-Id: Id3881908960398f87e7c95026a54ff83ff826700 Signed-off-by: Jacob He --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14

Re: [PATCH 2/4] PCI: Use ioremap, not phys_to_virt for platform rom

On Tuesday, March 3, 2020 9:38:27 AM EST Bjorn Helgaas wrote: > Cosmetics: > > s/ioremap/ioremap()/ (also in commit log) > s/phys_to_virt/phys_to_virt()/ (also in commit log) > s/pci_platform_rom/pci_platform_rom()/ (commit log) > s/rom/ROM/ > This changes the interface of pci_platform_rom()

RE: [PATCH 2/2] drm/amd/powerplay: map mclk to fclk for COMBINATIONAL_BYPASS case

Series is reviewed-by: Evan Quan -Original Message- From: Liang, Prike Sent: Wednesday, March 4, 2020 10:56 AM To: amd-gfx@lists.freedesktop.org Cc: Quan, Evan ; Huang, Ray ; Liang, Prike Subject: [PATCH 2/2] drm/amd/powerplay: map mclk to fclk for COMBINATIONAL_BYPASS case When

RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

Sorry for miss this. With the Alex's comment addressed, the patch is reviewed-by: Evan Quan -Original Message- From: Wu, Hersen Sent: Tuesday, March 3, 2020 9:19 PM To: Alex Deucher Cc: Quan, Evan ; amd-gfx@lists.freedesktop.org; Feng, Kenneth Subject: RE: [PATCH 2/2]

[PATCH 2/2] drm/amd/powerplay: map mclk to fclk for COMBINATIONAL_BYPASS case

When hit COMBINATIONAL_BYPASS the mclk will be bypass and can export fclk frequency to user usage. Signed-off-by: Prike Liang --- drivers/gpu/drm/amd/powerplay/renoir_ppt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/powerplay/renoir_ppt.c

[PATCH 1/2] drm/amd/powerplay: fix pre-check condition for setting clock range

This fix will handle some MP1 FW issue like as mclk dpm table in renoir has a reverse dpm clock layout and a zero frequency dpm level as following case. cat pp_dpm_mclk 0: 1200Mhz 1: 1200Mhz 2: 800Mhz 3: 0Mhz Signed-off-by: Prike Liang --- drivers/gpu/drm/amd/powerplay/amdgpu_smu.c | 2 +-

[PATCH 01/12] drm/amd/display: update soc bb for nv14

From: Martin Leung [why] nv14 previously inherited soc bb from generic dcn 2, did not match watermark values according to memory team [how] add nv14 specific soc bb: copy nv2 generic that it was using from before, but changed num channels to 8 Signed-off-by: Martin Leung Reviewed-by: Jun Lei

[PATCH 11/12] drm/amd/display: separate FEC capability from fec debug flag

From: Wenjing Liu [why] FEC capability query should not be affected by debugging decision on whether to disable FEC. We should not determine if display supports FEC by checking debug option. Signed-off-by: Wenjing Liu Reviewed-by: Ashley Thomas Acked-by: Rodrigo Siqueira ---

[PATCH 03/12] drm/amd/display: determine is mst hdcp based on stream instead of sink signal

From: Wenjing Liu [why] It is possible even if sink signal is MST but driver enables SST stream. We should not determine if we should do MST authentication based on sink's capability. Instead we should determine whether to do MST authentication based on what we have enabled in stream.

[PATCH 09/12] drm/amd/display: Stop if retimer is not available

Raven provides retimer feature support that requires i2c interaction in order to make it work well, all settings required for this configuration are loaded from the Atom bios which include the i2c address. If the retimer feature is not available, we should abort the attempt to set this feature,

[PATCH 08/12] drm/amd/display: fix a minor HDCP logging error

From: Wenjing Liu [why] In HDCP Uninitialzed State, a CPIRQ event would cause log output internal policy error because the CPIRQ event is not recognized as unexpected event. [how] CPIRQ is issued in HDCP uninitialized state is unexpected. We should set unexpected event flag in event ctx.

[PATCH 10/12] drm/amd/display: writing stereo polarity register if swapped

From: Martin Leung [why] on some displays that prefer swapped polarity we were seeing L/R images swapped because OTG_STEREO_SYNC_OUTPUT_POLARITY would always be mapped to 0 [how] fix initial dal3 implementation to properly update the polarity field according to the crtc_stereo_flags (same as

[PATCH 12/12] drm/amd/display: 3.2.76

From: Aric Cyr Signed-off-by: Aric Cyr Reviewed-by: Aric Cyr Acked-by: Rodrigo Siqueira --- drivers/gpu/drm/amd/display/dc/dc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dc.h b/drivers/gpu/drm/amd/display/dc/dc.h index

[PATCH 06/12] drm/amd/display: Program DSC during timing programming

From: Nikola Cornij [why] Link or DIG BE can't be exposed to a higher stream bandwidth than they can handle. When DSC is required to fit the stream into the link bandwidth, DSC has to be programmed during timing programming to ensure this. Without it, intermittent issues such as black screen

[PATCH 05/12] drm/amd/display: Not check wm and clk change flag in optimized bandwidth.

From: Yongqiang Sun [Why] System isn't able to enter S0i3 due to not send display count 0 to smu. When dpms off, clk changed flag is cleared alreay, and it is checked when doing optimized bandwidth, and update clocks is bypassed due to the flag is unset. [How] Remove check flag incide the

[PATCH 07/12] drm/amd/display: determine rx id list bytes to read based on device count

From: Wenjing Liu [why] Some RX doesn't like us to read rx id list upto max rx id list size. As discussed, we decided to read rx id list based on device count. [how] According to HDCP specs the actual size of rx id list is calculated as rx id list size = 2+3+16+5*device_count. We will read 16

[PATCH 00/12] DC Patches March 03, 2020

This DC patchset brings improvements in multiple areas. In summary, we highlight: * Fix i2c_write issue * Fix HDCP issues * Update nv14 soc Aric Cyr (1): drm/amd/display: 3.2.76 Isabel Zhang (1): drm/amd/display: Add stay count and bstatus to HDCP log Martin Leung (2): drm/amd/display:

[PATCH 04/12] drm/amd/display: Add registry for mem pwr control

From: bradenbakker [What] Need debug options to control lightl/deep sleep [How] Add registry for memory power control Signed-off-by: Braden Bakker Reviewed-by: Charlene Liu Acked-by: Rodrigo Siqueira --- drivers/gpu/drm/amd/display/dc/dc.h | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 02/12] drm/amd/display: Add stay count and bstatus to HDCP log

From: Isabel Zhang [Why] So the values of stay count and bstatus can be easily viewed during debugging. [How] Add stay count and bstatus values to be outputted in HDCP log Signed-off-by: Isabel Zhang Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira ---

Re: [PATCH v3 2/3] drm/amdgpu: Add USBC PD FW load to PSP 11

On 2020-03-03 17:02, Andrey Grodzovsky wrote: > Add the programming sequence. > > v2: > Change donwload wait loop to more efficient. > Move C2PMSG_CMD_GFX_USB_PD_FW_VER defintion > > v3: Fix lack of loop counter increment typo > > Signed-off-by: Andrey Grodzovsky > --- >

Re: [PATCH 1/4] drm/amdgpu/vcn: fix race condition issue for vcn start

On 2020-03-03 2:03 p.m., James Zhu wrote: On 2020-03-03 1:44 p.m., Christian König wrote: Am 03.03.20 um 19:16 schrieb James Zhu: Fix race condition issue when multiple vcn starts are called. Signed-off-by: James Zhu ---   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4  

[PATCH v3 1/3] drm/amdgpu: Add USBC PD FW load interface to PSP.

Used to load power Delivery FW to PSP. Signed-off-by: Andrey Grodzovsky Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h index

[PATCH v3 2/3] drm/amdgpu: Add USBC PD FW load to PSP 11

Add the programming sequence. v2: Change donwload wait loop to more efficient. Move C2PMSG_CMD_GFX_USB_PD_FW_VER defintion v3: Fix lack of loop counter increment typo Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 3 ++ drivers/gpu/drm/amd/amdgpu/psp_v11_0.c

[PATCH v3 3/3] drm/amdgpu: Add support for USBC PD FW download

Starts USBC PD FW download and reads back the latest FW version. v2: Move sysfs file creation to late init Add locking around PSP calls to avoid concurrent access to PSP's C2P registers Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 110

[PATCH v3 0/3] Add support for USBC PD FW download

This patchset adds the kernel driver part of supporting USBC power delivery firmware downloading to USBC chip on the ASIC. The FW is placed in DMA buffer visible to PSP which then proceeds and copies the FW over I2C to the USBC chip. Andrey Grodzovsky (3): drm/amdgpu: Add USBC PD FW load

Re: [PATCH v2 0/3] Add support for USBC PD FW download

Please ignore this patchset as there is a typo error in second patch, will resend fixed V3 in a moment. Andrey On 3/3/20 4:54 PM, Andrey Grodzovsky wrote: This patchset adds the kernel driver part of supporting USBC power delivery firmware downloading to USBC chip on the ASIC. The FW is

[PATCH v2 3/3] drm/amdgpu: Add support for USBC PD FW download

Starts USBC PD FW download and reads back the latest FW version. v2: Move sysfs file creation to late init Add locking around PSP calls to avoid concurrent access to PSP's C2P registers Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 110

[PATCH v2 2/3] drm/amdgpu: Add USBC PD FW load to PSP 11

Add the programming sequence. v2: Change donwload wait loop to more efficient. Move C2PMSG_CMD_GFX_USB_PD_FW_VER defintion Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h | 3 ++ drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 82 + 2

[PATCH v2 0/3] Add support for USBC PD FW download

This patchset adds the kernel driver part of supporting USBC power delivery firmware downloading to USBC chip on the ASIC. The FW is placed in DMA buffer visible to PSP which then proceeds and copies the FW over I2C to the USBC chip. Andrey Grodzovsky (3): drm/amdgpu: Add USBC PD FW load

[PATCH v2 1/3] drm/amdgpu: Add USBC PD FW load interface to PSP.

Used to load power Delivery FW to PSP. Signed-off-by: Andrey Grodzovsky Reviewed-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h index

Re: [PATCH] drm/amdgpu/sriov: skip programing some regs with new L1 policy

[AMD Public Use] Acked-by: Alex Deucher From: amd-gfx on behalf of Zhou, Tiecheng Sent: Tuesday, March 3, 2020 6:04 AM To: Zhou, Tiecheng ; amd-gfx@lists.freedesktop.org Subject: RE: [PATCH] drm/amdgpu/sriov: skip programing some regs with new L1 policy

[PATCH 5.4 080/152] drm/radeon: Inline drm_get_pci_dev

From: Daniel Vetter commit eb12c957735b582607e5842a06d1f4c62e185c1d upstream. It's the last user, and more importantly, it's the last non-legacy user of anything in drm_pci.c. The only tricky bit is the agp initialization. But a close look shows that radeon does not use the drm_agp midlayer

[PATCH 5.5 094/176] drm/radeon: Inline drm_get_pci_dev

From: Daniel Vetter commit eb12c957735b582607e5842a06d1f4c62e185c1d upstream. It's the last user, and more importantly, it's the last non-legacy user of anything in drm_pci.c. The only tricky bit is the agp initialization. But a close look shows that radeon does not use the drm_agp midlayer

Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

On 2020-03-03 14:06, Christian König wrote: > Am 02.03.20 um 21:47 schrieb Luben Tuikov: >> On 2020-02-28 2:47 a.m., Christian König wrote: >>> Am 28.02.20 um 06:08 schrieb Luben Tuikov: On 2020-02-27 4:40 p.m., Nirmoy Das wrote: > [SNIP] > + if (!(entity && sched_list &&

Re: [RFC PATCH 2/4] drm/scheduler: implement a function to modify sched list

Am 02.03.20 um 21:47 schrieb Luben Tuikov: On 2020-02-28 2:47 a.m., Christian König wrote: Am 28.02.20 um 06:08 schrieb Luben Tuikov: On 2020-02-27 4:40 p.m., Nirmoy Das wrote: [SNIP] + if (!(entity && sched_list && (num_sched_list == 0 || sched_list[0]))) + return

Re: [PATCH 1/4] drm/amdgpu/vcn: fix race condition issue for vcn start

On 2020-03-03 1:44 p.m., Christian König wrote: Am 03.03.20 um 19:16 schrieb James Zhu: Fix race condition issue when multiple vcn starts are called. Signed-off-by: James Zhu ---   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4   drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 +   2 files

Re: [PATCH] drm/amd/display: dcn20: remove an unused function

Hi, Thanks for your patch, everything lgtm. Reviewed-by: Rodrigo Siqueira On 03/02, Melissa Wen wrote: > The dpp2_get_optimal_number_of_taps function is never used. Removing just for > code cleaning up. > > Signed-off-by: Melissa Wen > --- > .../gpu/drm/amd/display/dc/dcn20/dcn20_dpp.c |

Re: [PATCH 1/4] drm/amdgpu/vcn: fix race condition issue for vcn start

Am 03.03.20 um 19:16 schrieb James Zhu: Fix race condition issue when multiple vcn starts are called. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 + 2 files changed, 5 insertions(+) diff --git

[PATCH 1/4] drm/amdgpu/vcn: fix race condition issue for vcn start

Fix race condition issue when multiple vcn starts are called. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h | 1 + 2 files changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c

[PATCH 4/4] drm/amdgpu/vcn2.5: stall DPG when WPTR/RPTR reset

Add vcn dpg harware and firmware synchronization to fix race condition issue among vcn driver, hardware and firmware Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c

[PATCH 2/4] drm/amdgpu/vcn: fix race condition issue for dpg unpause mode switch

Couldn't only rely on enc fence to decide switching to dpg unpaude mode. Since a enc thread may not schedule a fence in time during multiple threads running situation. Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 28 ++--

[PATCH 3/4] drm/amdgpu/vcn2.0: stall DPG when WPTR/RPTR reset

Add vcn dpg harware and firmware synchronization to fix race condition issue among vcn driver, hardware and firmware Signed-off-by: James Zhu --- drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c

Re: [PATCH 2/3] drm/amdgpu: Add USBC PD FW load to PSP 11

On 3/2/20 4:30 PM, Alex Deucher wrote: On Mon, Mar 2, 2020 at 2:24 PM Andrey Grodzovsky wrote: Add the programming sequence. Signed-off-by: Andrey Grodzovsky --- drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 76 ++ 1 file changed, 76 insertions(+) diff --git

RE: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

[AMD Official Use Only - Internal Distribution Only] Thanks million! I’ll change the patch. -Jacob From: Koenig, Christian Sent: Wednesday, March 4, 2020 12:09:36 AM To: He, Jacob ; amd-gfx@lists.freedesktop.org Subject: Re: [PATCH] drm/amdgpu: Update

Re: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

Am 03.03.20 um 17:07 schrieb He, Jacob: [AMD Official Use Only - Internal Distribution Only] Oh, you are right! If SPM_VMID is updated by other process while the SPM enabled commands is executing, that will cause VM fault. Is the wait vm idle right before unreserve vmid still necessary if

RE: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

[AMD Official Use Only - Internal Distribution Only] Oh, you are right! If SPM_VMID is updated by other process while the SPM enabled commands is executing, that will cause VM fault. Is the wait vm idle right before unreserve vmid still necessary if using asynchroneously setting SPM_VMID?

Re: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

See the SPM buffer address is set using CP commands as well, right? And those execute asynchronously. When we now synchronously update the SPM VMID we risk that we switch from one process to another while the new process is not ready yet with its setup. That could have quite a bunch of

Re: [PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

Am 03.03.20 um 16:22 schrieb Nirmoy: Hi Christian, On 3/3/20 4:14 PM, Christian König wrote: I mean the drm_gpu_scheduler * array doesn't needs to be constructed by the context code in the first place. Do you mean amdgpu_ctx_init_sched() should belong to somewhere else may be in

RE: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

[AMD Official Use Only - Internal Distribution Only] Thanks! Could you please take an example of trouble “This way we avoid a bunch of trouble when one process drops the VMID reservation and another one grabs it.”? Thanks Jacob From: Koenig, Christian Sent:

Re: [PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

Hi Christian, On 3/3/20 4:14 PM, Christian König wrote: I mean the drm_gpu_scheduler * array doesn't needs to be constructed by the context code in the first place. Do you mean amdgpu_ctx_init_sched() should belong to somewhere else may be in amdgpu_ring.c ? That's one possibility, yes. On

Re: [PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

Am 03.03.20 um 15:29 schrieb Nirmoy: On 3/3/20 3:03 PM, Christian König wrote: Am 03.03.20 um 13:50 schrieb Nirmoy Das: [SNIP]   struct amdgpu_mec {   struct amdgpu_bo    *hpd_eop_obj;   u64    hpd_eop_gpu_addr; @@ -280,8 +290,9 @@ struct amdgpu_gfx {   uint32_t   

Re: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

Am 03.03.20 um 15:34 schrieb He, Jacob: [AMD Official Use Only - Internal Distribution Only] /It would be better if we could do that asynchronously with a register write on the ring. / Sorry, I don’t get your point. Could you please elaborate more? You pass the ring from

Re: [PATCH 2/4] PCI: Use ioremap, not phys_to_virt for platform rom

Cosmetics: s/ioremap/ioremap()/ (also in commit log) s/phys_to_virt/phys_to_virt()/ (also in commit log) s/pci_platform_rom/pci_platform_rom()/ (commit log) s/rom/ROM/ On Mon, Mar 02, 2020 at 10:34:55PM -0500, Mikel Rychliski wrote: > On some EFI systems, the video BIOS is provided by the EFI

RE: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

[AMD Official Use Only - Internal Distribution Only] It would be better if we could do that asynchronously with a register write on the ring. Sorry, I don’t get your point. Could you please elaborate more? Thanks Jacob From: Christian König Sent:

Re: [PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

On 3/3/20 3:03 PM, Christian König wrote: Am 03.03.20 um 13:50 schrieb Nirmoy Das: [SNIP]   struct amdgpu_mec {   struct amdgpu_bo    *hpd_eop_obj;   u64    hpd_eop_gpu_addr; @@ -280,8 +290,9 @@ struct amdgpu_gfx {   uint32_t    num_gfx_sched;   unsigned 

Re: [PATCH] drm/amdgpu: Update SPM_VMID with the job's vmid when application reserves the vmid

Am 02.03.20 um 06:35 schrieb Jacob He: SPM access the video memory according to SPM_VMID. It should be updated with the job's vmid right before the job is scheduled. SPM_VMID is a global resource Change-Id: Id3881908960398f87e7c95026a54ff83ff826700 Signed-off-by: Jacob He ---

Re: [PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

Am 03.03.20 um 13:50 schrieb Nirmoy Das: [SNIP] struct amdgpu_mec { struct amdgpu_bo*hpd_eop_obj; u64 hpd_eop_gpu_addr; @@ -280,8 +290,9 @@ struct amdgpu_gfx { uint32_tnum_gfx_sched; unsigned

RE: [PATCH 2/2] drm/amdgpu/display: navi1x copy dcn watermark clock settings to smu resume from s3

[AMD Official Use Only - Internal Distribution Only] Hi Evan, Kenneth, Would you please help review this patch again? Thanks! Hersen -Original Message- From: Alex Deucher Sent: Monday, March 2, 2020 9:27 AM To: Wu, Hersen Cc: Quan, Evan ; amd-gfx@lists.freedesktop.org; Feng,

[PATCH v4 3/4] drm/amdgpu: change hw sched list on ctx priority override

Switch to appropriate sched list for an entity on priority override. Signed-off-by: Nirmoy Das --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 32 + 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c

[PATCH v2 2/4] drm/scheduler: implement a function to modify sched list

implement drm_sched_entity_modify_sched() which can modify existing sched_list with a different one. This is going to be helpful when userspace changes priority of a ctx/entity then driver can switch to corresponding hw shced list for that priority Signed-off-by: Nirmoy Das Reviewed-by:

[PATCH v6 1/1] drm/amdgpu: set compute queue priority at mqd_init

We were changing compute ring priority while rings were being used before every job submission which is not recommended. This patch sets compute queue priority at mqd initialization for gfx8, gfx9 and gfx10. Policy: make queue 0 of each pipe as high priority compute queue High/normal priority

[PATCH 4/4] drm/amdgpu: remove unused functions

amdgpu statically set priority for compute queues at initialization so remove all the functions responsible changing compute queue priority dynamically Signed-off-by: Nirmoy Das Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 70

Re: [PATCH v5 1/4] drm/amdgpu: set compute queue priority at mqd_init

On 3/2/20 6:16 PM, Christian König wrote: or else @@ -222,7 +229,8 @@ struct amdgpu_ring {     struct mutex    priority_mutex;     /* protected by priority_mutex */     int priority; -   bool    gfx_pipe_priority; + +   enum

RE: [PATCH] drm/amdgpu/sriov: skip programing some regs with new L1 policy

[AMD Official Use Only - Internal Distribution Only] Ping -Original Message- From: Tiecheng Zhou Sent: Monday, March 2, 2020 3:08 PM To: amd-gfx@lists.freedesktop.org Cc: Zhou, Tiecheng Subject: [PATCH] drm/amdgpu/sriov: skip programing some regs with new L1 policy With new L1

[PATCH 0/4] Fix loading of radeon BIOS from 32-bit EFI

This patch set fixes an opps when loading the radeon driver on old Macs with a 32-bit EFI implementation. Tested on a MacPro 1,1 with a Radeon X1900 XT card and 32-bit kernel. Mikel Rychliski (4): drm/radeon: Stop directly referencing iomem PCI: Use ioremap, not phys_to_virt for platform rom

[PATCH 4/4] drm/amdgpu: iounmap unused mapping

Now that pci_platform_rom creates a new mapping to access the ROM image, we should remove this mapping after extracting the BIOS. Signed-off-by: Mikel Rychliski --- drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 1/4] drm/radeon: Stop directly referencing iomem

pci_platform_rom returns an __iomem pointer which should not be accessed directly. Change radeon_read_platform_bios to use memcpy_fromio instead of calling kmemdup on the __iomem pointer. Signed-off-by: Mikel Rychliski --- drivers/gpu/drm/radeon/radeon_bios.c | 11 +++ 1 file changed, 7

[PATCH 3/4] drm/radeon: iounmap unused mapping

Now that pci_platform_rom creates a new mapping to access the ROM image, we should remove this mapping after extracting the BIOS. Signed-off-by: Mikel Rychliski --- drivers/gpu/drm/radeon/radeon_bios.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_bios.c

[PATCH 2/4] PCI: Use ioremap, not phys_to_virt for platform rom

On some EFI systems, the video BIOS is provided by the EFI firmware. The boot stub code stores the physical address of the ROM image in pdev->rom. Currently we attempt to access this pointer using phys_to_virt, which doesn't work with CONFIG_HIGHMEM. On these systems, attempting to load the