OMAP: USB Host: Wake up L3_init clockdomain ASAP on USB remote wakeup event

OMAP: USB Host: Wake up L3_init clockdomain ASAP on USB remote wakeup event

[backported from p-android-omap-3.4]

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, currently we enable different clocks
to the Host too late and its internal state
machine may enter in some bad state.

This patch ensures that clocks to the host are
enabled as soon as possible so its internal
state logic can start to handle remote wakeup
without latencies introduced by PM runtime
framework.

Change-Id: Id9658f69696d7040cc563681a1bb0c4527e81fdb
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>

Conflicts:
	arch/arm/mach-omap2/usb-host.c
omap: usb host: mux: force PHY STP line to low state in idle/off mode

omap: usb host: mux: force PHY STP line to low state in idle/off mode

[backported from p-android-omap-3.4]

If OMAP HS USB Host hwmod is not in active state,
USB remote wakeups are handled by I/O daisy chain
logic due to erratas around Host that don't
allow to use HW smart standby/idle capabilities:
 - i571: USB host EHCI may stall when entering smart-standby mode
 - i660: USBHOST Configured In Smart-Idle Can Lead To a Deadlock

As a result, we enable different clocks to the Host quite late
and its internal state machine may enter in some bad state.
Next patch http://review.omapzoom.org/32086 (OMAP: USB Host: Wake
up L3_init clockdomain ASAP on USB remote wakeup event)(1) fixed
this issue for OMAP4470 but it is not enough for 4430/4460
where restoring from OFF mode takes more time.

In this case next behavior has been observed on ULPI lines
for 4430/4460 (say initial OMAP's state is OFF mode):      (2)
 - a device connected to PHY issues remote wakeup
 - the PHY directly represents this state on D0:D1 lines
 - OMAP sees line state change and starts its 'resume from OFF'
   procedure
 - after ~100 uS after D0:D1 change, OMAP asserts STP line
 - PHY starts is internal resume procedure, deasserts DIR and
   starts to generate clocks to OMAP
 - after ~8ms OMAP deasserts STP line and puts the PHY to the
   low-power state immediately (sends 0x84-0x4A 0x84-0x4A 0x84-0x05
   sequence)
 - the OMAP restoring sequence is still in progress and is only on
   its start phase.

After above sequence the ULPI interface is not functional
anymore for OMAP - no matter PORTSC.FPR nor direct access
through INSNREG05_ULPI register you use.
The root cause seems to be related to i693 errata (USB HOST EHCI - Port
Resume Fails On Second Resume Iteration) that says we have to
switch ULPI_CLK to internal clocksource for short time after *each* PHY
suspend, otherwise internal EHCI counter will not reach
18 and second resume iteration will fail.
The reason of why it affects only 4430/4460 but not 4470 is because
after applying patch [1] 4470 restores from OFF mode fast enough
and so internal EHCI logic does not have a chance to
put the PHY in low power mode. Whereas for 4430/4460
the restore-from-OFF sequence is a little bit longer,
and we have PHY-resume and PHY-suspend [2], and after that
after end of restore-from-OFF we try to wakeup the PHY
again and meet the i693 condition.

The workaround here consists in keeping the STP line
in low state until the EHCI is ready to work with PHY.

For this, the patch uses some MUX magic, forcing the
STP to 'safe mode' and pulldown for idle or OFF state
and muxing it back to STP mode for active state.

This prevents wake-up-the-PHY in the middle of restoring from
off sequence and works fine on all OMAP4 SoCs.

Change-Id: I95d7bf707f76519ee7d81f4437d8564f03b5d602
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>