On Sat, Jan 11, 2014 at 12:31:19PM +0100, Robert Schwebel wrote:
> On Fri, Jan 10, 2014 at 11:23:37PM +0000, Russell King - ARM Linux wrote:
> > We do this in DT by providing a "superdevice" node which specifies
> > the components, eg:
> >
> > imx-drm {
> > compatible = "fsl,drm";
> > crtcs = <&ipu1>;
> > connectors = <&hdmi>;
> > };
>
> Saschas comment from 20140109074030.GN6750@xxxxxxxxxxxxxx isn't
> addressed yet:
This is not a comment against _this_ patch. It was a question for Sean
Paul. You can tell this by the contents of the To: and Cc: headers on
Sascha's email. If that's not what was intended, then the email headers
are misleading.
> Sascha Hauer wrote:
> > Can we have an example with a different number of
> > encoders/connectors/crtcs, like:
> >
> > exynos-drm {
> > compatible = "exynos,drm";
> > crtcs = <&fimd1>;
> > encoders = <&dp1>, <&hdmi1>, <&lvds1>;
> > connectors = <&ptn3460>, <&hdmi1>;
> > };
> >
> > Otherwise I get the impression that there is some topology of the
> > components or at least relationship between the components encoded
> > into the binding.
>
> If I remember correctly, Sascha+Philipp+Lucas still had issues with the
> bindings, but I'm not sure if they have been already addressed.
The bindings are not part of this patch. This patch doesn't even care
about DT one bit - that's part of the design goal of it. It doesn't
care about platform devices either.
All it cares about is maintaining lists of struct device pointers,
asking the master device(s) whether they have all their components, and
binding/unbinding the components at the appropriate moment. It's
completely up to the master device operations to decide how to make
these decisions, and how those decisions are made, whether it be by
looking up in DT, or ACPI, or whatever.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
