diff mbox

[v2] OMAP3: PM: USBHOST: clear wakeup events on both hosts

Message ID 1247877189-5754-1-git-send-email-vikram.pandita@ti.com (mailing list archive)
State Superseded
Delegated to: Kevin Hilman
Headers show

Commit Message

vikram pandita July 18, 2009, 12:33 a.m. UTC
USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
and only a single bit in the WKST register to indicate a wakeup event.

Because of the single WKST bit, we cannot know whether a wakeup event
was on HOST1 or HOST2, so enable both fclocks before clearing the
wakeup event to ensure both hosts can properly clear the event.

Signed-off-by: Vikram Pandita <vikram.pandita@ti.com>
---
 arch/arm/mach-omap2/pm34xx.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

Comments

Woodruff, Richard July 19, 2009, 1:35 p.m. UTC | #1
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Pandita, Vikram
> Sent: Friday, July 17, 2009 7:33 PM

> USBHOST module has 2 fclocks (for HOST1 and HOST2), only one iclock
> and only a single bit in the WKST register to indicate a wakeup event.
>
> Because of the single WKST bit, we cannot know whether a wakeup event
> was on HOST1 or HOST2, so enable both fclocks before clearing the
> wakeup event to ensure both hosts can properly clear the event.

Yes, if you need to clear bits clocks must be on.

Question which comes to mind is if the wakeup bit should have been set for target mode.  Ideally when this status is set the f-clk should have been already on.  Does USB framework even export good control of possible sleep modes...

Most WKST bits are used in conjunction with INACTIVE mode wakeup.  The exception to this is WAKUP-domain WKSTs which are also used in wakes from RET or OFF mode.

So point is... for USB having this WKST status bit set and NOT having the F-Clk enabled points to an issue in the OFF mode transition code in the USB driver.

Since the driver won't have access to PRCM registers the only places which can fix this issue today is the PRCM irq (like being proposed) or inside the clock-frame-work at the F-Clk shutdown point.

Generally if status is hanging around when you try to sleep, you will have a failed sleep.  Today what is happening is the prcm-irq will come and sweep up the status at some later time.  This will allow an eventual sleep success.

......

A - Sleeps states which don't require enumeration

TARGET: INACTIVE mode+wakeup-capable-to-usb-resume (mstandby asserted & dpll still requested) :: For USB, when it goes to USB-bus-suspend, if you want to wake on usb-bus-resume from the usb wake path, probably you would leave on the fclk.

TARGET: RET/OFF mode+wakeup-capapble+USB-SAR (mstandby asserted & no dpll requests) :: If you want to go to OFF or RET mode then you first move to usb-bus-suspend, then shut down f-clk, then setup for some io-ring wake event.

B - Sleep states which require enumeration on wake
-- mstandby must be asserted, however you can cheat to get there by using force-standby, forced-idle, then expect a full path reset and enumeration at wake up time.

.......

USB has a few state choices around sleep which it doesn't seem are well specified in code.  Just hooking to existing suspend/resume handlers which are meant more for 'B' handling caused issues if people are going for the 'A' behavior.

Regards,
Richard W.


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Woodruff, Richard July 19, 2009, 1:39 p.m. UTC | #2
> So point is... for USB having this WKST status bit set and NOT having the F-
> Clk enabled points to an issue in the OFF mode transition code in the USB
> driver.

Or if this is on 1st boot, then issue can be init code needing to clean up whatever damage the boot loader may have done. Prcm_init should really have done this as you don't always have a controlling USB driver.

Regards,
Richard W.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e80d59f..2430bed 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -264,8 +264,13 @@  static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
 					       CM_FCLKEN);
 			cm_set_mod_reg_bits(wkst, OMAP3430ES2_USBHOST_MOD,
 					    CM_ICLKEN);
-			cm_set_mod_reg_bits(wkst, OMAP3430ES2_USBHOST_MOD,
-					    CM_FCLKEN);
+			/* We don't know whether HOST1 or HOST2 woke us up,
+			 * so enable both clocks
+			 */
+			cm_set_mod_reg_bits(wkst |
+					(1<<OMAP3430ES2_EN_USBHOST2_SHIFT),
+					OMAP3430ES2_USBHOST_MOD,
+					CM_FCLKEN);
 			prm_write_mod_reg(wkst, OMAP3430ES2_USBHOST_MOD,
 					  PM_WKST);
 			while (prm_read_mod_reg(OMAP3430ES2_USBHOST_MOD,