Re: [PATCH v5 2/2] ASoC: Add support for Conexant CX2092X DSP

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2301 bytes --]

On Tue, Apr 11, 2017 at 03:43:40AM +0800, Simon Ho wrote:

> 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.

Changing that policy does sound like a good idea...  in any case if this
genuinely is just for tuning then I'd suggest removing this from your
initial submission and adding it as a separate patch so as not to slow
down the review of the bit that's used in production systems.

> 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? 

No, I'd not expect the machine driver to need to get involved for basic
interrupt functionality - look at how other drivers do interrupts.

> > 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. 

Some components are indeed very simple but they still require
integration with the rest of the system.

> 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.  

Could you please explain how this device works and integrates in the
system, I'm completely at a loss as to how this is supposed to work.
You appear to be saying that the device simply passes through audio and
provides no information to the rest of the system.  That makes it
unclear what function the device is performing.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]