On 03/07/2014 02:28 PM, Tomi Valkeinen wrote: (...) > 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 > This sounds similar to OMAP, at least roughly. > >> 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 :) > Well, I think not. > > In the external encoder case, the ports are there, and they are used. > You just didn't specify them, and thus make the driver deduce them from > the DT. > > In the FIMD case, if the the RGB port is needed, you need to specify it > in the DT data, and it's used. If you only need, say, DSI, the RGB port > is not used and thus it doesn't need to be present in the DT data. > > It's fine to leave the port definition out if it is not used at all. On Exynos, DSI is in fact RGB/DSI encoder (or I80/DSI). DSI and RGB pins are connected to the same FIMD output. So from FIMD point of view RGB port is used in both cases. > >>> 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 ? > Basically so that (using exynos terms) if, say DSI panel is to be > enabled, the DSI panel driver will reserve the DSI master for itself, > and the DSI master will reserve the FIMD for itself, presuming FIMD has > not already been reserved. When the DSI panel is disabled, FIMD is freed. > > 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
