Re: USB mini-summit at LinuxCon Vancouver

[Mauro Carvalho Chehab <mchehab@infradead.org>]

Hi Sarah/Greg,

Em 09-06-2011 21:21, Sarah Sharp escreveu:
> I'm pleased to announce a USB mini-summit at LinuxCon Vancouver.
> 
> What:	USB mini-summit
> When:	Tuesday, August 16th, all day
> Where:	At the conference venue, room TBD pending confirmation from
> 	Angela Brown.
> 
> Proposed topics include USB virtualization, and improved bandwidth APIs
> between the USB core and drivers (especially webcam drivers).  See the
> detailed topic list below.  Anyone is also welcome to propose or show up
> with a USB related topic.  MUSB?  USB 3.0 gadget drivers?  USB-IP?
> 
> The USB mini-summit does overlap with the virtualization mini-summit by
> a day, but I'm hoping we can schedule talks so some of the
> virtualization folks can make it to the USB mini-summit.  The other
> option was on Friday during the conference which was not ideal.
> 
> Proposed topics:
> 
> Topic 1
> -------
> 
> The KVM folks suggested that it would be good to get USB and
> virtualization developers together to talk about how to virtualize the
> xHCI host controller.  The xHCI spec architect worked closely with
> VMWare to get some extra goodies in the spec to help virtualization, and
> I'd like to see the other virtualization developers take advantage of
> that.  I'd also like us to hash out any issues they have been finding in
> the USB core or xHCI driver during the virtualization effort.
> 
> 
> Topic 2
> -------
> 
> I'd also like to get the V4L and audio developers who work with USB
> devices together with the core USB folks to talk about bandwidth
> management under xHCI.
> 
> One of the issues is that since the xHCI hardware does bandwidth
> management, not the xHCI driver, a schedule that will take too much
> bandwidth will get rejected much sooner than any USB driver currently
> expects (during a call to usb_set_interface).  This poses issues, since
> most USB video drivers negotiate the video size and frame rate after
> they call usb_set_interface, so they don't know whether they can fall
> back to a less bandwidth-intensive setting.  Currently, they just submit
> URBs with less and less bandwidth until one interval setting gets
> accepted that won't work under xHCI.
> 
> A second issue is that that some drivers need less bandwidth than the
> device advertises, and the xHCI driver currently uses whatever periodic
> interval the device advertises in its descriptors.  This is not what the
> video/audio driver wants, especially in the case of buggy high speed
> devices that advertise the interval in frames, not microframes.  There
> needs to be some way for the drivers to communicate their bandwidth
> needs to the USB core.  We've known about this issue for a while, and I
> think it's time to get everyone in the same room and hash out an API.
> 
> (I will send out an API proposal later this month.)

While discussing the topics for the media workshop that will happen together
with this year's KS/2011, one issue related to the USB stack came on our
discussions: it is related to multi-function USB devices, as you can
see on this thread:
	http://www.spinics.net/lists/linux-media/msg36195.html

We have several cases of multi-function devices at the media subsystem.
For example, most TV grabber devices provides Remote Controller, Video,
audio and MPEG streaming capabilities, either implementing the standard
USB API's, or the vendor class API's. There are even some devices that
support USB storage, 3G modem and Digital TV.

Some of those devices have some resources that are mutually exclusive.

For example, some Digital Cameras can provide either access to the stored
images, or can be used as webcams. Using them as webcams automatically
deletes all stored images from it. So, a properly implemented driver
should be returning -EBUSY (or -EPERM?) if someone tries to stream for
such devices if is there any pictures stored on it. Symmetrically,
accessing the stored pictures there should return -EBUSY if the device
is streaming.

Currently, the data access for Digital Cameras is implemented via libusb,
libgphoto and gvfs, while the streaming interface is implemented via
a gspca Kernel driver.

I know that this problem were somewhat solved for 3G modems, with the usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sure if such tricks will scale forever, as more
functions are seen on some USB devices.

So, if we have some time, maybe we could start some discussions about that
during the USB mini-summit.

It should be noticed that the media subsystem has currently similar problems 
on devices that provide both analog and digital TV, as some resources, like 
the tuner can't be used simultaneously by the two API's. This happens even
with PCI devices. So, maybe, in the end, we'll be writing some kernel library
for resource locking, but it would be good if we can have preliminary
discussions there, and let the final discussions to happen during KS/2011. 

What do you think?

Thanks!
Mauro