Re: [PATCHv4 4/6] ARM: OMAP3+: PRM: Enable IO wake up

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



added Rajendra, Nilesh, Vishwa, Mohan

Hi

On Fri, 2 Mar 2012, Tero Kristo wrote:

> Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
> managed in cpuidle path which is not the right place. Subsequent patch
> will remove IO Daisy chain handling in cpuidle path once daisy chain is
> handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
> enable code from the trigger function to init time setup.
> 
> Signed-off-by: Tero Kristo <t-kristo@xxxxxx>

Should we keep the I/O wakeups enabled all the time?

Seems like that could result in at least one spurious wake-up event -- and 
thus a PRCM interrupt -- for each I/O pad that has WAKEUPENABLE set.  
Seems like these interrupts could recur every time the I/O chain is reset.  
And that the I/O chain is now reset in every hwmod idle and enable 
operation for an IP block that contains dynamic mux data?

Thinking about the problem naïvely... maybe you all can think through this 
with me:

Consider an IP block 'A' that has a signal (like the UART rx_irrx signal) 
that's mux'ed to a pad with WAKEUPENABLE set.  (Some examples of 'A' might 
include a UART, a GPIO, or a McBSP.)  

Shouldn't we enable I/O wakeups (by setting EN_IO/GLOBAL_WUEN) only 
immediately before the powerdomain containing IP block 'A' is going to 
transition into RETENTION or OFF?

If we do that, then we can avoid needlessly resetting the I/O chain when a 
powerdomain is not going to go into a low-power state.

I haven't measured the time it takes for the I/O chain to be reset.  
Maybe one of you have.  But that 100 microsecond timeout that was 
specified in two of the other patches in this series has me a little 
worried.


- Paul

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux