All of lore.kernel.org
 help / color / mirror / Atom feed
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case
Date: Tue, 8 Dec 2015 09:16:59 -0600	[thread overview]
Message-ID: <878u55m0lw.fsf@saruman.tx.rr.com> (raw)
In-Reply-To: <5666EC67.7000203@ti.com>


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151208/6c125675/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Bin Liu <b-liu@ti.com>,
	Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	<linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <stable@vger.kernel.org>
Subject: Re: [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case
Date: Tue, 8 Dec 2015 09:16:59 -0600	[thread overview]
Message-ID: <878u55m0lw.fsf@saruman.tx.rr.com> (raw)
In-Reply-To: <5666EC67.7000203@ti.com>

[-- 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 --]

  reply	other threads:[~2015-12-08 15:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-20 16:12 [PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case Gregory CLEMENT
2015-08-20 16:12 ` Gregory CLEMENT
2015-08-21 12:29 ` Gregory CLEMENT
2015-08-21 12:29   ` Gregory CLEMENT
2015-08-31 15:52   ` Gregory CLEMENT
2015-08-31 15:52     ` Gregory CLEMENT
2015-10-05 20:02     ` Felipe Balbi
2015-10-05 20:02       ` Felipe Balbi
2015-10-20 17:33       ` Gregory CLEMENT
2015-10-20 17:33         ` Gregory CLEMENT
2015-12-07  9:52         ` Gregory CLEMENT
2015-12-07  9:52           ` Gregory CLEMENT
2015-12-07 19:26           ` Felipe Balbi
2015-12-07 19:26             ` Felipe Balbi
2015-12-08  9:07             ` Gregory CLEMENT
2015-12-08  9:07               ` Gregory CLEMENT
2015-12-08 14:20               ` Felipe Balbi
2015-12-08 14:20                 ` Felipe Balbi
2015-12-08 14:31                 ` Bin Liu
2015-12-08 14:31                   ` Bin Liu
2015-12-08 14:35                   ` Felipe Balbi
2015-12-08 14:35                     ` Felipe Balbi
2015-12-08 14:42                     ` Bin Liu
2015-12-08 14:42                       ` Bin Liu
2015-12-08 15:16                       ` Felipe Balbi [this message]
2015-12-08 15:16                         ` Felipe Balbi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878u55m0lw.fsf@saruman.tx.rr.com \
    --to=balbi@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.