Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Mon, 27 Sep 2010, Rafael J. Wysocki wrote: > >> > 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. > > That might appear more flexible, but is there any advantage to it? > That is, would there be a situation where the driver knows that the > next callback won't sleep but in general the callback might sleep > sometimes? It doesn't seem very likely. > > Kevin, do you have any feelings about this? For flexibility, I like the RPM_FASTPATH approach. At least in the drivers I'm currently tinkering with, most of the callers can sleep. It's only the occasional callback triggered from the ISR that can't sleep. During this "normal" (non-ISR) usage, there might very well be concurrent or pending requests, some of which might have to sleep. So, I think it's best to have the fastpath settable on a per-caller basis. Kevin -- 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
