From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Jeff Vanhoof <jdv1029@gmail.com>
Cc: Jeffrey Vanhoof <jvanhoof@motorola.com>,
"balbi@kernel.org" <balbi@kernel.org>,
"corbet@lwn.net" <corbet@lwn.net>,
"dan.scally@ideasonboard.com" <dan.scally@ideasonboard.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"laurent.pinchart@ideasonboard.com"
<laurent.pinchart@ideasonboard.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"m.grzeschik@pengutronix.de" <m.grzeschik@pengutronix.de>,
"paul.elder@ideasonboard.com" <paul.elder@ideasonboard.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Dan Vacura <W36195@motorola.com>
Subject: Re: [PATCH v3 2/6] usb: dwc3: gadget: cancel requests instead of release after missed isoc
Date: Fri, 21 Oct 2022 00:55:51 +0000 [thread overview]
Message-ID: <20221021005537.3vbtair35umh6vo2@synopsys.com> (raw)
In-Reply-To: <20221020224714.6v7djacqvl5xkc2w@synopsys.com>
On Thu, Oct 20, 2022, Thinh Nguyen wrote:
> On Thu, Oct 20, 2022, Jeff Vanhoof wrote:
> > Hi Thinh,
> >
> > On Wed, Oct 19, 2022 at 11:06:08PM +0000, Thinh Nguyen wrote:
> > > Hi,
> > >
> > > On Wed, Oct 19, 2022, Jeff Vanhoof wrote:
> > > > Hi Thinh,
> > > > On Wed, Oct 19, 2022 at 07:08:27PM +0000, Thinh Nguyen wrote:
> > > > > On Wed, Oct 19, 2022, Jeff Vanhoof wrote:
> > >
> > > <snip>
> > >
> > > > > >
> > > > > > From what I can gather from the log, with the current changes it seems that
> > > > > > after a missed isoc event few requests are staying longer than expected in the
> > > > > > started_list (not getting reclaimed) and this is preventing the transmission
> > > > > > from stopping/starting again, and opening the door for continuous stream of
> > > > > > missed isoc events that cause what appears to the user as a frozen video.
> > > > > >
> > > > > > So one thought, if IOC bit is not set every frame, but IMI bit is, when a
> > > > > > missed isoc related interrupt occurs it seems likely that more than one trb
> > > > > > request will need to be reclaimed, but the current set of changes is not
> > > > > > handling this.
> > > > > >
> > > > > > In the good transfer case this issue seems to be taken care of since the IOC
> > > > > > bit is not set every frame and the reclaimation will loop through every item in
> > > > > > the started_list and only stop if there are no additional trbs or if one has
> > > > >
> > > > > It should stop at the request that associated with the interrupt event,
> > > > > whether it's because of IMI or IOC.
> > > >
> > > > In this case I was concerned that if multipled queued reqs did not have IOC bit
> > > > set, but there was a missed isoc on one of the last reqs, whether or not we would
> > > > reclaim all of the requests up to the missed isoc related req. I'm not sure if
> > > > my concern is valid or not.
> > > >
> > >
> > > There should be no problem. If there's an interrupt event indicating a
> > > TRB completion, the driver will give back all the requests up to the
> > > request associated with the interrupt event, and the controller will
> > > continue processing the remaining TRBs. On the next TRB completion
> > > event, the driver will again give back all the requests up to the
> > > request associated with that event.
> > >
> >
> > I was testing with the following patch you suggested:
> >
> > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > > index 61fba2b7389b..8352f4b5dd9f 100644
> > > --- a/drivers/usb/dwc3/gadget.c
> > > +++ b/drivers/usb/dwc3/gadget.c
> > > @@ -3657,6 +3657,10 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
> > > if (event->status & DEPEVT_STATUS_SHORT && !chain)
> > > return 1;
> > >
> > > + if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> > > + (event->status & DEPEVT_STATUS_MISSED_ISOC) && !chain)
> > > + return 1;
> > > +
> > > if ((trb->ctrl & DWC3_TRB_CTRL_IOC) ||
> > > (trb->ctrl & DWC3_TRB_CTRL_LST))
> > > return 1;
> > >
> >
> > At this time the IMI bit was set for every frame. With these changes it
> > appeared in case of missed isoc that sometimes not all requests would be
> > reclaimed (enqueued != dequeued even 100ms after the last interrupt was
> > handled). If the 1st req in the started_list was fine (IMI set, but not IOC),
> > and a later req was the one actually missed, because of this status check the
> > reclaimation could stop early and not clean up to the appropriate req. As
>
> Oops. You're right.
>
> > suggested yesterday, I also tried only setting the IMI bit when no_interrupt is
> > not set, however I was still seeing the complete freezes. After analyzing this
> > issue a bit, I have updated the diff to look more like this:
> >
> > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> > index dfaf9ac24c4f..bb800a81815b 100644
> > --- a/drivers/usb/dwc3/gadget.c
> > +++ b/drivers/usb/dwc3/gadget.c
> > @@ -1230,8 +1230,9 @@ static void __dwc3_prepare_one_trb(struct dwc3_ep *dep, struct dwc3_trb *trb,
> > trb->ctrl = DWC3_TRBCTL_ISOCHRONOUS;
> > }
> >
> > - /* always enable Interrupt on Missed ISOC */
> > - trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
> > + /* enable Interrupt on Missed ISOC */
> > + if ((!no_interrupt && !chain) || must_interrupt)
> > + trb->ctrl |= DWC3_TRB_CTRL_ISP_IMI;
> > break;
>
> Either all or none of the TRBs of a request is set with IMI, and not
> some.
>
> >
> > case USB_ENDPOINT_XFER_BULK:
> > @@ -3195,6 +3196,11 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
> > if (event->status & DEPEVT_STATUS_SHORT && !chain)
> > return 1;
> >
> > + if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
> > + (event->status & DEPEVT_STATUS_MISSED_ISOC) && !chain
> > + && (trb->ctrl & DWC3_TRB_CTRL_ISP_IMI))
> > + return 1;
> > +
> > if ((trb->ctrl & DWC3_TRB_CTRL_IOC) ||
> > (trb->ctrl & DWC3_TRB_CTRL_LST))
> > return 1;
> >
> > Where the trb must have the IMI set before returning early. This seemed to make
> > the freezes recoverable.
>
> Can you try this revised change:
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 61fba2b7389b..a69d8c28d86b 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3654,7 +3654,7 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
> if ((trb->ctrl & DWC3_TRB_CTRL_HWO) && status != -ESHUTDOWN)
> return 1;
>
> - if (event->status & DEPEVT_STATUS_SHORT && !chain)
I accidentally deleted a couple of lines here.
> + if (DWC3_TRB_SIZE_TRBSTS(trb->size) == DWC3_TRBSTS_MISSED_ISOC && !chain)
> return 1;
>
> if ((trb->ctrl & DWC3_TRB_CTRL_IOC) ||
I meant to do this:
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 61fba2b7389b..cb65371572ee 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -3657,6 +3657,9 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
if (event->status & DEPEVT_STATUS_SHORT && !chain)
return 1;
+ if (DWC3_TRB_SIZE_TRBSTS(trb->size) == DWC3_TRBSTS_MISSED_ISOC && !chain)
+ return 1;
+
if ((trb->ctrl & DWC3_TRB_CTRL_IOC) ||
(trb->ctrl & DWC3_TRB_CTRL_LST))
return 1;
@@ -3673,6 +3676,7 @@ static int dwc3_gadget_ep_reclaim_trb_sg(struct dwc3_ep *dep,
struct scatterlist *s;
unsigned int num_queued = req->num_queued_sgs;
unsigned int i;
+ bool missed_isoc = false;
int ret = 0;
for_each_sg(sg, s, num_queued, i) {
@@ -3681,12 +3685,18 @@ static int dwc3_gadget_ep_reclaim_trb_sg(struct dwc3_ep *dep,
req->sg = sg_next(s);
req->num_queued_sgs--;
+ if (DWC3_TRB_SIZE_TRBSTS(trb->size) == DWC3_TRBSTS_MISSED_ISOC)
+ missed_isoc = true;
+
ret = dwc3_gadget_ep_reclaim_completed_trb(dep, req,
trb, event, status, true);
if (ret)
break;
}
+ if (missed_isoc)
+ ret = 1;
+
return ret;
}
BR,
Thinh
next prev parent reply other threads:[~2022-10-21 0:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-18 20:49 Jeffrey Vanhoof
2022-10-18 22:35 ` Thinh Nguyen
2022-10-19 1:41 ` Jeff Vanhoof
2022-10-19 2:02 ` Thinh Nguyen
2022-10-19 7:40 ` Jeff Vanhoof
2022-10-19 19:08 ` Thinh Nguyen
2022-10-19 21:34 ` Jeff Vanhoof
2022-10-19 23:06 ` Thinh Nguyen
2022-10-20 16:47 ` Jeff Vanhoof
2022-10-20 20:53 ` Jeff Vanhoof
2022-10-20 22:47 ` Thinh Nguyen
2022-10-21 0:55 ` Thinh Nguyen [this message]
2022-10-21 9:39 ` Jeff Vanhoof
2022-10-21 16:43 ` Thinh Nguyen
2022-10-21 18:28 ` Jeff Vanhoof
2022-10-21 19:09 ` Thinh Nguyen
2022-10-21 19:27 ` Jeff Vanhoof
-- strict thread matches above, loose matches on Subject: below --
2022-10-17 20:54 [PATCH v3 0/6] uvc gadget performance issues Dan Vacura
2022-10-17 20:54 ` [PATCH v3 2/6] usb: dwc3: gadget: cancel requests instead of release after missed isoc Dan Vacura
2022-10-17 21:30 ` Thinh Nguyen
2022-10-18 2:10 ` Dan Vacura
2022-10-18 18:45 ` Thinh Nguyen
2022-10-18 19:13 ` Michael Grzeschik
2022-10-18 22:45 ` Thinh Nguyen
2022-10-19 6:46 ` Michael Grzeschik
2024-02-22 0:02 ` Michael Grzeschik
2024-02-22 1:20 ` Thinh Nguyen
2024-02-27 21:01 ` Michael Grzeschik
2024-03-07 1:57 ` Thinh Nguyen
2024-03-07 16:15 ` Michael Grzeschik
2024-03-08 2:47 ` 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=20221021005537.3vbtair35umh6vo2@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=W36195@motorola.com \
--cc=balbi@kernel.org \
--cc=corbet@lwn.net \
--cc=dan.scally@ideasonboard.com \
--cc=gregkh@linuxfoundation.org \
--cc=jdv1029@gmail.com \
--cc=jvanhoof@motorola.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=m.grzeschik@pengutronix.de \
--cc=paul.elder@ideasonboard.com \
--cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®