Re: omap4 ehci sporadic resume issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux