LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
To: Felipe Balbi <balbi@kernel.org>,
Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>,
Roger Quadros <rogerq@ti.com>
Cc: "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Mon, 19 Mar 2018 11:36:20 +0000 [thread overview]
Message-ID: <410670D7E743164D87FA6160E7907A560113ABC945@am04wembxa.internal.synopsys.com> (raw)
In-Reply-To: 87d100qwc5.fsf@linux.intel.com
Hi,
On 3/19/2018 12:55 PM, Felipe Balbi wrote:
>
> Hi,
>
> Minas Harutyunyan <Minas.Harutyunyan@synopsys.com> writes:
>>>>>>> Thanks for picking this for -next.
>>>>>>> Is it better to have this in v4.16-rc fixes?
>>>>>>> and also stable? v4.12+
>>>>>>
>>>>>> Well, there was no "Fixes: foobar" or "Cc: stable" lines in the commit
>>>>>> log ;-)
>>>>>>
>>>>>> The best we can do now, is wait for -rc1 and manually send the commit to
>>>>>> stable.
>>>>>>
>>>>>
>>>>> That's fine. Thanks.
>>>>>
>>>>
>>>> Same issue seen in dwc3_gadget_ep_dequeue() function where also used
>>>> wait_event_lock_irq() - as result infinite loop.
>>>
>>> how did this happen? During rmmod dwc3? Or, perhaps, after you unloaded
>>> a gadget driver?
>>>
>> No, not during rmmod's.
>> We using our internal USB testing tool. Test case; ISOC OUT, transfer
>> size N frames. When host starts ISOC OUT traffic then the dwc3 based on
>> "Transfer not ready" event in frame F starts transfers staring from
>> frame F+4 (for bInterval=1) as result 4 requests, which already queued
>> on device side, remain incomplete. Function driver on some timeout
>> trying dequeue these 4 requests (without disabling EP) to complete test.
>> For IN ISOC's these requests completed on MISSED ISOC event, but for
>> ISOC OUT required call dequeue on some timeout.
>
> okay
>
>>>> Actually to fix this issue I updated condition of wait function
>>>> from:
>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING)
>>>> to:
>>>> !(dep->flags & DWC3_EP_END_TRANSFER_PENDING & DWC3_EP_ENABLED)
>>>
>>> you're not fixing anything. You're, essentially, removing the entire
>>> end transfer pending logic.
>> yes, you are right, but how to overcome this infinite loop? Replace
>> wait_event_lock_irq() by wait_event_interruptible_lock_irq_timeout()?
>
> The best way here would be to figure why we're missing command complete
> IRQ in those cases. According to documentation, we *should* receive that
> interrupt, so why is it missing?
>
Additional info on test. Core configuration is HS only mode, test speed
HS, core version v2.90a. Maybe it will help to understand cause of issue.
BTW, currently to pass above describe ISOC OUT test we just commented
wait_event_lock_irq() in dwc3_gadget_ep_dequeue() function and
successfully received request completion in function driver.
Thanks,
Minas
next prev parent reply other threads:[~2018-03-19 11:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 11:22 [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Roger Quadros
2018-02-28 3:04 ` Baolin Wang
2018-02-28 9:55 ` Roger Quadros
2018-02-28 7:53 ` Felipe Balbi
2018-02-28 9:59 ` Roger Quadros
2018-03-05 8:49 ` Felipe Balbi
2018-03-05 9:45 ` Roger Quadros
2018-03-05 10:41 ` Baolin Wang
2018-03-05 11:03 ` Roger Quadros
2018-03-05 11:06 ` Felipe Balbi
2018-03-05 11:14 ` Roger Quadros
2018-03-05 11:25 ` Baolin Wang
2018-03-05 11:27 ` Felipe Balbi
2018-03-09 9:19 ` Roger Quadros
2018-03-09 9:23 ` Felipe Balbi
2018-03-09 9:26 ` Roger Quadros
2018-03-09 9:49 ` Roger Quadros
2018-03-09 10:39 ` Felipe Balbi
2018-03-09 10:36 ` Felipe Balbi
2018-03-05 11:25 ` Felipe Balbi
2018-03-09 12:47 ` [PATCH v2] " Roger Quadros
2018-03-16 10:34 ` Roger Quadros
2018-03-16 11:00 ` Felipe Balbi
2018-03-16 11:03 ` Roger Quadros
2018-03-16 11:43 ` Minas Harutyunyan
2018-03-16 12:25 ` Felipe Balbi
2018-03-17 6:33 ` Minas Harutyunyan
2018-03-19 8:54 ` Felipe Balbi
2018-03-19 11:36 ` Minas Harutyunyan [this message]
2018-03-19 13:53 ` Minas Harutyunyan
2018-04-10 6:29 ` Minas Harutyunyan
2018-04-10 7:31 ` 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=410670D7E743164D87FA6160E7907A560113ABC945@am04wembxa.internal.synopsys.com \
--to=minas.harutyunyan@synopsys.com \
--cc=balbi@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=rogerq@ti.com \
/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 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).