On Mon, Jun 28, 2010 at 2:49 PM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> wrote: > 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." No, delaying until all children are ready wasn't my intent. I was thinking about a set of childs_dev_pm_ops() that would be called once for each child as each child suspends/resumes... but probably a moot point since we both agree that it adds a lot of complexity. :-) > > 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, np. Talk you you later. Have a great vacation. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
