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
