Re: Suspend broken on 3.3?

[Paul Walmsley <paul@pwsan.com>]

Hi

a few brief comments based on a quick scan:

On Wed, 11 Apr 2012, Raja, Govindraj wrote:

> Here is the patch [1] to do the same.

- I don't see where it affects I/O wakeups for the UART.  If I/O wakeups 
are still set on the UART pads, won't that still wake the chip up from 
suspend, even if module-level wakeups are disabled?

- The UART driver and integration code should not be reading from or 
writing to registers outside the UART IP block.  PRM register reads and 
writes belong in the PRM code, which should then export a higher-level 
interface to the calling code.  This is because, aside from making the 
code easier to read and debug, we're trying to move the PRM and CM code to 
drivers/.

- The code to change the PM_WKEN* and test the PM_WKST* bits should 
probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART 
code directly.  The UART code shouldn't need to care about the hardware 
details; it should just ask the integration layer to enable or disable 
module-level wakeups.

As you work on these changes, please split them up into several different 
topic series - one for the PRM changes, one for hwmod code/data changes, 
and one for the UART driver/integration changes.  Just note the 
dependencies in the series description E-mails.  That way, we can avoid 
merge conflicts.


- Paul