Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

On 2013-12-13 11:58, Archit Taneja wrote:

>>>> +    };
>>>> +
>>>> +    lcd0: display@0 {
>>>> +        compatible = "tpo,taal", "panel-dsi-cm";
>>>> +
>>>> +        gpios = <&gpio4 6 0>;    /* 102, reset */
>>>> +
>>>> +        lcd0_in: endpoint {
>>>> +            remote-endpoint = <&dsi1_out_ep>;
>>>> +        };
>>>> +    };
>>>
>>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>>> respectively? I don't see this for panels on other boards.
>>
>> Yes. The panels are _controlled_ with DSI. We model the child-parent
>> relationships in DT data based on the control. So an i2c peripheral is
>> controlled via i2c master, and is thus a child of the i2c master. Same
>> here. The ports/endpoints are used to define the data path, which is
>> separate thing from the control path.
>>
>> DPI panels which don't have any way to control them (except basic things
>> like gpios) are platform devices without any parent.
>>
>> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
>> master.
> 
> Ah, I thought the port/endpoint stuff had something to do with this. I
> forgot about the parent-child relationship for the control path.
> 
> In that case, for the sake of accuracy, the dsi-cm panel could get the
> "in" parameter via the parent node wherever it's used for control, like
> setting a DCS command for sleep out. And via
> omapdss_of_find_source_for_first_ep() when it's used to start data
> transfer, even though both the "in's" are finally the same dsi device?

Don't mix the DT data and the current driver =). The current driver does
not handle things properly. The driver still uses the current model,
where we don't have separate control and data path handling. I.e. both
control and data are handled via the single API, using the "in" field.

The important thing with this DT data is that in the future we can
change the driver model, if we so want, to manage data and control
separately. Or maybe add a DSI bus, as has been proposed elsewhere.

It's true that we could change the driver as you describe, but I don't
think it helps anything, as the current model in the driver only has a
single control-data path.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]