Re: New USB core API to change interval and max packet size

[Mauro Carvalho Chehab <m.chehab@samsung.com>]

Em Wed, 02 Oct 2013 12:38:14 -0400 (EDT)
Alan Stern <stern@rowland.harvard.edu> escreveu:

> On Wed, 2 Oct 2013, Mauro Carvalho Chehab wrote:
> 
> > > > So, there's no need to call usb_change_ep_bandwidth().
> > > 
> > > That's right.
> > > 
> > > > If so, then usb_change_ep_bandwidth() as a quirk, if bInterval
> > > > or wMaxPacketSize were improperly filled.
> > > > 
> > > > Right?
> > > 
> > > Or if the values are correct, but the driver wants to use something 
> > > different for its own reasons (for example, to get lower latency or 
> > > because it knows that it will never use packets as large as the 
> > > descriptor allows).  Right.
> > 
> > Ok, so, in this case, usb_change_ep_bandwidth() could be called
> > just before usb_alloc_urb(), in order to make it to use the packet
> > size that would be expected for that kind of ISOC traffic that
> > userspace indirectly selected, by adjusting the streaming
> > video resolution selected, right?
> 
> We haven't decided on the final API yet.  However, note that
> usb_alloc_urb() doesn't depend on the packet size.  It requires you to
> specify only the number of packets, not their sizes.  Therefore it
> doesn't matter whether you call usb_change_ep_bandwidth() before or
> after usb_alloc_urb().

Sure, but, at least on almost all V4L2 drivers, the number of packets
and their sizes should be calculated to be able to receive all URBs
needed to store a complete image frame (that generally arrives on 
every 1/60 Hz or 1/50 Hz - depending on the frames per second rate).

On those drivers, the transfer_buffer is allocated at the same loop 
where usb_alloc_urb() is called.

So, it makes sense for them to specify the bandwidth parameters at
the function that calls usb_alloc_coherent() and usb_alloc_urb().

Regards,
Mauro