Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
Quoting Daniel Vetter (2022-02-08 04:53:59) > On Mon, Jan 31, 2022 at 05:34:26PM +0100, Greg Kroah-Hartman wrote: > > On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > > > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > > > tell the host driver that it is time to assemble the aggregate driver > > > > > now that all the components have probed. The component framework > > > > > doesn't > > > > > attempt to resolve runtime PM or suspend/resume ordering, and > > > > > explicitly > > > > > mentions this in the code. This lack of support leads to some pretty > > > > > gnarly usages of the 'prepare' and 'complete' power management hooks > > > > > in > > > > > drivers that host the aggregate device, and it fully breaks down when > > > > > faced with ordering shutdown between the various components, the > > > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm > > > > > is > > > > > using 'prepare' and 'complete' to call the drm helpers > > > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > > > respectively, so that it can move the aggregate driver suspend/resume > > > > > callbacks to be before and after the components that make up the drm > > > > > device call any suspend/resume hooks they have. This only works as > > > > > long > > > > > as the component devices don't do anything in their own 'prepare' and > > > > > 'complete' callbacks. If they did, then the ordering would be > > > > > incorrect > > > > > and we would be doing something in the component drivers before the > > > > > aggregate driver could do anything. Yuck! > > > > > > > > > > Similarly, when trying to add shutdown support to the MSM driver we > > > > > run > > > > > across a problem where we're trying to shutdown the drm device via > > > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > > > chain have already been shutdown. This time, the component devices > > > > > aren't the problem (although they could be if they did anything in > > > > > their > > > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > > > chain that has already been shutdown before the driver hosting the > > > > > aggregate device runs shutdown. The ordering of driver probe is like > > > > > this: > > > > > > > > > > 1. msm_pdev_probe() (host driver) > > > > > 2. DSI bridge > > > > > 3. aggregate bind > > > > > > > > > > When it comes to shutdown we have this order: > > > > > > > > > > 1. DSI bridge > > > > > 2. msm_pdev_shutdown() (host driver) > > > > > > > > > > and so the bridge is already off, but we want to communicate to it to > > > > > turn things off on the display during msm_pdev_shutdown(). Double > > > > > yuck! > > > > > Unfortunately, this time we can't split shutdown into multiple phases > > > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > > > > > Let's make the component_master_ops into an actual device driver that > > > > > has > > > > > probe/remove/shutdown functions. The driver will only be bound to the > > > > > aggregate device once all component drivers have called > > > > > component_add() > > > > > to indicate they're ready to assemble the aggregate driver. This > > > > > allows > > > > > us to attach shutdown logic (and in the future runtime PM logic) to > > > > > the > > > > > aggregate driver so that it runs the hooks in the correct order. > > > > > > > > I know I asked before, but I can not remember the answer. > > > > > > > > This really looks like it is turning into the aux bus code. Why can't > > > > you just use that instead here for this type of thing? You are creating > > > > another bus and drivers for that bus that are "fake" which is great, but > > > > that's what the aux bus code was supposed to help out with, so we > > > > wouldn't have to write more of these. > > > > > > > > So, if this really is different, can you document it here so I remember > > > > next time you resend this patch series? > > > > > > aux takes a device and splits it into a lot of sub-devices, each with > > > their own driver. > > > > > > This takes a pile of devices, and turns it into a single logical > > > device with a single driver. > > > > > > So aux is 1:N, component is N:1. > > > > > > And yes you asked this already, I typed this up already :-) > > > > Ok, thanks. But then why is a bus needed if there's a single driver? > > I guess a bus for that driver? So one bus, one driver, and one device? > > Maybe? I have honestly no idea how this should be best modelled in the > linux device model. There can be one driver and multiple aggregate devices attached to that driver. This happens for the MediaTek SMMU (IOMMU) code that has two
Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Mon, Jan 31, 2022 at 05:34:26PM +0100, Greg Kroah-Hartman wrote: > On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > > tell the host driver that it is time to assemble the aggregate driver > > > > now that all the components have probed. The component framework doesn't > > > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > > > mentions this in the code. This lack of support leads to some pretty > > > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > > > drivers that host the aggregate device, and it fully breaks down when > > > > faced with ordering shutdown between the various components, the > > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > > > using 'prepare' and 'complete' to call the drm helpers > > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > > respectively, so that it can move the aggregate driver suspend/resume > > > > callbacks to be before and after the components that make up the drm > > > > device call any suspend/resume hooks they have. This only works as long > > > > as the component devices don't do anything in their own 'prepare' and > > > > 'complete' callbacks. If they did, then the ordering would be incorrect > > > > and we would be doing something in the component drivers before the > > > > aggregate driver could do anything. Yuck! > > > > > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > > > across a problem where we're trying to shutdown the drm device via > > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > > chain have already been shutdown. This time, the component devices > > > > aren't the problem (although they could be if they did anything in their > > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > > chain that has already been shutdown before the driver hosting the > > > > aggregate device runs shutdown. The ordering of driver probe is like > > > > this: > > > > > > > > 1. msm_pdev_probe() (host driver) > > > > 2. DSI bridge > > > > 3. aggregate bind > > > > > > > > When it comes to shutdown we have this order: > > > > > > > > 1. DSI bridge > > > > 2. msm_pdev_shutdown() (host driver) > > > > > > > > and so the bridge is already off, but we want to communicate to it to > > > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > > > Unfortunately, this time we can't split shutdown into multiple phases > > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > > > Let's make the component_master_ops into an actual device driver that > > > > has > > > > probe/remove/shutdown functions. The driver will only be bound to the > > > > aggregate device once all component drivers have called component_add() > > > > to indicate they're ready to assemble the aggregate driver. This allows > > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > > aggregate driver so that it runs the hooks in the correct order. > > > > > > I know I asked before, but I can not remember the answer. > > > > > > This really looks like it is turning into the aux bus code. Why can't > > > you just use that instead here for this type of thing? You are creating > > > another bus and drivers for that bus that are "fake" which is great, but > > > that's what the aux bus code was supposed to help out with, so we > > > wouldn't have to write more of these. > > > > > > So, if this really is different, can you document it here so I remember > > > next time you resend this patch series? > > > > aux takes a device and splits it into a lot of sub-devices, each with > > their own driver. > > > > This takes a pile of devices, and turns it into a single logical > > device with a single driver. > > > > So aux is 1:N, component is N:1. > > > > And yes you asked this already, I typed this up already :-) > > Ok, thanks. But then why is a bus needed if there's a single driver? > I guess a bus for that driver? So one bus, one driver, and one device? Maybe? I have honestly no idea how this should be best modelled in the linux device model. > I think we need better documentation here... https://dri.freedesktop.org/docs/drm/driver-api/component.html?highlight=component_del#component-helper-for-aggregate-drivers There's a kerneldoc overview for component, but it's for driver authors that want to use component to glue different hw pieces into a logical driver, so it skips over these internals. And I'm honestly not sure how we want to leak implementation internals like the bus/driver/device structure ot users of
Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman > wrote: > > > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > tell the host driver that it is time to assemble the aggregate driver > > > now that all the components have probed. The component framework doesn't > > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > > mentions this in the code. This lack of support leads to some pretty > > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > > drivers that host the aggregate device, and it fully breaks down when > > > faced with ordering shutdown between the various components, the > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > > using 'prepare' and 'complete' to call the drm helpers > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > respectively, so that it can move the aggregate driver suspend/resume > > > callbacks to be before and after the components that make up the drm > > > device call any suspend/resume hooks they have. This only works as long > > > as the component devices don't do anything in their own 'prepare' and > > > 'complete' callbacks. If they did, then the ordering would be incorrect > > > and we would be doing something in the component drivers before the > > > aggregate driver could do anything. Yuck! > > > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > > across a problem where we're trying to shutdown the drm device via > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > chain have already been shutdown. This time, the component devices > > > aren't the problem (although they could be if they did anything in their > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > chain that has already been shutdown before the driver hosting the > > > aggregate device runs shutdown. The ordering of driver probe is like > > > this: > > > > > > 1. msm_pdev_probe() (host driver) > > > 2. DSI bridge > > > 3. aggregate bind > > > > > > When it comes to shutdown we have this order: > > > > > > 1. DSI bridge > > > 2. msm_pdev_shutdown() (host driver) > > > > > > and so the bridge is already off, but we want to communicate to it to > > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > > Unfortunately, this time we can't split shutdown into multiple phases > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > Let's make the component_master_ops into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > I know I asked before, but I can not remember the answer. > > > > This really looks like it is turning into the aux bus code. Why can't > > you just use that instead here for this type of thing? You are creating > > another bus and drivers for that bus that are "fake" which is great, but > > that's what the aux bus code was supposed to help out with, so we > > wouldn't have to write more of these. > > > > So, if this really is different, can you document it here so I remember > > next time you resend this patch series? > > aux takes a device and splits it into a lot of sub-devices, each with > their own driver. > > This takes a pile of devices, and turns it into a single logical > device with a single driver. > > So aux is 1:N, component is N:1. > > And yes you asked this already, I typed this up already :-) Ok, thanks. But then why is a bus needed if there's a single driver? I guess a bus for that driver? So one bus, one driver, and one device? I think we need better documentation here... thanks, greg k-h
Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
Hi Daniel, On Mon, Jan 31, 2022 at 04:15:09PM +0100, Daniel Vetter wrote: > On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman wrote: > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > > The component framework only provides 'bind' and 'unbind' callbacks to > > > tell the host driver that it is time to assemble the aggregate driver > > > now that all the components have probed. The component framework doesn't > > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > > mentions this in the code. This lack of support leads to some pretty > > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > > drivers that host the aggregate device, and it fully breaks down when > > > faced with ordering shutdown between the various components, the > > > aggregate driver, and the host driver that registers the whole thing. > > > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > > using 'prepare' and 'complete' to call the drm helpers > > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > > respectively, so that it can move the aggregate driver suspend/resume > > > callbacks to be before and after the components that make up the drm > > > device call any suspend/resume hooks they have. This only works as long > > > as the component devices don't do anything in their own 'prepare' and > > > 'complete' callbacks. If they did, then the ordering would be incorrect > > > and we would be doing something in the component drivers before the > > > aggregate driver could do anything. Yuck! > > > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > > across a problem where we're trying to shutdown the drm device via > > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > > chain have already been shutdown. This time, the component devices > > > aren't the problem (although they could be if they did anything in their > > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > > chain that has already been shutdown before the driver hosting the > > > aggregate device runs shutdown. The ordering of driver probe is like > > > this: > > > > > > 1. msm_pdev_probe() (host driver) > > > 2. DSI bridge > > > 3. aggregate bind > > > > > > When it comes to shutdown we have this order: > > > > > > 1. DSI bridge > > > 2. msm_pdev_shutdown() (host driver) > > > > > > and so the bridge is already off, but we want to communicate to it to > > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > > Unfortunately, this time we can't split shutdown into multiple phases > > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > > > Let's make the component_master_ops into an actual device driver that has > > > probe/remove/shutdown functions. The driver will only be bound to the > > > aggregate device once all component drivers have called component_add() > > > to indicate they're ready to assemble the aggregate driver. This allows > > > us to attach shutdown logic (and in the future runtime PM logic) to the > > > aggregate driver so that it runs the hooks in the correct order. > > > > I know I asked before, but I can not remember the answer. > > > > This really looks like it is turning into the aux bus code. Why can't > > you just use that instead here for this type of thing? You are creating > > another bus and drivers for that bus that are "fake" which is great, but > > that's what the aux bus code was supposed to help out with, so we > > wouldn't have to write more of these. > > > > So, if this really is different, can you document it here so I remember > > next time you resend this patch series? > > aux takes a device and splits it into a lot of sub-devices, each with > their own driver. > > This takes a pile of devices, and turns it into a single logical > device with a single driver. > > So aux is 1:N, component is N:1. > > And yes you asked this already, I typed this up already :-) That's clear, but I'm still not sure why we need a bus for this :-) I'm not very enthousiastic about that. Some of our problems come from the fact we need to coordinate many devices, adding new ones hardly seem to be a solution to that. Granted, the components framework doesn't work nicely, and is in dire need of love (and documentation), or possibly better a complete replacement. I'll try to review the series this week and see if alternatives would be possible. -- Regards, Laurent Pinchart
Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Mon, Jan 31, 2022 at 2:48 PM Greg Kroah-Hartman wrote: > > On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > > The component framework only provides 'bind' and 'unbind' callbacks to > > tell the host driver that it is time to assemble the aggregate driver > > now that all the components have probed. The component framework doesn't > > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > > mentions this in the code. This lack of support leads to some pretty > > gnarly usages of the 'prepare' and 'complete' power management hooks in > > drivers that host the aggregate device, and it fully breaks down when > > faced with ordering shutdown between the various components, the > > aggregate driver, and the host driver that registers the whole thing. > > > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > > using 'prepare' and 'complete' to call the drm helpers > > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > > respectively, so that it can move the aggregate driver suspend/resume > > callbacks to be before and after the components that make up the drm > > device call any suspend/resume hooks they have. This only works as long > > as the component devices don't do anything in their own 'prepare' and > > 'complete' callbacks. If they did, then the ordering would be incorrect > > and we would be doing something in the component drivers before the > > aggregate driver could do anything. Yuck! > > > > Similarly, when trying to add shutdown support to the MSM driver we run > > across a problem where we're trying to shutdown the drm device via > > drm_atomic_helper_shutdown(), but some of the devices in the encoder > > chain have already been shutdown. This time, the component devices > > aren't the problem (although they could be if they did anything in their > > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > > chain that has already been shutdown before the driver hosting the > > aggregate device runs shutdown. The ordering of driver probe is like > > this: > > > > 1. msm_pdev_probe() (host driver) > > 2. DSI bridge > > 3. aggregate bind > > > > When it comes to shutdown we have this order: > > > > 1. DSI bridge > > 2. msm_pdev_shutdown() (host driver) > > > > and so the bridge is already off, but we want to communicate to it to > > turn things off on the display during msm_pdev_shutdown(). Double yuck! > > Unfortunately, this time we can't split shutdown into multiple phases > > and swap msm_pdev_shutdown() with the DSI bridge. > > > > Let's make the component_master_ops into an actual device driver that has > > probe/remove/shutdown functions. The driver will only be bound to the > > aggregate device once all component drivers have called component_add() > > to indicate they're ready to assemble the aggregate driver. This allows > > us to attach shutdown logic (and in the future runtime PM logic) to the > > aggregate driver so that it runs the hooks in the correct order. > > I know I asked before, but I can not remember the answer. > > This really looks like it is turning into the aux bus code. Why can't > you just use that instead here for this type of thing? You are creating > another bus and drivers for that bus that are "fake" which is great, but > that's what the aux bus code was supposed to help out with, so we > wouldn't have to write more of these. > > So, if this really is different, can you document it here so I remember > next time you resend this patch series? aux takes a device and splits it into a lot of sub-devices, each with their own driver. This takes a pile of devices, and turns it into a single logical device with a single driver. So aux is 1:N, component is N:1. And yes you asked this already, I typed this up already :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH v6 02/35] component: Introduce the aggregate bus_type
On Thu, Jan 27, 2022 at 12:01:08PM -0800, Stephen Boyd wrote: > The component framework only provides 'bind' and 'unbind' callbacks to > tell the host driver that it is time to assemble the aggregate driver > now that all the components have probed. The component framework doesn't > attempt to resolve runtime PM or suspend/resume ordering, and explicitly > mentions this in the code. This lack of support leads to some pretty > gnarly usages of the 'prepare' and 'complete' power management hooks in > drivers that host the aggregate device, and it fully breaks down when > faced with ordering shutdown between the various components, the > aggregate driver, and the host driver that registers the whole thing. > > In a concrete example, the MSM display driver at drivers/gpu/drm/msm is > using 'prepare' and 'complete' to call the drm helpers > drm_mode_config_helper_suspend() and drm_mode_config_helper_resume() > respectively, so that it can move the aggregate driver suspend/resume > callbacks to be before and after the components that make up the drm > device call any suspend/resume hooks they have. This only works as long > as the component devices don't do anything in their own 'prepare' and > 'complete' callbacks. If they did, then the ordering would be incorrect > and we would be doing something in the component drivers before the > aggregate driver could do anything. Yuck! > > Similarly, when trying to add shutdown support to the MSM driver we run > across a problem where we're trying to shutdown the drm device via > drm_atomic_helper_shutdown(), but some of the devices in the encoder > chain have already been shutdown. This time, the component devices > aren't the problem (although they could be if they did anything in their > shutdown callbacks), but there's a DSI to eDP bridge in the encoder > chain that has already been shutdown before the driver hosting the > aggregate device runs shutdown. The ordering of driver probe is like > this: > > 1. msm_pdev_probe() (host driver) > 2. DSI bridge > 3. aggregate bind > > When it comes to shutdown we have this order: > > 1. DSI bridge > 2. msm_pdev_shutdown() (host driver) > > and so the bridge is already off, but we want to communicate to it to > turn things off on the display during msm_pdev_shutdown(). Double yuck! > Unfortunately, this time we can't split shutdown into multiple phases > and swap msm_pdev_shutdown() with the DSI bridge. > > Let's make the component_master_ops into an actual device driver that has > probe/remove/shutdown functions. The driver will only be bound to the > aggregate device once all component drivers have called component_add() > to indicate they're ready to assemble the aggregate driver. This allows > us to attach shutdown logic (and in the future runtime PM logic) to the > aggregate driver so that it runs the hooks in the correct order. I know I asked before, but I can not remember the answer. This really looks like it is turning into the aux bus code. Why can't you just use that instead here for this type of thing? You are creating another bus and drivers for that bus that are "fake" which is great, but that's what the aux bus code was supposed to help out with, so we wouldn't have to write more of these. So, if this really is different, can you document it here so I remember next time you resend this patch series? thanks, greg k-h
[PATCH v6 02/35] component: Introduce the aggregate bus_type
The component framework only provides 'bind' and 'unbind' callbacks to
tell the host driver that it is time to assemble the aggregate driver
now that all the components have probed. The component framework doesn't
attempt to resolve runtime PM or suspend/resume ordering, and explicitly
mentions this in the code. This lack of support leads to some pretty
gnarly usages of the 'prepare' and 'complete' power management hooks in
drivers that host the aggregate device, and it fully breaks down when
faced with ordering shutdown between the various components, the
aggregate driver, and the host driver that registers the whole thing.
In a concrete example, the MSM display driver at drivers/gpu/drm/msm is
using 'prepare' and 'complete' to call the drm helpers
drm_mode_config_helper_suspend() and drm_mode_config_helper_resume()
respectively, so that it can move the aggregate driver suspend/resume
callbacks to be before and after the components that make up the drm
device call any suspend/resume hooks they have. This only works as long
as the component devices don't do anything in their own 'prepare' and
'complete' callbacks. If they did, then the ordering would be incorrect
and we would be doing something in the component drivers before the
aggregate driver could do anything. Yuck!
Similarly, when trying to add shutdown support to the MSM driver we run
across a problem where we're trying to shutdown the drm device via
drm_atomic_helper_shutdown(), but some of the devices in the encoder
chain have already been shutdown. This time, the component devices
aren't the problem (although they could be if they did anything in their
shutdown callbacks), but there's a DSI to eDP bridge in the encoder
chain that has already been shutdown before the driver hosting the
aggregate device runs shutdown. The ordering of driver probe is like
this:
1. msm_pdev_probe() (host driver)
2. DSI bridge
3. aggregate bind
When it comes to shutdown we have this order:
1. DSI bridge
2. msm_pdev_shutdown() (host driver)
and so the bridge is already off, but we want to communicate to it to
turn things off on the display during msm_pdev_shutdown(). Double yuck!
Unfortunately, this time we can't split shutdown into multiple phases
and swap msm_pdev_shutdown() with the DSI bridge.
Let's make the component_master_ops into an actual device driver that has
probe/remove/shutdown functions. The driver will only be bound to the
aggregate device once all component drivers have called component_add()
to indicate they're ready to assemble the aggregate driver. This allows
us to attach shutdown logic (and in the future runtime PM logic) to the
aggregate driver so that it runs the hooks in the correct order.
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Laurent Pinchart
Cc: "Rafael J. Wysocki"
Cc: Rob Clark
Cc: Russell King
Cc: Saravana Kannan
Signed-off-by: Stephen Boyd
---
drivers/base/component.c | 486 --
include/linux/component.h | 58 -
2 files changed, 417 insertions(+), 127 deletions(-)
diff --git a/drivers/base/component.c b/drivers/base/component.c
index 34f9e0802719..dc748ef0b23b 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -4,10 +4,14 @@
*/
#include
#include
+#include
#include
#include
#include
#include
+#include
+
+#include "base.h"
/**
* DOC: overview
@@ -31,8 +35,8 @@
*
* Aggregate drivers first assemble a component match list of what they need
* using component_match_add(). This is then registered as an aggregate driver
- * using component_master_add_with_match(), and unregistered using
- * component_master_del().
+ * using component_aggregate_register(), and unregistered using
+ * component_aggregate_unregister().
*/
struct component;
@@ -53,14 +57,20 @@ struct component_match {
};
struct aggregate_device {
- struct list_head node;
- bool bound;
-
const struct component_master_ops *ops;
struct device *parent;
+ struct device dev;
struct component_match *match;
+ struct aggregate_driver *adrv;
+
+ int id;
};
+static inline struct aggregate_device *to_aggregate_device(struct device *d)
+{
+ return container_of(d, struct aggregate_device, dev);
+}
+
struct component {
struct list_head node;
struct aggregate_device *adev;
@@ -69,11 +79,12 @@ struct component {
const struct component_ops *ops;
int subcomponent;
struct device *dev;
+ struct device_link *link;
};
static DEFINE_MUTEX(component_mutex);
static LIST_HEAD(component_list);
-static LIST_HEAD(aggregate_devices);
+static DEFINE_IDA(aggregate_ida);
#ifdef CONFIG_DEBUG_FS
@@ -89,7 +100,7 @@ static int component_devices_show(struct seq_file *s, void
*data)
seq_printf(s, "%-40s %20s\n", "aggregate_device name", "status");
seq_puts(s,
"-\n");
seq_printf(s, "%-40s
