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