On Thu, Nov 23, 2017 at 10:41:33AM +0100, Ricard Wanderlof wrote:
On Wed, 22 Nov 2017, Mark Brown wrote:
On Wed, Nov 22, 2017 at 01:33:37PM +0100, Ricard Wanderlof wrote:
Always CC maintainers on postings if you want them to be reliably seen...
Ok. I thought it was more of a general question than a maintainer question but I'll keep it in mind in future.
If you don't copy any actual people the chances of getting a response are vastly reduced.
The CODEC driver is broken, it shouldn't be powering off on idle if it takes a second to ramp, it should be leaving VMID up while the system is running - this is what the _STANDBY bias level is all about. Look at what older CODEC drivers like the wm8731 do.
It actually does leave VMID on as soon as the codec is not at the _OFF level, the problem is really that the output buffer is not enabled until a playback stream is set up, and its not until the output buffer is enabled that the output attains its operating level.
Of course, one solution would be to change the driver to enable the output already at the _STANDBY level. It does seem to me that that would violate part of the whole point of DAPM, on the other hand, I would think that at some point power management must take a second seat to actually getting a good user experience.
Yes, you'll need to do something like leave the outputs enabled. Most devices have some facility to keep VMID switched to the outputs, though I did see a few where someone thought it was a good idea to power on from cold always. A device that old isn't going to be that competitive power wise anyway even if it were well implemented which this one seems to not have been.
This is why we've got the digital_mute() callback - the idea is that the output is just going to be discarded until the interface has had a chance to settle down.
The problems we've had have been on the CPU side, with I2S interfaces that have problems synchronizing to an ongoing I2S stream when the CPU AIF is
That's what the digital mute handling is for - we're just throwing away any garbage the CPU puts out before it's stable. We're not expecting it to work around any CODEC side issues.
in slave mode, to the extent that in some cases its impossible to determine if the first sample received by or sent from the I2S interface is the left or right channel. If the DAIs had been set up once and been allowed to run continuously even when there is no actual audio to transfer, it would have helped this situation. Agreed, I'd rather have a DAI that worked properly, but sometimes one doesn't have that luxery. :-(
If you're getting L/R swap issues on some startups leaving things enabled all the time will mean that your random swap issue gets moved to boot.