Hi Roger On Thu, Jun 27, 2013 at 05:49:41PM +0300, Roger Quadros wrote: > +Ruslan > > On 06/27/2013 05:17 PM, Michael Trimarchi wrote: > > Hi Roger > > > > On Thu, Jun 27, 2013 at 04:59:38PM +0300, Roger Quadros wrote: > >> Hi Michael, > >> > >> On 06/27/2013 02:51 PM, Michael Trimarchi wrote: > >>> Hi > >>> > >>> I'm working on omap4460 with two ulpi connected to (SMSC3320 -> HUB SMSC2514) or (TUSB1210 -> HUB SMSC2514). > >>> The problem only happen when both port are used and after few suspend resume are triggered. > >>> If I use just one port there is no issue on suspend resume. I already covered all TI > >>> errata that I know and I'm working on TI kernel. > >>> > >>> The problem is here > >>> > >>> [ 77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD > >>> > >>> Both ports change status from 001005 to 001009 (you have a log just after). > >>> So from host point of view both hub connected are not working in HS mode. > >>> After that the omap ehci has gone because the bus can not work in FS and LS and I can not recover from here. > >>> Status of transceivers are dumped and they are ok after resume. > >>> > >>> Do you have any suggestion? > >> > >> I'm not very sure but both ports suddenly changing state like that look like > >> a hardware issue. Also, it is strange that you can reproduce it only when two > >> ports are simultaneously in use. Unfortunately, I can't match your setup with 2 ULPI > > > > Yes I know that TI doesn't have any setup like that. > > > >> ports. > >> > >> I have a OMAP5 uEVM that uses 2 ports but it won't be identical to your setup as > >> they are on HSIC and not ULPI. > >> > >> Did you try errata i693? > > > > Yes I have it. It's not clear if I need to wait after > > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg); > > polling the suspendM of the SMSC or the suspend status of the PORT or I can > > switch just after this instruction. Because TI kernel use an msleep of 4 mseconds and then switch. It could be a timing issue on how errata is implemented when I have two ports? How this internal count works? > > > The OMAP EHCI controller transparently sets the suspendM bit of the PHY when you > set the PORT_SUSPEND feature on the EHCI port. So you don't need to poll for anything. > A delay is necessary. If we apply the errata to the port before a delay the errata doesn't work. /* Use internal 60Mhz clock ULPIBx */ temp_reg = omap_readl(L3INIT_HSUSBHOST_CLKCTRL); temp_reg |= 1 << (8 + port); temp_reg &= ~(1 << (24 + port)); omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL); /* Wait 2ms to have transceiver transaction */ mdelay(2); /* Use external clock ULPIBx */ temp_reg &= ~(1 << (8 + port)); temp_reg |= 1 << (24 + port); omap_writel(temp_reg, L3INIT_HSUSBHOST_CLKCTRL); Now it's not clear to me what happen if I apply this clock too early (transeceiver still driver the clock) or too late. Any clue? > What the errata says is that once software sets the PORT_SUSPEND feature, the PHY will > got into suspend and cut the PHY clock sooner than required for the EHCI controller to > complete its suspend operations. (NOTE: this is only applicable when the PHY is providing the > ulpi_clk). > Yes this is the case > What the workaround does is to just wait for a while (don't know why 4ms), and remux the > ulpi_clock to an internal 60MHz clock for a while so that it can complete its suspend operations. What happen if I apply a big delay after PORT_SUSPEND. Will the internal state machine of the omap continue to wait the clock? Michael > > > > > First time is 18, and then? > > > I think it is 18 for every port suspend. > > >> > >> Also, are you suspending and resuming only the USB or the entire system? > >> > > > > Whole system. Right the only susbsytem that doens't go to suspend is the FSUSB > > but this depends on the bootloader. > > OK. > > cheers, > -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
