Re: [PATCH 2/2] OMAP2+: GPIO: move late PM out of interrupts-disabled idle path

[Kevin Hilman <khilman@deeprootsystems.com>]

"Basak, Partha" <p-basak2@ti.com> writes:

>  
>
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> Sent: Friday, September 24, 2010 5:23 AM
>> To: Basak, Partha
>> Cc: linux-omap@vger.kernel.org; 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@deeprootsystems.com> 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?

Yes, I meant to use the non-mutex versions.

Sorry,

Kevin