On Mon, Sep 22, 2014 at 05:04:54PM +0300, Tomi Valkeinen wrote: > On 22/09/14 10:54, Thierry Reding wrote: > > >> I wish all new display component bindings would use the video > >> ports/endpoints to describe the connections. It will be very difficult > >> to improve the display driver model later if we're missing such critical > >> pieces from the DT bindings. > > > > I disagree. Why would we want to burden all devices with a bloated > > I agree that the .dts becomes more bloated with video graph. > > > binding and drivers with parsing a complex graph when it's not even > > Hopefully not all drivers will need to do the parsing themselves. If > it's common stuff, I don't see why we can't have helpers to do the work. > > > known that it will be necessary? Evidently this device works fine > > using the current binding. Just because there are bindings to describe > > 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. The same issue exists whether you use the video graph or not. But like I said elsewhere, I think the key to making this work is by keeping the DT simple and making sure we can properly use the devices at the OS level so that we only need to make sure we have the right connections in the DT. > > ports in a generic way doesn't mean it has to be applied everywhere. > > After all the concept of ports/endpoints applies to non-video devices > > too, yet we don't require the bindings for those devices to add ports > > or endpoints nodes. > > 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. > > Also it won't be very difficult to extend the binding in a backwards > > compatible way if that becomes necessary. > > I don't know about that. More or less all the cases I've encountered > where a binding has not been good from the start have been all but "not > very difficult". > > 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. 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. While it's entirely possible to represent that using a generic graph, in most cases (at least the trivial ones) I think that's completely redundant. If you have a pipeline of two (single input/output) elements where video flows from the first to the second, then all you need is a phandle from the first element to the second element. Everything else can easily be derived. The input for the second device will be the first implicitly. No need to explicitly describe that in DT. Doing it explicitly would be redundant. Thierry
Attachment:
pgp8PTem57eBg.pgp
Description: PGP signature
