Re: [RFC 2/5] OMAP: mux: Make low level function private

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/24/10 19:07, Anand Gadiyar wrote:
-----Original Message-----
From: Tim Nordell [mailto:tim.nordell@xxxxxxxxxxx]
Sent: Saturday, September 25, 2010 5:20 AM
To: Gadiyar, Anand
Cc: Benoit Cousson; linux-omap@xxxxxxxxxxxxxxx; Tony
Lindgren; Paul Walmsley; Kevin Hilman
Subject: Re: [RFC 2/5] OMAP: mux: Make low level function private

On 09/24/10 18:09, Gadiyar, Anand wrote:
On Fri, Sep 24, 2010 at 2:45 PM, Benoit Cousson
<b-cousson@xxxxxx>  wrote:
omap_mux_read / omap_mux_write should not be accessed directly
outside the mux framework.
Do we really have use case that require dynamic mux change beside
GPIO?


Only case I can think of is for any workarounds for issues
that turn up.
No such cases exist today on OMAP3 at least, and none are likely to
appear in future (I hope). So your assumption is valid.


We have a use-case here - granted the code currently is a complete hack
and not something clean enough for the mainline kernel.

We recently rediscovered the USB3320 PHY suspend issue that is in the
errata on the OMAP35x platform (Advisory 3.1.1.193) and we came up with
a workaround for it (despite the errata saying there isn't any) where
essentially we do:

1) Allow the EHCI controller to suspend the PHY as normal
2) Cut the power to the USB host controller using power domains.  This
resets the logic states in the USB host controller so that it is usable
again.
3) Remux all the pins talking to the PHY into GPIO mode
4) Monitor said pins for changes in status to know when a remote wakeup
request occurs
5) Remux pins back to USB PHY mode
6) Reenable power to the USB host controller and reinitialize registers

We've tried this technique before - you still need to re-enumerate after
the resume, right? So you might as well just power down the PHY and
you should be able to recover.

Ajay Gupta did a lot of work on this - not sure if this worked well. We
basically gave up on this interoperability issue and decided to work
around it in newer silicon. 3630 ES1.1 and later has suspend-resume
working with the SMSC PHY.

So, currently our patch to our local kernel essentially the downstream device is reset-resumed. We needed to be able to support USB suspend with it waking up when a device is plugged into our USB port. Since we allow the PHY to suspend (rather than holding it in reset) and we're monitoring the PHY pins via GPIO we can wake up the USB subsystem when device is plugged into the system.

It works well enough that the USB subsystem comes up immediately after we plug in a device, and that it supports suspension without a device. I've even done some tests where I did a remote wakeup with a HID device (mouse button clicks) and some of the time the device would end up being reenumerated, and sometimes a reset-resume, so our current hack isn't perfect, but it does allow what we were mainly aiming for - being able to wake up the USB subsystem when a device is plugged in. That actually is working quite well with our current hack. I should note that our hardware has a permanent hub downstream of the USB3320 phy - not sure if this makes any difference in terms of the behavior of the PHY and doing GPIO against it.

And yes, you're right that newer silicon might work better with the PHY, but we also had hardware that was designed with the problematic PHY before we were aware of the errata. Having something that performs the minimum functionality we needed is better than nothing.

- Tim

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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux