From: Pekka Paalanen <ppaalanen@gmail.com>
To: "André 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 Olšák'" <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
Date: Tue, 16 Jan 2024 15:14:14 +0200 [thread overview]
Message-ID: <20240116151414.10b831e6@eldfell> (raw)
In-Reply-To: <a6099681-1ae9-48ef-99bc-d3c919007413@igalia.com>
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
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.
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(-)
> >>
> >
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-16 13:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 4:51 André Almeida
2024-01-16 4:51 ` [PATCH 1/2] drm/atomic: Allow drivers to write their own plane check for async flips André Almeida
2024-01-19 22:12 ` kernel test robot
2024-01-16 4:51 ` [PATCH 2/2] drm/amdgpu: Implement check_async_props for planes André Almeida
2024-01-16 9:45 ` [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async Pekka Paalanen
2024-01-16 11:50 ` André Almeida
2024-01-16 13:14 ` Pekka Paalanen [this message]
2024-01-16 13:35 ` André Almeida
[not found] ` <CAFZQkGyOQ5Tfu++-cHqgZ9NOJxqxm8cAF5XT18LmisuPAUbXAg@mail.gmail.com>
2024-01-17 8:55 ` Pekka Paalanen
2024-01-17 12:57 ` Xaver Hugl
2024-01-17 14:18 ` Michel Dänzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240116151414.10b831e6@eldfell \
--to=ppaalanen@gmail.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrealmeid@igalia.com \
--cc=christian.koenig@amd.com \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maraeo@gmail.com \
--cc=ville.syrjala@linux.intel.com \
--cc=xaver.hugl@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome