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