usb: otg: omap-usb2: add the PHY notifications

USB phy can send notifications about his state change
to any interesting in this subscriber.
This functionality was missed in current sources for OMAP4
and is added by this patch

Change-Id: Id9ecb1f601a6a4b505556c5cd3331583e31181bc
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
usb: musb: save/restore context in .suspend/.resume PM callbacks

.suspend/.resume PM callbacks are executing before putting the system
into a sleep state/after waking the system up from a sleep state.
At this time it's required to prepare device to suspend/resume.
For MUSB we need to save/restore its context at these points
so we don't loose its state.

Change-Id: I531396835e2d17b295f4969166b9f5febb4cc854
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
Revert "ARM: OMAP: mux: HACK: handle SYS_NIRQ1 and SYS_NIRQ2 wakeup interrupts"

This patch is reverted because another better solution
will be implemented

This reverts commit 67f1aeb1e6fa0706dde6d85ac4d78f4ff93622e8.

Change-Id: I747530c94628f3997a9ed32ef005704c68e16693
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@ti.com>
ARM: OMAP: PRM: fix work with I/O pads daisy chain

Due to concurrent access to IO chain reconfiguration,
wakeup status may be missesd before IO wakeup IRQ
handler firing.

This occurs usually in next way:

"resume from idle states by I/O wakeup"

--------------------------------------
 [1] spin_lock_irqsave()
 [2] omap_inc_mpu_core_pwrdm_usecount()
      |
 [3]   -omap_enable_core_notifier()
         |
 [4]      -omap2_gpio_resume_after_idle()
            |
 [5]         - omap_mux_reconfigure_iochain()  <-- clears all I/O WAKEUPEVENT bits!!
 [6] spin_unlock_irqrestore()
-------------------------------------

In the same time somewhere between [1] and [6]
I/O wakeup IRQ may be raised and its handler will
be called after [6] (because between [1] and [6]
interrupts are disabled). In this handler we check
I/O WAKEUPEVENT bits that was already cleared at
[5]th step and so we miss all these wakeup
events - the irq was successfully fired but
we cannot find out who the wakeup sourse is.

The fix is simple:
1) rearm IO chain at the end of I/O wakeup IRQ handler
2) at start of the omap_mux_reconfigure_iochain() function check
   if there is pending IO irq. If yes - do not reconfigure
   IO chain so it will be reconfigured later in the
   I/O wakeup IRQ handler

This patch is limited to OMAP4 devices only for
prevent any issues with OMAP5 where current sequence
seems to be working. In case of similar symptoms
we can extend this fix to OMAP5 family too.

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