linux-kernel - Re: [PATCH v7 2/9] drm: Support per-plane async flip configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <92595a28-fcc3-4a5e-bfcb-bd25aca603b9@igalia.com>
Date: Tue, 18 Jun 2024 17:45:12 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
 dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 nouveau@...ts.freedesktop.org, intel-gfx@...ts.freedesktop.org,
 kernel-dev@...lia.com, Melissa Wen <mwen@...lia.com>,
 alexander.deucher@....com, christian.koenig@....com,
 Simon Ser <contact@...rsion.fr>, Pekka Paalanen <ppaalanen@...il.com>,
 daniel@...ll.ch, Daniel Stone <daniel@...ishbar.org>,
 Marek Olšák <maraeo@...il.com>,
 Dave Airlie <airlied@...il.com>, ville.syrjala@...ux.intel.com,
 Xaver Hugl <xaver.hugl@...il.com>, Joshua Ashton <joshua@...ggi.es>,
 Michel Dänzer <michel.daenzer@...lbox.org>,
 Sam Ravnborg <sam@...nborg.org>, Boris Brezillon <bbrezillon@...nel.org>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Nicolas Ferre <nicolas.ferre@...rochip.com>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Claudiu Beznea <claudiu.beznea@...on.dev>,
 Rodrigo Vivi <rodrigo.vivi@...el.com>, Karol Herbst <kherbst@...hat.com>,
 Lyude Paul <lyude@...hat.com>
Subject: Re: [PATCH v7 2/9] drm: Support per-plane async flip configuration

Em 18/06/2024 14:43, Dmitry Baryshkov escreveu:
> On Tue, Jun 18, 2024 at 01:18:10PM GMT, André Almeida wrote:
>> Em 18/06/2024 07:07, Dmitry Baryshkov escreveu:
>>> On Tue, 18 Jun 2024 at 12:38, Jani Nikula <jani.nikula@...ux.intel.com> wrote:
>>>>
>>>> On Tue, 18 Jun 2024, André Almeida <andrealmeid@...lia.com> wrote:
>>>>> Drivers have different capabilities on what plane types they can or
>>>>> cannot perform async flips. Create a plane::async_flip field so each
>>>>> driver can choose which planes they allow doing async flips.
>>>>>
>>>>> Signed-off-by: André Almeida <andrealmeid@...lia.com>
>>>>> ---
>>>>>    include/drm/drm_plane.h | 5 +++++
>>>>>    1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
>>>>> index 9507542121fa..0bebc72af5c3 100644
>>>>> --- a/include/drm/drm_plane.h
>>>>> +++ b/include/drm/drm_plane.h
>>>>> @@ -786,6 +786,11 @@ struct drm_plane {
>>>>>          * @kmsg_panic: Used to register a panic notifier for this plane
>>>>>          */
>>>>>         struct kmsg_dumper kmsg_panic;
>>>>> +
>>>>> +     /**
>>>>> +      * @async_flip: indicates if a plane can do async flips
>>>>> +      */
>>>>
>>>> When is it okay to set or change the value of this member?
>>>>
>>>> If you don't document it, people will find creative uses for this.
>>>
>>> Maybe it's better to have a callback instead of a static field? This
>>> way it becomes clear that it's only relevant at the time of the
>>> atomic_check().
>>>
>>
>> So we would have something like bool (*async_flip) for struct
>> drm_plane_funcs I suppose. Then each driver will implement this function and
>> check on runtime if it should flip or not, right?
>>
>> I agree that it makes more clear, but as far as I can see this is not
>> something that is subject to being changed at runtime at all, so it seems a
>> bit overkill to me to encapsulate a static information like that. I prefer
>> to improve the documentation on the struct member to see if this solves the
>> problem. What do you think of the following comment:
> 
> It looks like I keep on mixing async_flips as handled via the
> DRM_MODE_PAGE_FLIP_ASYNC and the plane flips that are governed by
> .atomic_async_check / .atomic_async_update / drm_atomic_helper_check()
> and which end up being used just for legacy cursor updates.
> 
> So, yes, those are two different code paths, but with your changes I
> think it becomes even easier to get confused between
> atomic_async_check() and .async_flip member.
> 

I see, now that I read about atomic_async_check(), it got me confused as 
well :)

I see that drivers define atomic_async_check() to tell DRM whether or 
not such plane is able to do async flips... just like I'm trying to do 
here. amdgpu implementation for that function is almost the opposite of 
the restrictions that I've implemented in this patchset:

int amdgpu_dm_plane_atomic_async_check(...) {
	/* Only support async updates on cursor planes. */
	if (plane->type != DRM_PLANE_TYPE_CURSOR)
		return -EINVAL;

	return 0;
}

Anyway, I'll try to see if the legacy cursor path might be incorporated 
somehow in the DRM_MODE_PAGE_FLIP_ASYNC path, or to come up with 
something that makes them more distinguishable.

Thanks!

> 
>> /**
>>   * @async_flip: indicates if a plane can perform async flips. The
>>   * driver should set this true only for planes that the hardware
>>   * supports flipping asynchronously. It may not be changed during
>>   * runtime. This field is checked inside drm_mode_atomic_ioctl() to
>>   * allow only the correct planes to go with DRM_MODE_PAGE_FLIP_ASYNC.
>>   */
>