omap4 ehci sporadic resume issue

omap4 ehci sporadic resume issue

[Michael Trimarchi]

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?

Normal case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME

DIR has signal

CLOCK is 60 Mhz

Disconnect case

SUSPEND

DIR HIGH
CLOCK is OFF

AFTER RESUME
DIR is LOW
CLOCK is 60Mhz



[   77.593566] ehci-omap ehci-omap.0: ehci_omap_bus_resume
[   77.593658] ehci-omap ehci-omap.0: resume root hub
[   77.615814] hub 2-0:1.0: hub_resume
[   77.639251] hub 1-0:1.0: hub_resume
[   77.639282] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   77.639282] hub 1-0:1.0: port 1: status 0507 change 0000
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   77.639312] hub 1-0:1.0: port 2: status 0507 change 0000
[   77.639312] ehci-omap ehci-omap.0: GetStatus port:3 status 001000 0  ACK POWER sig=se0
[   77.639373] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   77.639404] usb 1-1: usb resume
[   77.639434] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   77.639434] usb 1-2: usb resume
[   77.678314] dump_tranceiver -----------> on port 1
[   77.678314] ULPI_FUNC_CTRL 0x40
[   77.678344] ULPI_IFC_CTRL 0x00
[   77.678344] ULPI_OTG_CTRL 0x06
[   77.678344] ULPI_DEBUG 0x00
[   77.678344] ULPI_USB_INT_STS 0x14
[   77.678344] dump_tranceiver <---------- on port 1
[   77.678375] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   77.678405] dump_tranceiver -----------> on port 2
[   77.678405] ULPI_FUNC_CTRL 0x40
[   77.678405] ULPI_IFC_CTRL 0x00
[   77.678436] ULPI_OTG_CTRL 0x06
[   77.678436] ULPI_DEBUG 0x00
[   77.678436] ULPI_USB_INT_STS 0x14
[   77.678436] dump_tranceiver <---------- on port 2
[   77.678466] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   77.701782] usb 1-1: finish resume
[   77.701812] usb 1-2: finish resume
[   77.701934] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
[   77.701934] Port 2 Status 0x1000
[   77.701934] Port 1 Status 0x1009
[   77.701965] Port 0 Status 0x1009
[   82.717529] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.717590] usb 1-2: kworker/u:12 timed out on ep0in len=0/2
[   82.717590] usb 1-2: gone after usb resume? status -110
[   82.717590] usb 1-2: can't resume, status -110
[   82.717620] hub 1-0:1.0: logical disconnect on port 2
[   82.717620] Disable PORT_PE
[   82.717651] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.717651] PM: Device 1-2 failed to resume async: error -110
[   82.733154] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   82.733184] usb 1-1: kworker/u:15 timed out on ep0in len=0/2
[   82.733215] usb 1-1: gone after usb resume? status -110
[   82.733215] usb 1-1: can't resume, status -110
[   82.733215] hub 1-0:1.0: logical disconnect on port 1
[   82.733215] Disable PORT_PE
[   82.733245] pm_op(): usb_dev_resume+0x0/0x18 returns -110
[   82.733245] PM: Device 1-1 failed to resume async: error -110
[   82.734741] PM: resume of devices complete after 5229.652 msecs
[   83.303863] PM: Finishing wakeup.
[   83.307525] Restarting tasks ... 
[   83.311157] hub 2-0:1.0: state 7 ports 1 chg 0000 evt 0000
[   83.317504] hub 2-0:1.0: hub_resume
[   83.321716] done.
[   83.323974] suspend: exit suspend, ret = 0 (2000-01-02 21:07:12.171992466 UTC)
[   83.323974] hub 2-0:1.0: activate --> -22
[   83.324005] hub 1-0:1.0: state 7 ports 3 chg 0006 evt 0006
[   83.324035] ehci-omap ehci-omap.0: GetStatus port:1 status 001801 0  ACK POWER sig=j CONNECT
[   83.324035] hub 1-0:1.0: port 1, status 0501, change 0000, 480 Mb/s
[   83.324035] usb 1-1: USB disconnect, device number 2
[   83.324066] usb 1-1.2: USB disconnect, device number 4
[   83.324066] usb 1-1.2: unregistering device
[   83.324066] usb 1-1.2: unregistering interface 1-1.2:1.0
[   83.530700] usb 1-1.2: usb_disable_device nuking all URBs
[   83.537200] usb 1-1.3: USB disconnect, device number 5
[   83.542907] usb 1-1.3: unregistering device
[   83.547546] usb 1-1.3: unregistering interface 1-1.3:1.0
[   83.554107] usb 1-1.3: usb_disable_device nuking all URBs
[   83.560577] usb 1-1: unregistering device
[   83.565063] usb 1-1: unregistering interface 1-1:1.0
[   83.570800] usb 1-1: usb_disable_device nuking all URBs


Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

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
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?

