On 22/09/14 11:26, Thierry Reding wrote:
> 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@0 {
> panel = <&panel0>;
> };
>
> panel@1 {
> panel = <&panel1>;
> };
> };
>
> ps8622: ... {
> bridge = <&mux>;
> };
>
> panel0: ... {
> ...
> };
>
> panel1: ... {
> ...
> };
Yes, it's true we need a mux there. But we still have the complication
that for panel0 we may need different ps8622 settings than for panel1.
If that's the case, then I think we'd need to have two output endpoints
in ps8622, both going to the mux, and each having the settings for the
respective panel.
>>> 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.
I'm not sure I follow.
Obviously there needs to be board specific .dts file that brings the
board and the display board together. So, say, the display-board.dtsi
has a i2c touchscreen node, but the board.dts will tell which i2c bus
it's connected to.
Well, now as I wrote that, I wonder if that's possible... A node needs
to have a parent, and for i2c that must be the i2c master. Is that
something the DT overlays/fragments or such are supposed to handle?
But let's only think about the video path for now. We could have an
encoder and a panel on the board. We could describe the video path
between the encoder and the panel in the display-board.dts as that is
fixed. Then all that's needed in the board.dts is to connect the board's
video output to the encoders input with the video graph. Why would that
not work?
Sure, there's more that's needed. Common encoder and panel drivers for
one. But it all starts with a common way to describe the video devices
and the connections in the DT. If we don't have that, we don't have
anything.
> 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.
I agree it's not relevant whether we use a simple phandle or complex
graph. What matter is that we have a standard way to express the video
paths, which everybody uses.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
