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 > > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html