From: Michael Grzeschik <mgr@pengutronix.de>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Felipe Balbi <balbi@kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"kernel@pengutronix.de" <kernel@pengutronix.de>
Subject: Re: [PATCH 2/2] dwc3: gadget: fix tracking of used sgs in request
Date: Tue, 27 Apr 2021 22:12:32 +0200 [thread overview]
Message-ID: <20210427201232.GG6975@pengutronix.de> (raw)
In-Reply-To: <50e13b71-bdc1-6279-a224-bfc99cf10dc8@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 4441 bytes --]
On Tue, Apr 27, 2021 at 03:18:57AM +0000, Thinh Nguyen wrote:
>Hi Michael,
>
>Thinh Nguyen wrote:
>> Felipe Balbi wrote:
>>>
>>> HI,
>>>
>>> Michael Grzeschik <mgr@pengutronix.de> writes:
>>>
>>> <big snip>
>>>
>
>
><bigger snip>
>
>
>> I think I see the issue that Michael reported.
>>
>> The problem is that we're using num_pending_sgs to track both pending SG
>> entries and queued SG entries. num_pending_sgs doesn't get updated until
>> TRB completion interrupt (ie XferInProgress). Before the driver queues
>> more SG requests, it will check if there's any pending SG in the started
>> request list before it prepares more. Since the num_pending_sgs doesn't
>> get updated until the request is completed, the driver doesn't process
>> more until the request is completed.
>>
>> I need to review more on Michael's patches next week, but I think what
>> he suggested makes sense (in term of properly usage of queued sgs vs
>> pending sgs). BTW, please correct me if I'm wrong, but we do modify
>> num_queued_sgs.
>>
>
>There's still some issue with your patch. I think this should cover it.
>Let me know if it works for you.
This works for me! Will you spin a proper patch from that?
>Note: this however probably needs more "Tested-by" and reviews
>to make sure I'm not missing anything. I only ran some basic tests,
>and will need to run more.
You may already have mine:
Tested-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
>Let me know if this makes sense.
From what I understand about the issue and the purpose of all
variables this makes total sense to me. So thanks for taking over
and make a proper solution.
Thanks,
Michael
>BR,
>Thinh
>
>
>diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>index dd80e5ca8c78..040cc67b3361 100644
>--- a/drivers/usb/dwc3/gadget.c
>+++ b/drivers/usb/dwc3/gadget.c
>@@ -1244,6 +1244,7 @@ static int dwc3_prepare_trbs_sg(struct dwc3_ep *dep,
> req->start_sg = sg_next(s);
>
> req->num_queued_sgs++;
>+ req->num_pending_sgs--;
>
> /*
> * The number of pending SG entries may not correspond to the
>@@ -1251,7 +1252,7 @@ static int dwc3_prepare_trbs_sg(struct dwc3_ep *dep,
> * don't include unused SG entries.
> */
> if (length == 0) {
>- req->num_pending_sgs -= req->request.num_mapped_sgs - req->num_queued_sgs;
>+ req->num_pending_sgs = 0;
> break;
> }
>
>@@ -2867,15 +2868,15 @@ static int dwc3_gadget_ep_reclaim_trb_sg(struct dwc3_ep *dep,
> struct dwc3_trb *trb = &dep->trb_pool[dep->trb_dequeue];
> struct scatterlist *sg = req->sg;
> struct scatterlist *s;
>- unsigned int pending = req->num_pending_sgs;
>+ unsigned int num_queued = req->num_queued_sgs;
> unsigned int i;
> int ret = 0;
>
>- for_each_sg(sg, s, pending, i) {
>+ for_each_sg(sg, s, num_queued, i) {
> trb = &dep->trb_pool[dep->trb_dequeue];
>
> req->sg = sg_next(s);
>- req->num_pending_sgs--;
>+ req->num_queued_sgs--;
>
> ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
> trb, event, status, true);
>@@ -2898,7 +2899,7 @@ static int dwc3_gadget_ep_reclaim_trb_linear(struct dwc3_ep *dep,
>
> static bool dwc3_gadget_ep_request_completed(struct dwc3_request *req)
> {
>- return req->num_pending_sgs == 0;
>+ return req->num_pending_sgs == 0 && req->num_queued_sgs == 0;
> }
>
> static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
>@@ -2907,7 +2908,7 @@ static int dwc3_gadget_ep_cleanup_completed_request(struct dwc3_ep *dep,
> {
> int ret;
>
>- if (req->num_pending_sgs)
>+ if (req->request.num_mapped_sgs)
> ret = dwc3_gadget_ep_reclaim_trb_sg(dep, req, event,
> status);
> else
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-04-27 20:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-21 20:48 [PATCH 0/2] usb: dwc3: gadget: fix scatter gather support Michael Grzeschik
2021-04-21 20:48 ` [PATCH 1/2] dwc3: gadget: fix setting of pending_sgs Michael Grzeschik
2021-04-22 10:51 ` Felipe Balbi
2021-04-22 21:28 ` Thinh Nguyen
2021-04-21 20:48 ` [PATCH 2/2] dwc3: gadget: fix tracking of used sgs in request Michael Grzeschik
2021-04-22 10:56 ` Felipe Balbi
2021-04-22 20:18 ` Michael Grzeschik
2021-04-22 21:28 ` Thinh Nguyen
2021-04-23 6:17 ` Felipe Balbi
[not found] ` <20210423102738.GD6975@pengutronix.de>
2021-04-23 11:15 ` Felipe Balbi
2021-04-23 13:18 ` Michael Grzeschik
2021-04-24 8:16 ` Felipe Balbi
2021-04-24 9:12 ` Michael Grzeschik
2021-04-24 13:43 ` Felipe Balbi
2021-04-24 19:41 ` Thinh Nguyen
2021-04-27 3:18 ` Thinh Nguyen
2021-04-27 20:12 ` Michael Grzeschik [this message]
2021-04-28 1:45 ` Thinh Nguyen
2021-04-28 7:37 ` Michael Grzeschik
2021-04-28 23:25 ` Thinh Nguyen
2021-04-29 6:51 ` Michael Grzeschik
2021-04-29 18:15 ` Thinh Nguyen
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=20210427201232.GG6975@pengutronix.de \
--to=mgr@pengutronix.de \
--cc=Thinh.Nguyen@synopsys.com \
--cc=balbi@kernel.org \
--cc=kernel@pengutronix.de \
--cc=linux-usb@vger.kernel.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.