[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3634f704-a496-4341-a01d-07182248eccf@quicinc.com>
Date: Mon, 8 Jul 2024 16:16:37 -0700
From: Wesley Cheng <quic_wcheng@...cinc.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
Amadeusz Sławiński
<amadeuszx.slawinski@...ux.intel.com>,
<srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
<perex@...ex.cz>, <conor+dt@...nel.org>, <corbet@....net>,
<broonie@...nel.org>, <lgirdwood@...il.com>, <krzk+dt@...nel.org>,
<Thinh.Nguyen@...opsys.com>, <bgoswami@...cinc.com>, <tiwai@...e.com>,
<robh@...nel.org>, <gregkh@...uxfoundation.org>
CC: <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-sound@...r.kernel.org>, <linux-usb@...r.kernel.org>,
<linux-arm-msm@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<alsa-devel@...a-project.org>
Subject: Re: [PATCH v23 32/32] ASoC: doc: Add documentation for SOC USB
On 7/4/2024 4:25 AM, Pierre-Louis Bossart wrote:
>>> Just so I understand...is it really desired that userspace doesn't
>>> have the flexibility to choose which USB device is offloaded? I know
>>> it complicates what needs to be done, but it could be just an
>>> additional feature that can be added later on. Again, by default, we
>>> select the last USB headset plugged in to be enabled for offload by
>>> default.
>> If it chooses endpoint by itself perhaps you can send patch set without
>> controls first? This has added benefit of less patches in series, making
>> it easier to review and it won't block whole patch set by discussion on
>> controls feature. Controls can be added in followup series.
> We do need read-only controls for userspace to know that offload is
> possible and which card/device to use. That can be done in a first step
> assuming there's a single device plugged-in.
I agree, some kcontrol need to be present to at least determine:
1. USB SND device is offload capable (ASoC card and PCM index)- Fetches associated (mapped) ASoC platform card and PCM index (read only)
2. ASoC platform card offload status - Current offload status (read only)
Those would be the minimum kcontrols we could have at this time. I will remove the device selection part, and leave that for future discussions. Does this sound good, Amadeusz/Pierre?
> Dealing with multiple devices and defining rules or configuration
> options to select the offloaded device is a second-level problem.
>
> In most cases the only thing that will be offloaded is a headset
> anyways, so the selection could be rather static based on a
> vendor/system ID, all other USB devices would be ignored.
If the USB SND offload driver (ie qc_audio_offload) isn't compiled in, then it would be disabled. Do we need some over-arching mechanism to disable the offload functionality? Although, one thing I can see if I can add is some device classification within the USB offload vendor driver.
Thanks
Wesley Cheng
Powered by blists - more mailing lists