Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: [...] >> >> We cannot do a get_sync() from ISR context, right? > > Right, but we *should* be able to. ;) > > I'm still trying to craft a good description of this problem so I can > argue better for it on linux-pm. > > Until then... > > A bit of a hack, but you could do a _get_noresume() (which is safe from > interrupt context) and directly call the drivers ->runtime_resume() > method, which would be the equivalent of a _get_sync(). Followed of > course by a _put() (async version, also interrupt safe) at the end of > the ISR to keep the usecount correct. You probably figured this out already, but I just realized that this won't currently work either as omap_hwmod is using mutexes, and is safe in ISR context either. :( What about for now just directly enabling (and re-disabling) the hwmod clocks in the ISR using omap_hwmod_[enable|disable]_clocks() Since this is a core driver in arch/arm/*omap*, you can directly call the omap_hwmod API. 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
