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

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Apr 17, 2018 at 05:37:25PM +0300, Tomi Valkeinen wrote:
> Hi Rob,
> 
> On 09/04/18 21:17, Rob Herring wrote:
> 
> >>> For HDMI, you can't know in advance what resolution will be. So I
> >>> think you always need to reserve 2 planes. Now, if you want to reduce
> >>
> >> We can decide not to support 2k+ resolutions for HDMI, which, with this
> >> series, happens by not reserving dual-plane for the HDMI.
> > 
> > Right. So turn this around. Define in DT what is the maximum
> > resolution supported for HDMI and configure the planes based on that.
> 
> 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.

And reassigning hw planes is allowed to be really expensive, that's why we
have the ALLOW_MODESET flag so userspace can choose whether it wants to
allow expensive reassignment or not.

For examples, see what msm folks are trying to do right now.
-Daniel

> >> But reserve how many of the planes? We have N planes and M displays. For
> >> some of the displays we know they're 2k+, some are known to be -2k and
> >> some are unknown. The driver can't independently make any sensible
> >> static reservation of the planes for the displays, because it doesn't
> >> know what the user wants to do.
> > 
> > After you've handled HDMI as above and any permanently attached panels
> > with fixed resolutions, what is left for a user to configure? Perhaps
> > only one display can support an overlay at that point because you are
> > out of planes?
> 
> I think I covered this in the example use cases above.
> 
> >> So either we reserve the extra planes at runtime on demand, making it
> >> difficult to manage for the userspace, or we rely on the user to give
> >> the driver a static partitioning of the planes according to the user's
> >> use case.
> > 
> > And by user, who do you mean exactly? The use case is tied to the
> > board design and product or tied to the whims of an end user (e.g. I
> > want to do video playback with overlay to disp 2)? You should equate
> > users making DT changes with telling users to update/change their
> > BIOS.
> 
> By user I mean the owner of the device, but it in some cases it could be
> the vendor too.
> 
> If we have a board with HDMI that can support 2k+, then the board vendor
> could provide DT files that do not specify virtual planes (so no 2k+),
> but give instructions how to define them for the users who want 2k+. So
> here the end user needs to deal with the static partitioning.
> 
> If we have a board with a fixed resolution 2k+ LCD, then the vendor has
> to have a virtual plane defined in the DT, and the vendor has to pick a
> configuration that it thinks is most useful.
> 
> And yes, it sucks to have to make changes in the DT or BIOS, but I still
> don't see a (good) alternative.
> 
> I think one option is to have the detailed DT configuration optional:
> 
> We'd have a flag in the DT to mark that a display supports 2k+ (or the
> max-resolution property as you suggested). Based on that, the driver
> guesses what kind of setup the user wants, which probably is just to set
> up planes in a way that each display has a fully functional "root"
> plane, and then split the remaining ones in some way.
> 
> But the user could also have detailed DT descriptions for the planes
> when he needs a more special setup.
> 
>  Tomi
> 
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel