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

[Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>]

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

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]