> > > I want to check the status of suspend/resume functionality when audio > > > subsystem is being used. Specifically, has some one tried the > following > > > tests on their omap3 based platforms: > > > > > > a) echo mem > /sys/power/state, when audio playback is running in > > > background > > > b) same command, when audio capture is running in > > > background > > > b) same command, when audio loopback is running in > > > background > > > > > > I am facing some issues with (b) & (c) so wanted to confirm whether > > > someone else has faced similar problem or not. > > > > As Jarkko pointed out in a separate mail, we should not expect the > > suspend/resume to be working correctly until the context save/restore, > and > > the > > clock management is sorted out. > > > > On the other hand it seams that the problem is in the capture path (b > and > > c > > having issues). > > > > How is the McBSP configured in your setup (master or slave)? > [Aggarwal, Anuj] TWL4030 is master and McBSP is slave. > > > I think we might have different issues with suspend/resume when OMAP > McBSP > > is > > slave or if it is master. Few (+)updates from my side:
a) Capture not working after suspend/resume: After taking a dump of mcbsp, DMA and codec registers and comparing them, I found out that DMA.CCR[Enable] and DMA.CSR[Sync] bits were set when system was coming out of suspend. I don't understand why these two bits are not set in case of playback running in backgnd but when I forcefully clear them in omap_pcm_trigger() fn under SNDRV_PCM_TRIGGER_RESUME, my problem goes away. Now I am able to do suspend/resume successfully while capture is running in bg without getting the Input/output error. b) McBSP registers being accessed from omap_pcm_trigger(): When audio playback is running in background and I try suspend, I saw mcbsp registers getting read/written by omap_pcm_trigger() through dma_data->set_threshold(). This happens when soc_pcm_trigger() calls platform->pcm_ops->trigger before cpu_dai->ops->trigger and the clocks are getting enabled only in cpu_dai->trigger. Because of this, I found one warning coming through but this needs a fix. c) System hangs when audio loopback is going on in background: Finally, I was able to narrow down the problem. After the mcbsp clocks are cut for playback stream, when suspend gets called for capture, mcbsp is stopped inside omap_mcbsp_dai_trigger->SNDRV_PCM_TRIGGER_PAUSE_PUSH, before disabling the clocks. This resulted in hang and the system doesn't come out of snd_pcm_suspend_all() which I reported in my previous email. I modified the clock disabling routine and averted the hang. Now the problem is with the mcbsp/DMA configuration as I am not able to resume the loopback fully (1 in 5 times only it works) and receive this error: ALSA sound/core/pcm_lib.c:1708: playback write error (DMA or IRQ trouble?) After this, the application exits gracefully. On further debugging, I realized that mcbsp is not getting configured properly on either the playback or capture stream, while resuming. Hence the error. I think this problem can go if I apply the mcbsp-register-cache patches but I have to try that before I can come to a conclusion. I have (dirty) fixes for (a) and (b) which, on cleaning, I would be sending for reviews. Thanks for the suggestions/pointers. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
