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: <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
---
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
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: <[email protected]>
> Signed-off-by: Gregory CLEMENT <[email protected]>
> ---
> 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
Hi Felipe,
On ven., août 21 2015, Gregory CLEMENT <[email protected]> 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: <[email protected]>
>> Signed-off-by: Gregory CLEMENT <[email protected]>
>> ---
>> 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 [email protected]
> 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
Hi Felipe,
I am going back on this subject (again :) )
On mar., oct. 20 2015, Gregory CLEMENT <[email protected]> wrote:
> Hi Felipe,
>
> On lun., oct. 05 2015, Felipe Balbi <[email protected]> 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 [email protected]
> 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
Hi,
Gregory CLEMENT <[email protected]> writes:
> Hi Felipe,
>
> I am going back on this subject (again :) )
>
> On mar., oct. 20 2015, Gregory CLEMENT <[email protected]> wrote:
>
>> Hi Felipe,
>>
>> On lun., oct. 05 2015, Felipe Balbi <[email protected]> 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
Hi Felipe,
On lun., déc. 07 2015, Felipe Balbi <[email protected]> wrote:
> Hi,
>
> Gregory CLEMENT <[email protected]> writes:
>> Hi Felipe,
>>
>> I am going back on this subject (again :) )
>>
>> On mar., oct. 20 2015, Gregory CLEMENT <[email protected]> wrote:
>>
>>> Hi Felipe,
>>>
>>> On lun., oct. 05 2015, Felipe Balbi <[email protected]> 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
Hi,
Gregory CLEMENT <[email protected]> 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
Felipe,
On 12/08/2015 08:20 AM, Felipe Balbi wrote:
>
> Hi,
>
> Gregory CLEMENT <[email protected]> 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.
Hi,
Bin Liu <[email protected]> writes:
> Felipe,
>
> On 12/08/2015 08:20 AM, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Gregory CLEMENT <[email protected]> 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
On 12/08/2015 08:35 AM, Felipe Balbi wrote:
>
> Hi,
>
> Bin Liu <[email protected]> writes:
>> Felipe,
>>
>> On 12/08/2015 08:20 AM, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Gregory CLEMENT <[email protected]> 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.
Hi,
Bin Liu <[email protected]> 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