Re: [RFR 2/2] drm/panel: Add simple panel support

[Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 5732 bytes --]

On Fri, Oct 25, 2013 at 03:47:21PM +0200, Laurent Pinchart wrote:
> Hi Thierry,
> 
> 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. 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.

> > 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?

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]