From: Pekka Paalanen <ppaalanen@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm: drivers may provide multiple primary planes per CRTC
Date: Mon, 7 Dec 2020 10:45:42 +0200 [thread overview]
Message-ID: <20201207104542.10657acd@eldfell> (raw)
In-Reply-To: <1A6pssulTBjmoPioJfGenq9NdbnGjw2dhBoivqmrgraY67Gac7BoUHupkvqc7UBF_q2P5RwEcXP-m-5Jd00vC2hg-QMkGj2Ms_Jh5nLz-os=@emersion.fr>
[-- Attachment #1.1: Type: text/plain, Size: 4174 bytes --]
On Sun, 06 Dec 2020 15:24:29 +0000
Simon Ser <contact@emersion.fr> wrote:
> Sorry, I think I lost track of this thread at some point and forgot
> about it. That said…
>
> On Friday, August 7th, 2020 at 3:06 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > On Fri, Aug 07, 2020 at 12:38:02PM +0300, Pekka Paalanen wrote:
> > > On Fri, 7 Aug 2020 11:07:06 +0200
> > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > > On Thu, Aug 06, 2020 at 10:33:31AM +0000, Simon Ser wrote:
> > > > > Some drivers may expose primary planes compatible with multiple CRTCs.
> > > > > Make this clear in the docs: the current wording may be misunderstood as
> > > > > "exactly one primary plane per CRTC".
> > > > >
> > > > > Signed-off-by: Simon Ser <contact@emersion.fr>
> > > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > > ---
> > > > > drivers/gpu/drm/drm_plane.c | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> > > > > index b7b90b3a2e38..108a922e8c23 100644
> > > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > > @@ -49,8 +49,8 @@
> > > > > * &struct drm_plane (possibly as part of a larger structure) and registers it
> > > > > * with a call to drm_universal_plane_init().
> > > > > *
> > > > > - * Cursor and overlay planes are optional. All drivers should provide one
> > > > > - * primary plane per CRTC to avoid surprising userspace too much. See enum
> > > > > + * Cursor and overlay planes are optional. All drivers should provide at least
> > > > > + * one primary plane per CRTC to avoid surprising userspace too much. See enum
> > > >
> > > > I think that's even more confusing, since this reads like there could be
> > > > multiple primary planes for a specific CRTC. That's not the case, there'
> > > > only one pointer going from drm_crtc->primary to a drm_plane in the
> > > > kernel.
> > >
> > > There could be multiple primary planes *usable* for a specific CRTC but
> > > just one used at a time, right?
> >
> > I'm not sure what you mean here, the crtc->primary link is invariant over
> > the lifetime of a driver load. You can't pick a different one, that's set
> > at driver init before drm_dev_register (and hence before userspace ever
> > sees anything).
>
> OK. I'm personally not very interested in documenting legacy bits, so I'll skip
> that. I'm mainly interested here in making it clear possible_crtcs for a
> primary plane can have more than one bit set. Because of the paragraph in the
> current docs, some user-space developers have understood "more than one bit set
> in possible_crtcs for a primary plane is a kernel bug".
>
> I'll send a v2 that makes it clear these pointers are for legacy uAPI.
Right, so this and what danvet said seem to be in direct conflict in
atomic uAPI, repeating above:
> > I'm not sure what you mean here, the crtc->primary link is invariant over
> > the lifetime of a driver load. You can't pick a different one, that's set
> > at driver init before drm_dev_register (and hence before userspace ever
> > sees anything).
But still, it is considered not a kernel bug that a primary plane has
more than one bit set in its possible_crtcs.
If a primary plane has more than one bit set in possible_crtcs, and it
is not a kernel bug, then userspace expects to be able to choose any
of the multiple indicated possible CRTCs for this primary plane.
Which way is it?
Or, is there a different limitation that for each CRTC, there must be
exactly one primary plane with that CRTCs bit set in its possible_crtcs?
IOW, you can have more CRTCs than primary planes in total, and you can
activate each CRTC alone, but you cannot activate all CRTCs
simultaneously because there are not enough primary planes for them?
Representing it mathematically, the possible assignments according to
possible_crtcs while ignoring all other limitations are:
N CRTCs <-> M primary planes
- Is N one or greater than one?
- Is M one or greater than one?
Thanks,
pq
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-12-07 8:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 10:33 [PATCH] drm: drivers may provide multiple primary planes per CRTC Simon Ser
2020-08-07 9:07 ` Daniel Vetter
2020-08-07 9:33 ` Simon Ser
2020-08-07 13:03 ` Daniel Vetter
2020-08-07 9:38 ` Pekka Paalanen
2020-08-07 13:06 ` Daniel Vetter
2020-12-06 15:24 ` Simon Ser
2020-12-07 8:45 ` Pekka Paalanen [this message]
2020-12-07 9:10 ` Simon Ser
2020-12-09 0:36 ` Daniel Vetter
2020-12-09 8:23 ` Pekka Paalanen
2020-12-09 10:40 ` Daniel Vetter
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=20201207104542.10657acd@eldfell \
--to=ppaalanen@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.