lkml.org 
[lkml]   [2020]   [Feb]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 8/8] ASoC: qcom: apq8096: add kcontrols to set PCM rate
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.

\
 
 \ /
  Last update: 2020-02-10 22:14    [W:0.082 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site