Re: [linux-pm] runtime_pm_get_sync() from ISR with IRQs disabled?

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

 



On Fri, 24 Sep 2010, Kevin Hilman wrote:

> >> So, what is the "right" thing to do here?
> >
> > You should call pm_runtime_get(), turn off the interrupt source, and
> > return.  Then your resume routine should check for an outstanding
> > interrupt or wakeup request and handle it (the easiest way may be 
> > simply to call the ISR).
> 
> For a "normal" device driver, your solution makes complete sense.  The
> only catch is that it introduces potentically significant latency in the
> interrupt handling and it requires the interrupt source to be masked,
> potentially loosing other interrupts, while waiting for the runtime PM
> workqueue to schedule.  For chained handlers in particular, this means
> that *all* interrupts managed by the chained handler would be masked for
> this additional time.  Not good.

Masking an interrupt source doesn't cause any interrupts to be lost, if 
you mask it at a time when you couldn't handle the interrupts anyway.

> The problematic device for me as an on-chip GPIO controller, and the ISR
> in question is a chained handler (run with interrupts disabled) which
> does the GPIO demux and then dispatches to the actual ISR.  Following the
> above approach means that all GPIO interrupts (in that bank) would be
> masked until ->runtime_resume() is called.  For a GPIO bank with
> multiple edge-triggered IRQs, masked IRQs for that amount of time could
> mean several missed interrupts while waiting.

Wait a minute, you're confusing me.  I take it that the GPIO controller
is the device being runtime suspended, right?  And you said that while
it is suspended you can't access its registers.  So then how can you
mask it?  

Do you mean that you have to mask the entire IRQ line because there's
no way to turn off the interrupt-request source in the GPIO controller?  
That's different from what you wrote above.

>  Hoever, this isn't a
> major concern as we don't (currently) have IRQF_DISABLED handlers hooked
> up to GPIO IRQs (that I know of.)

Isn't IRQF_DISABLED on its way out, anyway?

> It may seem like I'm trying to fight the design, but I'm actually trying
> to find ways to use it.  I want to use the API (and we're using it
> successfully in most of our drivers now.)  The problem is only in a few
> of these corner cases where using it introduces significant changes from
> previous behavior like introducing long, unbounded windows for missed
> interrupts.

Assuming the problem of missed interrupts didn't exist, would you still 
be unhappy about the latency issue?

In the general case there's no way to avoid it.  Even though a device
like your GPIO controller may be able to return to full power very
quickly, the fact that it was suspended may have led the PM core to
suspend its parent as well.  And the parent may be slow to resume,
requiring a full process context.

It seems as though what you really need is a way to tell the PM core 
that your device can change its power state quickly with no need for a 
process context.  Given that, pm_runtime_get() could invoke your 
runtime_resume callback directly; you wouldn't have to wait for the 
workqueue.  (Unless your device had a suspended parent that _did_ need 
a long time to resume.)

Would that solve your problem?  It seems like a reasonable sort of 
feature to add.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux