Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am Samstag, den 11.01.2014, 11:40 +0000 schrieb Russell King - ARM
Linux:
> 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.

Yes, I think the device tree bindings are in need of discussion, but
this is a separate issue. I'd be happy to hear your opinion on the
"imx-drm dt bindings" patches.

> 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.

I'm very much in favor of this particular patch being merged as soon as
sensible.

regards
Philipp

_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux