Re: [PATCH 2/2] USB: Gadget: Add Audio Class 2.0 Driver

[Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

Hi,

On Mon, Aug 22, 2011 at 06:30:36PM +0530, Jassi Brar wrote:
> > I understand your point, but then we will have two gadget drivers (and
> > two function drivers) for the same thing (USB Audio), it's the same
> > thing with the storage gadgets and we have decided on dropping one of
> > them recently, so I'm not keen on accepting another gadget driver which
> > will essentially do the same thing.
> No dear, not the same thing.
> As I said, they differ by features as well as USB-Spec... only the
> 'audio' thing is common.

and that's what I meant by same thing. How different is UAC_1 from
UAC_2.

> > If audio2.c can achieve audio.c's functionality, then you can start by
> > re-factoring audio.c so that it come closer to what audio2.c is today.
> audio.c and audio2.c have almost nothing in common. Please have a look
> at the code.
> Making audio.c closer to audio2.c would mean :-
>   * Changing all of the descriptors of audio.c {uac_1 -> uac_2}
>   * Removing all alsa related code and adding virtual alsa sound card.
>  At the end, audio.c would have been changed completely and Linux-usb-gadget
> lost the UAC_1 compliance.

it shouldn't loose compliance. If it does it was probably not done
right.

> > WRT UAC_1/UAC_2 compliance, you can use a Kconfig entry, or two separate
> > USB configurations (one with UAC_1 and another UAC_2). So there are ways
> > to make this all work while still keeping backwards compatibility.
> IIUC, you mean adding UAC_2 compliance and virtual sound-card i/f to
> audio.c, while
> preserving the it's original functionality ?

yes.

> But that would mean having two drivers in one file, because they are
> so different.

then make only a differnt function driver, f_uac2.c, which gets added as
another interface (or configuration) to audio.c.

> Otherwise, please have a look at audio.c and audio2.c and suggest what
> exactly you mean.

audio.c doesn't do anything audio related. It's just adding the
configuration to composite layer. The real specification is implemented
in f_audio.c (should probably be called f_uac1.c, though).

Then only thing different between audio.c and audio2.c is bDeviceClass,
bDeviceSubClass and bDeviceProtocol, but that can be easily handled with
Kconfig choice and/or module parameter.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]