On 09/23/2014 01:52 PM, Laurent Pinchart wrote: > On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote: >> On 09/23/2014 01:23 PM, Laurent Pinchart wrote: >>> On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote: >>>> On 09/23/2014 01:10 PM, Laurent Pinchart wrote: >>>>> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote: >>>>>> On 09/23/2014 11:30 AM, 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. >>>>>>> >>>>>>> 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). >>>>>> >>>>>> I do not see why performance may drop significantly? >>>>>> If the link is one-way it should probably work as below: >>>>>> - the destination registers itself in some framework, >>>>>> - the source looks for the destination in this framework using phandle, >>>>>> - the source starts to communicate with the destination - since now >>>>>> full two way link can be established dynamically. >>>>>> >>>>>> Where do you see here big performance penalty? >>>>> >>>>> The performance-related problems arise when you need to locate the >>>>> remote device in the direction opposite to the phandle link direction. >>>>> Traversing a link forward just involves a phandle lookup, but traversing >>>>> it backwards isn't possible the same way. >>>> >>>> But you do not need to traverse backwards. You just wait when the source >>>> start to communicate with the destination, at this moment destination can >>>> build back-link dynamically. >>> >>> Your driver might not need it today for your use cases, but can you be >>> certain that no driver on any OS would need to ? >> >> I have just showed how to create back-link dynamically if we have only >> forward-link in DT. >> Ie it is a trivial 'proof' that the direction is not so important. >> So I do not understand why do you pose such question? >> >>> This becomes an issue even on Linux when considering video-related devices >>> that can be part of either a capture pipeline or a display pipeline. If >>> the link always goes in the data flow direction, then it will be easy to >>> locate the downstream device (bridge or panel) from the display controller >>> driver, but it would be much more difficult to locate the same device from >>> a camera driver as all of a sudden the device would become an upstream >>> device. >> >> Why? >> >> If you have graph: >> sensor --> camera >> >> Then camera register itself in some framework as a destination device >> and sensor looks in this framework for the device identified by remote >> endpoint. >> Then sensor tells camera it is connected to it and voila. > > Except that both kernelspace and userspace deal with cameras the other way > around, the master device is the camera receiver, not the camera sensor. DRM > is architected the same way, with the component that performs DMA operations > being the master device.
But the link direction do not determines who should be the master device. It just determines who should perform initial handshake. Andrzej -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
