[alsa-devel] [PATCH v5 2/2] ASoC: Add support for Conexant CX2092X DSP

[Simon Ho]

On Fri, Apr 07, 2017 at 12:37:37PM +0100, Mark Brown wrote:
> On Thu, Apr 06, 2017 at 11:04:34AM +0800, simon.ho.cnxt at gmail.com wrote:
> > From: Simon Ho <simon.ho at conexant.com>
> > 
> > Initial commit of Conexant CX20921/CX20924 I2S Audio DSP driver
> > 
> > The CX2092X devices are designed for virtual assisant application need to
> > be always open, listening for users to summon it. There is no any power
> > saving mode support on this device. The processed voice data will be sent
> > to automatic speech recognition (ASR) application for further processing.

> 
> This is still fundamentally just passing undocumented commands straight
> through to the device (presumably to a firmware flashed onto the device
> since there's not even a firmware download happening) without any
> substantial integration with the rest of the system.  That still doesn't
> really feel like a Linux driver at all, it seems more like it's just
> punching a hole through the Linux driver stack for proprietary software
> to do its thing.  I'm also not clear how this can even implement always
> on speech recognition, there seems to be no interrupt support which I'd
> have thought would be a requirement.
> 

Thanks for review and Yes, there is a SPI memory for firmware and 
platform-specific configuration. The device can load and apply 
confguration automatically upon device is power on. No configuration 
is needed from driver side.

The purpose of the tunnel interface are for debugng and tunning purpose.
The manufactor can use the them to customized the firmware to suit their
needs. furtherore, the commands are platform specific and also firmware
version specific. So that it is impossible to provide such commands in 
kernel unless we change our firmware design and policy.

The device have GPIO pin can be configured as interrupt out pin, this 
feaures is option, not a must for SR application actually. In addition,
I think the interrupt is platfrom-specpfic should be configured by 
Machine driver, am I right? 

> There are other vendors with voice processing features, the drivers for
> all these devices should be presenting interfaces that look similar to
> each other.  What those drivers doing treaming the speech data to the
> host via a normal PCM which blocks while there's no speech data, that is
> much better integrated than this.
> 
> You really need to address this, a big part of how Linux has got to
> where it is today is that it doesn't just have custom interfaces for
> each device but instead generalizes things so that we share good
> practice and features between devices and users can write Linux
> applications rather than vendor specific applications.

Just like DMic, I imagine. The DMIC is not configurable, but it still
requires a driver to communicate with the reset of the system. This
won't prevent people from developing the application for DMIC to extend
its functionality. 

The device send the normal PCM data to host as it claimed by codec
driver, and we confirmed that the device can work with most SR 
software without problem.