Hi, We are not using OMAP3EVM and SMSC transreciever. We are using NXP ISP1504. The only reason why a reset can fail in ISP 1504 is when ULPI data bus is not held low. There is no way i can be sure that the ISP 1504 is out of reset other than giving a larger delay hoping that it will be ready for operation. We reset the PHY during resume. However during some cases (if device connected to trans reciever is busy) it does not work. In all other cases it works. Regards, sriram On Thu, Dec 3, 2009 at 10:07 AM, Gadiyar, Anand <gadiyar@xxxxxx> wrote: > Sriram V 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. > > > Your logs say you're trying this on an omap3 board. Are you using the > SMSC 332x transceiver? > > If so, there's an explicit interoperability issue with this PHY. > Suspend-resume does not work. It's not yet documented in the > official errata (but will be soon). I'm afraid there's no > software workaround other than to avoid suspending the link. > > If you do suspend, there's no way to recover without resetting or > power-cycling the PHY. > > - Anand > >> >> >> 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
