[PATCH v2 1/3] OMAP: PM: initial runtime PM core support

[Grant Likely]

On Mon, Jun 28, 2010 at 2:49 PM, Kevin Hilman
<khilman at deeprootsystems.com> wrote:
> Grant Likely <grant.likely at secretlab.ca> writes:
>
>> On Fri, Jun 25, 2010 at 4:46 PM, Kevin Hilman
>> <khilman at deeprootsystems.com> wrote:
>>> Grant Likely <grant.likely at secretlab.ca> 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.