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

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

Hi Rob,

On 23/03/18 03:23, Rob Herring wrote:

>> Ok, I think the description was a bit unclear. So, the driver can do
>> this just fine, it can reserve hw planes dynamically when needed. The
>> problem is the userspace.
>>
>> When a DRM application starts, it sees a bunch of planes, and can see on
>> which crtcs each plane can be used. The expectation is, of course, that
>> these planes can be used normally. If the driver would dynamically
>> reserve an additional, currently unused plane, the userspace would be
>> totally baffled, as it fails to configure basic plane setups.
>>
>> For example, the userspace could see that there are two planes, usable
>> on LCD and HDMI crtcs. But mysteriously modesetting would sometimes fail
>> if the HDMI is 2k+ display. Setting up a plane on the HDMI would work,
>> except when the LCD already has a plane. Setting up two planes on the
>> LCD would work, but moving one or both planes to the HDMI would fail. Etc.
> 
> I suspect this is a common problem. Not because the h/w requires
> different allocation of planes, but because the memory bandwidth can't
> handle having a 2nd plane if the resolution is above a certain
> size/depth. So while the plane doesn't disappear, the effect is the
> same. How does DRM handle this?

I don't think DRM handles this. Each driver can probably filter out
videomodes which it knows can't be used even with single plane (we do
this on omapdrm), and also can give an error if the plane setup would
result in too high bandwidth use.

So yes, plane setups can always fail, "mysteriously" from userspace's
perspective. But I don't think it's exactly comparable to this one. The
difference is that in this case we can avoid all the userspace issues
with a simple static plane partitioning done at probe time, but I can't
see how the bandwidth issue could be solved in a similar way.

>> We could, of course, convey this information to the userspace at runtime
>> via the DRM properties, but then it would mean we'd need customized
>> applications.
>>
>> So, as far as I can see, keeping normal DRM behavior with 2k+ displays
>> on OMAP DSS requires a static virtual plane setup. The most simple setup
>> would be to just split the number of available planes by 2, but then in
>> many use cases that wastes one hw plane.
> 
> 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.

> the max resolution for some reason, I guess we could have properties
> for that. That would be more generic and work whether you need to
> change plane allocation or have a limit for other reasons.
> 
> For attached panels, you know the resolution up front and can allocate
> planes before the userspace interface is up.

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.

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.

 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