On Tue, 23 Nov 2010, Rafael J. Wysocki wrote:
> > > Moreover, I'm not sure if we need an "IRQ safe" version of _idle. Why do
> > > we need it, exactly?
> >
> > Because pm_runtime_put_sync() calls rpm_idle(). If there were no
> > irq-safe version of rpm_idle() then drivers wouldn't be able to call
> > pm_runtime_put_sync() from within an interrupt handler.
>
> Right. Which they can't do now, can they?
True. That was the point of this patch -- to allow interrupt handlers
to do runtime PM, which they can't do now.
> Why do you think we should allow them to do that?
Are you suggesting that interrupt handlers stick to pm_runtime_suspend
and pm_runtime_resume, and ignore pm_runtime_get_sync and
pm_runtime_put_sync?
Recall that after probing is finished, the driver core does a
pm_runtime_put_sync. That might happen while an interrupt handler is
running on another CPU. If the interrupt handler didn't increment the
usage_count, the driver core could cause the device to suspend while
the interrupt handler was still using it.
Or are you suggesting that interrupt handlers use pm_runtime_get_sync
and implement a poor-man's version of pm_runtime_put_sync by doing:
pm_runtime_put_no_idle();
pm_runtime_suspend();
Is there some particular reason for denying interrupt handlers the
ability to use pm_runtime_put_sync? It seems odd to disallow that
while allowing pm_runtime_get_sync.
Or maybe you think that when pm_runtime_put_sync detects the
usage_count has decremented to 0 and the device is irq-safe, it should
call rpm_suspend directly instead of calling rpm_idle?
In short, I don't see any reason not to present the same API to
interrupt handlers for irq-safe devices as we present to
process-context drivers for ordinary devices.
> Anyway, though, if the only reason of doing this is to allow interrupt
> handlers
> to call pm_runtime_put_sync(), then I rather wouldn't do it at all.
Why not?
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
