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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
