On Wed, Jun 20, 2018 at 9:16 PM, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote: > On Wed, Jun 20, 2018 at 11:19 AM Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote: >> >> On Wed, Jun 20, 2018 at 8:32 PM, jonsmirl@xxxxxxxxx <jonsmirl@xxxxxxxxx> wrote: >> > >> > >> > >> > On Wed, Jun 20, 2018 at 9:36 AM Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote: >> >> >> >> On Tue, Feb 13, 2018 at 3:02 PM, Robert Bielik <Robert.Bielik@xxxxxxxxx> wrote: >> >> >> Enabling SOF interrupts will be a big pain :-) Well, enabling the >> >> >> interrupt itself is a no-brainer, but it'll cause terrible CPU overload. >> >> > >> >> > Oh, I see. Hmm... would it be possible to allow upper levels to config this dynamically ? I.e. for the ALSA subsystem there is no need for the SOF timestamps, whereas for my proposal they would be needed. >> >> > >> >> > And what kind of CPU overhead are we talking about ? The IRQs shouldn't come more often than every 125 us, and all that is needed is to take a timestamp value But I'm probably overlooking a lot of stuff... >> >> > >> >> I believe we could control data rate precisely enough for the >> >> feeedback ep to be needed only for compatibility with Windows (Linux >> >> is already tested to work fine, MacOS is reported to have worked when >> >> the code was upstreamed.). >> > >> > >> > Right now Windows 10 (all I have checked) refuses to even connect to a Linux based UAC2 device. It appears to be complaining that no endpoint supporting USB_ENDPOINT_USAGE_FEEDBACK mode is implement. My five minutes of poking in the spec implies that implementing this is required for an endpoint doing USB_ENDPOINT_SYNC_ASYNC. Maybe this is something that can be faked to the point of allowing Windows to connect to the UAC2 gadget driver? >> > >> Thats what I meant. >> >> > The Windows error you get is: >> > "The driver could not find a feedback endpoint for an asynchronous data OUT endpoint on device \Device\....." >> > >> For OUT, there might be some hoops to jump. Honestly it's been years >> since I read the spec and got the code to work. I find it tempting to >> look into Windows 10 as well, but I can't commit to a timeline. > > For my application there is no recording HW on the gadget. Maybe a > quick way to fix this would be to make a flag to say that the gadget > is output only? And then change the descriptors around? > There could be hacks to fool Windows but the right approach is to find some real uac2 "USB-IN only" device and share the lsusb output. Then we could kill some descriptor to pretend like that device. -- 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
