Hi, On Fri, Mar 26, 2010 at 2:13 AM, Gadiyar, Anand <gadiyar@xxxxxx> wrote: > Oliver Neukum wrote: >> >> Am Donnerstag, 25. März 2010 11:22:41 schrieb Sriram V: >> > Thank You, I went through the errata document. Probably that >> > explains the usb suspend-resumes failures. >> >> Can you make a link to this erratum available publically? > > This is the public errata document for the 3530. The internal one > is a little more detailed though. > > See page 94 for the description. > <http://focus.ti.com/lit/er/sprz278e/sprz278e.pdf> > >> >> > Now that we use this part on your board. Cant we support >> > suspend-resume for other interfaces at all without getting "usb resume >> > failures" >> > My understanding is - If suspend-resume has to work then we need to >> > put all the interfaces to suspend. >> > Is there a workaround/hack? >> >> Have you tried to set the reset resume quirk for the root hub? > > A root-hub reset resume might work of course. Good idea! I tried the following: 1) Added a Quirk for the root-hub for ehci host controller { USB_DEVICE(0x1d6b, 0x0002), .driver_info = USB_QUIRK_RESET_RESUME }, 2) In suspend - I put PHY in reset by doing a making USB_PHY_RESET_GPIO = 0. 3) In resume - I bring PHY out of reset in resume by doing a USB_PHY_RESET_GPIO = 1. But, I still get the following prints and the devices get re-enumerated and i am able to access them after resume. pm_op(): usb_dev_resume+0x0/0x18 returns -19 PM: Device 1-2.1 failed to resume: error -19 I also tried doing a reset for the hub and i get the same result. Trying to figure out what is happening and why this error occurs. Thank you, Regards, sriram > > We might need to power cycle the PHY, or reset it with the > OMAP GPIO that's connected to its reset pin. > > Thanks, > Anand > -- 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
