> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > Sent: Friday, September 24, 2010 5:23 AM > To: Basak, Partha > Cc: linux-omap@xxxxxxxxxxxxxxx; Varadarajan, Charulatha; Tero > Kristo; Cousson, Benoit > Subject: Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of > interrupts-disabled idle path > > 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. > omap_hwmod_[enable/disable]_clocks() use mutex inside & therefore cannot be used in the ISR context We cannot readily use the _enable_clocks/_disble_clocks directly as they are static APIs. But we can use the non-mutex versions, of omap_hwmod_enable/idle. (_omap_hwmod_enable/_omap_hwmod_disable) Do you agree? > 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
