On 10/24/2013 12:20 PM, Laurent Pinchart wrote: > Hi Stephen, > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
