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. 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 -- 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
