-----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. 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----- ÿôèº{.nÇ+?·?®??+%?Ëÿ±éݶ¥?wÿº{.nÇ+?·¥?{±þ??§ø§¶?¡Ü¨}©?²Æ zÚ&j:+v?¨þø ¯ù ®w¥þ?à2?Þ?¨èÚ&¢)ß¡«a¶Úÿÿûàz¿äz¹Þ?ú+?ù???Ý¢jÿ?wèþf
