[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cb864ea4-95e3-4e99-920d-341188006291@linux.intel.com>
Date: Tue, 7 May 2024 16:40:42 -0500
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Wesley Cheng <quic_wcheng@...cinc.com>, srinivas.kandagatla@...aro.org,
mathias.nyman@...el.com, perex@...ex.cz, conor+dt@...nel.org,
corbet@....net, lgirdwood@...il.com, andersson@...nel.org,
krzk+dt@...nel.org, gregkh@...uxfoundation.org, Thinh.Nguyen@...opsys.com,
broonie@...nel.org, bgoswami@...cinc.com, tiwai@...e.com,
bagasdotme@...il.com, robh@...nel.org, konrad.dybcio@...aro.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 v21 38/39] ASoC: qcom: Populate SoC components string
On 5/7/24 14:51, Wesley Cheng wrote:
> For userspace to know about certain capabilities of the current platform
> card, add tags to the components string that it can use to enable support
> for that audio path. In case of USB offloading, the "usboffldplybk: 1" tag
usboffloadplayback?
same question as before, do we need spaces?
And if we have controls, why do we need component strings? The component
string is not dynamic to the best of my knowledge, this could be
problematic if the card is no longer capable of supporting this stream,
while a control can be updated at will.
Powered by blists - more mailing lists