Re: [PATCH v3 2/3] ASoC: soc-pcm: Indicate warning if CPU / Codec availability mismatch

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

On 5/20/24 20:15, Kuninori Morimoto wrote:
> 
> Hi Pierre-Louis, Mark
> 
>> We cannot change the Maxim amplifier driver, it's used in a variety of
>> usages and platforms, and there's no reason to create a fake capture dai
>> just to reflect the use of a capture stream on the CPU side on some
>> Chromebooks.
> 
> Why cannot ??
> There is no effect to user if Maxim driver has full channel setting same as
> dammy DAI. It will be handled together with CPU, and system gets CPU
> channels as-is.

That would be changing the meaning and purpose of a 'dummy dai'

A 'dummy dai' has historically been used when data was
transmitted/received but the control of that DAI was done externally
with a sideband interface.

Here there is just no hardware for capture in the Maxim amp.

Adding a pretend DAI for the sake of adding a stricter 'sanity check'
does not sound good to me.

>> I don't disagree that the unconditional use of dpcm_capture isn't very
>> elegant, but it is what it is. This platform has been around since 2019
>> and still has about 6 or 7 years of support, so we can't break it with
>> stricter criteria.
> 
> My opinion is that working without channels settings is wrong.
> I can understand that it was working in long years, but it is working with
> wrong settings. So justify a wrong-settings is not good idea for me.
> And I don't think it is stricter criteria, it becomes *sane* criteria, IMO.
> 
> Because it was working with wrong-settings, we need to makes it sane.
> This is the reason why it has grace time.

allow me to give you another counter example, beyond the AEC reference I
mentioned earlier. It's not uncommon for CPU DAIs to have loopback
capabilities, which are used for tests on boards where the codec has no
capture capabilities. I think it's a feature that needs to be allowed,
not a 'wrong setting'.