Hi Stephen,
On Thursday 24 October 2013 23:06:18 Stephen Warren wrote:
On 10/24/2013 12:20 PM, Laurent Pinchart wrote:
quoted
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.
I expect the same level of details to be needed on both the KMS and V4L sides.
Taking the example of the ADV7511 HDMI transmitter, the only change in the DT
bindings between KMS and V4L would be the compatible string. "adi,adv7511-v4l"
and "adi,adv7511-kms" is an option that I don't really like. Renaming -v4l and
-kms to different names wouldn't fundamentally change the problem.
--
Regards,
Laurent Pinchart
On Fri, Oct 25, 2013 at 01:33:11PM +0200, Laurent Pinchart wrote:
Hi Stephen,
On Thursday 24 October 2013 23:06:18 Stephen Warren wrote:
quoted
On 10/24/2013 12:20 PM, Laurent Pinchart wrote:
quoted
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.
I expect the same level of details to be needed on both the KMS and V4L sides.
Taking the example of the ADV7511 HDMI transmitter, the only change in the DT
bindings between KMS and V4L would be the compatible string. "adi,adv7511-v4l"
and "adi,adv7511-kms" is an option that I don't really like. Renaming -v4l and
-kms to different names wouldn't fundamentally change the problem.
I think that we're doing something fundamentally wrong if we use the
same device (with the same functionality) in two different subsystems.
If the device is used to display something, shouldn't we be moving the
driver to DRM?
Thierry
On 10/25/2013 12:33 PM, Laurent Pinchart wrote:
On Thursday 24 October 2013 23:06:18 Stephen Warren wrote:
quoted
On 10/24/2013 12:20 PM, Laurent Pinchart wrote:
...
quoted
quoted
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 expect the same level of details to be needed on both the KMS and V4L sides.
Taking the example of the ADV7511 HDMI transmitter, the only change in the DT
bindings between KMS and V4L would be the compatible string. "adi,adv7511-v4l"
and "adi,adv7511-kms" is an option that I don't really like. Renaming -v4l and
-kms to different names wouldn't fundamentally change the problem.
Yes, two compatible values such as "adi,adv7511-v4l" and
"adi,adv7511-kms" sounds like a bad idea.
Rather, shouldn't we have just "adi,adv7511", and the driver for that
should register itself in a way that allows either/both the top-level
DRM or top-level V4L drivers to find it, and make use of its services.
There are plenty of drivers in the kernel already that export services
through two different subsystems, e.g. a GPIO HW module that registers
as both a struct gpio_chip and a struct irq_chip, or both a struct
gpio_chip and a pinctrl device.