On Fri, Nov 13, 2009 at 10:56:13PM +0800, Barry Song wrote:
This patch is to solve a completely different problem with the last one I sent. Its meaning is very simple actually. While
No, I get that it's fixing a different problem but it's in a similar areas and similar issues apply. Like I say, tweaking the ordering of suspend and resume will actually fix the TDM problem anyway.
card->instantiated is not 1, it means the card(cpu dai/codec dai and related stuff) and the whole links are not built successfully at all. So devices are not even initialized at all. And the audio system doesn't start to work. Since so, suspend/resume should be not needed for the whole system.
That's not the case unfortunately - some or all of the devices may have initialised themselves prior to registering with the SoC core and will be expecting the SoC core to give them a callback so that they can suspend and resume. At the minute there's basically an assumption that the card is going to come up completely and all we're doing here is avoiding race conditions during startup (which is realistic for production systems, partially constructed cards aren't likely there without broken hardware).
With pm_link we'll be able to move some or all of this ordering stuff out of the ASoC core and into the device model which will allow things to happen either way without two code paths.