On Sat, Nov 14, 2009 at 1:04 AM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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. > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
