mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®