mbox series

[pull] amdgpu, amdkfd drm-fixes-5.14

Message ID 20210714220858.5553-1-alexander.deucher@amd.com (mailing list archive)
State New, archived
Headers show
Series [pull] amdgpu, amdkfd drm-fixes-5.14 | expand

Pull-request

https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.14-2021-07-14

Message

Alex Deucher July 14, 2021, 10:08 p.m. UTC
Hi Dave, Daniel,

Fixes for 5.14.  The big change here is unifying the SMU13 code.  This was
new code added in 5.14 to support Yellow Carp, but we've since cleaned it
up and removed a lot of duplication, so better to merge it now to facilitate
any bug fixes in the future that need to go back to this kernel via stable.
Only affects Yellow Carp which is new for 5.14 anyway so not much chance for
regressions.  The rest is just standard bug fixes.

The following changes since commit 1e7b5812f4890ad84058bbb6c4a5deddfb2c5b25:

  Merge tag 'drm-misc-fixes-2021-07-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2021-07-13 15:15:17 +0200)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.14-2021-07-14

for you to fetch changes up to 775da83005cb61d4c213c636df9337da05714ff1:

  drm/amdgpu: add another Renoir DID (2021-07-14 15:08:55 -0400)

----------------------------------------------------------------
amd-drm-fixes-5.14-2021-07-14:

amdgpu:
- SR-IOV fixes
- RAS fixes
- eDP fixes
- SMU13 code unification to facilitate fixes in the future
- Add new renoir DID
- Yellow Carp fixes
- Beige Goby fixes
- Revert a bunch of TLB fixes that caused regressions
- Revert an LTTPR display regression

amdkfd
- Fix VRAM access regression
- SVM fixes

----------------------------------------------------------------
Aaron Liu (1):
      drm/amd/pm: Add waiting for response of mode-reset message for yellow carp

Chengming Gui (1):
      drm/amd/pm: Fix BACO state setting for Beige_Goby

Dmytro Laktyushkin (1):
      drm/amd/display: remove faulty assert

Emily Deng (1):
      drm/amdgpu: Correct the irq numbers for virtual crtc

Emily.Deng (1):
      drm/amdgpu: Restore msix after FLR

Eric Huang (5):
      Revert "drm/amdkfd: Add memory sync before TLB flush on unmap"
      Revert "drm/amdgpu: Fix warning of Function parameter or member not described"
      Revert "drm/amdkfd: Make TLB flush conditional on mapping"
      Revert "drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update"
      Revert "drm/amdkfd: Add heavy-weight TLB flush after unmapping"

Felix Kuehling (1):
      drm/amdkfd: Allow CPU access for all VRAM BOs

Jingwen Chen (1):
      drm/amdgpu: SRIOV flr_work should take write_lock

Jinzhou Su (1):
      drm/amdgpu: add another Renoir DID

Luben Tuikov (1):
      drm/amdgpu: Return error if no RAS

Nicholas Kazlauskas (1):
      drm/amd/display: Fix updating infoframe for DCN3.1 eDP

Philip Yang (1):
      drm/amdkfd: handle fault counters on invalid address

Wesley Chalmers (1):
      Revert "drm/amd/display: Always write repeater mode regardless of LTTPR"

Xiaomeng Hou (2):
      drm/amd/pm: drop smu_v13_0_1.c|h files for yellow carp
      drm/amd/display: update header file name

