-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 17 Jan 2013 11:22:55 +1100 NeilBrown <neilb@xxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 16 Jan 2013 13:11:26 +0200 Igor Grinberg <grinberg@xxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxx> > > > 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@xxxxxxxxxxxxxx> > > >>> 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@xxxxxxxxxxxxxxxxxxxx> wrote: > > >>>>>> > > >>>>>>> Hi Neil > > >>>>>>> > > >>>>>>> On 01/09/2013 11:19 AM, NeilBrown wrote: > > >>>>>>>> On Wed, 09 Jan 2013 12:00:05 +0200 Igor Grinberg <grinberg@xxxxxxxxxxxxxx> > > >>>>>>>> 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----- ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±þ??§ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
