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@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel