Re: [PATCH v2 8/8] ASoC: qcom: apq8096: add kcontrols to set PCM rate

From: Adam Serbinski <adam@serbinski.com>
To: Mark Brown <broonie@kernel.org>
Cc: Srini Kandagatla <srinivas.kandagatla@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Patrick Lai <plai@codeaurora.org>,
	Banajit Goswami <bgoswami@codeaurora.org>,
	Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
	alsa-devel@alsa-project.org, linux-arm-msm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 8/8] ASoC: qcom: apq8096: add kcontrols to set PCM rate
Date: Mon, 10 Feb 2020 16:13:52 -0500	[thread overview]
Message-ID: <7c57801d8f671c40d4c6094e5ce89681@serbinski.com> (raw)
In-Reply-To: <20200210200839.GG14166@sirena.org.uk>

On 2020-02-10 15:08, Mark Brown wrote:
> On Mon, Feb 10, 2020 at 03:00:55PM -0500, Adam Serbinski wrote:
>> On 2020-02-10 13:26, Mark Brown wrote:
> 
>> > To repeat my comment on another patch in the series there should still
>> > be some representation of the DAI for this device in the kernel.
> 
>> Respectfully, I'm not sure I understand what it is that you are 
>> suggesting.
> 
>> Is it your intention to suggest that instead of adding controls to the
>> machine driver, I should instead write a codec driver to contain those
>> controls?
> 
> I have already separately said that you should write a CODEC driver for
> this CODEC.  I'm saying that this seems like the sort of thing that
> might fit in that CODEC driver.

I see. My initial thought with respect to the codec driver would be just 
to use bt-sco.c, which is a dummy codec. I can certainly implement a new 
codec driver.

>> Or is it your intention to suggest that something within the kernel is
>> already aware of the rate to be set, and it is that which should set 
>> the
>> rate rather than a control?
> 
> That would be one example of how such a CODEC driver could be
> configured, and is how other baseband/BT devices have ended up going
> (see cx20442.c for example).

I am not aware of how this could be done for bluetooth, since the value 
still has to originate from userspace. The driver you referred to 
supports only a single sample rate, whereas for bluetooth, 2 sample 
rates are required, and nothing in the kernel is aware of the 
appropriate rate, at least in the case of the qca6174a I'm working with 
right now, or for that matter, TI Wilink 8, which I've also worked with.

My concern with implementing this in a new codec driver, is that this 
codec driver will be bound to qdsp6, since its purpose is to work around 
a characteristic of this DSP. Under simple-card, for instance, it would 
be redundant, since in that case, the parameters userspace uses to open 
the pcm will be propagated to the port. But under qdsp6, userspace could 
open the pcm at 44.1 kHz, yet the backend port is still set to 8 or 16 
kHz, and the DSP resamples between them, so the sole purpose of this 
change is to allow userspace to deliver the required sample rate to the 
back end of qdsp6.