Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp4992085ybc; Fri, 15 Nov 2019 13:07:53 -0800 (PST) X-Google-Smtp-Source: APXvYqyEtlechHUx8H8S58DRMImvhAOnYWYtTzBburHawyNBlEZvq/po7mn7VjHSrxFXkR4x1L6+ X-Received: by 2002:a1c:4606:: with SMTP id t6mr16455616wma.73.1573852073746; Fri, 15 Nov 2019 13:07:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573852073; cv=none; d=google.com; s=arc-20160816; b=cSsB4dX2Qy0Y3QesdmLsGRYySdwkFz/hHTCQ15CDpgJDdb0TOtBxaFRe8Ax4BLoWuY 6voA9s5Hst8kP/stQ77OcSJkLoBlkPVc9h/zszMBrYnpc3d2xeXW6bp3CbUE2hc0dWXB kjQTkhL6diTd8KkSq7bdJYw9s+j//7onSSIb2WPRCeVXXGPjSz57wMDM4V4t1ilnCLFu j/P30+HQlwa+OkNeiiZ9q+OCosr2nOOZaoZsa4E0Bu3qewQwFDh7zHdxecE/+E58e1B6 VvdwUP5avA6TSBepnG85yNG5I3KPPGYsQnIhbmque9mmgEJcWQt/uy3fRNviphTrYfVd GmVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=OFLnPGzX9rbi+lUX0YWNMEU3Lt1HhNBQ+2PXSSA1nNg=; b=GB/vMM+/r0oITB5vfIhZvjBLN6tBH6jSfwtgdaju6CzOIo/gFx1LVCjp8HGjoQQqPP sjhafTOCBrDvkulkfboUNW2DCtqjYjBmlAEb7zoXkT+P2k1C+jh67Nl7+uStY/CirYwy 8WLBZHNDwHhFMdHGDjCwKSNPMWBG470f6lT2vRqdh88j6iI4FNMAnXW5glD0fjhb6O5T aMDv+NdX7Fjc/9JN6nl+Tr8sV0/eONnicQRaU7vV/PgBe/7Wd2TUqYknmIX5/mtfKRjp 2QTnk9F0iQL4GMNap1w8Wsl+4mFEZSE8Y0Sq/nDtho1sXoziGU7MiRzeU4fvN9bwm6fm PCKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q4si6832198edr.80.2019.11.15.13.07.28; Fri, 15 Nov 2019 13:07:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726786AbfKOVGM (ORCPT + 99 others); Fri, 15 Nov 2019 16:06:12 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:55502 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726605AbfKOVGL (ORCPT ); Fri, 15 Nov 2019 16:06:11 -0500 Received: (qmail 7153 invoked by uid 2102); 15 Nov 2019 16:06:10 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Nov 2019 16:06:10 -0500 Date: Fri, 15 Nov 2019 16:06:10 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Thinh Nguyen cc: "linux-usb@vger.kernel.org" , Felipe Balbi , Greg Kroah-Hartman , "linux-kernel@vger.kernel.org" , "kernel@pengutronix.de" Subject: Re: [PATCH 2/2] usb: dwc3: gadget: restart the transfer if a isoc request is queued too late In-Reply-To: <6d4b87c8-5aca-18cb-81db-a8d2fd4bd86e@synopsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 14 Nov 2019, Thinh Nguyen wrote: > Michael Olbrich wrote: > >>> How about changing the gadget driver instead? For frames where the UVC > >>> gadget knows no video frame data is available (numbers 4, 8, 12, and so > >>> on in the example above), queue a zero-length request. Then there > >>> won't be any gaps in the isochronous packet stream. > >> What Alan suggests may work. Have you tried this? > > Yes and it works in general. There are however some problems with that > > approach that I want to avoid: > > > > 1. It adds extra overhead to handle the extra zero-length request. > > Especially for encoded video the available bandwidth can be quite a bit > > larger that what is actually used. I want to avoid that. This comment doesn't seem to make sense. If the available bandwidth is much _larger_ than what is actually used, what's the problem? You don't run into difficulties until the available bandwidth is too _small_. The extra overhead of a zero-length request should be pretty small. After all, the gadget expects to send a packet for every frame anyway, more or less. > > 2. The UVC gadget currently does no know how many zero-length request must > > added. So it needs fill all available request until a new video frame > > arrives. With the current 4 requests that is not a problem right now. But > > that does not scale for USB3 bandwidths. So one thing that I want to do is > > to queue many requests but only enable the interrupt for a few of than. > > From what I can tell from the code, the gadget framework and the dwc3 > > driver should already support this. > > This will result in extra latency. There is probably an acceptable > > trade-off with an acceptable interrupt load and latency. But I would like > > to avoid that if possible. There are two different situations to consider: In the middle of a video stream, latency isn't an issue. The gadget should expect to send a new packet for each frame, and it doesn't know what to put in that packet until it receives the video data or it knows there won't be any data. At the start of a video stream, latency can be an issue. But in this situation the gadget doesn't have to send 0-length requests until there actually is some data available. Either way, it should be okay. As far as interrupt load is concerned, I don't see how it relates to the issue of sending 0-length requests. > I think I understand the problem you're trying to solve now. > > The dwc3 driver does not know that there's a gap until after a new > request was queued, which then it will send an END_TRANSFER command and > dequeue all the requests to restart the transfer due to missed_isoc. > We do this because the dwc3 driver does not know whether the new request > is actually stale data, and we should not change this behavior. > > Now, with UVC, it needs to communicate to the dwc3 driver that there > will be a gap after a certain request (and that the device is expecting > to send 0-length data). This is not a normal operation for isoc > transfer. You may need to introduce a new way for the function driver to > do that, possibly a new field in usb_request structure to indicate that. > However, this seems a little awkward. Maybe others can comment on this. Note that on the host side, there is a difference between receiving a 0-length packet and receiving no packet at all. As long as both the host and the gadget expect the isochronous stream to be running, there shouldn't be any gaps if you can avoid it. Alan Stern