On Sat, Nov 14, 2009 at 1:04 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Nov 13, 2009 at 11:29:39PM +0800, Barry Song wrote:
The logic seems different: in snd_soc_instantiate_card(), only while all cpu DAIs and codec DAIs are found and registered in the system except ac97, their probes will be called. Then card->instantiated becomes 1. A case current codes will cause crash is: For a CPU DAI driver based on platform driver, if arch hasn't defined the platform device for cpu dai, then cpu dai is not registered and initialized in the probe() of its platform driver. Even though its instance is in card->dai_link, it doesn't really enter the system. But while suspend/resume, its entries will be called too since the call doesn't check the existence:
Yes, that can go wrong - but as I say the converse thing can also go wrong where some but not all of the card has managed to register and the bits that have managed to register expect to be suspended by the core.
I think suspend/resume of a DAI can only be called while it really exists and can be found in the dai_list, at least.
Checking to see if the device is in the DAI relevant list would work but...
So I add a overall condition for soc_suspend/resume just like if (!card->instantiated) return 0 has be done in soc_remove(), soc_poweroff().
...this is too broad.
Then do you think it is workable to find the dai in dai_list before calling its suspend/resume? My original plan was checking the existence of DAI in dai_list, if DAI doesn't exist, don't call its PM entries. Then I found card->instantiated, I moved to check it. If you have better plan for fixing this problem, I can wait and keep this fix locally.