[PATCH] drm: rework description of primary and cursor planes

[Alex Deucher]

On Thu, Dec 10, 2020 at 10:56 AM Daniel Vetter <daniel at ffwll.ch> wrote:
>
> On Thu, Dec 10, 2020 at 4:45 PM Simon Ser <contact at emersion.fr> wrote:
> > On Wednesday, December 9th, 2020 at 8:40 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > > But it's not enough, can't have two CRTCs with the same primary plane. Well,
> > > > I give up, it's just simpler to use Daniel's criteria.
> > >
> > > Yeah, also with the validation check we'll now real quick if any driver
> > > gets it wrong. Then I think we can have a useful discussion about why, and
> > > what to do with that case. As-is we're kinda drafting specs in the void,
> > > which is always a bit tough ...
> > >
> > > That's kinda another reason for doing the stricter check I proposed, it's
> > > easier to check and guarantee (on both the driver and compositor side
> > > hopefully).
> >
> > Hmm, actually, I'm already hitting a driver which doesn't guarantee that.
> > amdgpu with my hardware [1] has the first primary plane linked to the the last
> > CRTC, the second primary plane linked to the second-to-last CRTC, and so on.
> >
> > [1]: https://drmdb.emersion.fr/devices/129e158a4d9f
>
> Huh so crtc are registered forward and planes backward? I guess adding
> amd people. And yeah sounds like defacto you can't figure out which
> primary plane goes to which crtc, and we just take whatever goes.
> Maybe that stricter approach with more guarantees just doesn't work,
> ship sailed already :-/

IIRC, we used to register them both the same way, but ended up
reversing the order at some point because the direct mapping didn't
work for some reason.  This was years ago though, so the details are
hazy.  Maybe Harry or Leo remembers more details?

Alex

> -Daniel
>
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch