[PATCH] drm: drivers may provide multiple primary planes per CRTC

[Simon Ser]

On Monday, December 7th, 2020 at 9:45 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> > > > > > - * 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?

I think the current situation is that:

- It's perfectly fine for a driver to expose multiple bits in possible_crtcs.
  User-space can attach the primary plane to any of these CRTCs (of course, a
  primary plane still can only be attached to a single CRTC at a time). Drivers
  should provide as many primary planes as there are CRTCs.
- The legacy API doesn't expose primary planes. Some legacy IOCTLs like
  drmModeSetCrtc allow user-space to attach a FB directly to a CRTC. The driver
  needs to implicitly select a primary plane for this operation. That's the
  only case where the internal CRTC → primary plane link is used in the kernel.

Is this correct, Daniel?

So I believe M > 1 and N > 1 is possible and isn't a kernel bug. For instance
some drivers hardcode possible_crtcs to 0xFF (although it might be nicer to
user-space to set the bitmask depending on the number of CRTCs, to avoid
setting bits for non-existing CRTCs).