Also, are you suspending and resuming only the USB or the entire system?

cheers,
-roger

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

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?

First time is 18, and then?

> 
> 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.

Michael


> cheers,
> -roger

-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

+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.

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).

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.

> 
> 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

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

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

Re: omap4 ehci sporadic resume issue

[Ruslan Bilovol]

Hello guys,

On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> 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?

We need to wait 3ms for entire USB bus to go into suspend after
setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
will communicate with PHY so it is not safe to switch the clocks to
internal source.
That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
is enough here
and is successfully used last few years for production devices.

-- 
Best regards,
Ruslan Bilvol

>
>
>> 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-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> Hello guys,
> 
> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
> > 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?
> 
> We need to wait 3ms for entire USB bus to go into suspend after
> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
> will communicate with PHY so it is not safe to switch the clocks to
> internal source.
> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
> is enough here
> and is successfully used last few years for production devices.

Well this mdelay is the switch of the clock and not the delay after
PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?

Anyway I understand, but why both hub connected to the smsc3320 move from
HS to FS? So it's not important if there is a drift of delay but it must
be >= 4ms. Correct?

The code works if I just use one port or remove one hub ;)

Now the code is like this:

temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
temp |= PORT_WKDISC_E | PORT_WKOC_E;
ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);

mdelay(4);
omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));

The code of the function is up on this email.

Michael

> 
> -- 
> Best regards,
> Ruslan Bilvol
> 
> >
> >
> >> 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-usb" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Ruslan Bilovol]

On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi
>
> On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
>> Hello guys,
>>
>> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
>> <michael@amarulasolutions.com> wrote:
>> > 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?
>>
>> We need to wait 3ms for entire USB bus to go into suspend after
>> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
>> will communicate with PHY so it is not safe to switch the clocks to
>> internal source.
>> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
>> is enough here
>> and is successfully used last few years for production devices.
>
> Well this mdelay is the switch of the clock and not the delay after
> PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
> 4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?

Yes, sorry for confusing :)
Moreover, 2ms is more than enough, errata document says about 1ms delay
(and probably may be decreased up to few useconds)

>
> Anyway I understand, but why both hub connected to the smsc3320 move from
> HS to FS? So it's not important if there is a drift of delay but it must
> be >= 4ms. Correct?
>
> The code works if I just use one port or remove one hub ;)
>
> Now the code is like this:
>
> temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
> temp |= PORT_WKDISC_E | PORT_WKOC_E;
> ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
>
> mdelay(4);
> omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));
>
> The code of the function is up on this email.

Do you have locks around this software workaround?
The patch I did against 3.4 linux kernel may be helpful for
you in such case: http://review.omapzoom.org/28515
Another patch extends this WA for all OMAP4 SoCs:
http://review.omapzoom.org/31108

Regards
Ruslan

>
> Michael
>
>>
>> --
>> Best regards,
>> Ruslan Bilvol
>>
>> >
>> >
>> >> 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-usb" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
> > Hi
> >
> > On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> >> Hello guys,
> >>
> >> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> >> <michael@amarulasolutions.com> wrote:
> >> > 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?
> >>
> >> We need to wait 3ms for entire USB bus to go into suspend after
> >> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
> >> will communicate with PHY so it is not safe to switch the clocks to
> >> internal source.
> >> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
> >> is enough here
> >> and is successfully used last few years for production devices.
> >
> > Well this mdelay is the switch of the clock and not the delay after
> > PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
> > 4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?
> 
> Yes, sorry for confusing :)
> Moreover, 2ms is more than enough, errata document says about 1ms delay
> (and probably may be decreased up to few useconds)
> 
> >
> > Anyway I understand, but why both hub connected to the smsc3320 move from
> > HS to FS? So it's not important if there is a drift of delay but it must
> > be >= 4ms. Correct?
> >
> > The code works if I just use one port or remove one hub ;)
> >
> > Now the code is like this:
> >
> > temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
> > temp |= PORT_WKDISC_E | PORT_WKOC_E;
> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> >
> > mdelay(4);
> > omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));
> >
> > The code of the function is up on this email.
> 
> Do you have locks around this software workaround?
> The patch I did against 3.4 linux kernel may be helpful for
> you in such case: http://review.omapzoom.org/28515
> Another patch extends this WA for all OMAP4 SoCs:
> http://review.omapzoom.org/31108

Yes, I'm using this code already applied to p-android-3.4 tree.
So the code is fine because it works when I use just one port
but for some reason I have problem when both ulpibx are active.

The scenario is this one:

GOOD ONE

