Hi Clemens,
thanks for the reply.
I'm using the Cypress chip which offers a fixed set of alternative
settings and I use the one offering iso transfer so I cannot easily do
that. There are loads of sigma boards out there and because of the linux
firmware and the drivers not really into sync I need to do something
that keeps it intact.
The problem with setting the bInterval is that this happens at the init
of the driver but if the user wants to switch between different sampling
rates later on that this might upset other transfers. That really needs
to be on the level of a single endpoint and not resetting in the worst
case the whole setup (which switching between alternate settings).
Here's what I'll do: for xhci I'll do a "soft" interval in my firmware
and only send a packet back once a counter has counted to zero.
Otherwise I just send back a zero length packet. I keep bInterval=1
(125us) and then just send back data from the firmware at the sampling
rate requested by the driver. That obviously is exactly the opposite
what the xhci people have intended but in my case I need to init the
endpoints in a way that I can transfer at 8kHz if I want to. It's
important that the user can switch between different sampling rates at
any moment and keeping the latency always as low as possible. At the end
we use it for robot control. So, I'll waste a bit of bandwidth to keep
it as responsive as possible.
/Bernd
Clemens Ladisch wrote:
(quoting fixed)
Bernd Porr wrote:
Alan Stern wrote:
On Wed, 24 Jun 2015, Bernd Porr wrote:
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?
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.
And the xHCI specification requires this (section 6.2.3.6):
| For [isochronous] enpoint types, system software shall translate the
| bInterval field in the USB Endpoint Descriptor to the appropriate
| value for this field.
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().
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.
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.
Please note that you can implement Alan's suggestion in a mostly
backwards-compatible way by having the device offering multiple
alternate settings; an old driver (using EHCI) would still be able to
use a different interval with the 'wrong' alternate setting.
Regards,
Clemens
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
