Re: [PATCH 0/9] Doc/DT: DT bindings for various display components

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

On 28/02/14 18:27, Russell King - ARM Linux wrote:
> On Fri, Feb 28, 2014 at 02:20:07PM +0200, Tomi Valkeinen wrote:
>> Shortly about the display components in the series, in the order of probable
>> public interest:
>>
>> * Analog TV, DVI and HDMI Connectors represent a respective connector on the
>>   board. They don't do much, but they do mark the end of the video pipeline (from
>>   the board's pov), and they should also in the future offer ways to handle
>>   things like the +5V pin on DVI and HDMI connector and HPD pin.
> 
> The big thing which concerns me is that we're using very generic
> compatible strings here - has anyone done any searches to see whether
> there are any existing standards for this kind of stuff already?

I did look for any display related DT bindings when I started the work
on OMAP DSS DT bindings. I didn't really find any. If I recall right,
the only thing I found was an example of basically:

fb@1234567 {
	compatible="asd";
	reg=<1234567>;
};

So just a node for "framebuffer", with the register addresses. And maybe
video timings in some form.

Maybe I didn't know where to look.

> Even if none can be found, if we're going to create something like
> this, it should probably become a public standard not just for Linux.

This is totally unclear to me. How does it become a public standard?
What's the forum for this?

> If we're not willing to do that, I'd suggest prefixing the compatible
> strings with "linux," as a "company" identifier so that there's no
> chance that we may hit some major problem caused by a conflicting
> implementation in the future.

I don't have an issue with "linux," either. We could always later remove
the prefix (but keep drivers compatible with it). So it sounds quite a
safe approach to me, if we're not quite clear if these bindings are
acceptable, or how to get "public approval" for them.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]