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. I'm not saying we should stop everything until we have a 100% solution for the rare complex cases. But we should keep them in mind and, when possible, solve problems in a way that will work for the complex cases also. >> I guess non-video devices haven't had need for those. I have had lots of >> boards with video setup that cannot be represented with simple phandles. >> I'm not sure if I have just been unlucky or what, but my understand is >> that other people have encountered such boards also. Usually the >> problems encountered there have been circumvented with some hacky video >> driver for that specific board, or maybe a static configuration handled >> by the boot loader. > > I have yet to encounter such a setup. Can you point me at a DTS for one > such setup? I do remember a couple of hypothetical cases being discussed > at one time or another, but I haven't seen any actual DTS content where > this was needed. No, I can't point to them as they are not in the mainline (at least the ones I've been working on), for obvious reasons. With a quick glance, I have the following devices in my cabinet that have more complex setups: OMAP 4430 SDP, BeagleBoneBlack + LCD, AM43xx EVM. Many Nokia devices used to have such setups, usually so that the LCD and tv-out were connected to the same video source. >> Do we have a standard way of representing the video pipeline with simple >> phandles? Or does everyone just do their own version? If there's no >> standard way, it sounds it'll be a mess to support in the future. > > It doesn't matter all that much whether the representation is standard. Again, I disagree. > 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. The video graphs have two-way links, which of course is the safest options, but also more verbose and redundant. 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). Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
