On 03/08/18 17:36, Mark Brown wrote:
On Fri, Aug 03, 2018 at 01:57:05PM +0100, Jon Hunter wrote:
For soundcards that have several DAI links and many DAPM widgets the time taken for snd_soc_suspend to execute has been observed to be several milliseconds. The time is largely spent executing dapm_power_widgets() for each for the DAI links that need to be suspended. Given that dapm_power_widgets() is called again after suspending/resuming the DAI links, one way to optimise the suspend/resume time is to avoid calling dapm_power_widgets() for each DAI link and reduces the suspend time significantly.
It's a bit alarming that dapm_power_widgets() is taking substantial enough time to be worth worring about - it's *supposed* to be relatively well optimized so it's effectively free. It'll never be quite free, but close enough. The goal is that if nothing changes we end up testing a few nodes at most before we figure out that nothing changed state and stop. Do you have any idea what it's spending its time on, we do call it a lot so if there's any optimization opportunties there we can probably get a lot of benefit out of them.
Sorry for the delay, I was out last week.
I had taken some ftrace graphs but there was not one thing that really stood out. Looking again it seems that each call to async_schedule_domain() can take tens of uS and so it there are a lot of DAPM widgets (100+) this can take some time. I will dig into it a bit further.
One thing that it occurs to me might help is to start the suspend process by powering down all the input and output widgets that aren't ignoring suspend in one operation, that should hopefully have the effect of ensuring that most of the system that's going to get powered down does so on the first pass through.
If the async_schedule_domain() calls are the problem, then it may not help as we call that for all dapms apart from the card->dapm.
Please note that this has been observed on the Tegra210 Jetson TX1 platform which is not currently supported in the mainline for audio but has been tested with out-of-tree patches to enable I2S audio.
If someone could get the platform booting reliably in -next that'd be good but that's a separate issue...
Yes I plan to work on that in the next few months.
In the resume path, it is not clear if there could be any issues from not sync'ing the DAPM power state until after unmuting and resuming the CPU DAI drivers, because this will happen later with this change.
This is a definite problem, we want to have the audio path powered up before we start playing audio otherwise we loose the start of the audio which may be important.
I was thinking I could add another call to snd_soc_dapm_sync() after resuming the streams to address that. However, maybe I need to dig into this a bit more to understand exactly why dapm_power_widgets() takes so long.
Cheers Jon