Hi,
On 06/10/2011 05:08 PM, Alan Stern wrote:
[CC: list severely trimmed]
On Fri, 10 Jun 2011, Hans de Goede wrote:
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).
Indeed, the current code is not good. About the best we can say is
that it usually works, in undemanding circumstances.
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.
I've never tried doing that. Does it really fail?
It really fails with -ENOSPC.
Or does it set up
the transfer in a way that isn't fully compliant with the spec?
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.
In general, the USB-2.0 spec does not give high-speed controllers as
much flexibility for scheduling full- and low-speed periodic transfers
as full-speed controllers have. And even using the available
flexibility to its full advantage is _extremely_ difficult -- I doubt
we will ever implement it. But we could do better than we do now.
Right, I'm mostly advocating for the do better bit.
Rewriting the scheduling code will be a big project, and I have avoided
working on it for a couple of years now. :-) But it could be done if
the need was urgent enough.
I realize this is a big project, which is why I wanted to bring
to people's attention before the summit in Vancouver, who knows
maybe someone will volunteer :)
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.
I don't know... It's true that we're starting to see more machines
with no companion controllers. But it's also true that USB-3
controllers are starting to permeate the market -- and for them this
whole issue is moot since the scheduling is done automatically by the
hardware/firmware. So while the issue may be gaining importance, it's
also losing importance.
Interesting point. But I think we will see lots of machine for the
coming 2 years with usb1/2 ports and no companion controller. Since
that is what the current generation Intel chipsets ship with. Some
high-end machines may have a few usb3 ports, but they will still
have usb1/2 ports and guess where a user is more likely to plug
a usb1 cam in?
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
