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 > 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 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 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
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
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 > 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 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 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 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 >>> 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 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 > >> 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 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 > 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 > 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 > --- > 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
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 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 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 --- 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 > >> 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 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 >> 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 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 > 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 > >> 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
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 > 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 > >> 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_WKDIS
Re: omap4 ehci sporadic resume issue
On Thu, Jun 27, 2013 at 10:24 PM, Michael Trimarchi 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 >> 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://r
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 > 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
Re: omap4 ehci sporadic resume issue
Hello guys, On Thu, Jun 27, 2013 at 8:56 PM, Michael Trimarchi 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 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
+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 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
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
omap4 ehci sporadic resume issue
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 [ 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 [ 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 evt [ 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 , 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.56506