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

[Rob Herring]

On Mon, Mar 19, 2018 at 2:15 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
> Hi Rob,
>
> On 19/03/18 02:06, Rob Herring wrote:
>> On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen at ti.com> wrote:
>>> On 09/03/18 20:27, Benoit Parrot wrote:
>>>
>>>>> Is logical plane a h/w concept?
>>>>
>>>> It does represent a hardware resource.
>>>
>>> Logical plane is not a hw concept, it just describes a group of one or
>>> two HW planes. Then again, in the context of 2k+ displays, two HW planes
>>> must always be used together, so that way it could be considered a
>>> single HW resource.
>>>
>>>>> Really, I'm skeptical that any of this belongs in DT. For example,
>>>>> can't you figure out you need 2 physical planes whenever your
>>>>> panel/timing width is greater than 2048?
>>>>
>>>> As stated in the description I added above, we cannot have resources
>>>> exposed to user-space which can "disappear" dynamically.
>>>> Doing so would break user-space applications which rely on these
>>>> resources.
>>
>> Isn't this the point of atomic mode setting? If you have 2 planes
>> free, then you can support the mode, otherwise you fail. How would a
>> plane be in use if you are doing modesetting unless it is on another
>> display?
>>
>>> The question is, if not in DT, then where? I agree that this is not
>>> exactly describing the HW. But it can't be done dynamically either (or
>>> at least we have not figured out a way). And it must be user configurable.
>>
>> If you are plugging in a monitor, doesn't it have to be dynamic?
>>
>>> Module parameters are an option, but it would be somewhat difficult to
>>> give all this information there. And also, if your board has a 2k+
>>> display, you must have these configurations given to the driver, it's
>>> not optional.
>>
>> Can't you look at the panel size on boot or module load and determine
>> if you need to combine planes or not. The main difference I see is
>> that the driver would have to figure out which planes to use rather
>> than DT telling it what planes to use. Is deciding which planes a hard
>> problem?
>
> 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?

> 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
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.

Rob