Re: Help wanted with USB and OMAP3 off_mode

[NeilBrown <neilb@suse.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg <grinberg@compulab.co.il>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/16/13 12:19, NeilBrown wrote:
> > On Wed, 16 Jan 2013 11:28:02 +0200 Igor Grinberg <grinberg@compulab.co.il>
> > wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> > 
> >> On 01/16/13 09:26, NeilBrown wrote:
> >>> On Wed, 09 Jan 2013 14:54:00 +0200 Igor Grinberg <grinberg@compulab.co.il>
> >>> wrote:
> >>>
> >>>> On 01/09/13 14:08, Michael Trimarchi wrote:
> >>>>> Hi Neil
> >>>>>
> >>>>> I forget to answer to your questions
> >>>>>
> >>>>> On 01/09/2013 12:34 PM, NeilBrown wrote:
> >>>>>> On Wed, 09 Jan 2013 11:24:09 +0100 Michael Trimarchi
> >>>>>> <michael@amarulasolutions.com> wrote:
> >>>>>>
> >>>>>>> Hi Neil
> >>>>>>>
> >>>>>>> On 01/09/2013 11:19 AM, NeilBrown wrote:
> >>>>>>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <grinberg@compulab.co.il>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
> >>>>>>>>> Hash: SHA1
> >>>>>>>>
> >>>>>>>>> Hi Neil,
> >>>>>>>>
> >>>>>>>>> On 01/09/13 00:29, NeilBrown wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>  I'm trying to get off_mode working reliably on my gta04 mobile phone.
> >>>>>>>>>>
> >>>>>>>>>> My current stumbling block is USB.  The "Option" GSM module is attached via
> >>>>>>>>>> USB (there is a separate transceiver chip attached to port 1 which is placed
> >>>>>>>>>> in OMAP_EHCI_PORT_MODE_PHY).
> >>>>>>>>
> >>>>>>>>> Which PHY is this (vendor/model)?
> >>>>>>>>
> >>>>>>>> Hi Igor,
> >>>>>>>>   it is the SMSC USB3322
> >>>>>>>>
> >>>>>>>> http://www.smsc.com/media/Downloads_Public/Data_Sheets/3320.pdf
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> BTW I subsequently discovered that keeping USBHOST out off off_mode only
> >>>>>>>> sometimes avoid the problem, not always.  So there are probably multiple
> >>>>>>>> issues :-(
> >>>>
> >>>> We have the same PHY and it has some issues with the OMAP USB code.
> >>>> First issue we experience is that if we reset the PHY more then once
> >>>> w/o power cycling it, the PHY dies until next power cycle.
> >>>> So, we stop providing the reset GPIO to the usb code and do the reset
> >>>> in the board code.
> >>>
> >>> I've tried various change w.r.t the resetting and  I cannot fault it.
> >>> Resetting or not resetting neither causes a problem while the USB is
> >>> otherwise working, not fixed the USB while  it is otherwise failing.
> >>> So I don't think this is my problem - thanks.
> >>>
> >>>>
> >>>>>>>
> >>>>>>> Are you sure that you don't have glitch on power, reset pin during suspend?
> >>>>>>>
> >>>>>>
> >>>>>> No, I don't really have the equipment to measure such things.
> >>>>>> But is it likely?  Would enabling off_mode make it more likely?
> >>>>>
> >>>>> I don't know the reason of the off_mode problem :(
> >>>>
> >>>> We have the equipment to check this and no - this is not the case.
> >>>>
> >>>>>
> >>>>>> Can you suggest some way I could test the hypothesis?
> >>>>>
> >>>>> I had the same problem on a rugged mobile phone, so it is just experience
> >>>>> Check the modem power and reset gpio too, but if you don't need to unblock it
> >>>>> with the pin after resume we know that modem is not the problem
> >>>>
> >>>> I don't think modem is the problem...
> >>>> We have plain USB connector ports that are dead after the resume from off-mode.
> >>>>
> >>>> The good news are that we have the off-mode working on v3.6.1,
> >>>> including the USB, but we had to do some horrible ugly hacking for this.
> >>>>
> >>>
> >>> I assume this  means "some patches on top of 3.6.1" ??
> >>> Care to share your code?  Even horribly ugly hacks can be educational.
> > 
> >> We are not ready to share these patches (this will happen eventually
> >> after some work is finished), but I can explain what they do...
> > 
> >> We split the ehci_run function to separate the debugfs and sysfs stuff from
> >> other initializations, so we can run the new version without the debugfs and
> >> sysfs stuff multiple times.
> > 
> >> Then we implement the suspend/resume ehci callbacks:
> >> on suspend, assert phy reset,
> >> on resume, deassert phy reset, write EHCI_INSNREG04_DISABLE_UNSUSPEND to
> >> EHCI_INSNREG04, and call the new ehci_run() function.
> > 
> >> That does the job for USB host to resume from off mode.
> > 
> > Interesting thanks.  That makes a certain amount of sense.
> > 
> > However I tried compiling ehci-hcd as a module and  unload/reloading it which
> > should have a similar net effect to what you did, but it didn't make any
> > difference - device disappears on resume.
> 
> Yes it does for cm-t3730, in fact, that is what we have started from...
> 
> > 
> > I also tried restoring the correct value to EHCI_INSNREG04 and
> > EHCI_INSNREG05_ULPI which are the only registers written by 
> > ehci-omap.c, and that didn't help either.
> > 
> > The only thing I've found that works is keeping 'core' out of off-mode.
> 
> Ah, one more thing, we ensure that phy is completely powered off through
> the TPS power scripts, otherwise, it does not work...
> 

Ahhh....  that does make a difference.

I turned off the 5V5 rail which powered the phy (and a few other things) and
now the usb-attached modem appears after resume.  Very interesting.

I hadn't been doing this as I had been advised that the hardware wouldn't
like it.  There are a few devices (including the  USB PHY) which are supplied
by both a 1V8 rail and the 5V5 rail.  Some of them are out-of-spec if the 1V8
is supplied, but the 5V5 isn't.
The 1V8 must remain on during suspend as it keep the RAM powered, so the 5V5
must as well.  Awkward.


It is not entirely satisfactory for other reasons. It seems that with
off_mode fully working, we drop to off mode when CPUIDLE puts things to
sleep, and that removes the 5V5 too, which is bad.  This disconnects the USB.
My current console log shows:


[ 2453.837402] usb 1-2: new high-speed USB device number 10 using ehci-omap
[ 2454.006256] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 2454.015686] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 2454.025512] usb 1-2: Product: Globetrotter HSUPA Modem
[ 2454.031005] usb 1-2: Manufacturer: Option N.V.
[ 2455.355804] usb 1-2: USB disconnect, device number 10
[ 2459.829589] usb 1-2: new high-speed USB device number 11 using ehci-omap
[ 2459.997894] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 2460.007385] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 2460.017242] usb 1-2: Product: Globetrotter HSUPA Modem
[ 2460.022644] usb 1-2: Manufacturer: Option N.V.
[ 2469.496490] usb 1-2: USB disconnect, device number 11
[ 2472.845245] usb 1-2: new high-speed USB device number 12 using ehci-omap
[ 2473.013946] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 2473.023376] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 2473.033264] usb 1-2: Product: Globetrotter HSUPA Modem
[ 2473.038757] usb 1-2: Manufacturer: Option N.V.
[ 2474.528289] usb 1-2: USB disconnect, device number 12
[ 2478.829589] usb 1-2: new high-speed USB device number 13 using ehci-omap
[ 2478.998748] usb 1-2: New USB device found, idVendor=0af0, idProduct=8800
[ 2479.008209] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[ 2479.018005] usb 1-2: Product: Globetrotter HSUPA Modem
[ 2479.023498] usb 1-2: Manufacturer: Option N.V.
[ 2480.374694] usb 1-2: USB disconnect, device number 13

