Hi, When you say transceiver, do you mean its an USB transceiver (ULPI or FS OTG) ? Yes most probably the transceiver is not out of reset. From your log it looks like that the device is getting disconnected after the failed resume and does not enumerate again. So it looks like that transceiver is not coming out of reset at all when it fails. If its an ULPI transceiver then the clock will turned off during suspend and on during wakeup by the transceiver. If the clock is not turned on by the transceiver then the resume may fail. You may need a power-on reset to turn the transceiver clock . After the failure, if you unplug and plug the device from host, does it enumerate again? How do you make sure that the transceiver is out of reset on the device side? Regards, John On Thu, Dec 3, 2009 at 7:59 AM, Sriram V <vshrirama@xxxxxxxxx> wrote: > > Hi, > > I had posted this mail to linux-pm a few days back. Was not able to > resolve this issue > I thought this is the right list to post to. > > 1) I have a USB - GSM device which is connected to a transreciver. > 2) The transreciver is connected to the host controller and the only > control i got over it is to reset it > or bring it out of reset using a gpio. > 3) The USB GSM device is self powered and does not need current from > the USB Bus. > 4) When the usb device is idle - When i do suspend the system "echo > mem > /sys/power/state". > every thing works fine > 5) When the usb device is busy (Say somebody is calling the phone > when i am in suspend) > I get -19 as the error code. > > 6) What is being done in the suspend code is - turn off clocks and > bring transreciver in reset. > 7) In resume function - We turn on all the clocks and bring the > transreciver out of reset. > 8) The usb device is functional all through out since it is self > powered, However it is disconnected from the host. > > All i understood was - The host is not able to communicate with the > device when the resume fails or the device > has not replied back properly. > > USB a host initiated protocol In that case the GSM device cannot send > anything on the bus. isnt it? > So in this case the only problem i think could be the transreciever > has not got reset properly or within time. > I am not really sure though. > > I am not sure if this is a device issue? > > > Please advice. > > > Regards, > Sriram > > > > > > Successful resume: > ----------------------------- > > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > PM: Entering mem sleep > Suspending console(s) (use no_console_suspend to debug) > hub 1-0:1.0: hub_suspend > usb usb1: bus suspend > ehci-omap ehci-omap.0: suspend root hub > ehci-omap ehci-omap.0: port 3, 00001000 -> 00701000 > ehci-omap ehci-omap.0: port 2, 00001005 -> 00701085 > ehci-omap ehci-omap.0: port 1, 00001000 -> 00701000 > usb usb1: usb resume > USB resume > ehci-omap ehci-omap.0: resume root hub > ehci-omap ehci-omap.0: resumed port 2 > hub 1-0:1.0: hub_resume > ehci-omap ehci-omap.0: GetStatus port 1 status 001000 POWER sig=se0 > ehci-omap ehci-omap.0: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT > hub 1-0:1.0: port 2: status 0503 change 0000 > ehci-omap ehci-omap.0: GetStatus port 3 status 001000 POWER sig=se0 > PM: Finishing wakeup. > Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000 > done. > > Unsuccessful Resume: > ---------------------------------- > > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > PM: Entering mem sleep > Suspending console(s) (use no_console_suspend to debug) > hub 1-0:1.0: hub_suspend > usb usb1: bus suspend > ehci-omap ehci-omap.0: suspend root hub > ehci-omap ehci-omap.0: port 3, 00001000 -> 00701000 > ehci-omap ehci-omap.0: port 2, 00001005 -> 00701085 > ehci-omap ehci-omap.0: port 1, 00001000 -> 00701000 > usb usb1: usb resume > USB resume > ehci-omap ehci-omap.0: resume root hub > ehci-omap ehci-omap.0: irq status 000c FLR PCD > hub 1-0:1.0: hub_resume > ehci-omap ehci-omap.0: GetStatus port 1 status 001000 POWER sig=se0 > ehci-omap ehci-omap.0: GetStatus port 2 status 001002 POWER sig=se0 CSC > hub 1-0:1.0: port 2: status 0100 change 0001 > ehci-omap ehci-omap.0: GetStatus port 3 status 001000 POWER sig=se0 > ehci-omap ehci-omap.0: GetStatus port 2 status 001000 POWER sig=se0 > hub 1-0:1.0: port 2 status 0000.0100 after resume, -19 > usb 1-2: can't resume, status -19 > hub 1-0:1.0: logical disconnect on port 2 > pm_op(): usb_dev_resume+0x0/0x18 returns -19 > PM: Device 1-2 failed to resume: error -19 > PM: Finishing wakeup. > Restarting tasks ... <7>hub 1-0:1.0: state 7 ports 3 chg 0004 evt 0000 > ehci-omap ehci-omap.0: GetStatus port 2 status 001000 POWER sig=se0 > hub 1-0:1.0: port 2, status 0100, change 0000, 12 Mb/s > usb 1-2: USB disconnect, address 2 > usb 1-2: unregistering device > usb 1-2: usb_disable_device nuking all URBs > usb 1-2: unregistering interface 1-2:1.0 > usb 1-2:1.0: uevent > usb 1-2: unregistering interface 1-2:1.1 > usb 1-2:1.1: uevent > usb 1-2: unregistering interface 1-2:1.2 > usb 1-2:1.2: uevent > usb 1-2: unregistering interface 1-2:1.3 > done. > usb 1-2:1.3: uevent > usb 1-2: unregistering interface 1-2:1.4 > usb 1-2:1.4: uevent > usb 1-2: uevent > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
