Re: urb-interval differently interpreted via xhci for 2.0
(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 -- 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
Re: urb-interval differently interpreted via xhci for 2.0
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
Re: urb-interval differently interpreted via xhci for 2.0
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
