Received-SPF: pass (google.com: domain of linux-kernel+bounces-27409-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Tue, 16 Jan 2024 15:14:14 +0200
From: Pekka Paalanen <ppaalanen@gmail.com>
To: =?UTF-8?B?QW5kcsOp?= Almeida <andrealmeid@igalia.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>, 'Marek =?UTF-8?B?T2zFocOhayc=?= <maraeo@gmail.com>,
 Dave Airlie <airlied@gmail.com>, ville.syrjala@linux.intel.com, Xaver Hugl
 <xaver.hugl@gmail.com>
Subject: Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane
 check for async
Message-ID: <20240116151414.10b831e6@eldfell>
In-Reply-To: <a6099681-1ae9-48ef-99bc-d3c919007413@igalia.com>
References: <20240116045159.1015510-1-andrealmeid@igalia.com>
	<20240116114522.5b83d8b6@eldfell>
	<a6099681-1ae9-48ef-99bc-d3c919007413@igalia.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/i2t6EBxqq.bTAjLBweow2/Q";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Sig_/i2t6EBxqq.bTAjLBweow2/Q
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 16 Jan 2024 08:50:59 -0300
Andr=C3=A9 Almeida <andrealmeid@igalia.com> wrote:

> Hi Pekka,
>=20
> Em 16/01/2024 06:45, Pekka Paalanen escreveu:
> > On Tue, 16 Jan 2024 01:51:57 -0300
> > Andr=C3=A9 Almeida <andrealmeid@igalia.com> wrote:
> >  =20
> >> 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 w=
rite their
> >> own check for planes for async flips. =20
> >=20
> > Hi,
> >=20
> > 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 situati=
ons?
> >=20
> > Or is this not meant for generic userspace? =20
>=20
> Sorry, I forgot to document this. So the idea is that userspace will=20
> query what they can do here with DRM_MODE_ATOMIC_TEST_ONLY calls,=20
> 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.


Thanks,
pq

> >> I'm not sure if adding something new to drm_plane_funcs is the right w=
ay 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=C3=A9
> >>
> >> Andr=C3=A9 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(-)
> >> =20
> >  =20


--Sig_/i2t6EBxqq.bTAjLBweow2/Q
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAmWmgSYACgkQI1/ltBGq
qqcJGhAAmfkcI63j+PXidMJLZ9COPIfRspF9wDzlPbiyZOH2nvffM9dDdNKWIm+j
8dMw6bbmp8/AjEdymqKUmqsI0u0G8/otViBEYHA5DPJTNZxmFDW5awvwPZo/86fL
i8jfM9XTDN637bQKorVUR+QEu/CXag/IH5R19YT5QSRfmKGwvfvOYKkdHwAoe29m
Zazcouunhbns8EeRQnxWrwFpn7+gQunM79AwaUt88CxyFFbpxN9t6iU0UThtNFnb
CYKjIwIvYsE3ncULhV47giKpd05tSP0yRDBdPCVgzZO80n16yzvtZDe3pzQGZd2p
4zxOzYmDlu8789qfQReCCzQWoAJ9Wn5H7o4WH09gygqbRtEhpaUbbjX+WQJVl5j5
WCyH2ezdqOSz6mGN1Un9t1thK9oE13fM5v/EdCj+DWUsJbUEeoMcI2ymcBoHWB9C
GSetbRreGTejPDnCvW7c5i4Aa1TxJHHuNWLeBH2MbjLIjzSE/TCBaSoyJr/lol1L
xkDBFD6fnIIK9aNzkAFLjHZDZU/xOz06JlG/CtEE4cOmXfWrm/3PCzCXBF2C5FZn
ppeC1BKzvDIlgA9+lwV+H1YIN7xAc4EDYbksjCWpQwmZAYTcfJrLv732nA7ysRdr
92k6OK5F8WoaaZor9qs2dIT6lUbUoATCzJnY2yoXNl6si+ERA3g=
=EpBy
-----END PGP SIGNATURE-----

--Sig_/i2t6EBxqq.bTAjLBweow2/Q--