i.e. the modem disconnecting and reconnecting. every few seconds.  The modem
eventually got upset and has  entered a state where I cannot communicate with
it.

So - interesting and useful, but I don't have a complete solution yet.


Also, while this gets the internal USB working (to some extent) the external
usb (USB-OTG using the musb driver) is still broken.  When CORE is only
allowed into retention mode, it works fine. When CORE goes to off-mode, I
lose the USB port.  So that'll be another  problem to solve.

Thanks again,

NeilBrown
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQIVAwUBUPdEXznsnt1WYoG5AQJ5qg/8DrSirSXfIT0U/IqyQyimdRS6w11JjuUa
xQnSl7be6Tr0buNM/xZ1ZfQ6fs47aOOnFYjAVLUjHUqVxXhUjDZLo5KxI0yoYi35
gzoGWTB4AS8Bx/V7dOHxBtOO0t/vUyxiTiAWhG7AFZZc6CM/Z4UzQvD4uyY+bQNj
2YmF112lMULtpfW5m56vsqxyf9sQn+Cr+1snnOx416wF2Vq5lNaZhVhqX+Oqz9o2
TvtSS2p3hntAQPBPl0VZ4DZAdiquSkq8LZTKKca0u85MHwHx1v4HvG5S9NqDkDfo
hIaQdaku5Xe7SgLoUrIb4a2ppWe8OwjcrB6MSDugzP0Y0gt/kq5uoe75/TVJ23Kw
ijjo/LwQNvT1G8ruHBg0evawX5Ttn4prfh1FQeyJkDWewXtVaonb7AV4E+RUc2qw
obhZ4rxor+sGy7Qj18RBMsWv+8n4/QPKw1RkUYrkSITDof3OYI3UcnFfT9hKVwhe
Uz2vFX/rBj3uVn+5uSR3flMtwgpey9RAAb5tMzqDtPPi+R8v6gUxOZkvBjje6hQc
YLcULiFxdPiFNTiWs7BkTO7nRxS5DIE5mtG/LmWoa73abAN2JjIfVIPwRwlS7xdB
on0MwUNIQmNL58seYS2JA2UavDP/Y/Lcnjos0b/BqxjXWrHTEdP6WSkq2k48+40M
5D3wKCNXC8w=
=m9M+
-----END PGP SIGNATURE-----