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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

> Now, we should try to avoid this, because then that means that the
> original binding wasn't fully describing the HW. However, at least in
> the case of these simple LCD panels, it's hard to see that there is
> anything more than what's already in Thierry's binding. Remember, the
> binding is a description of the HW, not any Linux-internal details of
> how e.g. a CDF or DRM subsystem is supposed to use the HW; that had
> better be embodied into the driver or subsystem code, which aren't
> ABIs, and hence can be easily modified/enhanced.
-- 
Regards,

Laurent Pinchart