[PATCH v2 0/6] drm/gud: Use the shadow plane helper

[Greg KH]

On Thu, Dec 01, 2022 at 02:14:42PM +0100, Noralf Trønnes wrote:
> 
> 
> Den 01.12.2022 13.12, skrev Greg KH:
> > On Thu, Dec 01, 2022 at 11:00:44AM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 01.12.2022 06.55, skrev Greg KH:
> >>> On Wed, Nov 30, 2022 at 08:26:48PM +0100, Noralf Trønnes via B4 Submission Endpoint wrote:
> >>>> Hi,
> >>>>
> >>>> I have started to look at igt for testing and want to use CRC tests. To
> >>>> implement support for this I need to move away from the simple kms
> >>>> helper.
> >>>>
> >>>> When looking around for examples I came across Thomas' nice shadow
> >>>> helper and thought, yes this is perfect for drm/gud. So I'll switch to
> >>>> that before I move away from the simple kms helper.
> >>>>
> >>>> The async framebuffer flushing code path now uses a shadow buffer and
> >>>> doesn't touch the framebuffer when it shouldn't. I have also taken the
> >>>> opportunity to inline the synchronous flush code path and make this the
> >>>> default flushing stategy.
> >>>>
> >>>> Noralf.
> >>>>
> >>>> Cc: Maxime Ripard <mripard at kernel.org>
> >>>> Cc: Thomas Zimmermann <tzimmermann at suse.de>
> >>>> Cc: dri-devel at lists.freedesktop.org
> >>>> Signed-off-by: Noralf Trønnes <noralf at tronnes.org>
> >>>>
> >>>> ---
> >>>> Changes in v2:
> >>>> - Drop patch (Thomas):
> >>>>   drm/gem: shadow_fb_access: Prepare imported buffers for CPU access
> >>>> - Use src as variable name for iosys_map (Thomas)
> >>>> - Prepare imported buffer for CPU access in the driver (Thomas)
> >>>> - New patch: make sync flushing the default (Thomas)
> >>>> - Link to v1: https://lore.kernel.org/r/20221122-gud-shadow-plane-v1-0-9de3afa3383e@tronnes.org
> >>>
> >>> <formletter>
> >>>
> >>> This is not the correct way to submit patches for inclusion in the
> >>> stable kernel tree.  Please read:
> >>>     https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> >>> for how to do this properly.
> >>>
> >>> </formletter>
> >>
> >> Care to elaborate?
> >> Is it because stable got the whole patchset and not just the one fix
> >> patch that cc'ed stable?
> > 
> > That is what triggered this, yes.
> > 
> >> This patchset was sent using the b4 tool and I can't control this
> >> aspect. Everyone mentioned in the patches gets the whole set.
> > 
> > Fair enough, but watch out, bots will report this as being a problem as
> > they can't always read through all patches in a series to notice this...
> > 
> 
> Konstantin,
> 
> Can you add a rule in b4 to exclude stable at vger.kernel.org
> (stable at kernel.org as well?) from getting the whole patchset?

stable at kernel.org is a pipe to /dev/null so that's not needed to be
messed with.

As for this needing special casing in b4, it's rare that you send out a
patch series and only want 1 or 2 of them in stable, right?

thanks,

greg k-h