Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote: > However, we (as in the V4L2 community, and me personally) would have > appreciated to be CC'ed on the proposal. As you might know we already had a > solution for this problem, albeit V4L2-specific, in drivers/media/v4l2- > core/v4l2-async.c. There's a lot of people who would have liked to be on the Cc, but there's two problems: 1. the Cc list would be too big for mailing lists to accept the message, and 2. finding everyone who should be on the Cc list is quite an impossible task. > The topic is particularly hot given that a similar solution was also > proposed as part of the now defunct (or at least hibernating) common > display framework. Yes, I am aware of CDF. However, the annoying thing is that it's another case of the bigger picture not being looked at - which is that we don't need yet another subsystem specific solution to a problem which is not subsystem specific. The fact of the matter is that /anyone/ has the opportunity to come up with a generic solution to this problem, and no one did... instead, more solutions were generated - the proof is "we solved this in CDF with a CDF specific solution". :p > If I had replied to this mail thread without sleeping on it first I > might not have known better and have got half-paranoid, wondereding > whether there had been a deliberate attempt to fast-track this API > before the V4L2 developers noticed. To be perfectly clear, there is > *NO* implicit or explicit such accusation here, as I know better. What would have happened is that CDF would have been raised, and there would be a big long discussion with no real resolution. The problem would not have been solved (even partially). We'd be sitting here right now still without any kind of solution that anyone can use. Instead, what we have right now is the opportunity for people to start making use of this and solving the real problems they have with driver initialisation. For example, the IPU on iMX locks up after a number of mode changes, and it's useful to be able to unload the driver, poke about in the hardware, and reload it. Without this problem fixed, that's impossible without rebooting the kernel, because removing the driver oopses the kernel due to the broken work-arounds that it has to do - and it has to do those because this problem has not been solved, despite it being known about for /years/. > Accordingly, I would like to comment on the component API, despite the fact > that it has been merged in mainline already. The first thing that I believe > is > missing is documentation. Do you have any pending patch for that, either as > kerneldoc or as a text file for Documentation/ ? As I've read the code to > understand it I might have missed so design goals, so please bear with the > stupid questions that may follow. There's lots of things in the kernel which you just have to read the code for - and this is one of them at the moment. :) (Another is PM domains...) What I know is that this will not satisfy all your requirements - I don't want it to initially satisfy everyone's requirements, because that's just far too big a job, but it satisfies the common problem that most people are suffering from and have already implemented many badly written driver specific solutions. In other words - this is designed to _improve_ the current situation where we have lots of buggy implementions trying to work around this problem, factor that code out, and fix up those problems. Briefly, the idea is: - there is a master device - lots of these subsystems doing this already have that, whether that be ALSA or DRM based stuff. - then there are the individual component devices and their drivers. Subsystems like ALSA and DRM are not component based subsystems. These subsystems have two states - either they're initialised and the entire "card system" is known about, or they're not initialised. There is no possibility of a piecemeal approach, where they partially come up and additional stuff gets added later. With DRM, that's especially true because of how the userspace API works - to change that probably means changing stuff all the way through things like the X server and its xrandr application interface. This is probably the reason why David said at KS that DRM isn't going to do the hotplugging of components. The master device has a privileged position - it gets to make the decision about which component devices are relevant to it, and when the "card system" is fully known. As far as DT goes, we've had a long discussion about this approach in the past, and we've accepted this approach - we have the "sound" node which doesn't actually refer to any hardware block, it's a node which describes how the hardware blocks are connected together, which gets translated into a platform device. When a master device gets added, it gets added to the list of master devices, and then it's asked whether all the components that it needs a
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote: > Hi Russell, > > (CC'ing Philipp Zabel who might be able to provide feedback as a user of the > component framework) > > Could you please have a look at the questions below and provide an answer > when > you'll have time ? I'd like to bridge the gap between the component and the > V4L2 asynchronous registration implementations. I have a reply partly prepared, but I'm snowed under by the L2 cache stuff at the moment, sorry. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
Hi Russell,
(CC'ing Philipp Zabel who might be able to provide feedback as a user of the
component framework)
Could you please have a look at the questions below and provide an answer when
you'll have time ? I'd like to bridge the gap between the component and the
V4L2 asynchronous registration implementations.
On Friday 07 March 2014 00:24:33 Laurent Pinchart wrote:
> On Wednesday 26 February 2014 22:19:39 Russell King - ARM Linux wrote:
> > On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> > > Hi Russell
> > >
> > > (I suspect this my email will be rejected by ALKML too like other my
> > > recent emails, but at least other MLs will pick it up and individual CCs
> > > too, so, if replying, maybe it would be good to keep my entire reply,
> > > all the more that it's going to be very short)
> > >
> > > On Thu, 2 Jan 2014, Russell King wrote:
> > > > Subsystems such as ALSA, DRM and others require a single card-level
> > > > device structure to represent a subsystem. However, firmware tends to
> > > > describe the individual devices and the connections between them.
> > > >
> > > > Therefore, we need a way to gather up the individual component devices
> > > > together, and indicate when we have all the component devices.
> > > >
> > > > We do this in DT by providing a "superdevice" node which specifies
> > > >
> > > > the components, eg:
> > > > imx-drm {
> > > > compatible = "fsl,drm";
> > > > crtcs = <&ipu1>;
> > > > connectors = <&hdmi>;
> > > > };
> > >
> > > It is a pity linux-media wasn't CC'ed and apparently V4L developers
> > > didn't notice this and other related patches in a "clean up" series, and
> > > now this patch is already in the mainline. But at least I'd like to ask
> > > whether the bindings, defined in
> > > Documentation/devicetree/bindings/media/video-interfaces.txt and
> > > implemented in drivers/media/v4l2-core/v4l2-of.c have been considered
> > > for this job, and - if so - why have they been found unsuitable?
> > > Wouldn't it have been better to use and - if needed - extend them to
> > > cover any deficiencies? Even though the implementation is currently
> > > located under drivers/media/v4l2-code/ it's pretty generic and should be
> > > easily transferable to a more generic location.
> >
> > The component helpers have nothing to do with DT apart from solving
> > the problem of how to deal with subsystems which expect a single device,
> > but we have a group of devices and their individual drivers to cope with.
> > Subsystems like DRM and ALSA.
>
> (and V4L2)
>
> Point duly taken. First of all I want to mention that your proposal is
> greatly appreciated. This is a problem that crosses subsystem boundaries,
> and should thus be addressed centrally.
>
> However, we (as in the V4L2 community, and me personally) would have
> appreciated to be CC'ed on the proposal. As you might know we already had a
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v4l2-async.c. Whether or not this solution should have been made
> generic instead of coming up with a new separate implementation would of
> course have been debatable, but the most important point would have been to
> make sure that v4l2-async could easily be implemented on top of the common
> component architecture.
>
> The topic is particularly hot given that a similar solution was also
> proposed as part of the now defunct (or at least hibernating) common
> display framework. If I had replied to this mail thread without sleeping on
> it first I might not have known better and have got half-paranoid,
> wondereding whether there had been a deliberate attempt to fast-track this
> API before the V4L2 developers noticed. To be perfectly clear, there is
> *NO* implicit or explicit such accusation here, as I know better.
>
> Let's all take this as a positive opportunity to cooperate more closely,
> media devices still need a huge effort to be cleanly supported on modern
> hardware, and we'll need all the development power we can get.
>
> Accordingly, I would like to comment on the component API, despite the fact
> that it has been merged in mainline already. The first thing that I believe
> is missing is documentation. Do you have any pending patch for that, either
> as kerneldoc or as a text file for Documentation/ ? As I've read the code
> to understand it I might have missed so design goals, so please bear with
> the stupid questions that may follow.
>
> I'll first provide a brief comparison of the two models to make the rest of
> the comments easier to understand.
>
> v4l2-async calls the component master object v4l2_async_notifier. The base
> component child object is a v4l2_subdev instance instead of being a plain
> device. v4l2_subdev instances are stored in v4l2-async lists similarly to
> how the component framework stores objects, except that the list head is
> directly embedded inside the v4l2_
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
Hi Russell,
Time for me to jump in. The more, the merrier I suppose.
On Wednesday 26 February 2014 22:19:39 Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> > Hi Russell
> >
> > (I suspect this my email will be rejected by ALKML too like other my
> > recent emails, but at least other MLs will pick it up and individual CCs
> > too, so, if replying, maybe it would be good to keep my entire reply, all
> > the more that it's going to be very short)
> >
> > On Thu, 2 Jan 2014, Russell King wrote:
> > > Subsystems such as ALSA, DRM and others require a single card-level
> > > device structure to represent a subsystem. However, firmware tends to
> > > describe the individual devices and the connections between them.
> > >
> > > Therefore, we need a way to gather up the individual component devices
> > > together, and indicate when we have all the component devices.
> > >
> > > We do this in DT by providing a "superdevice" node which specifies
> > > the components, eg:
> > > imx-drm {
> > > compatible = "fsl,drm";
> > > crtcs = <&ipu1>;
> > > connectors = <&hdmi>;
> > > };
> >
> > It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't
> > notice this and other related patches in a "clean up" series, and now this
> > patch is already in the mainline. But at least I'd like to ask whether the
> > bindings, defined in
> > Documentation/devicetree/bindings/media/video-interfaces.txt and
> > implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for
> > this job, and - if so - why have they been found unsuitable? Wouldn't it
> > have been better to use and - if needed - extend them to cover any
> > deficiencies? Even though the implementation is currently located under
> > drivers/media/v4l2-code/ it's pretty generic and should be easily
> > transferable to a more generic location.
>
> The component helpers have nothing to do with DT apart from solving
> the problem of how to deal with subsystems which expect a single device,
> but we have a group of devices and their individual drivers to cope with.
> Subsystems like DRM and ALSA.
(and V4L2)
Point duly taken. First of all I want to mention that your proposal is
greatly appreciated. This is a problem that crosses subsystem boundaries, and
should thus be addressed centrally.
However, we (as in the V4L2 community, and me personally) would have
appreciated to be CC'ed on the proposal. As you might know we already had a
solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
core/v4l2-async.c. Whether or not this solution should have been made generic
instead of coming up with a new separate implementation would of course have
been debatable, but the most important point would have been to make sure that
v4l2-async could easily be implemented on top of the common component
architecture.
The topic is particularly hot given that a similar solution was also proposed
as part of the now defunct (or at least hibernating) common display framework.
If I had replied to this mail thread without sleeping on it first I might not
have known better and have got half-paranoid, wondereding whether there had
been a deliberate attempt to fast-track this API before the V4L2 developers
noticed. To be perfectly clear, there is *NO* implicit or explicit such
accusation here, as I know better.
Let's all take this as a positive opportunity to cooperate more closely, media
devices still need a huge effort to be cleanly supported on modern hardware,
and we'll need all the development power we can get.
Accordingly, I would like to comment on the component API, despite the fact
that it has been merged in mainline already. The first thing that I believe is
missing is documentation. Do you have any pending patch for that, either as
kerneldoc or as a text file for Documentation/ ? As I've read the code to
understand it I might have missed so design goals, so please bear with the
stupid questions that may follow.
I'll first provide a brief comparison of the two models to make the rest of
the comments easier to understand.
v4l2-async calls the component master object v4l2_async_notifier. The base
component child object is a v4l2_subdev instance instead of being a plain
device. v4l2_subdev instances are stored in v4l2-async lists similarly to how
the component framework stores objects, except that the list head is directly
embedded inside the v4l2_subdev structure instead of being part of a separate
structure allocated by the framework.
The notifier has three callback functions, bound, complete and unbind. The
bound function is called when one component has been bound to the master.
Similarly the unbind function is called when one component is about to be
unbound from the master. The complete function is called when all components
have been bound, and is thus equivalent to the bind function of the component
framework.
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
Hi Russell, Sorry for a long delay. On Wed, 26 Feb 2014, Russell King - ARM Linux wrote: [snip] > Better bindings for imx-drm are currently being worked on. Philipp > Zabel of Pengutronix is currently looking at it, and has posted many > RFC patches on this very subject, including moving the V4L2 OF helpers > to a more suitable location. OF people have been involved in that > discussion over the preceding weeks, and there's a working implementation > of imx-drm using these helpers from v4l2. Yes, I'm aware of that patch series, and I do look at the discussion from time to time, unfortunately I don't have too much time for it now. But in any case if this work is going to be used with imx-drm too, that should be a good direction to take, I think. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Wed, Feb 26, 2014 at 10:00:25PM +0100, Guennadi Liakhovetski wrote:
> Hi Russell
>
> (I suspect this my email will be rejected by ALKML too like other my
> recent emails, but at least other MLs will pick it up and individual CCs
> too, so, if replying, maybe it would be good to keep my entire reply, all
> the more that it's going to be very short)
>
> On Thu, 2 Jan 2014, Russell King wrote:
>
> > Subsystems such as ALSA, DRM and others require a single card-level
> > device structure to represent a subsystem. However, firmware tends to
> > describe the individual devices and the connections between them.
> >
> > Therefore, we need a way to gather up the individual component devices
> > together, and indicate when we have all the component devices.
> >
> > We do this in DT by providing a "superdevice" node which specifies
> > the components, eg:
> >
> > imx-drm {
> > compatible = "fsl,drm";
> > crtcs = <&ipu1>;
> > connectors = <&hdmi>;
> > };
>
> It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't
> notice this and other related patches in a "clean up" series, and now this
> patch is already in the mainline. But at least I'd like to ask whether the
> bindings, defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt and
> implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for
> this job, and - if so - why have they been found unsuitable? Wouldn't it
> have been better to use and - if needed - extend them to cover any
> deficiencies? Even though the implementation is currently located under
> drivers/media/v4l2-code/ it's pretty generic and should be easily
> transferable to a more generic location.
The component helpers have nothing to do with DT apart from solving
the problem of how to deal with subsystems which expect a single device,
but we have a group of devices and their individual drivers to cope with.
Subsystems like DRM and ALSA.
It is completely agnostic to whether you're using platform data, DT or
even ACPI - this code could *not* care less. None of that comes anywhere
near what this patch does. It merely provides a way to collect up
individual devices from co-operating drivers, and control their binding
such that a subsystem like DRM or ALSA can be presented with a "card"
level view of the hardware rather than a multi-device medusa with all
the buggy, racy, crap fsckage that people come up to make that kind of
thing work.
Now, as for the binding above, first, what does "eg" mean... and
secondly, how would a binding which refers to crtcs and connectors
have anything to do with ALSA? Clearly this isn't an example of a
binding for an ALSA use, which was talked about in the very first
line of the above commit commentry. So it's quite clear that what is
given there is an example of how it /could/ be used.
I suppose I could have instead turned imx-drm into a completely unusable
mess by not coming up with some kind of binding, and instead submitted
a whole pile of completely untested code. Alternatively, I could've
used the OF binding as you're suggesting, but that would mean radically
changing the /existing/ bindings for the IPU as a whole - something
which others are better suited at as they have a /much/ better
understanding of the complexities of this hardware than I.
So, what I have done is implemented - for a driver in staging which is
still subject to ongoing development and non-stable DT bindings -
something which allows forward progress with a *minimum* of disruption
to the existing DT bindings for everyone, while still allowing forward
progress.
Better bindings for imx-drm are currently being worked on. Philipp
Zabel of Pengutronix is currently looking at it, and has posted many
RFC patches on this very subject, including moving the V4L2 OF helpers
to a more suitable location. OF people have been involved in that
discussion over the preceding weeks, and there's a working implementation
of imx-drm using these helpers from v4l2.
I'm finding people who are working in the same area and trying to get
everyone talking to each other so that we /do/ end up with a set of
bindings for the display stuff which are suitable for everyone. Tomi
from TI has already expressed his input to this ongoing discussion.
You're welcome to get involved in those discussions too.
I hope this makes it clear, and clears up the confusion.
Thanks.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
Hi Russell
(I suspect this my email will be rejected by ALKML too like other my
recent emails, but at least other MLs will pick it up and individual CCs
too, so, if replying, maybe it would be good to keep my entire reply, all
the more that it's going to be very short)
On Thu, 2 Jan 2014, Russell King wrote:
> Subsystems such as ALSA, DRM and others require a single card-level
> device structure to represent a subsystem. However, firmware tends to
> describe the individual devices and the connections between them.
>
> Therefore, we need a way to gather up the individual component devices
> together, and indicate when we have all the component devices.
>
> We do this in DT by providing a "superdevice" node which specifies
> the components, eg:
>
> imx-drm {
> compatible = "fsl,drm";
> crtcs = <&ipu1>;
> connectors = <&hdmi>;
> };
It is a pity linux-media wasn't CC'ed and apparently V4L developers didn't
notice this and other related patches in a "clean up" series, and now this
patch is already in the mainline. But at least I'd like to ask whether the
bindings, defined in
Documentation/devicetree/bindings/media/video-interfaces.txt and
implemented in drivers/media/v4l2-core/v4l2-of.c have been considered for
this job, and - if so - why have they been found unsuitable? Wouldn't it
have been better to use and - if needed - extend them to cover any
deficiencies? Even though the implementation is currently located under
drivers/media/v4l2-code/ it's pretty generic and should be easily
transferable to a more generic location.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Feb 07, 2014 at 12:57:21PM +0100, Jean-Francois Moine wrote: > I started to use your code (which works fine, thanks), and it avoids a > lot of problems, especially, about probe_defer in a DT context. > > I was wondering if your componentised mechanism could be extended to the > devices defined by DT. It was developed against imx-drm, which is purely DT based. I already have a solution for the cubox armada DRM. -- 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". -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, 7 Feb 2014 09:46:56 + Russell King - ARM Linux wrote: > On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote: > > I've chatted a bit with Hans Verkuil about this topic at fosdem and > > apparently both v4l and alsa have something like this already in their > > helper libraries. Adding more people as fyi in case they want to > > switch to the new driver core stuff from Russell. > > It's not ALSA, but ASoC which has this. Mark is already aware of this > and will be looking at it from an ASoC perspective. Russell, I started to use your code (which works fine, thanks), and it avoids a lot of problems, especially, about probe_defer in a DT context. I was wondering if your componentised mechanism could be extended to the devices defined by DT. In the DT, when a device_node is a phandle, this means it is referenced by some other device(s), and these device(s) will not start until the phandle device is registered. Then, the idea is to do a component_add() for such phandle devices in device_add() (device_register). Pratically, - the component_add() call in device_register would not include any bind/unbind callback function, so, this should be tested in component_bind/unbind(), - component_add would not be called if the device being added already called component_add in its probe function. A simple flag in the struct device_node should solve this problem. What do you think about this? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
On Fri, Feb 07, 2014 at 10:04:30AM +0100, Daniel Vetter wrote: > I've chatted a bit with Hans Verkuil about this topic at fosdem and > apparently both v4l and alsa have something like this already in their > helper libraries. Adding more people as fyi in case they want to > switch to the new driver core stuff from Russell. It's not ALSA, but ASoC which has this. Mark is already aware of this and will be looking at it from an ASoC perspective. -- 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". -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems
I've chatted a bit with Hans Verkuil about this topic at fosdem and
apparently both v4l and alsa have something like this already in their
helper libraries. Adding more people as fyi in case they want to
switch to the new driver core stuff from Russell.
-Daniel
On Thu, Jan 2, 2014 at 10:27 PM, Russell King
wrote:
> Subsystems such as ALSA, DRM and others require a single card-level
> device structure to represent a subsystem. However, firmware tends to
> describe the individual devices and the connections between them.
>
> Therefore, we need a way to gather up the individual component devices
> together, and indicate when we have all the component devices.
>
> We do this in DT by providing a "superdevice" node which specifies
> the components, eg:
>
> imx-drm {
> compatible = "fsl,drm";
> crtcs = <&ipu1>;
> connectors = <&hdmi>;
> };
>
> The superdevice is declared into the component support, along with the
> subcomponents. The superdevice receives callbacks to locate the
> subcomponents, and identify when all components are present. At this
> point, we bind the superdevice, which causes the appropriate subsystem
> to be initialised in the conventional way.
>
> When any of the components or superdevice are removed from the system,
> we unbind the superdevice, thereby taking the subsystem down.
>
> Signed-off-by: Russell King
> ---
> drivers/base/Makefile |2 +-
> drivers/base/component.c | 379
> +
> include/linux/component.h | 31
> 3 files changed, 411 insertions(+), 1 deletions(-)
> create mode 100644 drivers/base/component.c
> create mode 100644 include/linux/component.h
>
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 94e8a80e87f8..870ecfd503af 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -1,6 +1,6 @@
> # Makefile for the Linux device tree
>
> -obj-y := core.o bus.o dd.o syscore.o \
> +obj-y := component.o core.o bus.o dd.o syscore.o \
>driver.o class.o platform.o \
>cpu.o firmware.o init.o map.o devres.o \
>attribute_container.o transport_class.o \
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> new file mode 100644
> index ..5492cd8d2247
> --- /dev/null
> +++ b/drivers/base/component.c
> @@ -0,0 +1,379 @@
> +/*
> + * Componentized device handling.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This is work in progress. We gather up the component devices into a list,
> + * and bind them when instructed. At the moment, we're specific to the DRM
> + * subsystem, and only handles one master device, but this doesn't have to be
> + * the case.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct master {
> + struct list_head node;
> + struct list_head components;
> + bool bound;
> +
> + const struct component_master_ops *ops;
> + struct device *dev;
> +};
> +
> +struct component {
> + struct list_head node;
> + struct list_head master_node;
> + struct master *master;
> + bool bound;
> +
> + const struct component_ops *ops;
> + struct device *dev;
> +};
> +
> +static DEFINE_MUTEX(component_mutex);
> +static LIST_HEAD(component_list);
> +static LIST_HEAD(masters);
> +
> +static struct master *__master_find(struct device *dev, const struct
> component_master_ops *ops)
> +{
> + struct master *m;
> +
> + list_for_each_entry(m, &masters, node)
> + if (m->dev == dev && (!ops || m->ops == ops))
> + return m;
> +
> + return NULL;
> +}
> +
> +/* Attach an unattached component to a master. */
> +static void component_attach_master(struct master *master, struct component
> *c)
> +{
> + c->master = master;
> +
> + list_add_tail(&c->master_node, &master->components);
> +}
> +
> +/* Detach a component from a master. */
> +static void component_detach_master(struct master *master, struct component
> *c)
> +{
> + list_del(&c->master_node);
> +
> + c->master = NULL;
> +}
> +
> +int component_master_add_child(struct master *master,
> + int (*compare)(struct device *, void *), void *compare_data)
> +{
> + struct component *c;
> + int ret = -ENXIO;
> +
> + list_for_each_entry(c, &component_list, node) {
> + if (c->master)
> + continue;
> +
> + if (compare(c->dev, compare_data)) {
> + component_attach_master(master, c);
> + ret = 0;
> + break;
> + }
> + }
> +
> + ret