[   23.389892] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   23.389923] usb 1-1: usb resume
[   23.390014] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   23.390045] usb 1-2: usb resume
[   23.428497] dump_tranceiver -----------> on port 1
[   23.428527] ULPI_FUNC_CTRL 0x40
[   23.428558] ULPI_IFC_CTRL 0x00
[   23.428558] ULPI_OTG_CTRL 0x06
[   23.428588] ULPI_DEBUG 0x00
[   23.428588] ULPI_USB_INT_STS 0x14
[   23.428619] dump_tranceiver <---------- on port 1
[   23.428649] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   23.428710] dump_tranceiver -----------> on port 2
[   23.428741] ULPI_FUNC_CTRL 0x40
[   23.428771] ULPI_IFC_CTRL 0x00
[   23.428771] ULPI_OTG_CTRL 0x06
[   23.428802] ULPI_DEBUG 0x00
[   23.428802] ULPI_USB_INT_STS 0x14
[   23.428802] dump_tranceiver <---------- on port 2
[   23.428863] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK POWER sig=se0 PE CONNECT

BAD ONE

[   32.741638] ehci-omap ehci-omap.0: GetStatus port:3 status 001000 0  ACK POWER sig=se0
[   32.741851] ehci-omap ehci-omap.0: GetStatus port:1 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   32.741912] usb 1-1: usb resume
[   32.741973] ehci-omap ehci-omap.0: GetStatus port:2 status 001885 0  ACK POWER sig=j SUSPEND PE CONNECT
[   32.742034] usb 1-2: usb resume
[   32.780395] dump_tranceiver -----------> on port 1
[   32.780426] ULPI_FUNC_CTRL 0x40
[   32.780456] ULPI_IFC_CTRL 0x00
[   32.780456] ULPI_OTG_CTRL 0x06
[   32.780487] ULPI_DEBUG 0x00
[   32.780487] ULPI_USB_INT_STS 0x14
[   32.780517] dump_tranceiver <---------- on port 1
[   32.780578] ehci-omap ehci-omap.0: GetStatus port:1 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   32.780639] dump_tranceiver -----------> on port 2
[   32.780670] ULPI_FUNC_CTRL 0x40
[   32.780670] ULPI_IFC_CTRL 0x00
[   32.780700] ULPI_OTG_CTRL 0x06
[   32.780700] ULPI_DEBUG 0x00
[   32.780731] ULPI_USB_INT_STS 0x14
[   32.780731] dump_tranceiver <---------- on port 2
[   32.780792] ehci-omap ehci-omap.0: GetStatus port:2 status 001005 0  ACK POWER sig=se0 PE CONNECT
[   32.803894] usb 1-2: finish resume
[   32.803985] usb 1-1: finish resume
[   32.804046] ehci-omap ehci-omap.0: irq status a004 Async Recl PCD
[   32.804046] Port 2 Status 0x1000
[   32.804077] Port 1 Status 0x1009
[   32.804077] Port 0 Status 0x1009

So status 1005 was good HS
1009 switch move to FS/LS device

[   37.819274] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   37.819427] usb 1-2: kworker/u:0 timed out on ep0in len=0/2
[   37.819458] usb 1-2: retry with reset-resume
[   37.819519] ehci-omap ehci-omap.0: port 2 reset
[   37.834899] ehci-omap ehci-omap.0: IAA watchdog: status a008 cmd 10065
[   37.835021] usb 1-1: kworker/u:3 timed out on ep0in len=0/2
[   37.835021] usb 1-1: retry with reset-resume
[   37.882049] ehci-omap ehci-omap.0: port 2 full speed --> companion
[   37.882110] ehci-omap ehci-omap.0: GetStatus port:2 status 003001 0  ACK POWER OWNER sig=se0 CONNECT
[   37.882141] ehci-omap ehci-omap.0: irq status 200c Recl FLR PCD
[   37.882171] Port 2 Status 0x1000
[   37.882202] Port 1 Status 0x300a
[   37.882202] Port 0 Status 0x1809
[   37.882263] hub 1-0:1.0: port 2 not reset yet, waiting 50ms
[   37.944396] ehci-omap ehci-omap.0: GetStatus port:2 status 00300a 0  ACK POWER OWNER sig=se0 PEC CSC
[   37.944488] hub 1-0:1.0: logical disconnect on port 2
[   37.944549] usb 1-2: gone after usb resume? status -19
[   37.944580] usb 1-2: can't resume, status -19
[   37.944580] hub 1-0:1.0: logical disconnect on port 2
[   37.944763] ehci-omap ehci-omap.0: port 1 reset
[   38.007171] ehci-omap ehci-omap.0: port 1 full speed --> companion
[   38.007232] ehci-omap ehci-omap.0: GetStatus port:1 status 003001 0  ACK POWER OWNER sig=se0 CONNECT
[   38.007263] ehci-omap ehci-omap.0: irq status 2004 Recl PCD


Michael

