Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
> > On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> >>> A label property is still an option.
> >>
> >> Hmm, what do you mean? Label as in:
> >>
> >> foo : node {
> >> };
> >>
> >> Isn't that 'foo' label only visible in DT itself, as a shortcut?
> >
> > Some driver use a "label" property like this:
> >
> > foo : node {
> >
> > label = "lcd";
> >
> > ...
> >
> > };
> >
> > See for example
> >
> > Documentation/devicetree/bindings/leds/common.txt
> > Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector labels that are displayed by xrandr for
instance come from ?
--
Regards,
Laurent Pinchart
Attachment:
signature.asc
Description: This is a digitally signed message part.
