Sriram V wrote: > > 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. Great. For this PHY, there's a PHY errata that you need to take care of (delay the STP line by a little). Check with NXP for that errata doc, and make sure you've taken care of that. Also, make sure you tie XTAL1 to GND instead of 1V8. This should take care of the suspend-resume failure. There's no need to reset the PHY during resume. You're not supposed to do that. The OMAP will take care of putting the PHY in low-power mode when it enters suspend. - Anand > > 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 > >> > >> > >> > >> > >> <log snipped>-- 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