> 
> Regards
> Ruslan
> 
> >
> > Michael
> >
> >>
> >> --
> >> Best regards,
> >> Ruslan Bilvol
> >>
> >> >
> >> >
> >> >> 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-usb" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> <michael@amarulasolutions.com> wrote:
> > Hi
> >
> > On Thu, Jun 27, 2013 at 09:59:35PM +0300, Ruslan Bilovol wrote:
> >> Hello guys,
> >>
> >> On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi
> >> <michael@amarulasolutions.com> wrote:
> >> > 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?
> >>
> >> We need to wait 3ms for entire USB bus to go into suspend after
> >> setting the PORT_SUSPEND bit. During this time, internal OMAP EHCI logic
> >> will communicate with PHY so it is not safe to switch the clocks to
> >> internal source.
> >> That's why with 2ms delay it fails. 4ms delay (3ms + 1ms for safety)
> >> is enough here
> >> and is successfully used last few years for production devices.
> >
> > Well this mdelay is the switch of the clock and not the delay after
> > PORT_SUSPEND. So after writing PORT_SUSPEND I need to wait
> > 4ms and then in 2ms you have a lot of clock to reach the 18 count. Correct?
> 
> Yes, sorry for confusing :)
> Moreover, 2ms is more than enough, errata document says about 1ms delay
> (and probably may be decreased up to few useconds)
> 
> >
> > Anyway I understand, but why both hub connected to the smsc3320 move from
> > HS to FS? So it's not important if there is a drift of delay but it must
> > be >= 4ms. Correct?
> >
> > The code works if I just use one port or remove one hub ;)
> >
> > Now the code is like this:
> >
> > temp &= ~(PORT_WKCONN_E | PORT_RWC_BITS);
> > temp |= PORT_WKDISC_E | PORT_WKOC_E;
> > ehci_writel(ehci, temp | PORT_SUSPEND, status_reg);
> >
> > mdelay(4);
> > omap_ehci_erratum_i693(ehci, ((wIndex & 0xff) - 1));
> >
> > The code of the function is up on this email.
> 
> Do you have locks around this software workaround?
> The patch I did against 3.4 linux kernel may be helpful for
> you in such case: http://review.omapzoom.org/28515
> Another patch extends this WA for all OMAP4 SoCs:
> http://review.omapzoom.org/31108

I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
the problem could be:

1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
could be it a problem?

2) idle status of ulpis pins?

Michael

> 
> Regards
> Ruslan
> 
> >
> > Michael
> >
> >>
> >> --
> >> Best regards,
> >> Ruslan Bilvol
> >>
> >> >
> >> >
> >> >> 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-usb" in
> >> > the body of a message to majordomo@vger.kernel.org
> >> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
> Hi Roger
> 
> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:

>> Do you have locks around this software workaround?
>> The patch I did against 3.4 linux kernel may be helpful for
>> you in such case: http://review.omapzoom.org/28515
>> Another patch extends this WA for all OMAP4 SoCs:
>> http://review.omapzoom.org/31108
> 
> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
> the problem could be:
> 
> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
> could be it a problem?

If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
issue if OFF mode is disabled? If yes then it probably is not related to SAR.

> 
> 2) idle status of ulpis pins?

Yes this can be possible.

When you said earlier that the problem doesn't happen when one of the ULPIs is used
did you try both of them individually. e.g. case 1: port 1 only enabled,
case 2: port 2 only enabled.

Did it work in both the cases?

cheers,
-roger

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
> > Hi Roger
> > 
> > On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> >> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> >> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> 
> >> Do you have locks around this software workaround?
> >> The patch I did against 3.4 linux kernel may be helpful for
> >> you in such case: http://review.omapzoom.org/28515
> >> Another patch extends this WA for all OMAP4 SoCs:
> >> http://review.omapzoom.org/31108
> > 
> > I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
> > the problem could be:
> > 
> > 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
> > could be it a problem?
> 
> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
> 

I don't go in full retantion for FSUSB now

