On Mon, Jun 22, 2020, at 9:02 AM, Alan Stern wrote: > On Sun, Jun 21, 2020 at 09:25:53PM -0500, Sid Spry wrote: > > I now must ask the list: What is the relation of the isochronous endpoint setup > > to the allocated bandwidth on the bus? > > Bandwidth allocation is determined by the host controller driver, or in > the case of xHCI, hardware. Therefore it will vary with different drivers > or controllers. > Ok, variation I expected. Sadly it seems like I am not made aware of which interface alternate setting is chosen. See: https://elixir.bootlin.com/linux/latest/source/drivers/usb/gadget/ function/f_fs.c#L3265. The ctrlrequest struct (https://elixir.bootlin.com/linux/latest/source/include /uapi/linux/usb/ch9.h#L213) is only sent for SETUP events. Of which I have yet to triggered. > > I understand the limit of 3 1024 byte > > transfers per frame, but this says nothing about how it will be allocated or > > how a device is refused bandwidth. Do I need to look for link degradation on > > the application layer? It seems like having a single non-spec device means > > the OS can't arbitrate link bandwidth. > > If allocation fails, the application will find out either when it tries to > issue a Set-Interface request or when it tries to submit an isochronous > URB. > > Did you say earlier that your host controller is xHCI? If it is then the > OS doesn't arbitrate link bandwidth; the xHCI hardware does. > It is. The device is HS USB2. Eventually I'll find a platform with a superspeed UDC. Suspecting I will have to repurpose a rooted Android phone. If anyone has a lead on something with an easily accessible hardware serial port I am interested. > > Also! > > > > For the list's consideration I have included an accepted but nonworking > > configuration that perplexes me. The application note for the original device > > I used specified a set of descriptors which was like so (device and > > configuration omitted): > > [apparently irrelevant details omitted] > > > libusb seems to encounter an error: > > > > (pyusb error output) > > ``` > > >>> import usb > > >>> ds = [d for d in usb.core.find(find_all=True, idVendor=0x1d6b, idProduct=0x0104)] > > >>> d = ds[0] > > >>> d.set_interface_altsetting(interface=1, alternate_setting=1) > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 902, in set_interface_altsetting > > self._ctx.managed_set_interface(self, interface, alternate_setting) > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 102, in wrapper > > return f(self, *args, **kwargs) > > File "/usr/lib/python3.7/site-packages/usb/core.py", line 204, in managed_set_interface > > self.backend.set_interface_altsetting(self.handle, i.bInterfaceNumber, alt) > > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 807, in set_interface_altsetting > > altsetting)) > > File "/usr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 595, in _check > > raise USBError(_strerror(ret), ret, _libusb_errno[ret]) > > usb.core.USBError: [Errno None] Other error > > ``` > > > > (libusb error from C code) > > ``` > > libusb: error [op_set_interface] setintf failed error -1 errno 32 > > ``` > > Error 32 means that the device returned a STALL status when it received > the Set-Interface request. The code responsible for this error response > might be in FunctionFS or in your driver. > I see the set-interface request in my code as a read/write error on the endpoints (errno 11: resource temporarily unavailable) and an enable event. Otherwise most things "just happen." I've had issues reusing endpoint numbers like you are supposed to. Either the descriptors aren't accepted or more commonly the UDC won't bind. E.g. I have to give interface 0 eps 1, 2 and interface 1 eps 3, 4. The numbering is preserved on the host, kind of. Eps are compacted into their numbering based on direction. So you see interface 0 with eps 0x81 and 0x01, and interface 1 with eps 0x82 and 0x02. This isn't causing me problems per se but does seem improper. I'll look through the functionfs code when I have some time. The user mode does not seem to be passed much information. > > But, if interface 1 alternate setting 0 is dropped, and interface 1 alternate > > setting 1 is kept, both invocations work and my C code spits out data very > > fast, although I must inspect it further as I seem to be duplicating data in my > > reads. > > If you drop altsetting 0 then you're probably not issuing a Set-Interface > request. That would explain why you don't get a failure. > > If you like, you can try issuing a Set-Interface(0) request (even though > it's redundant) just to see if it fails. > Ah, yes, I had done set-interface(0 [, 0]). set-interface(1, 0) also works. It is just set-interface(1, 1) that is nonfunctional when an alternate mode 0 is provided.
