[PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Thierry Reding]

On Fri, Sep 19, 2014 at 05:28:37PM +0300, Tomi Valkeinen wrote:
> On 19/09/14 16:59, Ajay kumar wrote:
> 
> > I am not really able to understand, what's stopping us from using this
> > bridge on a board with "complex" display connections. To use ps8622 driver,
> > one needs to "attach" it to the DRM framework. For this, the DRM driver
> 
> Remember that when we talk about DT bindings, there's no such thing as
> DRM. We talk about hardware. The same bindings need to work on any
> operating system.
> 
> > would need the DT node for ps8622 bridge. For which I use a phandle.
> 
> A complex one could be for example a case where you have two different
> panels connected to ps8622, and you can switch between the two panels
> with, say, a gpio. How do you present that with a simple phandle?

How do you represent that with a graph? Whether you describe it using a
graph or a simple phandle you'll need additional nodes somewhere in
between. Perhaps something like this:

	mux: ... {
		compatible = "gpio-mux-bridge";

		gpio = <&gpio 42 GPIO_ACTIVE_HIGH>;

		panel at 0 {
			panel = <&panel0>;
		};

		panel at 1 {
			panel = <&panel1>;
		};
	};

	ps8622: ... {
		bridge = <&mux>;
	};

	panel0: ... {
		...
	};

	panel1: ... {
		...
	};

> > If some XYZ platform wishes to pick the DT node via a different method,
> > they are always welcome to do it. Just because I am not specifying a
> > video port/endpoint in the DT binding example, would it mean that platform
> > cannot make use of ports in future? If that is the case, I can add something
> 
> All the platforms share the same bindings for ps8622. If you now specify
> that ps8622 bindings use a simple phandle, then anyone who uses ps8622
> should support that.
> 
> Of course the bindings can be extended in the future. In that case the
> drivers need to support both the old and the new bindings, which is
> always a hassle.
> 
> Generally speaking, I sense that we have different views of how display
> devices and drivers are structured. You say "If some XYZ platform wishes
> to pick the DT node via a different method, they are always welcome to
> do it.". This sounds to me that you see the connections between display
> devices as something handled by a platform specific driver.
> 
> I, on the other hand, see connections between display devices as common
> properties.
> 
> Say, we could have a display board, with a panel and an encoder and
> maybe some other components, which takes parallel RGB as input. The same
> display board could as well be connected to an OMAP board or to an
> Exynos board.
> 
> I think the exact same display-board.dtsi file, which describes the
> devices and connections in the display board, should be usable on both
> OMAP and Exynos platforms. This means we need to have a common way to
> describe video devices, just as we have for other things.

A common way to describe devices in DT isn't going to give you that. The
device tree is completely missing any information about how to access an
extension board like that. The operating system defines the API by which
the board can be accessed. I imagine that this would work by making the
first component of the board a bridge of some sort and then every driver
that supports that type of bridge (ideally just a generic drm_bridge)
would also work with that display board.

Whether this is described using a single phandle to the bridge or a more
complicated graph is irrelevant. What matters is that you get a phandle
to the bridge. The job of the operating system is to give drivers a way
to resolve that phandle to some object and provide an API to access that
object.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140922/16b2b0d3/attachment.sig>