Re: omap4 ehci sporadic resume issue
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 mich...@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. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
Hi Roger On Thu, Jul 4, 2013 at 10:53 AM, Michael Trimarchi mich...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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? 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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 mich...@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
Re: omap4 ehci sporadic resume issue
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 mich...@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? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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. 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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-kri...@ti.com Date: Wed, 25 Apr 2012 06:05:20 + 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-kri...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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. 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-kri...@ti.com Date: Wed, 25 Apr 2012 06:05:20 + 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-kri...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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. Michael cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
+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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
Hello guys, On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi mich...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 ehci sporadic resume issue
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 mich...@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
Re: omap4 ehci sporadic resume issue
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi mich...@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 mich...@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
Re: omap4 ehci sporadic resume issue
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 mich...@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 mich...@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
