Re: [PATCH v14 20/53] ASoC: Add SOC USB APIs for adding an USB backend

[Takashi Iwai <tiwai@xxxxxxx>]

On Fri, 09 Feb 2024 21:34:39 +0100,
Wesley Cheng wrote:
> 
> Hi Takashi,
> 
> On 2/9/2024 2:54 AM, Takashi Iwai wrote:
> > On Fri, 09 Feb 2024 00:13:33 +0100,
> > Wesley Cheng wrote:
> >> 
> >> Some platforms may have support for offloading USB audio devices to a
> >> dedicated audio DSP.  Introduce a set of APIs that allow for management of
> >> USB sound card and PCM devices enumerated by the USB SND class driver.
> >> This allows for the ASoC components to be aware of what USB devices are
> >> available for offloading.
> >> 
> >> Signed-off-by: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>
> > (snip)
> >> --- a/sound/soc/Makefile
> >> +++ b/sound/soc/Makefile
> >> @@ -1,5 +1,5 @@
> >>   # SPDX-License-Identifier: GPL-2.0
> >> -snd-soc-core-objs := soc-core.o soc-dapm.o soc-jack.o soc-utils.o soc-dai.o soc-component.o
> >> +snd-soc-core-objs := soc-core.o soc-dapm.o soc-jack.o soc-usb.o soc-utils.o soc-dai.o soc-component.o
> >>   snd-soc-core-objs += soc-pcm.o soc-devres.o soc-ops.o soc-link.o soc-card.o
> >>   snd-soc-core-$(CONFIG_SND_SOC_COMPRESS) += soc-compress.o
> > 
> > Do we really want to build this into ASoC core unconditionally?
> > This is very specific to Qualcomm USB-offload stuff, so it's better to
> > factor out.
> > 
> 
> Ideally, the SOC USB part shouldn't be Qualcomm specific.  Since I
> don't have access or insight into how other vendors are achieving the
> same thing, I can only base the soc-usb layer to work with the
> information that is required to get the audio stream up and running on
> the QC platforms.  In its simplest form, its basically just a SW
> entity that notifies ASoC components about changes occurring from USB
> SND, and I think all vendors that have an ASoC based platform card
> handling the offload will need this notification.

Yes, but it's not necessarily built into the snd-soc-core module at
all, but can be split to another module, right?  Otherwise all
machines must load this code even if it doesn't use at all.
If this were common among various chips, it'd be worth to be merged
into the default common module.  But I don't think that's the case.


thanks,

Takashi