[   36.317413]    PD_CORE curr=ON prev=ON logic=ON
[   36.317413]    PD_L3_INIT curr=ON prev=ON logic=ON
[   36.317413]       CD_L3_INIT mode=SW_SLEEP activity=0x2100
[   36.317413]          FSUSB mode=DISABLED stbyst=STBY idlest=TRANSITION
[   36.317413] Powerdomain (core_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3
[   36.317413] Powerdomain (l3init_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3

This with enable_off_mode equal to 1 and usb stuck

but if I switch to enable_off_mode 0 (debug file), it works. So the problem seems somewhere there.

Michael

> > 
> > 2) idle status of ulpis pins?
> 
> Yes this can be possible.
> 
> When you said earlier that the problem doesn't happen when one of the ULPIs is used
> did you try both of them individually. e.g. case 1: port 1 only enabled,
> case 2: port 2 only enabled.
> 
> Did it work in both the cases?
> 
> cheers,
> -roger
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

On 06/28/2013 03:26 PM, Michael Trimarchi wrote:
> Hi
> 
> On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
>> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
>>> Hi Roger
>>>
>>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
>>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>>>> <michael@amarulasolutions.com> wrote:
>>
>>>> Do you have locks around this software workaround?
>>>> The patch I did against 3.4 linux kernel may be helpful for
>>>> you in such case: http://review.omapzoom.org/28515
>>>> Another patch extends this WA for all OMAP4 SoCs:
>>>> http://review.omapzoom.org/31108
>>>
>>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
>>> the problem could be:
>>>
>>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
>>> could be it a problem?
>>
>> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
>> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
>>
> 
> I don't go in full retantion for FSUSB now
> 
> [   36.317413]    PD_CORE curr=ON prev=ON logic=ON
> [   36.317413]    PD_L3_INIT curr=ON prev=ON logic=ON
> [   36.317413]       CD_L3_INIT mode=SW_SLEEP activity=0x2100
> [   36.317413]          FSUSB mode=DISABLED stbyst=STBY idlest=TRANSITION
> [   36.317413] Powerdomain (core_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3
> [   36.317413] Powerdomain (l3init_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3
> 
> This with enable_off_mode equal to 1 and usb stuck
> 
> but if I switch to enable_off_mode 0 (debug file), it works. So the problem seems somewhere there.

OK. Looks like the FSUSB module is stuck in transition. This can happen if the bootloader
hasn't improperly managed the FSUSB clock.

Can you apply the below patch to your bootloader and make sure FSUSB module is OFF at boot.

Let's see how it behaves with FSUSB out of the picture.

cheers,
-roger

>From 0e42d3643d531daabd086f7ee451fdda8f22e72a Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Wed, 25 Apr 2012 06:05:20 +0000
Subject: [PATCH] omap4: do not enable fs-usb module

If this is done in the bootloader, the FS-USB will later be stuck into
intransition state, which will prevent the device from entering idle.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/cpu/armv7/omap4/clocks.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap4/clocks.c b/arch/arm/cpu/armv7/omap4/clocks.c
index e2189f7..2802559 100644
--- a/arch/arm/cpu/armv7/omap4/clocks.c
+++ b/arch/arm/cpu/armv7/omap4/clocks.c
@@ -355,7 +355,6 @@ void enable_basic_clocks(void)
 		&prcm->cm_l4per_gptimer2_clkctrl,
 		&prcm->cm_wkup_wdtimer2_clkctrl,
 		&prcm->cm_l4per_uart3_clkctrl,
-		&prcm->cm_l3init_fsusb_clkctrl,
 		&prcm->cm_l3init_hsusbhost_clkctrl,
 		0
 	};
@@ -482,7 +481,6 @@ void enable_non_essential_clocks(void)
 		&prcm->cm_dss_dss_clkctrl,
 		&prcm->cm_sgx_sgx_clkctrl,
 		&prcm->cm_l3init_hsusbhost_clkctrl,
-		&prcm->cm_l3init_fsusb_clkctrl,
 		0
 	};
 
-- 
1.7.4.1

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 03:55:08PM +0300, Roger Quadros wrote:
> On 06/28/2013 03:26 PM, Michael Trimarchi wrote:
> > Hi
> > 
> > On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
> >> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
> >>> Hi Roger
> >>>
> >>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> >>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> >>>> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> >>
> >>>> Do you have locks around this software workaround?
> >>>> The patch I did against 3.4 linux kernel may be helpful for
> >>>> you in such case: http://review.omapzoom.org/28515
> >>>> Another patch extends this WA for all OMAP4 SoCs:
> >>>> http://review.omapzoom.org/31108
> >>>
> >>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
> >>> the problem could be:
> >>>
> >>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
> >>> could be it a problem?
> >>
> >> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
> >> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
> >>
> > 
> > I don't go in full retantion for FSUSB now
> > 
> > [   36.317413]    PD_CORE curr=ON prev=ON logic=ON
> > [   36.317413]    PD_L3_INIT curr=ON prev=ON logic=ON
> > [   36.317413]       CD_L3_INIT mode=SW_SLEEP activity=0x2100
> > [   36.317413]          FSUSB mode=DISABLED stbyst=STBY idlest=TRANSITION
> > [   36.317413] Powerdomain (core_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3
> > [   36.317413] Powerdomain (l3init_pwrdm) didn't enter target state 1 Vs achieved state 3. current state 3
> > 
> > This with enable_off_mode equal to 1 and usb stuck
> > 
> > but if I switch to enable_off_mode 0 (debug file), it works. So the problem seems somewhere there.
> 
> OK. Looks like the FSUSB module is stuck in transition. This can happen if the bootloader
> hasn't improperly managed the FSUSB clock.
> 
> Can you apply the below patch to your bootloader and make sure FSUSB module is OFF at boot.
> 
> Let's see how it behaves with FSUSB out of the picture.

I was having already in the queue. Not was testing because the system is very complicated with boot security. BTW now I have fixed the retantion and change suspend
state of REGEN1 for a shutdown problem. So now the system
can suspend perfectly but the problem is still there. I have done a very
good step forward ;) anyway (was planned to test the new version of bootloader)

Michael


> 
> cheers,
> -roger
> 
> From 0e42d3643d531daabd086f7ee451fdda8f22e72a Mon Sep 17 00:00:00 2001
> From: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> Date: Wed, 25 Apr 2012 06:05:20 +0000
> Subject: [PATCH] omap4: do not enable fs-usb module
> 
> If this is done in the bootloader, the FS-USB will later be stuck into
> intransition state, which will prevent the device from entering idle.
> 
> Signed-off-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
> ---
>  arch/arm/cpu/armv7/omap4/clocks.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/omap4/clocks.c b/arch/arm/cpu/armv7/omap4/clocks.c
> index e2189f7..2802559 100644
> --- a/arch/arm/cpu/armv7/omap4/clocks.c
> +++ b/arch/arm/cpu/armv7/omap4/clocks.c
> @@ -355,7 +355,6 @@ void enable_basic_clocks(void)
>  		&prcm->cm_l4per_gptimer2_clkctrl,
>  		&prcm->cm_wkup_wdtimer2_clkctrl,
>  		&prcm->cm_l4per_uart3_clkctrl,
> -		&prcm->cm_l3init_fsusb_clkctrl,
>  		&prcm->cm_l3init_hsusbhost_clkctrl,
>  		0
>  	};
> @@ -482,7 +481,6 @@ void enable_non_essential_clocks(void)
>  		&prcm->cm_dss_dss_clkctrl,
>  		&prcm->cm_sgx_sgx_clkctrl,
>  		&prcm->cm_l3init_hsusbhost_clkctrl,
> -		&prcm->cm_l3init_fsusb_clkctrl,
>  		0
>  	};
>  
> -- 
> 1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
> > Hi Roger
> > 
> > On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
> >> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
> >> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> 
> >> Do you have locks around this software workaround?
> >> The patch I did against 3.4 linux kernel may be helpful for
> >> you in such case: http://review.omapzoom.org/28515
> >> Another patch extends this WA for all OMAP4 SoCs:
> >> http://review.omapzoom.org/31108
> > 
> > I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
> > the problem could be:
> > 
> > 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
> > could be it a problem?
> 
> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
> 
> > 
> > 2) idle status of ulpis pins?
> 
> Yes this can be possible.
> 
> When you said earlier that the problem doesn't happen when one of the ULPIs is used
> did you try both of them individually. e.g. case 1: port 1 only enabled,
> case 2: port 2 only enabled.
> 
> Did it work in both the cases?

