Re: Help wanted with USB and OMAP3 off_mode

[NeilBrown <neilb@suse.de>]

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

On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown <neilb@suse.de> wrote:

> -----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.

Actually, forget all that.  My testing methodology was flawed and I wasn't
really seeing what I thought I was seeing.
I'll try to find time to be more careful and if I find something interesting,
I'll let you know.

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

iQIVAwUBUPfDZTnsnt1WYoG5AQJ66w/6Ai4Gw4qQRcSWjK+trZ+1LjobLxjzSmOf
OXygPengsCbkAvHyEGPVilsz3C/INQm4DEo6xxqeva8aMU5LjCJFXgwdVCI/mi60
/FShjWVcLWzuakemEbBdXHLC4zrBTbYUb0yFwdqDlBhjSpBtyOqPCqfWNc3oTLs5
p2K8cUsCctKQfQCQW7LWOtgoyC1sRXQY1hTSCkdiXIruv5Kmb038CHUNhpdBbhkC
YrG8YE/Xjh7rEJPsrskPpemXgWS80gTQ0R0FPjQ9NNS85USvmAx20ei7DpoGZub1
8QIyGlULq9fXrA4wzlF5+dGgPsNkxjwRRd9MxFoogO0VUMdOocr6hnoS6QCn9AcI
VNNJvaBu8bOkyoWU65d46RL+NPYiYMb/6NzPdiLqSYbAeI050+DH589t/yZUeei8
vranN0haOGHbURoi3sw2A4EFID22uSyCdUtyIYAWLpxu0f3Cao3UddzGJFli63wk
LnG9a6T6iReeRf3fJwobiIQeEOQTjWTYQknaQscWBzzdFt3Wp72s5uTOhonvES0o
60HpCFHEqfQeK1KG7ueMlFUOggUfO81y0Yow3GZ7SG1QKaiJdt7SnqKJpb4T+IDX
BIatatH/s66jLCHWB205t/3/Xf7O83YaqEeLnyY8U4n91vspntW5J2gFltapTymj
jzJQI7m9+9c=
=ebni
-----END PGP SIGNATURE-----