[alsa-devel] [PATCH] ASoC: omap-mcbsp: When closing the port select PRCM source for CLKS signal
If external source for the CLKS signal selection kept after the port is no longer in use the system might refuse to go suspend. There is also a chance that the external clock is not running when next time the McBSP port is started which can result errors when we try to access McBSP registers. Reset the CLKS source back to PRCM source unconditionally.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com --- sound/soc/omap/mcbsp.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index d716793..21dbb05 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -548,6 +548,16 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp)
reg_cache = mcbsp->reg_cache;
+ /* + * Select CLKS source from internal source unconditionally before + * marking the McBSP port as free. + * If the external clock source via MCBSP_CLKS pin has been selected the + * system will refuse to enter idle if the CLKS pin source is not reset + * back to internal source. + */ + if (!cpu_class_is_omap1()) + omap2_mcbsp_set_clks_src(mcbsp, MCBSP_CLKS_PRCM_SRC); + spin_lock(&mcbsp->lock); if (mcbsp->free) dev_err(mcbsp->dev, "McBSP%d was not reserved\n", mcbsp->id);
On Mon, Mar 05, 2012 at 11:38:52AM +0200, Peter Ujfalusi wrote:
If external source for the CLKS signal selection kept after the port is no longer in use the system might refuse to go suspend. There is also a chance that the external clock is not running when next time the McBSP port is started which can result errors when we try to access McBSP registers. Reset the CLKS source back to PRCM source unconditionally.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
though it'd be better if the driver could remember and restore the setting when the device becomes active again so that machine drivers don't need to.
On 03/05/2012 01:58 PM, Mark Brown wrote:
though it'd be better if the driver could remember and restore the setting when the device becomes active again so that machine drivers don't need to.
Yes, this is my long term plan regarding to the clock selection. With this patch the omap3pandora can suspend after audio activity.
On Mon, Mar 5, 2012 at 11:38 AM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
If external source for the CLKS signal selection kept after the port is no longer in use the system might refuse to go suspend. There is also a chance that the external clock is not running when next time the McBSP port is started which can result errors when we try to access McBSP registers. Reset the CLKS source back to PRCM source unconditionally.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
I guess this depends on mcbsp move series? Do we have those queued somewhere, so I don't have to collect patches from the list?
On 03/05/2012 02:51 PM, Grazvydas Ignotas wrote:
I guess this depends on mcbsp move series?
Yes.
Do we have those queued somewhere, so I don't have to collect patches from the list?
It is not queued as of now since it has dependency on some other patches. I expect it will be in Liam's for-3.4 in a coming days.
Hi,
On 03/05/2012 02:51 PM, Grazvydas Ignotas wrote:
I guess this depends on mcbsp move series? Do we have those queued somewhere, so I don't have to collect patches from the list?
You can apply this patch on top of my for-3.4 branch which I have just updated on top of Liam's for-3.4 branch:
git@gitorious.org:omap-audio/linux-audio.git peter/topic/for-3.4
On Tue, 2012-03-06 at 14:54 +0200, Peter Ujfalusi wrote:
Hi,
On 03/05/2012 02:51 PM, Grazvydas Ignotas wrote:
I guess this depends on mcbsp move series? Do we have those queued somewhere, so I don't have to collect patches from the list?
You can apply this patch on top of my for-3.4 branch which I have just updated on top of Liam's for-3.4 branch:
git@gitorious.org:omap-audio/linux-audio.git peter/topic/for-3.4
I've now applied these patches on top of my for-3.4.
Regards
Liam
On Tue, Mar 6, 2012 at 4:44 PM, Liam Girdwood lrg@ti.com wrote:
I've now applied these patches on top of my for-3.4.
I pulled these on top of today's linux-next and it doesn't build as a module:
Building modules, stage 2. MODPOST 36 modules ERROR: "omap_mcbsp_start" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_get_tx_delay" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_st_disable" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_init" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_st_set_chgain" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_set_rx_threshold" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_st_get_chgain" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_free" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap2_mcbsp_set_clks_src" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_st_is_enabled" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_stop" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap2_mcbsp1_mux_fsr_src" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_request" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap2_mcbsp1_mux_clkr_src" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_config" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_get_rx_delay" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_set_tx_threshold" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_mcbsp_sysfs_remove" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined! ERROR: "omap_st_enable" [sound/soc/omap/snd-soc-omap-mcbsp.ko] undefined!
Hi,
On Thu, Mar 8, 2012 at 4:00 PM, Grazvydas Ignotas notasas@gmail.com wrote:
On Tue, Mar 6, 2012 at 4:44 PM, Liam Girdwood lrg@ti.com wrote:
I've now applied these patches on top of my for-3.4.
I pulled these on top of today's linux-next and it doesn't build as a module:
Opps. I have not tried it as a module... There seams to be an issue with the Kconfig/Makefile change. Thanks for reporting it, I'll fix it.
On Mon, Mar 5, 2012 at 11:38 AM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
If external source for the CLKS signal selection kept after the port is no longer in use the system might refuse to go suspend. There is also a chance that the external clock is not running when next time the McBSP port is started which can result errors when we try to access McBSP registers. Reset the CLKS source back to PRCM source unconditionally.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@ti.com
Tested-by: Grazvydas Ignotas notasas@gmail.com
sound/soc/omap/mcbsp.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index d716793..21dbb05 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -548,6 +548,16 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp)
reg_cache = mcbsp->reg_cache;
- /*
- * Select CLKS source from internal source unconditionally before
- * marking the McBSP port as free.
- * If the external clock source via MCBSP_CLKS pin has been selected the
- * system will refuse to enter idle if the CLKS pin source is not reset
- * back to internal source.
- */
- if (!cpu_class_is_omap1())
- omap2_mcbsp_set_clks_src(mcbsp, MCBSP_CLKS_PRCM_SRC);
spin_lock(&mcbsp->lock); if (mcbsp->free) dev_err(mcbsp->dev, "McBSP%d was not reserved\n", mcbsp->id); -- 1.7.8.5
participants (5)
-
Grazvydas Ignotas -
Liam Girdwood -
Mark Brown -
Peter Ujfalusi -
Ujfalusi, Peter