mbox series

[git,pull] drm fixes round two for 5.13-rc1

Message ID CAPM=9twAN82gkzrfc2CGQopjkjEdWtBKMF2DgBOtw+6RsZ++fw@mail.gmail.com (mailing list archive)
State New, archived
Headers show
Series [git,pull] drm fixes round two for 5.13-rc1 | expand

Pull-request

git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-05-10

Message

Dave Airlie May 9, 2021, 6:16 p.m. UTC
Hey Linus,

Bit later than usual, I queued them all up on Friday then promptly
forgot to write the pull request email. This is mainly amdgpu fixes,
with some radeon/msm/fbdev and one i915 gvt fix thrown in.

Hopefully I get you before you drop rc1, but nothing insanely urgent if not.

Dave.

drm-next-2021-05-10:
drm fixes for 5.13-rc1

amdgpu:
- MPO hang workaround
- Fix for concurrent VM flushes on vega/navi
- dcefclk is not adjustable on navi1x and newer
- MST HPD debugfs fix
- Suspend/resumes fixes
- Register VGA clients late in case driver fails to load
- Fix GEM leak in user framebuffer create
- Add support for polaris12 with 32 bit memory interface
- Fix duplicate cursor issue when using overlay
- Fix corruption with tiled surfaces on VCN3
- Add BO size and stride check to fix BO size verification

radeon:
- Fix off-by-one in power state parsing
- Fix possible memory leak in power state parsing

msm:
- NULL ptr dereference fix

fbdev:
- procfs disabled warning fix

i915:
- gvt: Fix a possible division by zero in vgpu display rate calculation
The following changes since commit 1cd6b4a04f038eb24fd18c8010e763d1140a9c7a:

  Merge tag 'drm-intel-next-fixes-2021-04-27' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2021-04-30
10:42:03 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-05-10

for you to fetch changes up to 0844708ac3d2dbdace70f4a6020669d56958697f:

  Merge tag 'amd-drm-fixes-5.13-2021-05-05' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-05-07
12:44:51 +1000)

----------------------------------------------------------------
drm fixes for 5.13-rc1

amdgpu:
- MPO hang workaround
- Fix for concurrent VM flushes on vega/navi
- dcefclk is not adjustable on navi1x and newer
- MST HPD debugfs fix
- Suspend/resumes fixes
- Register VGA clients late in case driver fails to load
- Fix GEM leak in user framebuffer create
- Add support for polaris12 with 32 bit memory interface
- Fix duplicate cursor issue when using overlay
- Fix corruption with tiled surfaces on VCN3
- Add BO size and stride check to fix BO size verification

radeon:
- Fix off-by-one in power state parsing
- Fix possible memory leak in power state parsing

msm:
- NULL ptr dereference fix

fbdev:
- procfs disabled warning fix

i915:
- gvt: Fix a possible division by zero in vgpu display rate calculation

----------------------------------------------------------------
Bas Nieuwenhuizen (2):
      drm/amdgpu: Init GFX10_ADDR_CONFIG for VCN v3 in DPG mode.
      drm/amdgpu: Use device specific BO size & stride check.

Christian K├Ânig (1):
      drm/amdgpu: fix concurrent VM flushes on Vega/Navi v2

Colin Xu (1):
      drm/i915/gvt: Prevent divided by zero when calculating refresh rate

Darren Powell (2):
      amdgpu/pm: Prevent force of DCEFCLK on NAVI10 and SIENNA_CICHLID
      amdgpu/pm: set pp_dpm_dcefclk to readonly on NAVI10 and newer gpus

Dave Airlie (3):
      Merge tag 'drm-intel-next-fixes-2021-04-30' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
      Merge tag 'drm-misc-next-fixes-2021-05-06' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next
      Merge tag 'amd-drm-fixes-5.13-2021-05-05' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next

Evan Quan (1):
      drm/amdgpu: add new MC firmware for Polaris12 32bit ASIC

Guenter Roeck (1):
      fbmem: Mark proc_fb_seq_ops as __maybe_unused

Harry Wentland (1):
      drm/amd/display: Reject non-zero src_y and src_x for video planes

Jani Nikula (1):
      Merge tag 'gvt-next-fixes-2021-04-29' of
https://github.com/intel/gvt-linux into drm-intel-next-fixes

Kai-Heng Feng (1):
      drm/amdgpu: Register VGA clients after init can no longer fail

Kees Cook (2):
      drm/radeon: Fix off-by-one power_state index heap overwrite
      drm/radeon: Avoid power table parsing memory leaks

Mikita Lipski (1):
      drm/amd/display: fix wrong statement in mst hpd debugfs

Pavan Kumar Ramayanam (1):
      drm/amdgpu: Handling of amdgpu_device_resume return value for
graceful teardown

Rob Clark (1):
      drm/msm/dpu: Delete bonkers code

Rodrigo Siqueira (1):
      drm/amd/display: Fix two cursor duplication when using overlay

