Sorry for interrupting,
2014-03-04 21:00 GMT+09:00 Andrzej Hajda <a.hajda@xxxxxxxxxxx>:
> 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.
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>;
};
};
};
panel and lvds node could be a child of other masters, maybe i2c or spi.
Thanks,
Inki Dae
> In case DSI panel is controlled via different bus the path should be
> specified
> explicitly.
>
> I have no strong feelings against making this binding required but as
> you have
> stated above "in this case it's obvious" and for me quite redundant.
>
> What is the gain in specifying explicitly video paths in such cases?
>
>
>> Or, as a theoretical panel, you could have a DSI controlled panel, being
>> a child of the DSI master, but the video data would come via, say,
>> parallel RGB. You can actually do that with some panels/encoders, even
>> if the concept is silly.
>
> In this case explicit binding will work also.
>
> Regards
> Andrzej
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
