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:
signature.asc
Description: Digital signature
