[alsa-devel] Audio:suspend to ram issue
Hi Mark I am not sure about the behavior in case of audio suspend/resume.
I tested the audio driver with aplay and then suspended to ram (using echo mem > /sys/power/state). After pressing wake to resume, the audio does not play unless aplay is closed and re-run. Do we expect the audio suspend/resume to work?
In the platform trigger part I am doing nothing and in case of cpu(i2s) , just disabling the i2s.
Best Regards Rajeev
Hello Mark In the continuation of the last mail.I run alsa_aplay and the WAV file sounds. Then press ctrl-z - aplay will go to background(suspend state) and i2s is stopped. Then type fg and the audio restart. Is there any difference between these two suspend ctrl-z and echo mem > /sys/power/state. In both the cases trigger will call with cmd value '1 ' in case of resume and '0' in case of suspend.
While going through the alsa framework I found that suspend and resume functionality is handled by the framework itself.Please correct me if my understanding is not correct.
Best Regards Rajeev
On 8/18/2011 11:35 AM, Rajeev kumar wrote:
Hi Mark I am not sure about the behavior in case of audio suspend/resume.
I tested the audio driver with aplay and then suspended to ram (using echo mem > /sys/power/state). After pressing wake to resume, the audio does not play unless aplay is closed and re-run. Do we expect the audio suspend/resume to work?
In the platform trigger part I am doing nothing and in case of cpu(i2s) , just disabling the i2s.
Best Regards Rajeev
On Thu, Aug 18, 2011 at 04:21:37PM +0530, Rajeev kumar wrote:
Is there any difference between these two suspend ctrl-z and echo mem > /sys/power/state.
Yes. For example in system suspend it is likely that some of the system power supplies will be disabled and low power states will be entered which cause register contents to be lost.
While going through the alsa framework I found that suspend and resume functionality is handled by the framework itself.Please correct me if my understanding is not correct.
DAPM will be taken care of but there is usually some other work required, if only restoring the register maps of devices. There are callbacks into the individual drivers in order to allow them to take whatever action is required to quiesce and restore the device.
Hello Marks Thanks for your reply
On 8/18/2011 9:55 PM, Mark Brown wrote:
On Thu, Aug 18, 2011 at 04:21:37PM +0530, Rajeev kumar wrote:
Is there any difference between these two suspend ctrl-z and echo mem> /sys/power/state.
Yes. For example in system suspend it is likely that some of the system power supplies will be disabled and low power states will be entered which cause register contents to be lost.
While going through the alsa framework I found that suspend and resume functionality is handled by the framework itself.Please correct me if my understanding is not correct.
DAPM will be taken care of but there is usually some other work required, if only restoring the register maps of devices. There are callbacks into the individual drivers in order to allow them to take whatever action is required to quiesce and restore the device.
[Rajeev]: Is it necessary to implement DAPM? When I checked the command value (cmd part ) in trigger function it is 1 (SNDRV_PCM_TRIGGER_START ) , in case system get resumes and an 0 (SNDRV_PCM_TRIGGER_STOP) in case system goes in suspend mode. In trigger start for cpu(i2s) i am enabling all the register value and in case of stop just clearing all the bit. Please find below the code for trigger function for platform and cpu part.
For i2s trigger ============ static int dw_i2s_trigger(struct snd_pcm_substream *substream, int cmd, struct snd_soc_dai *dai) { struct dw_i2s_dev *dev = snd_soc_dai_get_drvdata(dai); int ret = 0;
switch (cmd) { case SNDRV_PCM_TRIGGER_START: dev->active++; if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) i2s_start_play(dev, substream); else i2s_start_rec(dev, substream); case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: break;
case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_SUSPEND: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: i2s_stop(dev, substream); break; default: ret = -EINVAL; break; } return ret; }
For platform trigger ================= static int spear13xx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) { struct spear13xx_runtime_data *prtd = substream->runtime->private_data; int ret = 0;
switch (cmd) { case SNDRV_PCM_TRIGGER_START: prtd->frag_count = -1; tasklet_schedule(&prtd->tasklet); break; case SNDRV_PCM_TRIGGER_STOP: case SNDRV_PCM_TRIGGER_PAUSE_PUSH: case SNDRV_PCM_TRIGGER_SUSPEND: chan->device->device_control(chan, DMA_TERMINATE_ALL, 0); /* terminate all the DMA transfer */ break; case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: case SNDRV_PCM_TRIGGER_RESUME: break; default: ret = -EINVAL; } return ret; }
one more point I would like to mention that there is no any suspend/resume function I have implemented in the cpu driver as i thought this is handled by the framework itself.Am I correct?
Best Regards Rajeev
On Fri, 2011-08-19 at 09:53 +0530, Rajeev kumar wrote:
Is it necessary to implement DAPM?
It's only really relevant for CODEC drivers. For CODEC drivers it's essentially mandatory, for CPU drivers it's not relevant.
one more point I would like to mention that there is no any suspend/resume function I have implemented in the cpu driver as i thought this is handled by the framework itself.Am I correct?
I can only repeat what I said in my previous mail - if there are any steps required to quiesce the hardware for suspend or restore it from the lower power states entered on on suspend then these should be handled in suspend and resume methods. If your hardware does not require any actions outside what you're already doing and there's nothing extra for suspend and resume methods to implement then there's nothing to do. The framework doesn't know anything about your hardware or the particular requirements it has.
participants (2)
-
Mark Brown -
Rajeev kumar