On 03/07/2014 01:32 PM, Tomi Valkeinen wrote:
On 07/03/14 14:22, Andrzej Hajda wrote:
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>; } } }
If both fimd and dsi are SoC components, I don't see any strict need for that. I think the ports/endpoints are only important when dealing with external components, which can be used on any platform. For SoC internal components you can have relevant data directly in the drivers, as it is fixed (for that SoC).
Of course, if using ports for SoC internal components makes things easier for you, I don't see any problems with it either.
There are many possible connections from FIMD, some of them: FIMD ---> RGB panel, external FIMD ---> DSI, on SoC FIMD ---> eDP, on SoC FIMD ---> ImageEnhacer, on SoC
In the first case port should be created. In other cases connection could be determined by presence/absence of specific nodes, so in fact the port can be optional, almost like in my proposal :)
For OMAP, the SoC's display blocks are all inside one bigger DSS "container", so I have not seen need to represent the connections between the internal components in the DT data.
How do you deal with situation when IPs in SoC can be connected in different ways ?
Andrzej
If the display components were truly independent IPs on the SoC, then using ports might make things easier.
Tomi