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

From: Daniel Vetter <daniel@ffwll.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org, Jyri Sarha <jsarha@ti.com>,
	Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Rob Herring <robh+dt@kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node
Date: Fri, 20 Apr 2018 10:08:47 +0200	[thread overview]
Message-ID: <20180420080847.GN31310@phenom.ffwll.local> (raw)
In-Reply-To: <5efc8763-7ab8-5f4e-de40-95e2671e2af3@ti.com>

On Fri, Apr 20, 2018 at 10:21:35AM +0300, Tomi Valkeinen wrote:
> 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 =).

Hm, I think we fail to doc that properly, at least in-kernel. Improving
atomic docs is somewhere on my huge todo list still :-/

The lwn article I've written does explain the motivation behind TEST_ONLY
in detail though:

https://lwn.net/Articles/653071/

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

Strive for, sure. "Always" is a bit much since you easily might run out of
clocks (if they all run at different modes), or memmory bandwidth (if
there's too many 8k screens) and stuff like that. It's really all best
effort.

The only guarantee we give for mode_valid is that you should be able to
light this mode up if
- no other CRTC enabled,
- only using the primary plane,
- and you tried all the pixel formats of that plane (in case xrbg8888 is
  too much you might need to try out rgb565, or *shock* C8). I think in
  practice just trying xrbg8888 should be good enough, since that's what
  plymouth and other simple generic userspace requires. You're running on
  some really funky hw if that doesn't work.

Yes that guarantee is very minimal, but it's the best we can do really.

Historical note aside: The above problem is why atomic's TEST_ONLY also
works for modesets, and why atomic does updates across multiple CRTC:
Intel's gen7 was the first popular platform that had 3 pipe support but in
many situations only allowed to light up 2 outputs, not 3. Userspace died
to no end on failed modesets :-/
-Daniel
-- 
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