On Monday, September 27, 2010, Alan Stern wrote: > On Fri, 24 Sep 2010, Rafael J. Wysocki wrote: > > > On Friday, September 24, 2010, Kevin Hilman wrote: > > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > > > > > On Thu, 23 Sep 2010, Kevin Hilman wrote: > > ... > > > > > > > > You're trying to fight the runtime-PM design instead of using it as it > > > > was intended. We already have an API for starting a resume from > > > > interrupt context, and that's what you should use. > > > > > > 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. > > > > This really sounds to me like you need _noirq() runtime PM callbacks > > and some framework around them. > > > > I'm not fundamentally against that, but it will require some time to introduce, > > if we decide that it's really necessary. > > > > I need to think a bit more about that, thanks for the example. > > How about adding another flag to the dev_pm_info structure, to indicate > that the runtime callbacks may be called in interrupt context? > > Maybe that will lead to problems I haven't thought of. But if it seems > okay to you, I can code it up easily enough. Hmm. I was thinking about adding a new RPM_ flag for that, like RPM_FASTPATH, telling the PM core to assume the callbacks will not sleep and that the call might be from interrupt handler. Thanks, Rafael -- 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
