Re: [PATCHv2 3/3] usb: gadget: f_uac*: Support multiple sampling rates

[Ruslan Bilovol]

Hi guys,

On Mon, Jul 2, 2018 at 7:30 PM, Eugeniu Rosca <erosca@xxxxxxxxxxxxxx> wrote:
> Hi Julian,
>
> [CC:Takashi, since we are discussing sound-related parts of USB]
>
> On Mon, Jul 02, 2018 at 04:07:19PM +0200, Julian Scheel wrote:
>> Hi Eugeniu,
>>
>> On 30.06.2018 20:16, Eugeniu Rosca wrote:
>> > Would it be possible to revive the uac2 multiple sampling rate
>> > patch-set [1] by rebasing it onto the most recent kernel? If you
>> > don't have time for this, I could help you.
>>
>> I have this on my todo-list for a while now... In fact I fixed the build
>> errors reported by the robot last year, but didn't had the time to
>> verify all of it and push again.
>> Still, I'd be happy to get this merged, so I'll try to check the state
>> of this within the next days and either post to the list or get back to
>> you if more work needs to be done.
>
> We've been living with an internally developed uac2 multiple rate
> support since June 2015, initially written on top of v3.14. Due to
> significant refactoring of uac2 driver brought by v4.13 commit [1], I
> went through the comparison between the in-house implementation (which
> no more applied cleanly to post-[1] vanilla) and your proposal from [2].
>

When Julian posted his patches, I've been working on UAC3 gadget
implementation which I posted later [1]. While I originally tried to make
UAC3 function to have same configfs files as UAC1/2, now, preparing
UAC3 gadget patch I see it doesn't fit this approach, and patch
"usb: gadget: f_uac*: Reduce code duplication" isn't applicable for UAC3
case. Especially for channels configuration which in new spec can be
done only through clusters descriptions, which makes configfs interface
more complicated and not so straightforward as UAC1/2 have.

I didn't finish my UAC3 gadget patch v2 yet, but if you can try to avoid
adding patch "Reduce code duplication" or wait for a few weeks, when
I'll post UAC3 patches, it would be great; so we will be able to take into
account new spec as well.

[1]: https://lkml.org/lkml/2017/11/6/1514

Thanks,
Ruslan