Hi Alan,
thanks for the quick reply. I guess the cleanest solution is to write
additional code in both the firmware and the driver for xhci and then
once the older drivers change roll that over.
I've been trying to avoid changing the firmware because it's not really
maintained in sync with the kernel. So I need to be careful. The best
approach is (I think but correct me) to ditch ISO for now just for xhci
and then much later also for the other drivers. If I use bulk for xhci
instead then the firmware can release the data at the rate the user
wants to have it. In that way I can update the firmware for xhci and
test it without causing havoc for those using the drivers just now.
In that way USB 2.0 is untouched and I can write the xhci support which
doesn't work at all at the moment so can only get better.
/Bernd
Alan Stern wrote:
On Wed, 24 Jun 2015, Bernd Porr wrote:
Hi all,
I'm the maintainter of the the USBDUX* devices.
They are USB 2.0 high speed devices. I use urb->interval to control the
sampling rate of these devices. That works fine with the ehci driver.
When I use the xhci driver it seems to be interpreting the urb->interval
in a different way and/or ignoring it? I need essentially intervals of
1,2,4,8 microframes (125us, 250, 500, 1000us).
As you have seen from the source code, xhci-hcd ignores the
urb->interval value provided by the driver and instead uses the value
from the endpoint descriptor.
In the future, other host controller drivers may behave the same way.
This is because the bus's periodic bandwidth needs to be allocated
beforehand, at the time the alternate setting is installed -- which is
before any URBs can be submitted.
Currently, I think the only way to do what you want is to set
ep->desc.bInterval to the desired value and then call
usb_set_interface().
Alan Stern
--
http://www.berndporr.me.uk
http://www.imdb.com/name/nm3293421/
http://www.facebook.com/bernd.porr
+44 (0)7840 340069
--
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