Simon Ser (1):
      amdgpu: fix GEM obj leak in amdgpu_display_user_framebuffer_create

Tom Rix (1):
      drm/amd/pm: initialize variable

Victor Zhao (1):
      drm/amdgpu: fix r initial values

 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c         |  28 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c        | 184 ++++++++++++++++++++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c            |   3 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c            |  19 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c             |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h             |   1 +
 drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c              |  13 +-
 drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c              |   4 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  68 ++++++++
 .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c  |   2 +-
 drivers/gpu/drm/amd/pm/amdgpu_pm.c                 |  10 +-
 drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c    |   5 +-
 .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c    |   4 +-
 drivers/gpu/drm/i915/gvt/handlers.c                |   6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c           |  10 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c          |  16 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h          |   6 -
 drivers/gpu/drm/radeon/radeon_atombios.c           |  26 ++-
 drivers/video/fbdev/core/fbmem.c                   |   2 +-
 19 files changed, 332 insertions(+), 81 deletions(-)

Comments

pr-tracker-bot@kernel.org May 9, 2021, 8:49 p.m. UTC | #1
The pull request you sent on Mon, 10 May 2021 04:16:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-05-10

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/efc58a96adcd29cc37487a60582d9d08b34f6640

Thank you!
Linus Torvalds May 9, 2021, 9:08 p.m. UTC | #2
On Sun, May 9, 2021 at 11:16 AM Dave Airlie <airlied@gmail.com> wrote:
>
> Bit later than usual, I queued them all up on Friday then promptly
> forgot to write the pull request email. This is mainly amdgpu fixes,
> with some radeon/msm/fbdev and one i915 gvt fix thrown in.

Hmm. Gcc seems ok with this, but clang complains:

   drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute
declaration must precede definition [-Wignored-attributes]
   static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
                       ^

but I noticed it only after I had already pushed out the pull.

I'm actually surprised that gcc accepted that horrid mess: putting
"__maybe_unused" between the "struct" and the struct name is very very
wrong.

I fixed it up after the merge due to not noticing earlier..

Maybe the drm test robots should start testing with clang too?

           Linus
Dave Airlie May 9, 2021, 11:28 p.m. UTC | #3
On Mon, 10 May 2021 at 07:08, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, May 9, 2021 at 11:16 AM Dave Airlie <airlied@gmail.com> wrote:
> >
> > Bit later than usual, I queued them all up on Friday then promptly
> > forgot to write the pull request email. This is mainly amdgpu fixes,
> > with some radeon/msm/fbdev and one i915 gvt fix thrown in.
>
> Hmm. Gcc seems ok with this, but clang complains:
>
>    drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute
> declaration must precede definition [-Wignored-attributes]
>    static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
>                        ^
>
> but I noticed it only after I had already pushed out the pull.
>
> I'm actually surprised that gcc accepted that horrid mess: putting
> "__maybe_unused" between the "struct" and the struct name is very very
> wrong.
>
> I fixed it up after the merge due to not noticing earlier..
>
> Maybe the drm test robots should start testing with clang too?

My current build, test + sign machine " 09:23:22 up 419 days", running
fc29, has clang 7 which is my current blocker on implementing a clang
bit in my build cycles.

The machine is in an office, that due to RH not being able to fathom a
country where COVID isn't rampant, I have to fill insane amounts of
paperwork and high management intervention to visit, I'm afraid to
remote upgrade or reboot it unless I really have to.

I've some rough ideas to update it to f33/34 which would give me a
good enough clang, I suppose I could just build my own llvm/clang I've
done so for years for other reasons, if I can't come up with an update
plan soon I might consider it.

Dave.
Guenter Roeck May 10, 2021, 12:47 a.m. UTC | #4
On 5/9/21 2:08 PM, Linus Torvalds wrote:
> On Sun, May 9, 2021 at 11:16 AM Dave Airlie <airlied@gmail.com> wrote:
>>
>> Bit later than usual, I queued them all up on Friday then promptly
>> forgot to write the pull request email. This is mainly amdgpu fixes,
>> with some radeon/msm/fbdev and one i915 gvt fix thrown in.
> 
> Hmm. Gcc seems ok with this, but clang complains:
> 

Yeah, sorry, that was supposed to fix a problem, not replace it with
another one. And, as you noticed, gcc didn't complain, so I didn't
realize that I created a mess (and don't ask me why I put that
__maybe_unused after 'struct' - no idea).

Guenter

>     drivers/video/fbdev/core/fbmem.c:736:21: warning: attribute
> declaration must precede definition [-Wignored-attributes]
>     static const struct __maybe_unused seq_operations proc_fb_seq_ops = {
>                         ^
> 
> but I noticed it only after I had already pushed out the pull.
> 
> I'm actually surprised that gcc accepted that horrid mess: putting
> "__maybe_unused" between the "struct" and the struct name is very very
> wrong.
> 
> I fixed it up after the merge due to not noticing earlier..
> 
> Maybe the drm test robots should start testing with clang too?
> 
>             Linus
>