Yes, so I don't think could be a problem of ulpi pins and why this happen
on both at the same time? Seems more connected to somenthing else.

Michael

> 
> cheers,
> -roger
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On 06/28/2013 01:46 PM, Roger Quadros wrote:
> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
>> Hi Roger
>>
>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>>> <michael@amarulasolutions.com> wrote:
> 
>>> Do you have locks around this software workaround?
>>> The patch I did against 3.4 linux kernel may be helpful for
>>> you in such case: http://review.omapzoom.org/28515
>>> Another patch extends this WA for all OMAP4 SoCs:
>>> http://review.omapzoom.org/31108
>>
>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
>> the problem could be:
>>
>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
>> could be it a problem?
> 
> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
> 
>>
>> 2) idle status of ulpis pins?
> 
> Yes this can be possible.
> 
> When you said earlier that the problem doesn't happen when one of the ULPIs is used
> did you try both of them individually. e.g. case 1: port 1 only enabled,
> case 2: port 2 only enabled.
> 
> Did it work in both the cases?

off state of the line can make the situation worst ;). What are the idle/off state of the lines
on your platforms?

I can use PAD_REMUX flag to change the datax and signal of each port. I think that when the core
is in RET_OFF the signal lines are remuxed in off mode. Correct?

Michael


> 
> cheers,
> -roger
> 

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
> Hi
> 
> On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
>> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
>>> Hi Roger
>>>
>>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
>>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>>>> <michael@amarulasolutions.com> wrote:
>>
>>>> Do you have locks around this software workaround?
>>>> The patch I did against 3.4 linux kernel may be helpful for
>>>> you in such case: http://review.omapzoom.org/28515
>>>> Another patch extends this WA for all OMAP4 SoCs:
>>>> http://review.omapzoom.org/31108
>>>
>>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
>>> the problem could be:
>>>
>>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
>>> could be it a problem?
>>
>> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
>> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
>>
>>>
>>> 2) idle status of ulpis pins?
>>
>> Yes this can be possible.
>>
>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>> case 2: port 2 only enabled.
>>
>> Did it work in both the cases?
> 
> Yes, so I don't think could be a problem of ulpi pins and why this happen
> on both at the same time? Seems more connected to somenthing else.
> 

Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.

I'm not sure how to go about fixing this. How important is OFF Mode for your application.
Can you keep it always disabled?

cheers,
-roger

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On 07/02/2013 04:42 PM, Roger Quadros wrote:
> On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
>> Hi
>>
>> On Fri, Jun 28, 2013 at 02:46:11PM +0300, Roger Quadros wrote:
>>> On 06/28/2013 02:33 PM, Michael Trimarchi wrote:
>>>> Hi Roger
>>>>
>>>> On Thu, Jun 27, 2013 at 11:07:11PM +0300, Ruslan Bilovol wrote:
>>>>> On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi
>>>>> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>>>
>>>>> Do you have locks around this software workaround?
>>>>> The patch I did against 3.4 linux kernel may be helpful for
>>>>> you in such case: http://review.omapzoom.org/28515
>>>>> Another patch extends this WA for all OMAP4 SoCs:
>>>>> http://review.omapzoom.org/31108
>>>>
>>>> I'm testing using pm_test and stop to core (5ms and not 5 seconds) (usb suspend cycle are done correctly) so
>>>> the problem could be:
>>>>
>>>> 1) SAR usb context restore. I have applied the SAR workaround but the core doesn't go in full retantion
>>>> could be it a problem?
>>>
>>> If core doesn't go in to OFF then SAR will not come into play. Are you still affected by the
>>> issue if OFF mode is disabled? If yes then it probably is not related to SAR.
>>>
>>>>
>>>> 2) idle status of ulpis pins?
>>>
>>> Yes this can be possible.
>>>
>>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>>> case 2: port 2 only enabled.
>>>
>>> Did it work in both the cases?
>>
>> Yes, so I don't think could be a problem of ulpi pins and why this happen
>> on both at the same time? Seems more connected to somenthing else.
>>
> 
> Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.
> 
> I'm not sure how to go about fixing this. How important is OFF Mode for your application.
> Can you keep it always disabled?
> 

Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline.

Last question:
If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?


Michael


> cheers,
> -roger
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Nishanth Menon]

On 16:49-20130702, Michael Trimarchi wrote:
> Last question:
> If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?
Without going to the depth of what TRM says already:
SAR comes into play only if device-off sequence was triggered. Depending
on which domain and what level of retention state was programmed,
device-off sequence may not even start. Note: Generically speaking, not
achieving device OFF may not mean other powerdomains cannot achieve OFF
and loose context. Specific example of USB tied on core domain, the
behavior could be different.

-- 
Regards,
Nishanth Menon

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
> Hi Roger
> 
> On 07/02/2013 04:42 PM, Roger Quadros wrote:
>> On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
>>> Hi
>>>

>>>>
>>>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>>>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>>>> case 2: port 2 only enabled.
>>>>
>>>> Did it work in both the cases?
>>>
>>> Yes, so I don't think could be a problem of ulpi pins and why this happen
>>> on both at the same time? Seems more connected to somenthing else.
>>>
>>
>> Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.
>>
>> I'm not sure how to go about fixing this. How important is OFF Mode for your application.
>> Can you keep it always disabled?
>>


> 
> Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline.
> 

Yes, our aim is to get it working with mainline as well.

> Last question:
> If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?
> 

SAR restore will only happen when the Device enters OFF mode.

Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend
if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter
"3.9.3 Device OFF State Management" in the TRM.

cheers,
-roger

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi

On 07/02/2013 05:03 PM, Roger Quadros wrote:
> 
> On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
>> Hi Roger
>>
>> On 07/02/2013 04:42 PM, Roger Quadros wrote:
>>> On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
>>>> Hi
>>>>
> 
>>>>>
>>>>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>>>>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>>>>> case 2: port 2 only enabled.
>>>>>
>>>>> Did it work in both the cases?
>>>>
>>>> Yes, so I don't think could be a problem of ulpi pins and why this happen
>>>> on both at the same time? Seems more connected to somenthing else.
>>>>
>>>
>>> Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.
>>>
>>> I'm not sure how to go about fixing this. How important is OFF Mode for your application.
>>> Can you keep it always disabled?
>>>
> 
> 
>>
>> Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline.
>>
> 
> Yes, our aim is to get it working with mainline as well.
> 
>> Last question:
>> If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?
>>
> 
> SAR restore will only happen when the Device enters OFF mode.
> 
> Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend
> if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter
> "3.9.3 Device OFF State Management" in the TRM.

What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device
will not go in off mode and the sar will not be used? How can work the restore?

> 

I have added a check of CM_RESTORE_ST. This register need to be clear before
going in OFF mode and then show if the status of phase1 2a and 2b is completed.
So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register,
but without success.

Michael

> cheers,
> -roger
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: omap4 ehci sporadic resume issue

[Michael Trimarchi]

Hi Roger

On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi
<michael@amarulasolutions.com> wrote:
> Hi
>
> On 07/02/2013 05:03 PM, Roger Quadros wrote:
>>
>> On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
>>> Hi Roger
>>>
>>> On 07/02/2013 04:42 PM, Roger Quadros wrote:
>>>> On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
>>>>> Hi
>>>>>
>>

I'm working on PM consumption of other subsystem because it's a very
complex device.
Right now the pm consumption is sleep mode is 6mA just for (off mode disabled)

omap4 + LPDDR2 and TWL6032

I don't exactly know if they have updated the last bootloader but I think so.

I have tried to work on STP signal and re-enable it just before resume
but nothing change

Anyway my idea is the problem is releated on 18clk counter and an
invalid state of the
hw. I will try to implement save & restore register by hand instead
using the sar.

Michael


>>>>>>
>>>>>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>>>>>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>>>>>> case 2: port 2 only enabled.
>>>>>>
>>>>>> Did it work in both the cases?
>>>>>
>>>>> Yes, so I don't think could be a problem of ulpi pins and why this happen
>>>>> on both at the same time? Seems more connected to somenthing else.
>>>>>
>>>>
>>>> Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.
>>>>
>>>> I'm not sure how to go about fixing this. How important is OFF Mode for your application.
>>>> Can you keep it always disabled?
>>>>
>>
>>
>>>
>>> Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline.
>>>
>>
>> Yes, our aim is to get it working with mainline as well.
>>
>>> Last question:
>>> If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?
>>>
>>
>> SAR restore will only happen when the Device enters OFF mode.
>>
>> Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend
>> if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter
>> "3.9.3 Device OFF State Management" in the TRM.
>
> What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device
> will not go in off mode and the sar will not be used? How can work the restore?
>
>>
>
> I have added a check of CM_RESTORE_ST. This register need to be clear before
> going in OFF mode and then show if the status of phase1 2a and 2b is completed.
> So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register,
> but without success.
>
> Michael
>
>> cheers,
>> -roger
>>
>
>

Re: omap4 ehci sporadic resume issue

[Roger Quadros]

Hi Michael,

On 08/30/2013 08:59 PM, Michael Trimarchi wrote:
> Hi Roger
> 
> On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi
> <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>> Hi
>>
>> On 07/02/2013 05:03 PM, Roger Quadros wrote:
>>>
>>> On 07/02/2013 05:49 PM, Michael Trimarchi wrote:
>>>> Hi Roger
>>>>
>>>> On 07/02/2013 04:42 PM, Roger Quadros wrote:
>>>>> On 06/28/2013 07:47 PM, Michael Trimarchi wrote:
>>>>>> Hi
>>>>>>
>>>
> 
> I'm working on PM consumption of other subsystem because it's a very
> complex device.
> Right now the pm consumption is sleep mode is 6mA just for (off mode disabled)
> 
> omap4 + LPDDR2 and TWL6032
> 
> I don't exactly know if they have updated the last bootloader but I think so.
> 
> I have tried to work on STP signal and re-enable it just before resume
> but nothing change
> 
> Anyway my idea is the problem is releated on 18clk counter and an
> invalid state of the
> hw. I will try to implement save & restore register by hand instead
> using the sar.

There are 2 erratas related to the issues you mentioned.

i693 - USB HOST EHCI - Port Resume Fails On Second Resume Iteration
i719 - HS USB: Multiple OFF Mode Transitions Introduce Corruption

cheers,
-roger

> 
> Michael
> 
> 
>>>>>>>
>>>>>>> When you said earlier that the problem doesn't happen when one of the ULPIs is used
>>>>>>> did you try both of them individually. e.g. case 1: port 1 only enabled,
>>>>>>> case 2: port 2 only enabled.
>>>>>>>
>>>>>>> Did it work in both the cases?
>>>>>>
>>>>>> Yes, so I don't think could be a problem of ulpi pins and why this happen
>>>>>> on both at the same time? Seems more connected to somenthing else.
>>>>>>
>>>>>
>>>>> Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously.
>>>>>
>>>>> I'm not sure how to go about fixing this. How important is OFF Mode for your application.
>>>>> Can you keep it always disabled?
>>>>>
>>>
>>>
>>>>
>>>> Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline.
>>>>
>>>
>>> Yes, our aim is to get it working with mainline as well.
>>>
>>>> Last question:
>>>> If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode?
>>>>
>>>
>>> SAR restore will only happen when the Device enters OFF mode.
>>>
>>> Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend
>>> if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter
>>> "3.9.3 Device OFF State Management" in the TRM.
>>
>> What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device
>> will not go in off mode and the sar will not be used? How can work the restore?
>>
>>>
>>
>> I have added a check of CM_RESTORE_ST. This register need to be clear before
>> going in OFF mode and then show if the status of phase1 2a and 2b is completed.
>> So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register,
>> but without success.
>>
>> Michael
>>
>>> cheers,
>>> -roger
>>>
>>
>>

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html