[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3f404a27-50e8-42c5-a497-b46751154613@rowland.harvard.edu>
Date: Wed, 22 May 2024 10:50:31 -0400
From: Alan Stern <stern@...land.harvard.edu>
To: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc: Michael Grzeschik <mgr@...gutronix.de>,
Avichal Rakesh <arakesh@...gle.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Daniel Scally <dan.scally@...asonboard.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jayant Chowdhary <jchowdhary@...gle.com>,
"etalvala@...gle.com" <etalvala@...gle.com>,
Michael Riesch <michael.riesch@...fvision.net>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] usb: gadget: uvc: allocate requests based on frame
interval length and buffersize
On Wed, May 22, 2024 at 01:41:42AM +0000, Thinh Nguyen wrote:
> On Wed, May 22, 2024, Michael Grzeschik wrote:
> > On Fri, May 17, 2024 at 01:44:05AM +0000, Thinh Nguyen wrote:
> > > For isoc endpoint IN, yes. If the host requests for isoc data IN while
> > > no TRB is prepared, then the controller will automatically send 0-length
> > > packet respond.
> >
> > Perfect! This will help a lot and will make active queueing of own
> > zero-length requests run unnecessary.
>
> Yes, if we rely on the current start/stop isoc transfer scheme for UVC,
> then this will work.
You shouldn't rely on this behavior. Other device controllers might not
behave this way; they might send no packet at all to the host (causing a
USB protocol error) instead of sending a zero-length packet.
On the other hand, it may not make any difference. The host's UVC
driver most likely won't care about the difference between no packet and
a 0-length packet. :-)
Alan Stern
Powered by blists - more mailing lists