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

Hi Stephen,

On Sunday 20 October 2013 23:07:36 Stephen Warren wrote:

On 10/17/2013 12:07 PM, Laurent Pinchart wrote:
...

quoted

quoted

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

On 10/24/2013 12:20 PM, Laurent Pinchart wrote:

Hi Stephen,

On Sunday 20 October 2013 23:07:36 Stephen Warren wrote:

quoted

On 10/17/2013 12:07 PM, Laurent Pinchart wrote:
...

quoted

quoted

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.