Re: How to use generic power domains (pm_genpd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 22, 2012 at 2:52 PM, Rickard Andersson
<rickard.andersson@xxxxxxxxxxxxxx> wrote:

> Another thing that I am trying to find out is if genpd works ok if a driver
> in the power domain does pm_runtime_get_sync(..) in interrupt context?

I discussed this with Kevin Hilman in Copenhagen some weeks
back.

Basically IIRC it is OK to call *_sync() operations from interrupt
context if and only if you have first called
pm_runtime_irq_safe(struct device *dev)
on the device.

You can check in
drivers/base/power/runtime.c
what happens when this flag is set: for example idling
does not propagate upwards to parents immediately, since
the parent may not be able to *_sync() in interrupt context.

Documentation/power/runtime.txt has even more details,
but doesn't talk about the PM domains explicitly, as far as
I can tell it's a convention that if you set pm_runtime_irq_safe()
for the device, then the PM domain, bus, and device
suspend/resume/etc callbacks (whatever you have) all
need to be IRQ safe.

I guess the driver has to mark itself irqsafe in its
probe().

If a driver does *_sync() in IRQ context and the device
is not flagged as IRQ safe the PM core will puke warnings
from code sites like this:

might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe);

So you will notice.

However I wonder what I as a driver writer should do if
I mark my driver as pm_runtime_irq_safe() and then do
a *_sync() operation in IRQ context.

I *guess* I shall just assume that any PM domain using this
will have to adopt to this constraint coming from the device
it is trying to handle, as it gets this _sync() call, basically
the PM domain will inherit the limitation and cannot do
anything non-atomic if it is to handle a device like this.

So its like a PROLOG engine that propagates constraints
upward at runtime and screams if it can't resolve the
constraints.

Now Kevin & Rafael can correct all my mistakes in the
above understanding ...

Yours,
Linus Walleij


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux