From: Sebastian Reichel <hidden> Date: 2013-12-12 10:05:28
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
quoted
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
-- Sebastian
From: Tomi Valkeinen <hidden> Date: 2013-12-12 14:13:04
On 2013-12-12 12:05, Sebastian Reichel wrote:
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
quoted
quoted
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.
Tomi
Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
On 2013-12-12 12:05, Sebastian Reichel wrote:
quoted
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
quoted
quoted
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
From: Tomi Valkeinen <hidden> Date: 2013-12-12 14:19:01
On 2013-12-12 16:15, Laurent Pinchart wrote:
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 ?
drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
for connectors and encoders. Maybe from those.
Tomi
From: Sebastian Reichel <hidden> Date: 2013-12-12 17:31:33
On Thu, Dec 12, 2013 at 04:19:01PM +0200, Tomi Valkeinen wrote:
On 2013-12-12 16:15, Laurent Pinchart wrote:
quoted
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 ?
drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
for connectors and encoders. Maybe from those.
The xrandr names are generated from the list Tomi mentioned.
=> drm_connector_enum_list
This requires a mapping from omapdss types to DRM types, which is
done in drivers/gpu/drm/omapdrm/omap_drv.c:get_connector_type().
Currently only HDMI and DVI are handled properly.
-- Sebastian
From: Tomi Valkeinen <hidden> Date: 2013-12-13 12:01:22
On 2013-12-12 16:13, Tomi Valkeinen wrote:
On 2013-12-12 12:05, Sebastian Reichel wrote:
quoted
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
quoted
quoted
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.
I came to the conclusion that it's better to add the label to keep
backward compatibility, especially as it was very easy to add.
So we'll have 'name' and 'alias' for each display (as we have already).
In the current non-DT boot (which is going away):
- 'alias' is created by omapdss dynamically (first display to be
registered is display0, etc.)
- 'name' comes from platform data
In the DT boot:
- 'alias' comes from the DT aliases node, or if there are no display
aliases, it's created the same way as to non-DT. The code presumes that
there either is a DT alias for all displays, or there are none.
- 'name' comes from 'label' property
In both non-DT and DT cases, if 'name' is NULL (i.e. not set in platform
data or no 'label' property), the alias is used as a name.
I think this works fine, and was a trivial change.
Tomi