* Stephen Warren wrote:
> On 04/13/2012 03:14 AM, Thierry Reding wrote:
> > display-controllers = <&disp1 &disp2>;
> > outputs = <&lvds &hdmi &tvo &dsi>;
>
> I don't think you need both the child nodes and those two properties.
>
> In other words, I think you either want:
>
> graphics@54000000 {
> ... a bunch of child nodes
> };
>
> or you want:
>
> disp1 : dc@54200000 {
> ...
> };
> disp2 : dc@54240000 {
> ...
> };
> ... all the other graphics nodes
>
> graphics@54000000 {
> display-controllers = <&disp1 &disp2>;
> outputs = <&lvds &hdmi &tvo &dsi>;
> };
>
> In the former case, presumably the drivers for the child nodes would
> make some API call into the parent node and just register themselves
> directly as a certain type of driver, so avoiding the
> display-controllers/outputs properties.
I think I like the former better. The way I understand it the children of the
graphics node will have to be registered explicitly by the DRM driver because
of_platform_populate() doesn't work recursively. That would ensure that the
DRM driver can setup the CRTC and output registries before the other devices
call back into the DRM to register themselves.
> > /* initial configuration */
> > configuration {
> > lvds {
> > display-controller = <&disp1>;
> > output = <&lvds>;
> > };
> >
> > hdmi {
> > display-controller = <&disp2>;
> > output = <&hdmi>;
> > };
> > };
> > };
> >
> > I added an additional node for the initial configuration so that the driver
> > knows which mapping to setup at boot.
>
> Isn't that kind of thing usually set up by the video= KMS-related kernel
> command-line option? See Documentation/fb/modedb.txt. Again here, I
> think the actual display controllers would be allocated to whichever
> outputs get used on a first-come first-serve based, so no need for the
> display-controller property above either way.
Boards should still be able to boot and display a console on the "standard"
output even if the user doesn't provide a video= option. Shouldn't there be a
way for a board DTS to specify what the default (or even allowed) connections
are?
Evaluation hardware like the Harmony might have LVDS, HDMI and VGA connectors
to provide for a wide range of use cases. The Plutux for instance has only an
HDMI connector and the Medcom has only LVDS. For the Medcom it would be quite
confusing for people to suddenly see an HDMI-1 connector pop up f.e. in
xrandr. It would be equally useless for the Plutux to show up as supporting
an LVDS or VGA connector.
> > What I don't quite see yet is where to
> > attach EDID data or pass the phandle to the I2C controller for DDC/EDID
> > probing.
>
> I think there's a third node type.
>
> 1) Nodes for the display controllers in Tegra (Also known as CRTCs I
> believe)
>
> 2) Nodes for the video outputs from the Tegra chips (what you have as
> outputs above)
>
> 3) Connectors, which aren't represented in your DT above yet.
>
> I think you need to add additional nodes for (3). These are where you'd
> represent all the EDID/I2C/... stuff. Then, the nodes for the outputs
> will point at the nodes for the connectors using phandles, or vice-versa.
I see. Maybe this could be used for board-specific configuration? For
example, the Plutux could have something like this:
connectors {
hdmi {
output = <&hdmi>;
ddc = <&i2c2>;
};
};
The Medcom could have:
connectors {
lvds {
output = <&lvds>;
edid = <&edid>;
};
};
While Harmony could be more generic and provide more outputs:
connectors {
lvds {
output = <&lvds>;
ddc = <&i2c1>;
};
vga {
/* which output is used for VGA? */
output = <...>;
ddc = <&i2c2>;
hdmi {
output = <&hdmi>;
ddc = <&i2c3>;
};
};
Has there been any discussion as to how EDID data would best be represented
in DT? Should it just be a binary blob or rather some textual representation?
> (IIRC, although I didn't look at them in detail, the sdrm patches
> recently mentioned something about splitting up the various object types
> in DRM and allowing them to be represented separately, and I vaguely
> recall something along the lines of the types I mention above. I might
> expect to have a 1:1 mapping between the DRM object types and DT nodes.)
I've looked at them in more detail and I'm not sure that they're very well
suited for the Tegra. I think they may be a bit too simple to support
advanced features that will be required for Tegra. For the current state it
may be enough, but people at NVIDIA and Nouveau seem to be eager to start
working on things like 2D acceleration and I wouldn't want to convert to SDRM
now just to convert it back when somebody needs a feature that can't be added
with SDRM.
Thierry
Attachment:
pgpkxvAt37Yw1.pgp
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
