Re: [RFC PATCH v2 19/21] ARM: dts: exynos5250-arndale: add dsi and panel nodes

[Andrzej Hajda <a.hajda@samsung.com>]

On 03/05/2014 01:06 PM, Inki Dae wrote:
> Sorry for interrupting,
>
>
> 2014-03-04 21:00 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>:
>> On 02/28/2014 02:39 PM, Tomi Valkeinen wrote:
>>> On 28/02/14 15:31, Tomi Valkeinen wrote:
>>>
>>>> Compared to what I've done on OMAP, you don't seem to specify the video
>>>> inputs for the tc358764 at all. In this case it's obvious, as the chip
>>>> is a child of the DSI master. But the chip could as well be controlled
>>>> via i2c, and so be placed as a child of the i2c nodes.
>>>>
>>>> So even if the driver doesn't use it, maybe it would be more future
>>>> proof to have both input and output endpoints for the tc358764?
>>> Oh, and one addition: how me and Laurent see the DSI case (and other
>>> similar ones), the child/parent relationship gives the control bus path,
>>> and the video ports give the video data path.
>>>
>>> So both are always needed. A DSI panel may be controlled via DSI, i2c,
>>> spi, but the video path will always go from DSI master to the panel.
>> I have made video path binding optional, in case of video bus
>> if the specific video path is not present driver uses the bus it is
>> connected to.
> You mean the case that video path isn't wrote in dt file for some
> machine? If so, shouldn't we always write video patch in the dt file
> correctly? I'm not sure the optional binding is needed because which
> bus and which panel are used depends on machine.
>
> And If I understood correctly the video interfaces document, it seems
> that you don't deal with the document.
I have followed the document, I have even specified it in bridge bindings.
I have just made those bindings optional in case control bus is the same
as video bus - DSI master/slave case.
>
> The below is simple dt binding I think in case that video path goes
> from MIPI-DSI to LVDS bridge, and then from LVDS bridge to LCD Panel,
>
> panel {
>         ...
>         port {
>                 ...
>                 panel_0: endpoint {
>                         remote-endpoint=<&lvds_1>;
>                 };
>         };
> };
>
> lvds {
>        ...
>        port@1 {
>                ...
>                lvds_0: endpoint {
>                        remote-endpoint=<&dsi_0>;
>                };
>        };
>        port@2 {
>               ...
>               lvds_1: endpoint {
>                        remote-endpoint=<&panel_0>;
>               };
>        };
> };
>
> dsi {
>         ...
>         port {
>                 dsi_0: endpoint {
>                         remote-endpoint=<&lvds_0>;
>                 };
>         };
> };
>
I think we should even extend the bindings to fimd:
dsi {
    port@0 {
        dsi_0: endpoint {
            remote-endpoint=<&fimd_0>;
        }
    }
    port@1 {
        dsi_1: endpoint {
            remote-endpoint=<&lvds_0>;
        }
    }
}

fimd {
    port@0 {
        fimd_0: endpoint {
            remote-endpoint=<&dsi_0>;
        }
    }
}


> panel and lvds node could be a child of other masters, maybe i2c or spi.
As I mentioned earlier, in such cases bindings should be specified
explicitly.
My proposition of omitting obvious bindings was made to simplify a bit
dts files,
but as I stated earlier it is not something I want to die for :)

Regards
Andrzej