Re: [PATCH v2 0/2] ASoC: qcom: q6dsp-lpass-ports: Expand sampling rate and PCM format constraints

["Alexey Klimov" <alexey.klimov@linaro.org>]

On Wed Dec 17, 2025 at 12:56 PM GMT, Srinivas Kandagatla wrote:
>
>
> On 12/17/25 11:38 AM, Alexey Klimov wrote:
>> On Mon Dec 15, 2025 at 7:29 AM GMT, Ravi Hothi wrote:
>>>
>>>
>>> On 12/10/2025 7:26 PM, Alexey Klimov wrote:
>>>> On Wed Dec 10, 2025 at 6:51 AM GMT, Ravi Hothi wrote:
>>>>> This patch series expands the existing constraints in
>>>>> the q6dsp-lpass-ports driver to improve compatibility
>>>>> and flexibility for audio stream configurations.
>>>>>
>>>>> The first patch extends the supported sampling rates to cover a wider
>>>>> range, from 8000 Hz to 192000 Hz, ensuring better compatibility with
>>>>> diverse audio hardware and allowing more flexible audio stream setups.
>>>>>
>>>>> The second patch adds support for the 32-bit PCM format
>>>>> (SNDRV_PCM_FMTBIT_S32_LE) alongside the existing 16-bit
>>>>> and 24-bit formats, enabling handling of high-resolution
>>>>> audio streams and improving audio quality for supported hardware.
>>>>
>>>> Is q6dsp-lpass-ports involved in compress offloaded playback on
>>>> existing devices? If yes, then how is it gonna play with
>>>> explicitly setting format/sampling rate to s16le/48k in sndcards drivers?
>
> be_hw_params_fixup callback in machine drivers can select any format
> that fits the usecase. currently this is hardcoded for s16le samples and
> 48K rate, but its not limited to this. This patch is expanding the
> allowed range in the dais so that machine drivers should be able to
> select other options, ex: for HDMI its better to be at S24LE or S32LE.

Yes. Exactly.
So, should we add kcontrols to machine driver to handle these usecases like
selecting s24le instead of s16le? Or what's the plan?

>>> Support for s16le/48k is already available; these patch will expand the 
>>> existing constraint so that customers can use a wider range.
>> 
>> Unfortunately, you didn't answer any of my questions or answered
>> a different one.
>> 
>> Perhaps the main one: is q6dsp-lpass-ports involved in compress offloaded
>> playback on existing devices?
>
> lpass-ports are the Backend DAI ports, So yes, they will be involved in
> all the usecases that deal with handling sinks or sources irrespective
> of pcm or compressed content.

Thanks,
Alexey