| Message ID | 20210303134319.3160762-1-lee.jones@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Rid GPU from W=1 warnings | expand |
The vmwgfx ones look all good to me, so for 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> That said, they were already signed off by Zack, so not sure what happened here. Roland On 03.03.21 14:42, Lee Jones wrote: > This is a resend. All of these patches have been sent before. > > The vmwgfx ones were even applied, but were dropped for some reason. > > Lee Jones (53): > drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc > drm/nouveau/dispnv50/disp: Remove unused variable 'ret' > drm/msm/dp/dp_display: Remove unused variable 'hpd' > drm/amd/display/dc/bios/command_table: Remove unused variable > include: drm: drm_atomic: Make use of 'new_plane_state' > drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc > headers > drm/amd/display/dc/bios/command_table: Remove unused variable and > associated comment > drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the > stack to the heap > drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from > the stack > drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field > overwritten' issue > drm/amd/display/dc/dce80/dce80_resource: Make local functions static > drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc > header > drm/nouveau/nouveau_bo: Remove unused variables 'dev' > drm/nouveau/nouveau_display: Remove set but unused variable 'width' > drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers > drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function > returning void > drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' > static > drm/nouveau/nv50_display: Remove superfluous prototype for local > static functions > drm/nouveau/dispnv50/disp: Include header containing our prototypes > drm/nouveau/nouveau_ioc32: File headers are not good candidates for > kernel-doc > drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void > function > drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment > block > drm/vmwgfx/vmwgfx_execbuf: Fix some kernel-doc related issues > drm/vmwgfx/vmwgfx_kms: Remove unused variable 'ret' from > 'vmw_du_primary_plane_atomic_check()' > drm/vmwgfx/vmwgfx_kms: Mark vmw_{cursor,primary}_plane_formats as > __maybe_unused > drm/vmwgfx/vmwgfx_drv: Fix some kernel-doc misdemeanours > drm/vmwgfx/vmwgfx_ioctl: Provide missing '@' sign required by > kernel-doc > drm/vmwgfx/vmwgfx_resource: Fix worthy function headers demote some > others > drm/vmwgfx/vmwgfx_ttm_buffer: Supply some missing parameter > descriptions > drm/vmwgfx/vmwgfx_fifo: Demote non-conformant kernel-doc header > drm/vmwgfx/vmwgfx_ldu: Supply descriptions for 'state' function > parameter > drm/vmwgfx/vmwgfx_kms: Update worthy function headers and demote > others > drm/vmwgfx/vmwgfx_overlay: Demote kernel-doc abuses to standard > comment blocks > drm/vmwgfx/vmwgfx_fence: Add, remove and demote various documentation > params/headers > drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply > another > drm/vmwgfx/vmwgfx_context: Demote kernel-doc abuses > drm/vmwgfx/vmwgfx_scrn: Demote unworthy kernel-doc headers and update > others > drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues > drm/vmwgfx/vmwgfx_cmdbuf_res: Rename param description and remove > another > drm/vmwgfx/vmwgfx_shader: Demote kernel-doc abuses and fix-up worthy > headers > drm/vmwgfx/vmwgfx_cmdbuf: Fix a bunch of missing or incorrectly > formatted/named params > drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret' > drm/vmwgfx/vmwgfx_stdu: Add some missing param/member descriptions > drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural > drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation > problems > drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member > drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and > remove others > drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg' > drm/vmwgfx/vmwgfx_blit: Add description for 'vmw_bo_cpu_blit's 'diff' > param > drm/vmwgfx/vmwgfx_validation: Add some missing struct member/function > param descriptions > drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another > drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member > 'manager' > drm/vmwgfx/ttm_object: Reorder header to immediately precede its > struct > > .../drm/amd/display/dc/bios/command_table.c | 16 +- > .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 1151 +++++++++-------- > drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 - > .../drm/amd/display/dc/dce80/dce80_resource.c | 16 +- > drivers/gpu/drm/msm/dp/dp_display.c | 3 - > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- > drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 +- > drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 - > drivers/gpu/drm/nouveau/nouveau_display.c | 8 +- > drivers/gpu/drm/nouveau/nouveau_ioc32.c | 4 +- > drivers/gpu/drm/nouveau/nouveau_svm.c | 5 +- > drivers/gpu/drm/nouveau/nv50_display.h | 3 - > .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- > .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 +-- > .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 +- > drivers/gpu/drm/vmwgfx/ttm_object.c | 25 +- > drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 9 +- > drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 14 +- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 8 +- > drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 6 +- > drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 +- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 +- > drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20 +- > drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 18 +- > drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16 +- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +- > drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 16 +- > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 10 +- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +- > drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 10 +- > drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 9 +- > drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 17 +- > drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 + > drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 5 +- > include/drm/drm_atomic.h | 3 +- > 44 files changed, 818 insertions(+), 847 deletions(-) > > Cc: Alex Deucher <alexander.deucher@amd.com> > Cc: amd-gfx@lists.freedesktop.org > Cc: Anthony Koo <Anthony.Koo@amd.com> > Cc: Ben Skeggs <bskeggs@redhat.com> > Cc: "Christian König" <christian.koenig@amd.com> > Cc: Colin Ian King <colin.king@canonical.com> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: Dave Airlie <airlied@redhat.com> > Cc: David Airlie <airlied@linux.ie> > Cc: dri-devel@lists.freedesktop.org > Cc: freedreno@lists.freedesktop.org > Cc: Harry Wentland <harry.wentland@amd.com> > Cc: Jeremy Kolb <jkolb@brandeis.edu> > Cc: Kuogee Hsieh <khsieh@codeaurora.org> > Cc: Lee Jones <lee.jones@linaro.org> > Cc: Leo Li <sunpeng.li@amd.com> > Cc: linaro-mm-sig@lists.linaro.org > Cc: linux-arm-msm@vger.kernel.org > Cc: linux-media@vger.kernel.org > Cc: Lyude Paul <lyude@redhat.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Maxime Ripard <mripard@kernel.org> > Cc: nouveau@lists.freedesktop.org > Cc: Qinglang Miao <miaoqinglang@huawei.com> > Cc: Rob Clark <rob.clark@linaro.org> > Cc: Rob Clark <robdclark@gmail.com> > Cc: Roland Scheidegger <sroland@vmware.com> > Cc: Sean Paul <sean@poorly.run> > Cc: Sumit Semwal <sumit.semwal@linaro.org> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> > Cc: Zack Rusin <zackr@vmware.com> >
On Fri, 05 Mar 2021, Roland Scheidegger wrote: > The vmwgfx ones look all good to me, so for > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > That said, they were already signed off by Zack, so not sure what > happened here. Yes, they were accepted at one point, then dropped without a reason. Since I rebased onto the latest -next, I had to pluck them back out of a previous one.
On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > The vmwgfx ones look all good to me, so for > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > That said, they were already signed off by Zack, so not sure what > > happened here. > > Yes, they were accepted at one point, then dropped without a reason. > > Since I rebased onto the latest -next, I had to pluck them back out of > a previous one. They should show up in linux-next again. We merge patches for next merge window even during the current merge window, but need to make sure they don't pollute linux-next. Occasionally the cut off is wrong so patches show up, and then get pulled again. Unfortunately especially the 5.12 merge cycle was very wobbly due to some confusion here. But your patches should all be in linux-next again (they are queued up for 5.13 in drm-misc-next, I checked that). Sorry for the confusion here. -Daniel
On Thu, 11 Mar 2021, Daniel Vetter wrote: > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > The vmwgfx ones look all good to me, so for > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > That said, they were already signed off by Zack, so not sure what > > > happened here. > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > a previous one. > > They should show up in linux-next again. We merge patches for next merge > window even during the current merge window, but need to make sure they > don't pollute linux-next. Occasionally the cut off is wrong so patches > show up, and then get pulled again. > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > confusion here. But your patches should all be in linux-next again (they > are queued up for 5.13 in drm-misc-next, I checked that). > > Sorry for the confusion here. Oh, I see. Well so long as they don't get dropped, I'll be happy. Thanks for the explanation Daniel
On Thu, 11 Mar 2021, Lee Jones wrote: > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > The vmwgfx ones look all good to me, so for > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > That said, they were already signed off by Zack, so not sure what > > > > happened here. > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > a previous one. > > > > They should show up in linux-next again. We merge patches for next merge > > window even during the current merge window, but need to make sure they > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > show up, and then get pulled again. > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > confusion here. But your patches should all be in linux-next again (they > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > Sorry for the confusion here. > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > Thanks for the explanation Daniel After rebasing today, all of my GPU patches have remained. Would someone be kind enough to check that everything is still in order please?
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones <lee.jones@linaro.org> wrote: > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > > That said, they were already signed off by Zack, so not sure what > > > > > happened here. > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > a previous one. > > > > > > They should show up in linux-next again. We merge patches for next merge > > > window even during the current merge window, but need to make sure they > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > show up, and then get pulled again. > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > confusion here. But your patches should all be in linux-next again (they > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > Sorry for the confusion here. > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > Thanks for the explanation Daniel > > After rebasing today, all of my GPU patches have remained. Would > someone be kind enough to check that everything is still in order > please? It's still broken somehow. I've kiced Maxime and Maarten again, they're also on this thread. -Daniel
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones <lee.jones@linaro.org> wrote: > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > happened here. > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > a previous one. > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > window even during the current merge window, but need to make sure they > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > show up, and then get pulled again. > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > > confusion here. But your patches should all be in linux-next again (they > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > Sorry for the confusion here. > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > Thanks for the explanation Daniel > > > > After rebasing today, all of my GPU patches have remained. Would > > someone be kind enough to check that everything is still in order > > please? > > It's still broken somehow. I've kiced Maxime and Maarten again, > they're also on this thread. You're patches have made it into drm-next meanwhile, so they should show up in linux-next through that tree at least. Except if that one also has some trouble. -Daniel
On Thu, 18 Mar 2021, Daniel Vetter wrote: > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones <lee.jones@linaro.org> wrote: > > > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > > happened here. > > > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > > a previous one. > > > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > > window even during the current merge window, but need to make sure they > > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > > show up, and then get pulled again. > > > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > > > confusion here. But your patches should all be in linux-next again (they > > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > > > Sorry for the confusion here. > > > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > > > Thanks for the explanation Daniel > > > > > > After rebasing today, all of my GPU patches have remained. Would > > > someone be kind enough to check that everything is still in order > > > please? > > > > It's still broken somehow. I've kiced Maxime and Maarten again, > > they're also on this thread. > > You're patches have made it into drm-next meanwhile, so they should > show up in linux-next through that tree at least. Except if that one > also has some trouble. Thanks for letting me know. I see some patches made it back in, others didn't. I'll resend the stragglers - bear with.
On Fri, Mar 19, 2021 at 08:24:07AM +0000, Lee Jones wrote: > On Thu, 18 Mar 2021, Daniel Vetter wrote: > > > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones <lee.jones@linaro.org> wrote: > > > > > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > > > happened here. > > > > > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > > > a previous one. > > > > > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > > > window even during the current merge window, but need to make sure they > > > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > > > show up, and then get pulled again. > > > > > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > > > > confusion here. But your patches should all be in linux-next again (they > > > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > > > > > Sorry for the confusion here. > > > > > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > > > > > Thanks for the explanation Daniel > > > > > > > > After rebasing today, all of my GPU patches have remained. Would > > > > someone be kind enough to check that everything is still in order > > > > please? > > > > > > It's still broken somehow. I've kiced Maxime and Maarten again, > > > they're also on this thread. > > > > You're patches have made it into drm-next meanwhile, so they should > > show up in linux-next through that tree at least. Except if that one > > also has some trouble. > > Thanks for letting me know. > > I see some patches made it back in, others didn't. > > I'll resend the stragglers - bear with. The vmwgfx ones should all be back, the others I guess just werent ever applied. I'll vacuum them all up if you resend. Apologies for the wobbly ride. -Daniel
On Fri, 19 Mar 2021, Daniel Vetter wrote: > On Fri, Mar 19, 2021 at 08:24:07AM +0000, Lee Jones wrote: > > On Thu, 18 Mar 2021, Daniel Vetter wrote: > > > > > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > > > > > > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones <lee.jones@linaro.org> wrote: > > > > > > > > > > On Thu, 11 Mar 2021, Lee Jones wrote: > > > > > > > > > > > On Thu, 11 Mar 2021, Daniel Vetter wrote: > > > > > > > > > > > > > On Mon, Mar 08, 2021 at 09:19:32AM +0000, Lee Jones wrote: > > > > > > > > On Fri, 05 Mar 2021, Roland Scheidegger wrote: > > > > > > > > > > > > > > > > > The vmwgfx ones look all good to me, so for > > > > > > > > > 23-53: Reviewed-by: Roland Scheidegger <sroland@vmware.com> > > > > > > > > > That said, they were already signed off by Zack, so not sure what > > > > > > > > > happened here. > > > > > > > > > > > > > > > > Yes, they were accepted at one point, then dropped without a reason. > > > > > > > > > > > > > > > > Since I rebased onto the latest -next, I had to pluck them back out of > > > > > > > > a previous one. > > > > > > > > > > > > > > They should show up in linux-next again. We merge patches for next merge > > > > > > > window even during the current merge window, but need to make sure they > > > > > > > don't pollute linux-next. Occasionally the cut off is wrong so patches > > > > > > > show up, and then get pulled again. > > > > > > > > > > > > > > Unfortunately especially the 5.12 merge cycle was very wobbly due to some > > > > > > > confusion here. But your patches should all be in linux-next again (they > > > > > > > are queued up for 5.13 in drm-misc-next, I checked that). > > > > > > > > > > > > > > Sorry for the confusion here. > > > > > > > > > > > > Oh, I see. Well so long as they don't get dropped, I'll be happy. > > > > > > > > > > > > Thanks for the explanation Daniel > > > > > > > > > > After rebasing today, all of my GPU patches have remained. Would > > > > > someone be kind enough to check that everything is still in order > > > > > please? > > > > > > > > It's still broken somehow. I've kiced Maxime and Maarten again, > > > > they're also on this thread. > > > > > > You're patches have made it into drm-next meanwhile, so they should > > > show up in linux-next through that tree at least. Except if that one > > > also has some trouble. > > > > Thanks for letting me know. > > > > I see some patches made it back in, others didn't. > > > > I'll resend the stragglers - bear with. > > The vmwgfx ones should all be back, the others I guess just werent ever > applied. I'll vacuum them all up if you resend. Apologies for the wobbly > ride. NP, it happens.
This is a resend. All of these patches have been sent before. The vmwgfx ones were even applied, but were dropped for some reason. Lee Jones (53): drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc drm/nouveau/dispnv50/disp: Remove unused variable 'ret' drm/msm/dp/dp_display: Remove unused variable 'hpd' drm/amd/display/dc/bios/command_table: Remove unused variable include: drm: drm_atomic: Make use of 'new_plane_state' drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers drm/amd/display/dc/bios/command_table: Remove unused variable and associated comment drm/amd/display/dc/calcs/dce_calcs: Move some large variables from the stack to the heap drm/amd/display/dc/calcs/dce_calcs: Remove some large variables from the stack drm/amd/display/dc/dce/dce_aux: Remove duplicate line causing 'field overwritten' issue drm/amd/display/dc/dce80/dce80_resource: Make local functions static drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header drm/nouveau/nouveau_bo: Remove unused variables 'dev' drm/nouveau/nouveau_display: Remove set but unused variable 'width' drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static drm/nouveau/nv50_display: Remove superfluous prototype for local static functions drm/nouveau/dispnv50/disp: Include header containing our prototypes drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block drm/vmwgfx/vmwgfx_execbuf: Fix some kernel-doc related issues drm/vmwgfx/vmwgfx_kms: Remove unused variable 'ret' from 'vmw_du_primary_plane_atomic_check()' drm/vmwgfx/vmwgfx_kms: Mark vmw_{cursor,primary}_plane_formats as __maybe_unused drm/vmwgfx/vmwgfx_drv: Fix some kernel-doc misdemeanours drm/vmwgfx/vmwgfx_ioctl: Provide missing '@' sign required by kernel-doc drm/vmwgfx/vmwgfx_resource: Fix worthy function headers demote some others drm/vmwgfx/vmwgfx_ttm_buffer: Supply some missing parameter descriptions drm/vmwgfx/vmwgfx_fifo: Demote non-conformant kernel-doc header drm/vmwgfx/vmwgfx_ldu: Supply descriptions for 'state' function parameter drm/vmwgfx/vmwgfx_kms: Update worthy function headers and demote others drm/vmwgfx/vmwgfx_overlay: Demote kernel-doc abuses to standard comment blocks drm/vmwgfx/vmwgfx_fence: Add, remove and demote various documentation params/headers drm/vmwgfx/vmwgfx_bo: Remove superfluous param description and supply another drm/vmwgfx/vmwgfx_context: Demote kernel-doc abuses drm/vmwgfx/vmwgfx_scrn: Demote unworthy kernel-doc headers and update others drm/vmwgfx/vmwgfx_surface: Fix some kernel-doc related issues drm/vmwgfx/vmwgfx_cmdbuf_res: Rename param description and remove another drm/vmwgfx/vmwgfx_shader: Demote kernel-doc abuses and fix-up worthy headers drm/vmwgfx/vmwgfx_cmdbuf: Fix a bunch of missing or incorrectly formatted/named params drm/vmwgfx/vmwgfx_cmdbuf_res: Remove unused variable 'ret' drm/vmwgfx/vmwgfx_stdu: Add some missing param/member descriptions drm/vmwgfx/vmwgfx_cmdbuf: Fix misnaming of 'headers' should be plural drm/vmwgfx/vmwgfx_cotable: Fix a couple of simple documentation problems drm/vmwgfx/vmwgfx_so: Add description for 'vmw_view's 'rcu' member drm/vmwgfx/vmwgfx_binding: Provide some missing param descriptions and remove others drm/vmwgfx/vmwgfx_msg: Fix misspelling of 'msg' drm/vmwgfx/vmwgfx_blit: Add description for 'vmw_bo_cpu_blit's 'diff' param drm/vmwgfx/vmwgfx_validation: Add some missing struct member/function param descriptions drm/vmwgfx/ttm_object: Demote half-assed headers and fix-up another drm/vmwgfx/vmwgfx_thp: Add description for 'vmw_thp_manager's member 'manager' drm/vmwgfx/ttm_object: Reorder header to immediately precede its struct .../drm/amd/display/dc/bios/command_table.c | 16 +- .../gpu/drm/amd/display/dc/calcs/dce_calcs.c | 1151 +++++++++-------- drivers/gpu/drm/amd/display/dc/dce/dce_aux.h | 1 - .../drm/amd/display/dc/dce80/dce80_resource.c | 16 +- drivers/gpu/drm/msm/dp/dp_display.c | 3 - drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 - drivers/gpu/drm/nouveau/nouveau_display.c | 8 +- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 4 +- drivers/gpu/drm/nouveau/nouveau_svm.c | 5 +- drivers/gpu/drm/nouveau/nv50_display.h | 3 - .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 +-- .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 +- drivers/gpu/drm/vmwgfx/ttm_object.c | 25 +- drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 9 +- drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 14 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 3 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 +- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20 +- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 18 +- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 16 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 9 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 17 +- drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 2 + drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 5 +- include/drm/drm_atomic.h | 3 +- 44 files changed, 818 insertions(+), 847 deletions(-) Cc: Alex Deucher <alexander.deucher@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: Anthony Koo <Anthony.Koo@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: Harry Wentland <harry.wentland@amd.com> Cc: Jeremy Kolb <jkolb@brandeis.edu> Cc: Kuogee Hsieh <khsieh@codeaurora.org> Cc: Lee Jones <lee.jones@linaro.org> Cc: Leo Li <sunpeng.li@amd.com> Cc: linaro-mm-sig@lists.linaro.org Cc: linux-arm-msm@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: Lyude Paul <lyude@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: nouveau@lists.freedesktop.org Cc: Qinglang Miao <miaoqinglang@huawei.com> Cc: Rob Clark <rob.clark@linaro.org> Cc: Rob Clark <robdclark@gmail.com> Cc: Roland Scheidegger <sroland@vmware.com> Cc: Sean Paul <sean@poorly.run> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: VMware Graphics <linux-graphics-maintainer@vmware.com> Cc: Zack Rusin <zackr@vmware.com>