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 08:20:45 -0600	[thread overview]
Message-ID: <87h9jtm37m.fsf@saruman.tx.rr.com> (raw)
In-Reply-To: <874mft9ukx.fsf@free-electrons.com>


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
-------------- 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/d9555e81/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <b-liu@ti.com>, 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 08:20:45 -0600	[thread overview]
Message-ID: <87h9jtm37m.fsf@saruman.tx.rr.com> (raw)
In-Reply-To: <874mft9ukx.fsf@free-electrons.com>

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

  reply	other threads:[~2015-12-08 14:20 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 [this message]
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
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=87h9jtm37m.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.