Grant Likely <grant.likely@xxxxxxxxxxxx> writes: > 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. I see your point now, but I think this indeed might complicate things too much. Also, I'm not crazy about how this would delay the per-device PM hooks to be essentially batched until all devices under the parent are "ready." But anyways, it just needs some more research on my part. Unfortunately, I'll be away from this work on vacation for most of July, so this won't get any attention from me until August. >> 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. They were involved in the early discussions about overriding the platform_bus dev_pm_ops methods, which led us to the current implementation. But as I explore the custom bus approach a bit more (in August) I'll broaden the audience. Thanks again for all your helpful suggestions, Kevin -- 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
