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(-)
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!
On Sun, May 9, 2021 at 11:16 AM Dave Airlie airlied@gmail.com wrote:
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
On Mon, 10 May 2021 at 07:08, Linus Torvalds torvalds@linux-foundation.org wrote:
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.
On 5/9/21 2:08 PM, Linus Torvalds wrote:
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
dri-devel@lists.freedesktop.org