[PATCH] OMAP4: clockdomain: Follow recommended enable sequence

[Kevin Hilman]

Rajendra Nayak <rnayak at ti.com> writes:

[...]

>>
>> It's also breaking boot on OMAP35xx BeagleBoard rev C2.  The kernel
>> boot messages are below - omap2plus_defconfig + DEBUG_LL.  Reverting
>> the patch fixes it.  Could you please take a look?
>
> I got hold of a Beagle, a sticker on which says rev C1D.
> Not sure if there is a better way to identify the rev, but
> this one seems to boot fine for me even with this patch.
> I just applied this one patch on top of the the tag
> 'integration-2.6.39-20110310-008' of git://git.pwsan.com/linux-
> integration.

In the process of testing Santosh's OMAP4 PM series (which includes
$SUBJECT patch) on OMAP3, I also noticed some problems on beagle (mine
is a C3.)

Specifially, with $SUBJECT patch applied, none of the powerdomains ever
reach inactive or RET during idle (suspend seems to work fine.)

Just reverting $SUBJECT patch makes things go back to working normally.

I pushed the test branch I used which is a merge of Santosh's v3 branch
with my pm branch (branch: tmp/santosh-omap4-pm)

I tested by first doing a suspend test and confirming all the
powerdomains hit retention.  That worked fine.  Then I did an idle test:

  echo 5 > /sys/devices/platform/omap/omap_uart.0/sleep_timeout               
  echo 5 > /sys/devices/platform/omap/omap_uart.1/sleep_timeout               
  echo 5 > /sys/devices/platform/omap/omap_uart.2/sleep_timeout               
  echo 1 > /debug/pm_debug/sleep_while_idle

and waited for the UARTs to timeout.

Well after the UART timeouts expired, I do not see any powerdomains
transitioning from ON.

What's even more strange is that the same thing is working fine on all
the other OMAP3 platforms I tested: 3430/n900, 3630/zoom3 and even a
different 3530-based platform, the OMAP3EVM.

Kevin