From: Felipe Balbi <balbi@kernel.org>
To: Roger Quadros <rogerq@ti.com>, Baolin Wang <baolin.wang@linaro.org>
Cc: USB <linux-usb@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Fri, 09 Mar 2018 12:36:58 +0200 [thread overview]
Message-ID: <87h8ppa62d.fsf@linux.intel.com> (raw)
Hi,
Roger Quadros <rogerq@ti.com> writes:
>>> This is what the v3.10 databook says
>>>
>>> "When issuing an End Transfer command, software must set the CmdIOC
>>> bit (field 8) so that an Endpoint Command Complete event is generated
>>> after the transfer ends. This is necessary to synchronize the
>>> conclusion of system bus traffic before the End Transfer command is
>>> completed."
>>>
>>> with a note
>>>
>>> "If GUCTL2[Rst_actbitlater] is set, Software can poll the completion
>>> of the End Transfer command by polling the command active bit to be
>>> cleared to 0."
>>>
>>> fyi.
>>>
>>> Rst_actbitlater - "Enable clearing of the command active bit for the
>>> ENDXFER command after the command execution is completed. This bit is
>>> valid in device mode only."
>>>
>>> So I'd prefer not to clear CMDIOC for all cases.
>>>
>>> Could we some how just tackle the dwc3_gadget_exit case like I did in
>>> this patch?
>>
>> if you can send a version that doesn't iterate over all endpoints twice,
>> sure. We still need a comment somewhere, and I fear we may get
>> interrupts later in some cases. How would we deal with that?
>>
>
> how about explicitly masking that interrupt? Is it possible?
I think I showed that the bit is reserved on recent dwc3 core releases
(anytyhing 2.40a+, at least).
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Roger Quadros <rogerq@ti.com>, Baolin Wang <baolin.wang@linaro.org>
Cc: USB <linux-usb@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume
Date: Fri, 09 Mar 2018 12:36:58 +0200 [thread overview]
Message-ID: <87h8ppa62d.fsf@linux.intel.com> (raw)
In-Reply-To: <f8edc87c-919f-46ab-f437-303dede74c82@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
Hi,
Roger Quadros <rogerq@ti.com> writes:
>>> This is what the v3.10 databook says
>>>
>>> "When issuing an End Transfer command, software must set the CmdIOC
>>> bit (field 8) so that an Endpoint Command Complete event is generated
>>> after the transfer ends. This is necessary to synchronize the
>>> conclusion of system bus traffic before the End Transfer command is
>>> completed."
>>>
>>> with a note
>>>
>>> "If GUCTL2[Rst_actbitlater] is set, Software can poll the completion
>>> of the End Transfer command by polling the command active bit to be
>>> cleared to 0."
>>>
>>> fyi.
>>>
>>> Rst_actbitlater - "Enable clearing of the command active bit for the
>>> ENDXFER command after the command execution is completed. This bit is
>>> valid in device mode only."
>>>
>>> So I'd prefer not to clear CMDIOC for all cases.
>>>
>>> Could we some how just tackle the dwc3_gadget_exit case like I did in
>>> this patch?
>>
>> if you can send a version that doesn't iterate over all endpoints twice,
>> sure. We still need a comment somewhere, and I fear we may get
>> interrupts later in some cases. How would we deal with that?
>>
>
> how about explicitly masking that interrupt? Is it possible?
I think I showed that the bit is reserved on recent dwc3 core releases
(anytyhing 2.40a+, at least).
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next reply other threads:[~2018-03-09 10:36 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-09 10:36 Felipe Balbi [this message]
2018-03-09 10:36 ` [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume Felipe Balbi
-- strict thread matches above, loose matches on Subject: below --
2018-04-10 7:31 [v2] " Felipe Balbi
2018-04-10 7:31 ` [PATCH v2] " Felipe Balbi
2018-04-10 6:29 [v2] " Minas Harutyunyan
2018-04-10 6:29 ` [PATCH v2] " Minas Harutyunyan
2018-03-19 13:53 [v2] " Minas Harutyunyan
2018-03-19 13:53 ` [PATCH v2] " Minas Harutyunyan
2018-03-19 11:36 [v2] " Minas Harutyunyan
2018-03-19 11:36 ` [PATCH v2] " Minas Harutyunyan
2018-03-19 8:54 [v2] " Felipe Balbi
2018-03-19 8:54 ` [PATCH v2] " Felipe Balbi
2018-03-17 6:33 [v2] " Minas Harutyunyan
2018-03-17 6:33 ` [PATCH v2] " Minas Harutyunyan
2018-03-16 12:25 [v2] " Felipe Balbi
2018-03-16 12:25 ` [PATCH v2] " Felipe Balbi
2018-03-16 11:43 [v2] " Minas Harutyunyan
2018-03-16 11:43 ` [PATCH v2] " Minas Harutyunyan
2018-03-16 11:03 [v2] " Roger Quadros
2018-03-16 11:03 ` [PATCH v2] " Roger Quadros
2018-03-16 11:00 [v2] " Felipe Balbi
2018-03-16 11:00 ` [PATCH v2] " Felipe Balbi
2018-03-16 10:34 [v2] " Roger Quadros
2018-03-16 10:34 ` [PATCH v2] " Roger Quadros
2018-03-09 12:47 [v2] " Roger Quadros
2018-03-09 12:47 ` [PATCH v2] " Roger Quadros
2018-03-09 10:39 Felipe Balbi
2018-03-09 10:39 ` [PATCH] " Felipe Balbi
2018-03-09 9:49 Roger Quadros
2018-03-09 9:49 ` [PATCH] " Roger Quadros
2018-03-09 9:26 Roger Quadros
2018-03-09 9:26 ` [PATCH] " Roger Quadros
2018-03-09 9:23 Felipe Balbi
2018-03-09 9:23 ` [PATCH] " Felipe Balbi
2018-03-09 9:19 Roger Quadros
2018-03-09 9:19 ` [PATCH] " Roger Quadros
2018-03-05 11:27 Felipe Balbi
2018-03-05 11:27 ` [PATCH] " Felipe Balbi
2018-03-05 11:25 Felipe Balbi
2018-03-05 11:25 ` [PATCH] " Felipe Balbi
2018-03-05 11:25 Baolin Wang
2018-03-05 11:25 ` [PATCH] " Baolin Wang
2018-03-05 11:14 Roger Quadros
2018-03-05 11:14 ` [PATCH] " Roger Quadros
2018-03-05 11:06 Felipe Balbi
2018-03-05 11:06 ` [PATCH] " Felipe Balbi
2018-03-05 11:03 Roger Quadros
2018-03-05 11:03 ` [PATCH] " Roger Quadros
2018-03-05 10:41 Baolin Wang
2018-03-05 10:41 ` [PATCH] " Baolin Wang
2018-03-05 9:45 Roger Quadros
2018-03-05 9:45 ` [PATCH] " Roger Quadros
2018-03-05 8:49 Felipe Balbi
2018-03-05 8:49 ` [PATCH] " Felipe Balbi
2018-02-28 9:59 Roger Quadros
2018-02-28 9:59 ` [PATCH] " Roger Quadros
2018-02-28 9:55 Roger Quadros
2018-02-28 9:55 ` [PATCH] " Roger Quadros
2018-02-28 7:53 Felipe Balbi
2018-02-28 7:53 ` [PATCH] " Felipe Balbi
2018-02-28 3:04 Baolin Wang
2018-02-28 3:04 ` [PATCH] " Baolin Wang
2018-02-27 11:22 Roger Quadros
2018-02-27 11:22 ` [PATCH] " Roger Quadros
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=87h8ppa62d.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=baolin.wang@linaro.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 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.