Re: Unable to Use Isochronous Behavior w/ Isoc Endpoint in FunctionFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 22, 2020 at 10:41:14AM -0500, Sid Spry wrote:
> 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.

Like I said before, you'll need to ask someone who knows more about 
FunctionFS.

> > > 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.

That's exactly how it's supposed to work.  Don't mix up endpoint _numbers_ 
with endpoint _addresses_; they aren't the same thing.  Read through the 
USB-2.0 specification for more information.

Also don't forget that two interfaces in the same configuration are not 
allowed to share an endpoint (other than endpoint 0, which doesn't really 
belong to any interface).

> This isn't causing me problems per se but does seem improper.

Why?

> I'll look through the functionfs code when I have some time. The user mode
> does not seem to be passed much information.

If you think this is a weakness of FunctionFS and it needs to be fixed, 
report it to the FunctionFS maintainers.  See the MAINTAINERS file in the 
top-level directory of the kernel source code.

> > > 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.

Okay.  Maybe the problem occurs in the code that enables the endpoints for 
altsetting 1.

Alan Stern



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux