Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support

On 16/05/14 21:01, Tony Lindgren wrote:

quoted

IMHO appending -omap-dss to a random device is an even bigger hack,
since its adding lots of bloat to the API. Let's assume there is
another OS using DT for ARM, but has no proper API for SPI
controllers and it introduces your hack to SPI devices. That would
mean each SPI device has -omap-spi appended (or -exynos-spi,
-foo-spi, ...). At least I would blame them for creating a huge
unmaintainable mess.

I think you're misunderstanding. I do not want the naming to
be Linux specific. The naming should naturally be as hardware
specific as possible. In this case something like:

compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";

Or we should probably use:

compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";

As dpi here reflects the hardware it's connected to. The dss
is probably a Linux name.

Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
wouldn't really be a good extension, as what we want is an omapdss
driver specific compatible string. So I think "-omapdss" is the best
extension if that method is used.

But I don't think that's really the point. The point is that the panel's
compatible string should be "sharp,ls037v7dw01", nothing else.

All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
only made for Linux SW reasons. So I would say they are Linux specific
SW names, even if the words themselves are also HW terms.

Not use what you're after with the SPI example though, but sounds
like that's something different.

I think Sebastien's example is just like the issue here.

 Tomi

* Tomi Valkeinen [off-list ref] [140519 02:22]:

On 16/05/14 21:01, Tony Lindgren wrote:

quoted

quoted

IMHO appending -omap-dss to a random device is an even bigger hack,
since its adding lots of bloat to the API. Let's assume there is
another OS using DT for ARM, but has no proper API for SPI
controllers and it introduces your hack to SPI devices. That would
mean each SPI device has -omap-spi appended (or -exynos-spi,
-foo-spi, ...). At least I would blame them for creating a huge
unmaintainable mess.

I think you're misunderstanding. I do not want the naming to
be Linux specific. The naming should naturally be as hardware
specific as possible. In this case something like:

compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";

Or we should probably use:

compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";

As dpi here reflects the hardware it's connected to. The dss
is probably a Linux name.

Well, "dss" or "omapdss" is as much a hardware term as "dpi". And "dpi"
wouldn't really be a good extension, as what we want is an omapdss
driver specific compatible string. So I think "-omapdss" is the best
extension if that method is used.

But I don't think that's really the point. The point is that the panel's
compatible string should be "sharp,ls037v7dw01", nothing else.

All the variations of "sharp,ls037v7dw01-dss" are not correct, and are
only made for Linux SW reasons. So I would say they are Linux specific
SW names, even if the words themselves are also HW terms.

If you really want to use only "sharp,ls037v7dw01" as the compatible
string, then you can still do that and bail out from the undesired
drivers by using of_machine_is_compatible check.

In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".
 

quoted

Not use what you're after with the SPI example though, but sounds
like that's something different.

I think Sebastien's example is just like the issue here.

Hmm is there some existing example in the kernel like that?

Regards,

Tony

On 19/05/14 19:04, Tony Lindgren wrote:

In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".

All those sound like SoC components. In that case it sounds fine to have
the device compatible contain the SoC name. We're talking here about
external, detachable devices.

quoted

quoted

Not use what you're after with the SPI example though, but sounds
like that's something different.

I think Sebastien's example is just like the issue here.

Hmm is there some existing example in the kernel like that?

No, Sebastien's example was just a hypothetical case. Here, using your
way of having SoC specific data in the .dts, we would have
"sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
sensor we'd have, say, "synaptics,xyz123-omap-spi".

 Tomi

On Mon, May 19, 2014 at 10:05:15PM +0300, Tomi Valkeinen wrote:

On 19/05/14 19:04, Tony Lindgren wrote:

quoted

In many cases however we do have multiple compatible strings that
describe how the device is wired. See drivers/tty/serial/of_serial.c
for example. It has "ns16550" but then it also has additional
"nvidia,tegra20-uart", "nxp,lpc3220-uart" and "ibm,qpace-nwp-serial".

All those sound like SoC components. In that case it sounds fine to have
the device compatible contain the SoC name. We're talking here about
external, detachable devices.

quoted

quoted

quoted

Not use what you're after with the SPI example though, but sounds
like that's something different.

I think Sebastien's example is just like the issue here.

Hmm is there some existing example in the kernel like that?

No, Sebastien's example was just a hypothetical case. Here, using your
way of having SoC specific data in the .dts, we would have
"sharp,ls037v7dw01-omap-dss", and in Sebastien's example with a touch
sensor we'd have, say, "synaptics,xyz123-omap-spi".

Yes, that's what I wanted to say :)

My name is spelled Sebastian, though. Sebastien is the French
variant as far as i know.

-- Sebastian