OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it

OMAP3: PM: Ensure MUSB is accessible before we attempt to reset it

Depending on the OMAP3 boot mode the MUSB peripheral may or may not be
accessible when the kernel starts.

The OMAP3 can boot from several devices including USB. The sequence of the
devices the OMAP will attempt to boot from is configured via the sys_boot
pins on the device. If USB is one of the devices the OMAP boot ROM attempts
to boot from on power-on, then the interface clock to the MUSB peripheral
will be enabled by the boot ROM and the MUSB peripheral will be accessible
when the kernel boots. However, if USB is not one of the devices OMAP
attempts to boot from, then the interface clock is not enabled and the MUSB
peripheral will not be accessible on start-up.

If the MUSB peripheral is not accessible when the kernel boots, then the
kernel will crash when attempting to access the OTG_SYSCONFIG in the
function musb_platform_init(). The actual cause of the crash is the write
to the OTG_SYSCONFIG register in the function usb_musb_pm_init() to reset
the MUSB peripheral which occurs prior to calling musb_platform_init().
The function usb_musb_pm_init() does not check to see if the interface
clock for the MUSB peripheral is enabled before writing to MUSB register.
This write access does not generate a data-abort at this point, but because
this write does not complete all future accesses to the MUSB controller will
generate data-aborts regardless of whether the interface clock has been
enabled at a later stage. The only way I have found to recover from this is
resetting the device. My understanding is that the interconnect works in
this way to prevent a bad access locking up the system.

This patch ensures the interface clock for the MUSB in the function
usb_musb_pm_init() is enabled. This patch also ensures that the interface
clock is disabled after the reset is complete. My reasoning for always
disabling the clock rather than maintaing its state is:

1). If the MUSB peripheral is not being used then the interface clock
    should be disabled.
2). The musb_set_clock() function uses a static variable called
    "clk_on" to determine if the MUSB interface clock is on or off. On
    boot-up clk_on will be 0 and so this function assumes that the
    clock is off by default which may not be the case in the current
    code.

I have also added a while-loop to wait for the reset of the MUSB module to
complete before this function exits and the interface clock it disabled.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>