Received-SPF: pass (google.com: domain of linux-kernel+bounces-27423-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <47c6866a-34d6-48b1-a977-d21c48d991dc@igalia.com>
Date: Tue, 16 Jan 2024 10:35:16 -0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane
 check for async
Content-Language: en-US
To: Pekka Paalanen <ppaalanen@gmail.com>
Cc: dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
 linux-kernel@vger.kernel.org, kernel-dev@igalia.com,
 alexander.deucher@amd.com, christian.koenig@amd.com,
 Simon Ser <contact@emersion.fr>, daniel@ffwll.ch,
 Daniel Stone <daniel@fooishbar.org>, =?UTF-8?B?J01hcmVrIE9sxaHDoWsn?=
 <maraeo@gmail.com>, Dave Airlie <airlied@gmail.com>,
 ville.syrjala@linux.intel.com, Xaver Hugl <xaver.hugl@gmail.com>,
 Joshua Ashton <joshua@froggi.es>
References: <20240116045159.1015510-1-andrealmeid@igalia.com>
 <20240116114522.5b83d8b6@eldfell>
 <a6099681-1ae9-48ef-99bc-d3c919007413@igalia.com>
 <20240116151414.10b831e6@eldfell>
From: =?UTF-8?Q?Andr=C3=A9_Almeida?= <andrealmeid@igalia.com>
In-Reply-To: <20240116151414.10b831e6@eldfell>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

+ Joshua

Em 16/01/2024 10:14, Pekka Paalanen escreveu:
> On Tue, 16 Jan 2024 08:50:59 -0300
> André Almeida <andrealmeid@igalia.com> wrote:
> 
>> Hi Pekka,
>>
>> Em 16/01/2024 06:45, Pekka Paalanen escreveu:
>>> On Tue, 16 Jan 2024 01:51:57 -0300
>>> André Almeida <andrealmeid@igalia.com> wrote:
>>>    
>>>> Hi,
>>>>
>>>> AMD hardware can do more on the async flip path than just the primary plane, so
>>>> to lift up the current restrictions, this patchset allows drivers to write their
>>>> own check for planes for async flips.
>>>
>>> Hi,
>>>
>>> what's the userspace story for this, how could userspace know it could do more?
>>> What kind of userspace would take advantage of this and in what situations?
>>>
>>> Or is this not meant for generic userspace?
>>
>> Sorry, I forgot to document this. So the idea is that userspace will
>> query what they can do here with DRM_MODE_ATOMIC_TEST_ONLY calls,
>> instead of having capabilities for each prop.
> 
> That's the theory, but do you have a practical example?
> 
> What other planes and props would one want change in some specific use
> case?
> 
> Is it just "all or nothing", or would there be room to choose and pick
> which props you change and which you don't based on what the driver
> supports? If the latter, then relying on TEST_ONLY might be yet another
> combinatorial explosion to iterate through.
> 

That's a good question, maybe Simon, Xaver or Joshua can share how they 
were planning to use this on Gamescope or Kwin.

> 
> Thanks,
> pq
> 
>>>> I'm not sure if adding something new to drm_plane_funcs is the right way to do,
>>>> because if we want to expand the other object types (crtc, connector) we would
>>>> need to add their own drm_XXX_funcs, so feedbacks are welcome!
>>>>
>>>> 	André
>>>>
>>>> André Almeida (2):
>>>>     drm/atomic: Allow drivers to write their own plane check for async
>>>>       flips
>>>>     drm/amdgpu: Implement check_async_props for planes
>>>>
>>>>    .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 30 +++++++++
>>>>    drivers/gpu/drm/drm_atomic_uapi.c             | 62 ++++++++++++++-----
>>>>    include/drm/drm_atomic_uapi.h                 | 12 ++++
>>>>    include/drm/drm_plane.h                       |  5 ++
>>>>    4 files changed, 92 insertions(+), 17 deletions(-)
>>>>   
>>>    
>