Zhan Liu (1):
      drm/amdgpu/display - only update eDP's backlight level when necessary

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h         |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   |  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c             |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c            |   1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c            |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c            |  18 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c            |  49 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.h            |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c             |  11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h             |   2 +-
 drivers/gpu/drm/amd/amdgpu/dce_virtual.c           |   2 +-
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c              |   4 +-
 drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c              |   4 +-
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c           |  45 +-
 drivers/gpu/drm/amd/amdkfd/kfd_process.c           |   3 +-
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c               |  30 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   2 +-
 .../drm/amd/display/dc/clk_mgr/dcn31/dcn31_smu.c   |   4 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |   8 +-
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c |   2 +-
 .../drm/amd/include/asic_reg/mp/mp_13_0_1_offset.h | 355 --------------
 .../amd/include/asic_reg/mp/mp_13_0_1_sh_mask.h    | 531 ---------------------
 drivers/gpu/drm/amd/pm/inc/smu_v13_0.h             |   1 +
 drivers/gpu/drm/amd/pm/inc/smu_v13_0_1.h           |  57 ---
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c     |   1 +
 drivers/gpu/drm/amd/pm/swsmu/smu13/Makefile        |   2 +-
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c     |  24 +
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_1.c   | 311 ------------
 .../gpu/drm/amd/pm/swsmu/smu13/yellow_carp_ppt.c   |  49 +-
 29 files changed, 182 insertions(+), 1372 deletions(-)
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/mp/mp_13_0_1_offset.h
 delete mode 100644 drivers/gpu/drm/amd/include/asic_reg/mp/mp_13_0_1_sh_mask.h
 delete mode 100644 drivers/gpu/drm/amd/pm/inc/smu_v13_0_1.h
 delete mode 100644 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_1.c

Comments

Sam Ravnborg July 15, 2021, 4:52 a.m. UTC | #1
Hi Alex,

On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
> 
> Fixes for 5.14.  The big change here is unifying the SMU13 code.  This was
> new code added in 5.14 to support Yellow Carp, but we've since cleaned it
> up and removed a lot of duplication, so better to merge it now to facilitate
> any bug fixes in the future that need to go back to this kernel via stable.
> Only affects Yellow Carp which is new for 5.14 anyway so not much chance for
> regressions.  The rest is just standard bug fixes.

This pull seems not to include any fixes for the W=1 warnings that
has crept in again. It would be nice if the amdgpu could be warning free
again, this would maybe motivate the others to fix theirs too so we
could keep most/all of drivers/gpu/ free of W=1 warnings.

	Sam
Alex Deucher July 15, 2021, 2:07 p.m. UTC | #2
On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Alex,
>
> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > Fixes for 5.14.  The big change here is unifying the SMU13 code.  This was
> > new code added in 5.14 to support Yellow Carp, but we've since cleaned it
> > up and removed a lot of duplication, so better to merge it now to facilitate
> > any bug fixes in the future that need to go back to this kernel via stable.
> > Only affects Yellow Carp which is new for 5.14 anyway so not much chance for
> > regressions.  The rest is just standard bug fixes.
>
> This pull seems not to include any fixes for the W=1 warnings that
> has crept in again. It would be nice if the amdgpu could be warning free
> again, this would maybe motivate the others to fix theirs too so we
> could keep most/all of drivers/gpu/ free of W=1 warnings.

We haven't really been monitoring the W=1 stuff that closely.  I'll
see what we can do going forward.

Alex
Michel Dänzer July 15, 2021, 3:51 p.m. UTC | #3
On 2021-07-15 4:07 p.m., Alex Deucher wrote:
> On Thu, Jul 15, 2021 at 12:52 AM Sam Ravnborg <sam@ravnborg.org> wrote:
>> On Wed, Jul 14, 2021 at 06:08:58PM -0400, Alex Deucher wrote:
>>> Hi Dave, Daniel,
>>>
>>> Fixes for 5.14.  The big change here is unifying the SMU13 code.  This was
>>> new code added in 5.14 to support Yellow Carp, but we've since cleaned it
>>> up and removed a lot of duplication, so better to merge it now to facilitate
>>> any bug fixes in the future that need to go back to this kernel via stable.
>>> Only affects Yellow Carp which is new for 5.14 anyway so not much chance for
>>> regressions.  The rest is just standard bug fixes.
>>
>> This pull seems not to include any fixes for the W=1 warnings that
>> has crept in again. It would be nice if the amdgpu could be warning free
>> again, this would maybe motivate the others to fix theirs too so we
>> could keep most/all of drivers/gpu/ free of W=1 warnings.
> 
> We haven't really been monitoring the W=1 stuff that closely.  I'll
> see what we can do going forward.

IMHO keeping the W=1 build clean isn't realistic without enforcing it in CI.