On Wed, Jun 20, 2018 at 8:32 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > > > > On Wed, Jun 20, 2018 at 9:36 AM Jassi Brar <jassisinghb...@gmail.com> wrote: >> >> On Tue, Feb 13, 2018 at 3:02 PM, Robert Bielik <robert.bie...@dirac.com> >> 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. Cheers! -- 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
