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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Takashi,

On 2/10/2024 12:08 AM, Takashi Iwai wrote:
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.


That's fair. I'll make it a separate module and upload v15 tomorrow. Thanks for the explanation.

Thanks
Wesley Cheng




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux