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

Tomi Valkeinen tomi.valkeinen at ti.com
Fri Apr 20 07:21:35 UTC 2018


On 20/04/18 10:00, Daniel Vetter wrote:

(Adding Benoit back, he was dropped at some point in the thread)

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

Ok, thanks. This makes sense to me, and actually makes our (driver
developers) life easier... Is "Stuff randomly not working is officially
how atomic works." mentioned in the DRM documentation? I think that
sentence summarizes it quite well =).

Does the driver still have some minimal set of functionality it always
has to allow? E.g. is enabling all the available displays with the
display's native resolution (or whatever passes the mode_valid), each
with a single non-scaled full-screen primary plane, something every
driver should ensure is always possible?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


More information about the dri-devel mailing list