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

From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Jyri Sarha <jsarha@ti.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Date: Mon, 19 Mar 2018 09:15:50 +0200	[thread overview]
Message-ID: <c3b9897f-aae0-35b1-e4e9-99b904d47cda@ti.com> (raw)
In-Reply-To: <CAL_JsqJxDTj66V5eGYgQErhXZf6sfp=99De2XqaX+GyD7NCtGw@mail.gmail.com>

Hi Rob,

On 19/03/18 02:06, Rob Herring wrote:
> On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen <tomi.valkeinen@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.

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.

 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