Hi Thierry, On Friday 25 October 2013 16:10:30 Thierry Reding wrote: > On Fri, Oct 25, 2013 at 03:47:21PM +0200, Laurent Pinchart wrote: > > On Friday 25 October 2013 10:13:15 Thierry Reding wrote: > > > On Thu, Oct 24, 2013 at 11:06:18PM +0100, Stephen Warren wrote: > > > > On 10/24/2013 12:20 PM, Laurent Pinchart wrote: > > > > > On Sunday 20 October 2013 23:07:36 Stephen Warren wrote: > > > > >> On 10/17/2013 12:07 PM, Laurent Pinchart wrote: > > > > >> ... > > > > >> > > > > >>>> As I said, anything that really needs a CDF binding to work > > > > >>>> likely isn't "simple" anymore, therefore a separate driver can > > > > >>>> easily be justified. > > > > >>> > > > > >>> The system as a whole would be more complex, but the panel could > > > > >>> be the same. We can't have two drivers for the same piece of > > > > >>> hardware in the DT world, as there will be a single compatible > > > > >>> string and no way to choose between the drivers (unlike the board > > > > >>> code world that could set device names to "foo- encoder-v4l2" or > > > > >>> "foo-encoder-drm" and live happily with that ever after). > > > > >> > > > > >> That's not true. We can certainly define two different compatible > > > > >> values for a piece of HW if we have to. We can easily control > > > > >> whether they are handled by the same or different drivers in the > > > > >> OS. > > > > > > > > > > From an implementation point of view, sure. But from a conceptual > > > > > point of view, that would make the DT bindings pretty Linux- > > > > > specific, with a description of what the operating system should do > > > > > instead of a description of what the hardware looks like. My > > > > > understanding is that we've tried pretty hard in the past not to > > > > > open that Pandora's box. > > > > > > > > > > The case I'm mostly concerned about would be two different > > > > > compatibility strings to select whether the device should be handled > > > > > by a KMS or V4L driver. I don't think that's a good idea. > > > > > > > > I wouldn't think of the two compatible values as selecting different > > > > specific Linux drivers, but rather they simply describe the HW in > > > > different levels of detail. The fact that if we know a certain level > > > > of detail about the HW means that Linux can and does create a KMS > > > > driver rather than a V4L2 driver seems like a detail that's completely > > > > hidden inside the OS. > > > > > > I've had a somewhat similar idea the other day but couldn't really put > > > it into words. Interestingly someone else mentioned a similar concept in > > > a different thread which I think describes what I had in mind as well. > > > > > > I was wondering if we couldn't use two compatible values to denote two > > > > > > interfaces that the device implements. Something along the lines of: > > > compatible = "vendor,block-name", "encoder"; > > > > > > So a driver could primarily match on "vendor,block-name", but at the > > > same time it could use the additional information of being required to > > > implement "encoder" to expose an additonal interface. > > > > Let's take the hardware architecture described in > > http://www.ideasonboard.org/media/meetings/20131024-elce.pdf#39 (page 39) > > as an example. The green blocks are part of the capture pipeline and > > handled by the V4L subsystem. The blue blocks are part of the display > > pipeline and handled by the KMS subsystem. One ADV7511 HDMI transmitter > > instance need to be controlled by a KMS driver and the second one by a > > V4L driver. > > > > The two instances are identical, so their DT nodes will show no difference > > if we stick to a hardware description only. There would then be no way to > > bind to different drivers. > > I don't quite see why some of the green parts couldn't be part of the > display (KMS) pipeline. Because there might be no blue pipeline in the device, just the green one. The green pipeline is a video capture pipeline and happens to have an HDMI output with a deep pipeline only, with no frame buffer. We can't create a KMS driver for that, as there's no frame buffer and no CRTC. > I thought I remember you say something about implementing deep pipelining > support in one of the more recent talks. This sounds exactly like a case > where this would be useful. > > Obviously as long as that work isn't finished that won't help you, but I > think that providing a way to pass a video stream object from V4L2 to > DRM/KMS would be a more proper solution to this problem. We need that as well, but it won't solve the problem when no KMS device is present. > > > I suppose that perhaps something like a device_type property could be > > > used for that as well, and that might even be the more correct thing to > > > do. > > > > > > We already do something similar to make GPIO controllers expose an > > > interrupt chip by adding an interrupt-controller property. We also use > > > the gpio-controller property to mark a device node as exposing the GPIO > > > interface for that matter. > > > > > > So if a HW block can actually implement two different interfaces, each > > > of them being optional, then there should be ways to represent that in > > > DT as well. We already do that for "simpler" HW blocks, so there's no > > > reason we shouldn't be able to do the same with multimedia components. > > > > > > If it's really an encoder, though, the problem might be different, > > > though, since the interface (at a hardware or functional level if you > > > will) remains the same. But I think in that case it's something that > > > needs to be figured out internally by the OS. In my opinion, if we are > > > in a situation where we have two different drivers in two subsystems for > > > the same device, then we're doing something wrong and it should be fixed > > > at that level, not by quirking the DT into making a decision for us. > > > > I tend to agree, and I'd like to be able to share drivers between V4L and > > KMS. This is way down the road though. > > My point is that I don't see a need for sharing the drivers if we can > make both V4L2 and DRM/KMS interoperate well enough to cover such use > cases. > > Why share the drivers if we can make it work by sharing the data? Would you like to try and merge the two subsystems ? :-) -- Regards, Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
