* [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case @ 2015-08-20 16:12 Gregory CLEMENT 2015-08-21 12:29 ` Gregory CLEMENT 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-08-20 16:12 UTC (permalink / raw) To: Felipe Balbi Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, Gregory CLEMENT, stable According to the OTG specification after a timeout of OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must move from the state a_wait_vrise to the state a_wait_bcon. However, the dsps version of musb does not handle this case. Without it, the driver could remain stuck in the a_wait_vrise. It can be reproduce with the following steps: 1) Boot a board with no USB adapter inserted 2) Insert an empty OTG adapter 3) Wait 2 seconds then remove the OTG adapter 4) The unit is now stuck in host mode, the VBUS switch is latched on and the ID pin is no longer polled. The only way to exit this state was to insert a OTG adapter with an USB device connected. Until this, the usb device mode was not available. It was tested on a AM35x based board. CC: <stable@vger.kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> --- drivers/usb/musb/musb_dsps.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 65d931a..2d22683 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -145,6 +145,7 @@ struct dsps_glue { struct timer_list timer; /* otg_workaround timer */ unsigned long last_timer; /* last timer data for each instance */ bool sw_babble_enabled; + int otg_state_a_wait_vrise_timeout; struct dsps_context context; struct debugfs_regset32 regset; @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb) spin_lock_irqsave(&musb->lock, flags); switch (musb->xceiv->otg->state) { + case OTG_STATE_A_WAIT_VRISE: + if ((glue->otg_state_a_wait_vrise_timeout)) { + musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON; + musb->is_active = 0; + } + mod_timer(&glue->timer, jiffies + + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); + break; case OTG_STATE_A_WAIT_BCON: dsps_writeb(musb->mregs, MUSB_DEVCTL, 0); skip_session = 1; + glue->otg_state_a_wait_vrise_timeout = 0; /* fall */ case OTG_STATE_A_IDLE: @@ -359,7 +369,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci) MUSB_HST_MODE(musb); musb->xceiv->otg->default_a = 1; musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; - del_timer(&glue->timer); + glue->otg_state_a_wait_vrise_timeout = 1; + mod_timer(&glue->timer, jiffies + + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); } else { musb->is_active = 0; MUSB_DEV_MODE(musb); -- 2.1.0 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-08-20 16:12 [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Gregory CLEMENT @ 2015-08-21 12:29 ` Gregory CLEMENT 2015-08-31 15:52 ` Gregory CLEMENT 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-08-21 12:29 UTC (permalink / raw) To: Felipe Balbi Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Hi all, On 20/08/2015 18:12, Gregory CLEMENT wrote: > According to the OTG specification after a timeout of > OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must > move from the state a_wait_vrise to the state a_wait_bcon. However, > the dsps version of musb does not handle this case. > > Without it, the driver could remain stuck in the a_wait_vrise. It can > be reproduce with the following steps: > > 1) Boot a board with no USB adapter inserted > 2) Insert an empty OTG adapter > 3) Wait 2 seconds then remove the OTG adapter > 4) The unit is now stuck in host mode, the VBUS switch is latched on > and the ID pin is no longer polled. > > The only way to exit this state was to insert a OTG adapter with an > USB device connected. Until this, the usb device mode was not > available. > > It was tested on a AM35x based board. > > CC: <stable@vger.kernel.org> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> > --- > drivers/usb/musb/musb_dsps.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > index 65d931a..2d22683 100644 > --- a/drivers/usb/musb/musb_dsps.c > +++ b/drivers/usb/musb/musb_dsps.c > @@ -145,6 +145,7 @@ struct dsps_glue { > struct timer_list timer; /* otg_workaround timer */ > unsigned long last_timer; /* last timer data for each instance */ > bool sw_babble_enabled; > + int otg_state_a_wait_vrise_timeout; > > struct dsps_context context; > struct debugfs_regset32 regset; > @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb) > > spin_lock_irqsave(&musb->lock, flags); > switch (musb->xceiv->otg->state) { > + case OTG_STATE_A_WAIT_VRISE: > + if ((glue->otg_state_a_wait_vrise_timeout)) { > + musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON; > + musb->is_active = 0; > + } > + mod_timer(&glue->timer, jiffies + > + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); After more test on more USB drive, it seems that for some of them OTG_TIME_A_WAIT_VRISE is too short. 200ms seems better. It is disturbing because according to the OTG specification the maximum is 100ms, however I am not so surprised that USB device maker don't follow it. > + break; > case OTG_STATE_A_WAIT_BCON: > dsps_writeb(musb->mregs, MUSB_DEVCTL, 0); > skip_session = 1; > + glue->otg_state_a_wait_vrise_timeout = 0; > /* fall */ > > case OTG_STATE_A_IDLE: > @@ -359,7 +369,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci) > MUSB_HST_MODE(musb); > musb->xceiv->otg->default_a = 1; > musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; > - del_timer(&glue->timer); > + glue->otg_state_a_wait_vrise_timeout = 1; > + mod_timer(&glue->timer, jiffies + > + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); > } else { > musb->is_active = 0; > MUSB_DEV_MODE(musb); > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-08-21 12:29 ` Gregory CLEMENT @ 2015-08-31 15:52 ` Gregory CLEMENT 2015-10-05 20:02 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-08-31 15:52 UTC (permalink / raw) To: Felipe Balbi Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Hi Felipe, On ven., août 21 2015, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: >> According to the OTG specification after a timeout of >> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must >> move from the state a_wait_vrise to the state a_wait_bcon. However, >> the dsps version of musb does not handle this case. >> >> Without it, the driver could remain stuck in the a_wait_vrise. It can >> be reproduce with the following steps: >> >> 1) Boot a board with no USB adapter inserted >> 2) Insert an empty OTG adapter >> 3) Wait 2 seconds then remove the OTG adapter >> 4) The unit is now stuck in host mode, the VBUS switch is latched on >> and the ID pin is no longer polled. >> >> The only way to exit this state was to insert a OTG adapter with an >> USB device connected. Until this, the usb device mode was not >> available. >> >> It was tested on a AM35x based board. >> >> CC: <stable@vger.kernel.org> >> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> >> --- >> drivers/usb/musb/musb_dsps.c | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c >> index 65d931a..2d22683 100644 >> --- a/drivers/usb/musb/musb_dsps.c >> +++ b/drivers/usb/musb/musb_dsps.c >> @@ -145,6 +145,7 @@ struct dsps_glue { >> struct timer_list timer; /* otg_workaround timer */ >> unsigned long last_timer; /* last timer data for each instance */ >> bool sw_babble_enabled; >> + int otg_state_a_wait_vrise_timeout; >> >> struct dsps_context context; >> struct debugfs_regset32 regset; >> @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb) >> >> spin_lock_irqsave(&musb->lock, flags); >> switch (musb->xceiv->otg->state) { >> + case OTG_STATE_A_WAIT_VRISE: >> + if ((glue->otg_state_a_wait_vrise_timeout)) { >> + musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON; >> + musb->is_active = 0; >> + } >> + mod_timer(&glue->timer, jiffies + >> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); > > After more test on more USB drive, it seems that for some of them > OTG_TIME_A_WAIT_VRISE is too short. 200ms seems better. It is > disturbing because according to the OTG specification the maximum > is 100ms, however I am not so surprised that USB device maker don't > follow it. So after many tests on different devices, 200ms is enough for most of them, but for one, 2000ms (2s) was needed! I see several option: - adding a sysfs entry to setup the time - adding a debugs entry entry - adding configuration option in menuconfig - using 2000ms and hopping it was enough for everyone My preference would go to the first option, what is your opinion? Thanks, Gregory > > >> + break; >> case OTG_STATE_A_WAIT_BCON: >> dsps_writeb(musb->mregs, MUSB_DEVCTL, 0); >> skip_session = 1; >> + glue->otg_state_a_wait_vrise_timeout = 0; >> /* fall */ >> >> case OTG_STATE_A_IDLE: >> @@ -359,7 +369,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci) >> MUSB_HST_MODE(musb); >> musb->xceiv->otg->default_a = 1; >> musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE; >> - del_timer(&glue->timer); >> + glue->otg_state_a_wait_vrise_timeout = 1; >> + mod_timer(&glue->timer, jiffies + >> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); >> } else { >> musb->is_active = 0; >> MUSB_DEV_MODE(musb); >> > > > -- > Gregory Clement, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-08-31 15:52 ` Gregory CLEMENT @ 2015-10-05 20:02 ` Felipe Balbi 2015-10-20 17:33 ` Gregory CLEMENT 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-10-05 20:02 UTC (permalink / raw) To: Gregory CLEMENT Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable [-- Attachment #1: Type: text/plain, Size: 3731 bytes --] Gregory CLEMENT <gregory.clement@free-electrons.com> writes: > Hi Felipe, > > On ven., août 21 2015, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: >>> According to the OTG specification after a timeout of >>> OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must >>> move from the state a_wait_vrise to the state a_wait_bcon. However, >>> the dsps version of musb does not handle this case. >>> >>> Without it, the driver could remain stuck in the a_wait_vrise. It can >>> be reproduce with the following steps: >>> >>> 1) Boot a board with no USB adapter inserted >>> 2) Insert an empty OTG adapter >>> 3) Wait 2 seconds then remove the OTG adapter >>> 4) The unit is now stuck in host mode, the VBUS switch is latched on >>> and the ID pin is no longer polled. >>> >>> The only way to exit this state was to insert a OTG adapter with an >>> USB device connected. Until this, the usb device mode was not >>> available. >>> >>> It was tested on a AM35x based board. >>> >>> CC: <stable@vger.kernel.org> >>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> >>> --- >>> drivers/usb/musb/musb_dsps.c | 14 +++++++++++++- >>> 1 file changed, 13 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c >>> index 65d931a..2d22683 100644 >>> --- a/drivers/usb/musb/musb_dsps.c >>> +++ b/drivers/usb/musb/musb_dsps.c >>> @@ -145,6 +145,7 @@ struct dsps_glue { >>> struct timer_list timer; /* otg_workaround timer */ >>> unsigned long last_timer; /* last timer data for each instance */ >>> bool sw_babble_enabled; >>> + int otg_state_a_wait_vrise_timeout; >>> >>> struct dsps_context context; >>> struct debugfs_regset32 regset; >>> @@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb) >>> >>> spin_lock_irqsave(&musb->lock, flags); >>> switch (musb->xceiv->otg->state) { >>> + case OTG_STATE_A_WAIT_VRISE: >>> + if ((glue->otg_state_a_wait_vrise_timeout)) { >>> + musb->xceiv->otg->state = OTG_STATE_A_WAIT_BCON; >>> + musb->is_active = 0; >>> + } >>> + mod_timer(&glue->timer, jiffies + >>> + msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE)); >> >> After more test on more USB drive, it seems that for some of them >> OTG_TIME_A_WAIT_VRISE is too short. 200ms seems better. It is >> disturbing because according to the OTG specification the maximum >> is 100ms, however I am not so surprised that USB device maker don't >> follow it. > > So after many tests on different devices, 200ms is enough for most of > them, but for one, 2000ms (2s) was needed! > > I see several option: > - adding a sysfs entry to setup the time > - adding a debugs entry entry > - adding configuration option in menuconfig > - using 2000ms and hopping it was enough for everyone > > My preference would go to the first option, what is your opinion? I'm not sure if either of them is good. man 2s is just too large. If the device isn't following the specification, I'm afraid that device needs to be fixed. I think the real issue here is the lack of a disconnect IRQ from AM335x devices. But here's something I've been meaning to test but never had time. If you look into AM335x address space, there's a bit in the wrapper which tells it to use the standard MUSB registers for IRQ, instead of the TI-specific thing. Can you see if we get a disconnect IRQ with that ? TRM is at [1], see page 2566. Basically, if you set bit 3 in register offset 0x1014, then it should use Mentor IRQ registers. If that works, quite a few problems will actually vanish :-p [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-10-05 20:02 ` Felipe Balbi @ 2015-10-20 17:33 ` Gregory CLEMENT 2015-12-07 9:52 ` Gregory CLEMENT 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-10-20 17:33 UTC (permalink / raw) To: Felipe Balbi Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Hi Felipe, On lun., oct. 05 2015, Felipe Balbi <balbi@ti.com> wrote: >> So after many tests on different devices, 200ms is enough for most of >> them, but for one, 2000ms (2s) was needed! >> >> I see several option: >> - adding a sysfs entry to setup the time >> - adding a debugs entry entry >> - adding configuration option in menuconfig >> - using 2000ms and hopping it was enough for everyone >> >> My preference would go to the first option, what is your opinion? > > I'm not sure if either of them is good. man 2s is just too large. If the > device isn't following the specification, I'm afraid that device needs > to be fixed. > > I think the real issue here is the lack of a disconnect IRQ from AM335x > devices. But here's something I've been meaning to test but never had > time. If you look into AM335x address space, there's a bit in the > wrapper which tells it to use the standard MUSB registers for IRQ, > instead of the TI-specific thing. Can you see if we get a disconnect IRQ > with that ? > > TRM is at [1], see page 2566. Basically, if you set bit 3 in register > offset 0x1014, then it should use Mentor IRQ registers. If that works, > quite a few problems will actually vanish :-p So I tried it with the following patch: ------------------------------------- diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index c791ba5..c714500 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb) /* Reset the musb */ dsps_writel(reg_base, wrp->control, (1 << wrp->reset)); + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); musb->isr = dsps_interrupt; @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb) if (session_restart || !glue->sw_babble_enabled) { dev_info(musb->controller, "Restarting MUSB to recover from Babble\n"); dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset)); + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); usleep_range(100, 200); usb_phy_shutdown(musb->xceiv); usleep_range(100, 200); ------------------------------------ I am not very familiar with that driver but my understanding was that the Mentor IRQ registeres are managed by the musb_interrupt() function which is called from the dsps_interrupt() interrupt handler. Am I right? if it is the case then it didn't fix the issue I had. I activated the following debug line: [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" But I didn't get any interrupt while disconnecting the cable without any device connected on it (whereas I got an interrupt when I connected it). Note that I applied this patch instead of the "usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case", is what you had in mind ? Gregory > > [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf > > -- > balbi -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-10-20 17:33 ` Gregory CLEMENT @ 2015-12-07 9:52 ` Gregory CLEMENT 2015-12-07 19:26 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-12-07 9:52 UTC (permalink / raw) To: Felipe Balbi Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Hi Felipe, I am going back on this subject (again :) ) On mar., oct. 20 2015, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: > Hi Felipe, > > On lun., oct. 05 2015, Felipe Balbi <balbi@ti.com> wrote: > > >>> So after many tests on different devices, 200ms is enough for most of >>> them, but for one, 2000ms (2s) was needed! >>> >>> I see several option: >>> - adding a sysfs entry to setup the time >>> - adding a debugs entry entry >>> - adding configuration option in menuconfig >>> - using 2000ms and hopping it was enough for everyone >>> >>> My preference would go to the first option, what is your opinion? >> >> I'm not sure if either of them is good. man 2s is just too large. If the Well 2s is lon I agree, but currently instead of 2s we have an infinite wait, which is worse! >> device isn't following the specification, I'm afraid that device needs >> to be fixed. I agree but these devices are for most of them USB stick that we find in retail. We have no influence on them, so we have to do with them, even if they do not follow the sepc. So what about using configfs or sysfs to let the user confgiure this value if needed? I go back on this because, your suggestion didn't work. At least, I didn't manage to make it improve the situation. Thanks, >> >> I think the real issue here is the lack of a disconnect IRQ from AM335x >> devices. But here's something I've been meaning to test but never had >> time. If you look into AM335x address space, there's a bit in the >> wrapper which tells it to use the standard MUSB registers for IRQ, >> instead of the TI-specific thing. Can you see if we get a disconnect IRQ >> with that ? >> >> TRM is at [1], see page 2566. Basically, if you set bit 3 in register >> offset 0x1014, then it should use Mentor IRQ registers. If that works, >> quite a few problems will actually vanish :-p > > So I tried it with the following patch: > > ------------------------------------- > diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c > index c791ba5..c714500 100644 > --- a/drivers/usb/musb/musb_dsps.c > +++ b/drivers/usb/musb/musb_dsps.c > @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb) > > /* Reset the musb */ > dsps_writel(reg_base, wrp->control, (1 << wrp->reset)); > + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); > > musb->isr = dsps_interrupt; > > @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb) > if (session_restart || !glue->sw_babble_enabled) { > dev_info(musb->controller, "Restarting MUSB to recover from Babble\n"); > dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset)); > + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); > usleep_range(100, 200); > usb_phy_shutdown(musb->xceiv); > usleep_range(100, 200); > ------------------------------------ > > I am not very familiar with that driver but my understanding was that > the Mentor IRQ registeres are managed by the musb_interrupt() function > which is called from the dsps_interrupt() interrupt handler. > > Am I right? > > if it is the case then it didn't fix the issue I had. > > I activated the following debug line: > > [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" > [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" > > But I didn't get any interrupt while disconnecting the cable without any > device connected on it (whereas I got an interrupt when I connected it). > > Note that I applied this patch instead of the "usb: musb: dsps: handle > the otg_state_a_wait_vrise_timeout case", is what you had in mind ? > > Gregory > >> >> [1] http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf >> >> -- >> balbi > > -- > Gregory Clement, Free Electrons > Kernel, drivers, real-time and embedded Linux > development, consulting, training and support. > http://free-electrons.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-07 9:52 ` Gregory CLEMENT @ 2015-12-07 19:26 ` Felipe Balbi 2015-12-08 9:07 ` Gregory CLEMENT 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-12-07 19:26 UTC (permalink / raw) To: Gregory CLEMENT, b-liu Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable [-- Attachment #1: Type: text/plain, Size: 4754 bytes --] Hi, Gregory CLEMENT <gregory.clement@free-electrons.com> writes: > Hi Felipe, > > I am going back on this subject (again :) ) > > On mar., oct. 20 2015, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: > >> Hi Felipe, >> >> On lun., oct. 05 2015, Felipe Balbi <balbi@ti.com> wrote: >> >> >>>> So after many tests on different devices, 200ms is enough for most of >>>> them, but for one, 2000ms (2s) was needed! >>>> >>>> I see several option: >>>> - adding a sysfs entry to setup the time >>>> - adding a debugs entry entry >>>> - adding configuration option in menuconfig >>>> - using 2000ms and hopping it was enough for everyone >>>> >>>> My preference would go to the first option, what is your opinion? >>> >>> I'm not sure if either of them is good. man 2s is just too large. If the > > Well 2s is lon I agree, but currently instead of 2s we have an infinite > wait, which is worse! > >>> device isn't following the specification, I'm afraid that device needs >>> to be fixed. > > I agree but these devices are for most of them USB stick that we find in > retail. We have no influence on them, so we have to do with them, even > if they do not follow the sepc. > > So what about using configfs or sysfs to let the user confgiure this > value if needed? iff we have to; I'm still not 100% convinced. > I go back on this because, your suggestion didn't work. At least, I > didn't manage to make it improve the situation. > > Thanks, > >>> >>> I think the real issue here is the lack of a disconnect IRQ from AM335x >>> devices. But here's something I've been meaning to test but never had >>> time. If you look into AM335x address space, there's a bit in the >>> wrapper which tells it to use the standard MUSB registers for IRQ, >>> instead of the TI-specific thing. Can you see if we get a disconnect IRQ >>> with that ? >>> >>> TRM is at [1], see page 2566. Basically, if you set bit 3 in register >>> offset 0x1014, then it should use Mentor IRQ registers. If that works, >>> quite a few problems will actually vanish :-p >> >> So I tried it with the following patch: >> >> ------------------------------------- >> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c >> index c791ba5..c714500 100644 >> --- a/drivers/usb/musb/musb_dsps.c >> +++ b/drivers/usb/musb/musb_dsps.c >> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb) >> >> /* Reset the musb */ >> dsps_writel(reg_base, wrp->control, (1 << wrp->reset)); >> + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); overwritting reset. >> musb->isr = dsps_interrupt; >> >> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb) >> if (session_restart || !glue->sw_babble_enabled) { >> dev_info(musb->controller, "Restarting MUSB to recover from Babble\n"); >> dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset)); >> + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); here too. No wonder it won't work, right :-) >> I am not very familiar with that driver but my understanding was that >> the Mentor IRQ registeres are managed by the musb_interrupt() function >> which is called from the dsps_interrupt() interrupt handler. >> >> Am I right? yeah, however the way IRQs are reported is a different thing. AM335x introduced its own IRQ reporting scheme which, basically, reads MUSB generic IRQ status registers and reports on an AM335x specific register. No idea why TI did that for AM335x devices. >> if it is the case then it didn't fix the issue I had. >> >> I activated the following debug line: >> >> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >> >> But I didn't get any interrupt while disconnecting the cable without any >> device connected on it (whereas I got an interrupt when I connected it). >> >> Note that I applied this patch instead of the "usb: musb: dsps: handle >> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? yeah, that's what I had in mind. But your patch seems wrong :-) I tried writing a more correct version here and found 2 issues: a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's registers b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note that according to TRM, RESET_ISOLATION _must_ be set prior to a soft reset and cleared afterwards. But right after setting RESET_ISOLATION, if I try a read of CTRL, it'll hang forever. Bin, do you know about these problems ? They both seem rather alarming to me. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-07 19:26 ` Felipe Balbi @ 2015-12-08 9:07 ` Gregory CLEMENT 2015-12-08 14:20 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Gregory CLEMENT @ 2015-12-08 9:07 UTC (permalink / raw) To: Felipe Balbi Cc: b-liu, Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Hi Felipe, On lun., déc. 07 2015, Felipe Balbi <balbi@ti.com> wrote: > Hi, > > Gregory CLEMENT <gregory.clement@free-electrons.com> writes: >> Hi Felipe, >> >> I am going back on this subject (again :) ) >> >> On mar., oct. 20 2015, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote: >> >>> Hi Felipe, >>> >>> On lun., oct. 05 2015, Felipe Balbi <balbi@ti.com> wrote: >>> >>> >>>>> So after many tests on different devices, 200ms is enough for most of >>>>> them, but for one, 2000ms (2s) was needed! >>>>> >>>>> I see several option: >>>>> - adding a sysfs entry to setup the time >>>>> - adding a debugs entry entry >>>>> - adding configuration option in menuconfig >>>>> - using 2000ms and hopping it was enough for everyone >>>>> >>>>> My preference would go to the first option, what is your opinion? >>>> >>>> I'm not sure if either of them is good. man 2s is just too large. If the >> >> Well 2s is lon I agree, but currently instead of 2s we have an infinite >> wait, which is worse! >> >>>> device isn't following the specification, I'm afraid that device needs >>>> to be fixed. >> >> I agree but these devices are for most of them USB stick that we find in >> retail. We have no influence on them, so we have to do with them, even >> if they do not follow the sepc. >> >> So what about using configfs or sysfs to let the user confgiure this >> value if needed? > > iff we have to; I'm still not 100% convinced. > >> I go back on this because, your suggestion didn't work. At least, I >> didn't manage to make it improve the situation. >> >> Thanks, >> >>>> >>>> I think the real issue here is the lack of a disconnect IRQ from AM335x >>>> devices. But here's something I've been meaning to test but never had >>>> time. If you look into AM335x address space, there's a bit in the >>>> wrapper which tells it to use the standard MUSB registers for IRQ, >>>> instead of the TI-specific thing. Can you see if we get a disconnect IRQ >>>> with that ? >>>> >>>> TRM is at [1], see page 2566. Basically, if you set bit 3 in register >>>> offset 0x1014, then it should use Mentor IRQ registers. If that works, >>>> quite a few problems will actually vanish :-p >>> >>> So I tried it with the following patch: >>> >>> ------------------------------------- >>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c >>> index c791ba5..c714500 100644 >>> --- a/drivers/usb/musb/musb_dsps.c >>> +++ b/drivers/usb/musb/musb_dsps.c >>> @@ -470,6 +470,7 @@ static int dsps_musb_init(struct musb *musb) >>> >>> /* Reset the musb */ >>> dsps_writel(reg_base, wrp->control, (1 << wrp->reset)); >>> + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); > > overwritting reset. > >>> musb->isr = dsps_interrupt; >>> >>> @@ -625,6 +626,7 @@ static int dsps_musb_reset(struct musb *musb) >>> if (session_restart || !glue->sw_babble_enabled) { >>> dev_info(musb->controller, "Restarting MUSB to recover from Babble\n"); >>> dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset)); >>> + dsps_writel(musb->ctrl_base, wrp->control, BIT(3)); > > here too. No wonder it won't work, right :-) > >>> I am not very familiar with that driver but my understanding was that >>> the Mentor IRQ registeres are managed by the musb_interrupt() function >>> which is called from the dsps_interrupt() interrupt handler. >>> >>> Am I right? > > yeah, however the way IRQs are reported is a different thing. AM335x > introduced its own IRQ reporting scheme which, basically, reads MUSB > generic IRQ status registers and reports on an AM335x specific > register. No idea why TI did that for AM335x devices. > >>> if it is the case then it didn't fix the issue I had. >>> >>> I activated the following debug line: >>> >>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >>> >>> But I didn't get any interrupt while disconnecting the cable without any >>> device connected on it (whereas I got an interrupt when I connected it). >>> >>> Note that I applied this patch instead of the "usb: musb: dsps: handle >>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? > > yeah, that's what I had in mind. But your patch seems wrong :-) > > I tried writing a more correct version here and found 2 issues: > > a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's > registers > > b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note > that according to TRM, RESET_ISOLATION _must_ be set prior to a soft > reset and cleared afterwards. But right after setting RESET_ISOLATION, > if I try a read of CTRL, it'll hang forever. The datasheet seems not very coherent about it, on one side we have: "This bit should be set high prior to setting bit 0 and cleared after bit 0 is cleared." and on the other side: "Both the soft_reset and soft_reset_isolation bits should be asserted simultaneously." The hang you saw could be explained by the following: "Setting only the soft_reset_isolation bit will cause all USB0 output signals to go to a known constant value via multiplexers. This will prevent future access to USB0." page 2567 Gregory > > Bin, do you know about these problems ? They both seem rather alarming > to me. > > -- > balbi -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-08 9:07 ` Gregory CLEMENT @ 2015-12-08 14:20 ` Felipe Balbi 2015-12-08 14:31 ` Bin Liu 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-12-08 14:20 UTC (permalink / raw) To: Gregory CLEMENT Cc: b-liu, Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable [-- Attachment #1: Type: text/plain, Size: 1871 bytes --] Hi, Gregory CLEMENT <gregory.clement@free-electrons.com> writes: >>>> if it is the case then it didn't fix the issue I had. >>>> >>>> I activated the following debug line: >>>> >>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >>>> >>>> But I didn't get any interrupt while disconnecting the cable without any >>>> device connected on it (whereas I got an interrupt when I connected it). >>>> >>>> Note that I applied this patch instead of the "usb: musb: dsps: handle >>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? >> >> yeah, that's what I had in mind. But your patch seems wrong :-) >> >> I tried writing a more correct version here and found 2 issues: >> >> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's >> registers >> >> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note >> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft >> reset and cleared afterwards. But right after setting RESET_ISOLATION, >> if I try a read of CTRL, it'll hang forever. > > The datasheet seems not very coherent about it, > > on one side we have: > "This bit should be set high prior to setting bit 0 and cleared after bit 0 > is cleared." > > and on the other side: > "Both the soft_reset and soft_reset_isolation bits should be asserted > simultaneously." > > The hang you saw could be explained by the following: > "Setting only the soft_reset_isolation bit will cause all USB0 output > signals to go to a known constant value via multiplexers. > This will > prevent future access to USB0." page 2567 good catch. Setting them together makes the hang go away. I still have the other problem, which is legacy IRQ reporting mode not really working. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-08 14:20 ` Felipe Balbi @ 2015-12-08 14:31 ` Bin Liu 2015-12-08 14:35 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-12-08 14:31 UTC (permalink / raw) To: Felipe Balbi, Gregory CLEMENT Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable Felipe, On 12/08/2015 08:20 AM, Felipe Balbi wrote: > > Hi, > > Gregory CLEMENT <gregory.clement@free-electrons.com> writes: >>>>> if it is the case then it didn't fix the issue I had. >>>>> >>>>> I activated the following debug line: >>>>> >>>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >>>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >>>>> >>>>> But I didn't get any interrupt while disconnecting the cable without any >>>>> device connected on it (whereas I got an interrupt when I connected it). >>>>> >>>>> Note that I applied this patch instead of the "usb: musb: dsps: handle >>>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? >>> >>> yeah, that's what I had in mind. But your patch seems wrong :-) >>> >>> I tried writing a more correct version here and found 2 issues: >>> >>> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's >>> registers >>> >>> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note >>> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft >>> reset and cleared afterwards. But right after setting RESET_ISOLATION, >>> if I try a read of CTRL, it'll hang forever. >> >> The datasheet seems not very coherent about it, >> >> on one side we have: >> "This bit should be set high prior to setting bit 0 and cleared after bit 0 >> is cleared." >> >> and on the other side: >> "Both the soft_reset and soft_reset_isolation bits should be asserted >> simultaneously." >> >> The hang you saw could be explained by the following: >> "Setting only the soft_reset_isolation bit will cause all USB0 output >> signals to go to a known constant value via multiplexers. >> This will >> prevent future access to USB0." page 2567 > > good catch. Setting them together makes the hang go away. > > I still have the other problem, which is legacy IRQ reporting mode not > really working. > I never tried to change the IRQ mapping. The 8 MUSB interrupt will be the same no matter where they are reported from. What do you expect when switch to the MUSB IRQ reporting mode? Regards, -Bin. -- Regards, -Bin. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-08 14:31 ` Bin Liu @ 2015-12-08 14:35 ` Felipe Balbi 2015-12-08 14:42 ` Bin Liu 0 siblings, 1 reply; 13+ messages in thread From: Felipe Balbi @ 2015-12-08 14:35 UTC (permalink / raw) To: Bin Liu, Gregory CLEMENT Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable [-- Attachment #1: Type: text/plain, Size: 2381 bytes --] Hi, Bin Liu <b-liu@ti.com> writes: > Felipe, > > On 12/08/2015 08:20 AM, Felipe Balbi wrote: >> >> Hi, >> >> Gregory CLEMENT <gregory.clement@free-electrons.com> writes: >>>>>> if it is the case then it didn't fix the issue I had. >>>>>> >>>>>> I activated the following debug line: >>>>>> >>>>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >>>>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >>>>>> >>>>>> But I didn't get any interrupt while disconnecting the cable without any >>>>>> device connected on it (whereas I got an interrupt when I connected it). >>>>>> >>>>>> Note that I applied this patch instead of the "usb: musb: dsps: handle >>>>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? >>>> >>>> yeah, that's what I had in mind. But your patch seems wrong :-) >>>> >>>> I tried writing a more correct version here and found 2 issues: >>>> >>>> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's >>>> registers >>>> >>>> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note >>>> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft >>>> reset and cleared afterwards. But right after setting RESET_ISOLATION, >>>> if I try a read of CTRL, it'll hang forever. >>> >>> The datasheet seems not very coherent about it, >>> >>> on one side we have: >>> "This bit should be set high prior to setting bit 0 and cleared after bit 0 >>> is cleared." >>> >>> and on the other side: >>> "Both the soft_reset and soft_reset_isolation bits should be asserted >>> simultaneously." >>> >>> The hang you saw could be explained by the following: >>> "Setting only the soft_reset_isolation bit will cause all USB0 output >>> signals to go to a known constant value via multiplexers. >>> This will >>> prevent future access to USB0." page 2567 >> >> good catch. Setting them together makes the hang go away. >> >> I still have the other problem, which is legacy IRQ reporting mode not >> really working. >> > > I never tried to change the IRQ mapping. The 8 MUSB interrupt will be > the same no matter where they are reported from. What do you expect when > switch to the MUSB IRQ reporting mode? read events from MUSB's registers instead of TI's :-) so, MUSB_INTRUSB, MUSB_INTRRX and MUSB_INTRTX. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-08 14:35 ` Felipe Balbi @ 2015-12-08 14:42 ` Bin Liu 2015-12-08 15:16 ` Felipe Balbi 0 siblings, 1 reply; 13+ messages in thread From: Bin Liu @ 2015-12-08 14:42 UTC (permalink / raw) To: Felipe Balbi, Gregory CLEMENT Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable On 12/08/2015 08:35 AM, Felipe Balbi wrote: > > Hi, > > Bin Liu <b-liu@ti.com> writes: >> Felipe, >> >> On 12/08/2015 08:20 AM, Felipe Balbi wrote: >>> >>> Hi, >>> >>> Gregory CLEMENT <gregory.clement@free-electrons.com> writes: >>>>>>> if it is the case then it didn't fix the issue I had. >>>>>>> >>>>>>> I activated the following debug line: >>>>>>> >>>>>>> [musb_hdrc]musb_interrupt =_ "** IRQ %s usb%04x tx%04x rx%04x\012" >>>>>>> [musb_dsps]dsps_interrupt =p "usbintr (%x) epintr(%x)\012" >>>>>>> >>>>>>> But I didn't get any interrupt while disconnecting the cable without any >>>>>>> device connected on it (whereas I got an interrupt when I connected it). >>>>>>> >>>>>>> Note that I applied this patch instead of the "usb: musb: dsps: handle >>>>>>> the otg_state_a_wait_vrise_timeout case", is what you had in mind ? >>>>> >>>>> yeah, that's what I had in mind. But your patch seems wrong :-) >>>>> >>>>> I tried writing a more correct version here and found 2 issues: >>>>> >>>>> a) bit 3 doesn't do anything :-p I cannot read IRQs from mentor's >>>>> registers >>>>> >>>>> b) when setting RESET_ISOLATION bit, reads of CTRL register hang. Note >>>>> that according to TRM, RESET_ISOLATION _must_ be set prior to a soft >>>>> reset and cleared afterwards. But right after setting RESET_ISOLATION, >>>>> if I try a read of CTRL, it'll hang forever. >>>> >>>> The datasheet seems not very coherent about it, >>>> >>>> on one side we have: >>>> "This bit should be set high prior to setting bit 0 and cleared after bit 0 >>>> is cleared." >>>> >>>> and on the other side: >>>> "Both the soft_reset and soft_reset_isolation bits should be asserted >>>> simultaneously." >>>> >>>> The hang you saw could be explained by the following: >>>> "Setting only the soft_reset_isolation bit will cause all USB0 output >>>> signals to go to a known constant value via multiplexers. >>>> This will >>>> prevent future access to USB0." page 2567 >>> >>> good catch. Setting them together makes the hang go away. >>> >>> I still have the other problem, which is legacy IRQ reporting mode not >>> really working. >>> >> >> I never tried to change the IRQ mapping. The 8 MUSB interrupt will be >> the same no matter where they are reported from. What do you expect when >> switch to the MUSB IRQ reporting mode? > > read events from MUSB's registers instead of TI's :-) so, MUSB_INTRUSB, > MUSB_INTRRX and MUSB_INTRTX. > I meant you expect to see any different event when switch to MUSB IRQ mode? The TI wrapper just reports the same 8 interrupt events. I don't think you would get any difference. BTY, I think I miss some context here. This Gregory's patch is trying to fix the OTG state machine problem in musb_dsps, which is replicated with a cable without a device connected. But it also mentions about non-compliant MSC devices. How are the thumb drives related to this OTG state issue? -- Regards, -Bin. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case 2015-12-08 14:42 ` Bin Liu @ 2015-12-08 15:16 ` Felipe Balbi 0 siblings, 0 replies; 13+ messages in thread From: Felipe Balbi @ 2015-12-08 15:16 UTC (permalink / raw) To: Bin Liu, Gregory CLEMENT Cc: Greg Kroah-Hartman, linux-usb, linux-kernel, linux-arm-kernel, stable [-- Attachment #1: Type: text/plain, Size: 1725 bytes --] Hi, Bin Liu <b-liu@ti.com> writes: >>>>> "This bit should be set high prior to setting bit 0 and cleared after bit 0 >>>>> is cleared." >>>>> >>>>> and on the other side: >>>>> "Both the soft_reset and soft_reset_isolation bits should be asserted >>>>> simultaneously." >>>>> >>>>> The hang you saw could be explained by the following: >>>>> "Setting only the soft_reset_isolation bit will cause all USB0 output >>>>> signals to go to a known constant value via multiplexers. >>>>> This will >>>>> prevent future access to USB0." page 2567 >>>> >>>> good catch. Setting them together makes the hang go away. >>>> >>>> I still have the other problem, which is legacy IRQ reporting mode not >>>> really working. >>>> >>> >>> I never tried to change the IRQ mapping. The 8 MUSB interrupt will be >>> the same no matter where they are reported from. What do you expect when >>> switch to the MUSB IRQ reporting mode? >> >> read events from MUSB's registers instead of TI's :-) so, MUSB_INTRUSB, >> MUSB_INTRRX and MUSB_INTRTX. >> > I meant you expect to see any different event when switch to MUSB IRQ > mode? The TI wrapper just reports the same 8 interrupt events. I don't > think you would get any difference. still valid to make sure ;-) > BTY, I think I miss some context here. This Gregory's patch is trying to > fix the OTG state machine problem in musb_dsps, which is replicated with > a cable without a device connected. But it also mentions about > non-compliant MSC devices. How are the thumb drives related to this OTG > state issue? the problem seems to be caused by the missing disconnect IRQ. Not really missing, but taking seconds to trigger. -- balbi [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 818 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2015-12-08 15:17 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-20 16:12 [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Gregory CLEMENT 2015-08-21 12:29 ` Gregory CLEMENT 2015-08-31 15:52 ` Gregory CLEMENT 2015-10-05 20:02 ` Felipe Balbi 2015-10-20 17:33 ` Gregory CLEMENT 2015-12-07 9:52 ` Gregory CLEMENT 2015-12-07 19:26 ` Felipe Balbi 2015-12-08 9:07 ` Gregory CLEMENT 2015-12-08 14:20 ` Felipe Balbi 2015-12-08 14:31 ` Bin Liu 2015-12-08 14:35 ` Felipe Balbi 2015-12-08 14:42 ` Bin Liu 2015-12-08 15:16 ` Felipe Balbi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).