[PATCH v2 0/6] drm/gud: Use the shadow plane helper
Noralf Trønnes
noralf at tronnes.org
Thu Dec 1 13:14:42 UTC 2022
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?
Noralf.
More information about the dri-devel
mailing list