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

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

 



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.



[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