Hi,
On 11/29/2009 06:42 PM, Alan Stern wrote:
On Sun, 29 Nov 2009, Hans de Goede wrote:
Hi,
I've the following problem, which has lead me to believe that for
scheduling isoc streams ehci-sched.c should uses the actual isoc
urb packetsize instead of wMaxPacketSize.
This can't be done. The URB packet size isn't known at the time the
scheduling is performed. That is, the packet size for the _current_
URB is known but not the sizes for URBs to be submitted in the future.
That is true, but I would assume that it is normal for all urb's
in an isoc stream to be the same packet size, after scheduling one could
check that future URB's have the same size and if not error out. The
same is already done for interval.
Some webcams, at least those based on stv06xx
bridges, have only 1 alt setting,
Are the manufacturers aware that this is a violation of the USB 2.0
specification?
I dunno, this is an old usb1 cam which might very well predate the
usb2 spec. Oh, I see I fsck-ed up. Sorry it was a while ago I worked on
this (I was planning on investigating some more back then) but I just
got pinged about it, so I thought it would be good to write a mail about
this now. While doing so, running from old memories I fsck-ed up and
started looking at the ehci driver to write my mail, which is very wrong
as that is the usb2 host driver, I should have looked at the OHCI driver
(and I guess also the UHCI driver) instead.
Sorry, I know this does not inspire fate.
Please believe me when I say the rest of my story is accurate :)
but they have a register which allows
one to tell it to send isoc frames which are never bigger then the value
set in the register. I've tested this and it works as advertised,
when you create isoc urbs with a size< wMaxPacketSize, then normally
when trying to stream from the camera, you will get -EMSGSIZE errors (iirc)
as the camera sends isoc frames, larger then the buffers in the isoc urbs
created.
But if you then write the size you created the isoc urbs with to the register
in question, things will work. So this seems to works as advertised.
I would like to use this feature of the camera to make it work in cases
where there is another isoc stream also active (for example a usb 1.1 audio
device) and thus there is not enough bandwidth to make the camera stream
with wMaxPacketSize sized isoc urbs, so usb_submit_urb() will fail
with -ENOSPC.
But even if I make the packets smaller (and thus using less
bandwidth) I keep getting -ENOSPC, as ehci-sched.c: iso_stream_init()
does not look at the size of the submitted urb, but just assumes
wMaxPacketSize, which in case of these webcam simply is not necessarily
true.
As well written drivers for devices which do always send isoc packets
up to wMaxPacketSize, should always submit isoc urbs of wMaxPacketSize,
changing this inside ehci-sched.c should not impact existing drivers,
where as it will help hardware which can be told to always send
packets< wMaxPacketSize, this I would like to propose to change
ehci-sched.c: iso_stream_init() to use the actual urb size to calculate
the amount of needed usecs.
I'm willing to write a patch for this, but have not done so far, because
if this idea gets shot down it is little use to spend time on such a
patch.
This isn't a good idea. The trend for the future is to allocate
bandwidth as soon as a config or an altsetting is installed, based on
the descriptor values. (The xHCI driver for USB 3.0 already works this
way.) In your case the allocation would fail even before the driver
got a chance to modify the camera's register values.
And usb3 probably has enough bandwidth to make this makes sense, maybe usb2
even has enough bandwidth for this to make sense but usb1 (which I know I did
not say this was about, again this is my bad, sorry), does not have enough
bandwidth.
The correct solution to the problem of limited bandwidth is to have
multiple altsettings, providing support for different levels of
resolution and bandwidth. Of course, only the manufacturer can do
this.
I agree, but the designers of these (rather old) camera's thought
differently about this it seems.
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
