Re: [RFC 4/4] drm: Add NVIDIA Tegra support

[Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>]

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

* Stephen Warren wrote:
> On 04/15/2012 02:39 AM, Thierry Reding wrote:
> > 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.
> 
> Yes, with the first way, the DRM driver will have to call
> of_platform_populate() recursively to make this work.
> 
> The thing here is that the device tree should model hardware, not be
> designed purely to match the device registration needs of the DRM
> driver. I'm not sure that it's correct to model all those devices as
> children of the top-level graphics object; I /think/ all the devices are
> flat on a single bus, and hence not children of each-other. That all
> said, I guess having the nodes as children isn't too far off how the HW
> is designed (even if the register accesses aren't on a child bus, the
> modules at least logically are grouped together in an umbrella
> situation), so I wouldn't push back on the first option above that you
> prefer.

After trying to implement this I'm not so sure anymore that this is the best
approach. I think I'll have to play around with this some more to see what
fits best.

> > 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?
> 
> Why wouldn't the default be to light up all outputs that have an
> attached display, or an algorithm something like:
> 
> * If internal LCD is present, use that
> * Else, if HDMI display plugged in, use that
> ...

That sounds doable.

> > 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.
> 
> So the device tree for those devices would disable (or not include) the
> connectors that were not present on the board.

Okay, makes sense.

> > 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?
> 
> I think a binary blob makes sense - that's the exact same format it'd
> have if read over the DDC I2C bus.

DTC has /incbin/ for that. Is arch/arm/boot/dts still the correct place for
EDID blobs? I could add tegra-medcom.edid if that's okay.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]