[Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Daniel Vetter]

On Thu, Apr 19, 2018 at 10:11:05AM +0300, Tomi Valkeinen wrote:
> On 19/04/18 09:34, Daniel Vetter wrote:
> 
> >> But the kernel cannot know what the user wants to do, so it cannot
> >> configure the planes. If we have an HDMI output which supports 2k+ and a
> >> -2k LCD, and 4 hw planes, we can set up the planes at least in the
> >> following ways:
> >>
> >> - One virtual plane on HDMI, two normal planes on LCD. Here the normal
> >> planes can also be used on the HDMI, as long as the input width is -2k.
> >>
> >> - One virtual plane on HDMI, one virtual plane on LCD, but sometimes
> >> both planes on the same display (either HDMI or LCD).
> >>
> >> - No virtual planes (and fbdev support disabled). This needs the
> >> userspace to take care not to configure 2k+ planes. But considering that
> >> the modes supported are still quit close to 2k in width, I believe
> >> upscaling a 2k plane cover the whole display would provide quite ok image.
> >>
> >> Each of those requires a different virtual plane setup.
> > 
> > Why do you want to hardcode this in DT? The recommended approach is to
> > have a bunch of virtual planes, and runtime assign whatever hw resources
> > you need to get there. If you run out of hw planes you just fail with
> > -EINVAL in atomic_check.
> 
> That is possible, but how many userspace apps will work correctly if the
> planes work or don't work in a random manner (from userspace's point of
> view)? I like the idea more that the DRM driver exposes a lesser number
> of planes which always work, instead of exposing larger number of planes
> which sometimes do not work.
> 
> And with userspace apps, I don't mainly mean Weston and X, but instead
> the numerous custom applications the customers write themselves. Perhaps
> I'm worrying too much, but I can imagine a flood of support requests
> about why plane setup is not working when one does this or that simple
> setup.

Stuff randomly not working is officially how atomic works. That's what the
TEST_ONLY mode is for. There's a lot more than virtualized planes that
might or might not push any given plane setup over some random hw limit:
memory bandwidth, aggregate scaling limits (because not enough fifo),
thermal limits, aggregate pixel clock limits. There's all kinds of cases
where with one setup you can light up 4 planes, then move them a bit and
only 3 work. And yes sometimes that means you can't light up all the
outputs if you have a too fancy plane config on the other CRTC.

Only userspace which is written with intimate knowledge of the exact
kernel driver and hw it runs on can avoid TEST_ONLY and some kind of
fallback strategy to "render everything into the 1 single primary plane".
Both drm_hwcomposer and weston atomic have such a fallback strategy (with
various degrees of intermediate cleverness).

> Also one complication with runtime assignment is that the hw planes are
> not identical: some support YUV modes, some don't, some support scaling,
> some don't. That's probably not a show stopper, but it does limit the
> options as e.g. we can't have all virtual planes advertising YUV support
> when we have a hw plane that doesn't support YUV.

Yeah that makes it a notch more complicated to implement.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch