Re: USB mini-summit at LinuxCon Vancouver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 06/10/2011 02:21 AM, Sarah Sharp wrote:
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?


I would like to give a short presentation on / demo off the usb redirection
over the network (USB-IP replacement with a less dumb protocol) I've been
working on, followed by a questions and answers session.

For those who want to give this a try now, see:
http://hansdegoede.livejournal.com/9682.html

Sheets from the presentation I gave on this at FOSDEM:
http://people.fedoraproject.org/~jwrdegoede/usb-redir.pdf

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.

I'm not really happy with how the management / hand over of userspace
to kernel space drivers and vice versa works. This is a problem when
doing usb-redirection to a virtual machine. I think this is best discussed
in a separate thread, and then if needed further discussed during the
mini summit. I'll send a mail on this shortly. I'll use the same address
list as this mail, except that I'm going to cut linux-kernel from the CC list.


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.

Interesting, being able to tell the core how much bandwidth a device
will actually use (versus what it claims as maxpacketsize in its
descriptors) is something which we really need. I know of at least
2 usb1 webcam chipsets (and drivers) which have only 1 altsetting which
claim 1023 bytes maxpacketsize. But they also have a register which
allows the driver to configure how large the largest (iso) packet it
sends will actually be.

Currently these drivers have this "beauty" to be able to tell the
linux usb core that they won't be using 1023 as maxpacketsize but
something else, and thus function without needing full usb1 bandwidth:

struct usb_host_interface *alt;
alt = &gspca_dev->dev->config->intf_cache[0]->altsetting[1];
alt->endpoint[0].desc.wMaxPacketSize = cpu_to_le16(packet_size);
ret = usb_set_interface(gspca_dev->dev, gspca_dev->iface, 1);

Yes they are overwriting the kernels cached descriptors ...

###

Something which I would also like to bring to everyone's attention
is that we really need to fix the ehci schedule code wrt scheduling
usb1 transfers over usb2 hubs.

The current code is very broken when it comes to periodic transfers,
it basically disallows using the last microframe (let alone the
crossing of the frame boundary and using the first microframe of
the next frame).

This means that trying to submit isoc transfers with a size of 1023
will just plain fail, even if this is the only device on the entire
bus. This is one of the reasons I ended up doing the hack above, so
that these devices will at least work (be it at a decreased framerate)
through a usb2 hub.

Things become even messier when the device has a build in usb audio
microphone, often this will just not work.

Finally fixing this has become more important now then ever since
sandybridge machines (and maybe generation one core i# machines too,
I don't know) no longer have a companion controller, but instead
have an integrated usb2 hub.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux