On pią, 2014-10-31 at 15:22 +0100, Pavel Machek wrote: > On Fri 2014-10-31 10:14:55, Krzysztof Kozlowski wrote: > > On pon, 2014-10-20 at 11:04 +0200, Krzysztof Kozlowski wrote: > > > Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime > > > PM IRQ safe was set or not. > > > > > > Various bus drivers implementing runtime PM may use choose to suspend > > > differently based on IRQ safeness status of child driver (e.g. do not > > > unprepare the clock if IRQ safe is not set). > > > > > > Signed-off-by: Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx> > > > Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx> > > > > Rafael, Len, Pavel, > > > > Is proposed API ok? Do you have any comments? > > > > I'll upload whole patchset to Russell's patch tracking system. However > > an ack from PM maintainer is probably needed. > > I don't like the API. Having callbacks work in different context (irq > / noirq) based on what another function reports is ugly. > > What is the penalty if we always decide callbacks are not IRQ safe? Then pm_runtime_get_sync() could not be called in atomic context. The pl330 runtime PM would have to be completely reworked because one pm_runtime_get_sync() is called in device_issue_pending which cannot sleep (at least in non preemptible kernels). Probably this can be solved some way... Best regards, Krzysztof > > > > --- a/Documentation/power/runtime_pm.txt > > > +++ b/Documentation/power/runtime_pm.txt > > > @@ -468,6 +468,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: > > > - set the power.irq_safe flag for the device, causing the runtime-PM > > > callbacks to be invoked with interrupts off > > > > > > + bool pm_runtime_is_irq_safe(struct device *dev); > > > + - return true if power.irq_safe flag was set for the device, causing > > > + the runtime-PM callbacks to be invoked with interrupts off > > > + > > > void pm_runtime_mark_last_busy(struct device *dev); > > > - set the power.last_busy field to the current time > > > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
