Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks

[Tony Lindgren <tony@atomide.com>]

* Tero.Kristo@nokia.com <Tero.Kristo@nokia.com> [080821 14:08]:
>  
> 
> >-----Original Message-----
> >From: linux-omap-owner@vger.kernel.org 
> >[mailto:linux-omap-owner@vger.kernel.org] On Behalf Of ext 
> >Tony Lindgren
> >Sent: 20 August, 2008 14:37
> >To: Hogander Jouni (Nokia-D/Tampere)
> >Cc: linux-omap@vger.kernel.org
> >Subject: Re: [PATCH 2/4] PM: Workaround for taking care of gpio clocks
> >
> >* Jouni Hogander <jouni.hogander@nokia.com> [080815 10:47]:
> >> In omap3 gpios 2-6 are in per domain. Functional clocks for these 
> >> should be disabled. This patch is needed until gpio driver disables 
> >> gpio clocks.
> >> 
> >> GPIO modules in PER domain are not able to act as a wake up 
> >source if 
> >> PER domain is in retention. PER domain sleep transition 
> >before MPU is 
> >> prevented by leaving icks active. PER domain still enters retention 
> >> together with MPU. When this happens IOPAD wake up mechanism is used 
> >> for gpios.
> >
> >As we talked offline.. Should we pass the GPIO wake-up 
> >configuration from board-*.c files? Or can we always 
> >automatically do this safely on 34xx?
> 
> After some investigation it seems that we can configure wake-up events
> for almost every GPIO from the padconfigs. There are only 2 pins that do
> not seem to have this functionality, however I am not sure if this is a
> documentation bug or what because it is strange that only 2 pins lack
> this capability. GPIOs 32 and 187 are missing wake-up capability from
> padconfig.
> 
> Because of this, our proposal would be to make GPIO clock switching
> global, but this would be enabled from a sysfs entry pretty much like
> how it is in the patches now. However, this would be separated from UART
> clock switching. So, we would introduce two new sysfs files:
> uart_clocks_off_while_idle and gpio_clocks_off_while_idle. This would
> avoid introducing new complexity in to the idle loop.
> 
> How does this sound like?

Sounds good to me. Then we may be able to remove both sysfs files
eventually.

Regards,

Tony