[PATCH 04/14] drm/exynos: remove struct *_win_data abstraction on planes

[Daniel Stone]

Hi,

On 5 February 2015 at 12:26, Rob Clark <robdclark at gmail.com> wrote:
> On Thu, Feb 5, 2015 at 4:15 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> Yeah I noticed the zpos fun when hacking around too. Exynos should
>> probably switch defaults so that overlays are visible by default. And we
>> need to standardize the zpos property so that other drivers can use it
>> too.
>
> jfyi, I have a bit of logic in mdp5_crtc_atomic_check() (and really
> mdp4 probably needs the same) to sort attached planes and derive the
> actual hw zpos (with each layer having a unique zpos)..
>
> I suspect most hw will end up needing the same (ie. dislike having two
> overlays at same zpos), so might not be a horrible idea to make the
> atomic helpers do this sorting for us..

Same with Exynos, except it's a bit funnier still. In terms of its
hardware, each CRTC has a number of planes which have a fixed zpos.
The reason exynos_drm exposes zpos is because it sets up a fixed
number of planes for the entire device and declares they can run
across every single CRTC, and then works out from the combination of
CRTC assignment and zpos property, which hardware plane to assign it
to. This includes the primary, so if you accidentally get zpos==0 in
there, then you smash the primary plane. Or set a duplicate zpos and
then the last one in wins.

It also means if you're using multiple CRTCs (e.g. FIMD for internal
panel plus mixer for external HDMI), then you can only use 5 planes in
total, rather than 5 planes per head. (And let's not forget that each
backend has disjoint format support, so again the driver just lies to
you and claims to support them all, with a silent fallback via a
default case statement when the format isn't actually supported.
Whoops.)

I think a more ideal setup would be a much more direct 1:1 mapping
with the hardware, where each actual plane on each actual CRTC gets
exposed directly to userspace, perhaps with a fixed/read-only zpos
property to tell the userspace which plane it's actually configuring.
I suspect this would be a pretty good map to other hardware as well.

Cheers,
Daniel