-----Original Message----- From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- owner@vger.kernel.org] On Behalf Of Jarkko Nikula Sent: Saturday, November 14, 2009 1:50 PM To: Wang, Jane Cc: alsa-devel@alsa-project.org; linux-omap@vger.kernel.org; peter.ujfalusi@nokia.com; broonie@opensource.wolfsonmicro.com Subject: Re: [PATCH 1/2] OMAP3: MCBSP: Suspend/resume failure fix
Hi
On Fri, 13 Nov 2009 11:39:47 -0600 Jane Wang jwang@ti.com wrote:
McBSP fucntional clock is not disabled when suspend is triggerd which prevents PER domain entering target low-power state. To fix the problem:
Disable/enable McBSP functional clock for suspend/resume.
In addition, reconfigure McBSP, this is needed when systerm comes out
of OFF state.
...
--- a/arch/arm/plat-omap/include/mach/mcbsp.h +++ b/arch/arm/plat-omap/include/mach/mcbsp.h @@ -440,6 +440,8 @@ static inline int
omap_mcbsp_get_dma_op_mode(unsigned int id) { return 0; }
#endif int omap_mcbsp_request(unsigned int id); void omap_mcbsp_free(unsigned int id); +void omap_mcbsp_disable_fclk(unsigned int id); +void omap_mcbsp_enable_fclk(unsigned int id);
...
--- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -229,18 +229,28 @@ static int omap_mcbsp_dai_trigger(struct
snd_pcm_substream *substream, int cmd,
switch (cmd) { case SNDRV_PCM_TRIGGER_START:
- case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: mcbsp_data->active++; omap_mcbsp_start(mcbsp_data->bus_id, play, !play); break;
- case SNDRV_PCM_TRIGGER_RESUME:
mcbsp_data->active++;omap_mcbsp_enable_fclk(mcbsp_data->bus_id);omap_mcbsp_config(mcbsp_data->bus_id,&mcbsp_data->regs);omap_mcbsp_start(mcbsp_data->bus_id, play, !play);break;For me this looks more like a simple workaround for the audio case than comprehensive implementation to McBSP OFF mode context save/restore. My thoughts:
- McBSP clock management partially moved out of low-level driver
- McBSP client must do the context restore
I do know that arch/arm/plat-omap/mcbsp.c enables the clocks in omap_mcbsp_request, I don't know do some API or feature there really require clocks (or McBSP itself) to be active just after the request time but I would look that path instead (even it is more complicated).
If no API or feature would require active McBSP block before the omap_mcbsp_start call, then the clock management could be done inside the omap_mcbsp_start/-stop functions.
[Aggarwal, Anuj] I tried doing that but it didn't work because before _start, we need to call set_hw_params which configures mcbsp, for which clocks are required.
Also context save/restore operations belongs more to PM callbacks of .../plat-omap/mcbsp.c. Or probably that can be done also dynamically inside the omap_mcbsp_start/-stop for keeping the whole McBSP shutdown whenever it is idle.
[Aggarwal, Anuj] I am sorry I couldn't understand that. Did you mean that PM hooks can be added in the mcbsp driver which can be registered and called As and when required? Any reference driver for this, if my understanding is correct?
I think it's worth to look McBSP register cache concept [1] from Janusz Krzysztofik would it help all of this context save/restore operations.
[Aggarwal, Anuj] I tried these two patches on omap3 evm but they didn't work for me. The system doesn't go to the suspend state when I do: echo mem > /sys/power/state And the culprits were core (think sdma) and per domain. I tried disabling the mcbsp i/f clock as well but it didn't help. On mcbsp register dump, I couldn't find the sysconfig register getting configured. Could that be the root cause?
-- Jarkko
-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html