Hi Thierry, On Friday 25 October 2013 14:29:26 Thierry Reding wrote: > On Fri, Oct 25, 2013 at 01:33:11PM +0200, Laurent Pinchart wrote: > > On Thursday 24 October 2013 23:06:18 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 expect the same level of details to be needed on both the KMS and V4L > > sides. Taking the example of the ADV7511 HDMI transmitter, the only > > change in the DT bindings between KMS and V4L would be the compatible > > string. "adi,adv7511-v4l" and "adi,adv7511-kms" is an option that I don't > > really like. Renaming -v4l and -kms to different names wouldn't > > fundamentally change the problem. > > I think that we're doing something fundamentally wrong if we use the > same device (with the same functionality) in two different subsystems. > If the device is used to display something, shouldn't we be moving the > driver to DRM? Let's discuss this in reply to the e-mail from this thread in which I mention the ADV7511 example. -- Regards, Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
