On Friday 30 April 2010 13:23:10 ext Mark Brown wrote: > On Fri, Apr 30, 2010 at 01:10:14PM +0300, Peter Ujfalusi wrote: > > On Friday 30 April 2010 12:56:37 ext Mark Brown wrote: > > > Then just use > > > the hooks in the normal audio stream bringup/teardown surely? It's > > > possible that I'm missing something as a result of your list of use > > > cases but I'd expect this to flow fairly naturally from the normal call > > > flow. > > > > The thing is, that I want to handle the chip power in one place, and > > dac33_set_bias_level is a really good place for that. > > Sure, but it shouldn't need to be worrying about playback at all. Valid point ;) > > > At the time when pcm_prepare is called the codec is still in OFF. > > So I just postponed the dac33_prepare_chip call for later, when the codec > > switches BIAS level. > > Than I enable the power and if there is a stream, than I do the > > preparation. Note: the BIAS level change is still within the pcm_prepare > > call chain... > > Surely a much more straightforward solution to this is just to add a > post-DAPM prepare() callback to the DAI ops? It seems like a perfectly > reasonable thing to have that callback and it means you can rely on the > existing mechanisms having taken care of the power for you. Hmm, right... Well. This is not going to work, I think. I need to keep the dac33_pcm_prepare level of configuration for cases, when the codec is in ON and a playback is starting (and if the codec is not ON, than respond it for later, when it is switch on), right? I _need_ to do the things, which is done in the dac33_prepare_chip function every time, when a stream is starting :( Now, if I use DAPM_SUPPLY attached to the DAC: If the codec has been brought up because the loopback is enabled, than the dac33_prepare_chip will be called twice: once from dac33_pcm_prepare, and then from the SUPPLY event. This might be also the case if I use the post-DAPM prepare (or pre) I do agree, that it is not really nice to have playback related thing in the dac33_set_bias_level, but so far I think that is the only way to avoid additional hassle (which means more places to have error, problems). > > > In this way I don't need to do any additional housekeeping while managing > > the power of the codec. > > My point here is that it seems like you need to do more housekeeping > than you should :) HeHe :) My problem with that, is the additional house keeping needs more code, which usually means more place, where some corner case is not handled correctly. Well, more code == more place for bugs ;) > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- Péter _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
