On Fri, Jun 25, 2010 at 4:46 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > >> Another way to look at the problem is that these runtime >> customizations are kind of a property of the parent device (the bus, >> not the bus_type). Would it make sense for parent devices to have >> runtime ops to perform for each child that is suspended/resumed? That >> would make it simple to register another device that implements the >> bus behaviour and attach it at runtime instead of compile time. > > Maybe I didn't fully understand your idea, but the problem here is > devices do not have dev_pm_ops. Only busses, classes, and types have > dev_pm_ops. Sorry, I mistyped. What I meant was for the parent device's device_driver to be able to have a set of child dev_pm_ops; but I'm wading into territory (power management) I'm not particularly familiar with, and that might be making things far too complex. > Though I'm horribly unfamiliar with the intended usage of 'struct > device_type', an interesing discovery is that dev->type also has > dev_pm_ops, and it takes precedence over the bus type in the > suspend/resume. IOW, when suspending, when deciding which dev_pm_ops to > use, it checks class, type, then bus in that order. So I guess my suggestion above boils down to somehow inserting "parent" between type and bus in that list. > I need to explore this 'type' feature a little more, but using that or > the 'class' might be another way to have custom PM ops for certain > platform_devices. Should maybe start cc'ing Greg and linux-kernel/linux-pm in this discussion. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
