Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend

[Felipe Balbi <balbi@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

Hi,

On Mon, Oct 29, 2012 at 01:53:37PM +0530, Santosh Shilimkar wrote:
> >>Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON
> >>domain where as remaing 5 are in peripheral domain. Letting individual
> >>banks idle allowed you let the clock domain idle than keeping all the
> >>6 banks and hence respective clock/power domain in ON state.
> >>
> >>So the adding timeout might be reasonable but I am not sure about
> >>the mod_usage change here.
> >
> >IMHO that whole mod_usage is broken. I remember sending a big series of
> >patches getting rid of that long ago. I _did_ break a few things but
> >just because of omap_gpio_prepare_for_idle() /
> >omap_gpio_resume_from_idle() hackery to get GPIO suspended early enough.
> >
> Well so far I haven't seen/come across a patch/proposal which fixes it.

fair point

> >I still think mod_usage needs to go, so does
> >omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it
> >looks like that needs to be done on ->prepare()/->complete() callbacks
> >of system suspend and the gpio driver needs to learn proper runtime
> >suspend.
> >
> I am not saying it shouldn't go :-)
> The $subject patch isn't fixing it correctly is what I said.
> 
> Don't get hung up on suspend case because thats the easiest
> way to address it. The issue is with idle where GPIO can prevent
> SOC idle if it isn't taken care. And since its just an IO, its not
> easy to implement something like inactivity timer towards
> autosupend.

I don't see the relation here. Care to expand a bit ?

> Co-processor also makes use of GPIO via syslink proxy and thats
> make things even harder.

that's supposed to be solved with hwspinlock, isn't it ?

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]