Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1285159 > unrolled thread

Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Gregory CLEMENT <gregory.clement@free-electrons.com> - 2015-12-07 11:00 +0100
    Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Felipe Balbi <balbi@ti.com> - 2015-12-07 20:30 +0100
      Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Gregory CLEMENT <gregory.clement@free-electrons.com> - 2015-12-08 10:20 +0100
        Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Felipe Balbi <balbi@ti.com> - 2015-12-08 15:30 +0100
          Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Felipe Balbi <balbi@ti.com> - 2015-12-08 15:40 +0100
            Re: [PATCH] usb: musb: dsps: handle the  otg_state_a_wait_vrise_timeout case Bin Liu <b-liu@ti.com> - 2015-12-08 15:50 +0100
              Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Felipe Balbi <balbi@ti.com> - 2015-12-08 16:20 +0100
          Re: [PATCH] usb: musb: dsps: handle the  otg_state_a_wait_vrise_timeout case Bin Liu <b-liu@ti.com> - 2015-12-08 15:40 +0100

#1285159 — Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1285867

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1286339

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286526

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1286532

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1286553 — Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286571

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1286544 — Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web