On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote: > On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote: > > On 23/09/14 09:21, Thierry Reding wrote: > > >> Well, I can write almost any kind of bindings, and then evidently my > > >> device would work. For me, on my board. > > > > > > Well, that's the whole problem with DT. For many devices we only have a > > > single setup to test against. And even when we have several they often > > > are derived from each other. But the alternative would be to defer > > > (possibly indefinitely) merging support for a device until a second, > > > wildly different setup shows up. That's completely unreasonable and we > > > need to start somewhere. > > > > Yes, but in this case we know of existing boards that have complex > > setups. It's not theoretical. > > Complex setups involving /this particular/ bridge and binding are > theoretical at this point, however. > > > > phandles should simply point to the next element in the pipeline and the > > > OS abstractions should be good enough to handle the details about how to > > > chain the elements. > > > > I, on the other hand, would rather see the links the other way around. > > Panel having a link to the video source, etc. > > Why? It seems much more natural to describe this using the natural flow > of data. The device furthest away from the CPU should be the target of > the phandle. That way the DT can be used to trace the flow of data down > the pipeline. > > > The video graphs have two-way links, which of course is the safest > > options, but also more verbose and redundant. > > Right. If we take that line of thinking to the extreme we end up listing > individual registers in DT so that we can safely assume that we can > control all possible aspects of the device. And the other extreme would be to have a single DT node for the logical video device with all information pertaining to it stored in C code. Extremes are never good, we need to find a reasonable middle-ground here. I believe OF graph fulfills that requirement, it might be slightly more verbose than a single phandle, but it's also much more versatile. > Like I said, this seems to be the latest response to DT ABI stability > requirement. Add as much data to a DT node as possible so that it has > higher chances of being complete. The result is often overly complex DT > content that doesn't add any real value. > > > When this was discussed earlier, it was unclear which way the links > > should be. It's true that only links to one direction are strictly > > needed, but the question raised was that if in the drivers we end up > > always going the links the other way, the performance penalty may be > > somewhat big. (If I recall right). > > I doubt that graphs will become so complex that walking it would become > a performance bottleneck. In fact if we're constantly walking the graph > we're already doing something wrong. It should only be necessary when > the pipeline configuration changes, which should hopefully not be very > often (i.e. not several times per second). -- Regards, Laurent Pinchart -- 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
