[alsa-devel] [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Based on the original patch by Tony Lindgren Link: https://patchwork.kernel.org/patch/9305867/
Cc: Tony Lindgren tony@atomide.com Cc: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Matt Ranostay matt@ranostay.consulting --- Changes from v1: * add calculations for latency per number of FIFO locations
Changes from v2: * add missing mcbsp.h header change
Changes from v3: * base the latency calculations on threshold, buffer size, sample rate, and channels
Changes from v4: * using Peter Ujfalusi's suggestions for restoring a higher latency on audio stream completion, or if not applicable remove the QoS request
sound/soc/omap/mcbsp.c | 37 +++++++++++++++++++++++++++++++++++++ sound/soc/omap/mcbsp.h | 3 +++ sound/soc/omap/omap-mcbsp.c | 11 ++++++++++- 3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 06fec5699cc8..f079650b71e3 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -25,6 +25,7 @@ #include <linux/io.h> #include <linux/slab.h> #include <linux/pm_runtime.h> +#include <linux/pm_qos.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
@@ -640,9 +641,28 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp) */ void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx) { + struct pm_qos_request *pm_qos_req = &mcbsp->pm_qos_req; + int stream1 = tx ? SNDRV_PCM_STREAM_PLAYBACK : SNDRV_PCM_STREAM_CAPTURE; + int stream2 = tx ? SNDRV_PCM_STREAM_CAPTURE : SNDRV_PCM_STREAM_PLAYBACK; int enable_srg = 0; + int latency; u16 w;
+ /* Prevent omap hardware from hitting off between FIFO fills */ + if (!mcbsp->latency[stream2] || + mcbsp->latency[stream1] < mcbsp->latency[stream2]) + latency = mcbsp->latency[stream1]; + else + latency = mcbsp->latency[stream2]; + + if (latency) { + if (pm_qos_request_active(pm_qos_req)) + pm_qos_update_request(pm_qos_req, latency); + else + pm_qos_add_request(pm_qos_req, PM_QOS_CPU_DMA_LATENCY, + latency); + } + if (mcbsp->st_data) omap_st_start(mcbsp);
@@ -731,6 +751,20 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx, int rx)
if (mcbsp->st_data) omap_st_stop(mcbsp); + + if (pm_qos_request_active(&mcbsp->pm_qos_req)) { + int stream1 = tx ? SNDRV_PCM_STREAM_PLAYBACK : + SNDRV_PCM_STREAM_CAPTURE; + int stream2 = tx ? SNDRV_PCM_STREAM_CAPTURE : + SNDRV_PCM_STREAM_PLAYBACK; + + mcbsp->latency[stream1] = 0; + if (mcbsp->latency[stream2]) + pm_qos_update_request(&mcbsp->pm_qos_req, + mcbsp->latency[stream2]); + else + pm_qos_remove_request(&mcbsp->pm_qos_req); + } }
int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id) @@ -1098,6 +1132,9 @@ int omap_mcbsp_init(struct platform_device *pdev)
void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp) { + if (pm_qos_request_active(&mcbsp->pm_qos_req)) + pm_qos_remove_request(&mcbsp->pm_qos_req); + if (mcbsp->pdata->buffer_size) sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h index 61e93b1c185d..46ae1269a698 100644 --- a/sound/soc/omap/mcbsp.h +++ b/sound/soc/omap/mcbsp.h @@ -323,8 +323,11 @@ struct omap_mcbsp {
unsigned int fmt; unsigned int in_freq; + unsigned int latency[2]; int clk_div; int wlen; + + struct pm_qos_request pm_qos_req; };
void omap_mcbsp_config(struct omap_mcbsp *mcbsp, diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index d018e966e533..7e00938271c6 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -226,6 +226,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, int wlen, channels, wpf; int pkt_size = 0; unsigned int format, div, framesize, master; + unsigned int buffer_size = mcbsp->pdata->buffer_size;
dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); channels = params_channels(params); @@ -240,7 +241,9 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, default: return -EINVAL; } - if (mcbsp->pdata->buffer_size) { + if (buffer_size) { + int latency; + if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { int period_words, max_thrsh; int divider = 0; @@ -271,6 +274,12 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, /* Use packet mode for non mono streams */ pkt_size = channels; } + + latency = ((((buffer_size - pkt_size) / channels) * 1000) + / (params->rate_num / params->rate_den)); + + mcbsp->latency[substream->stream] = latency; + omap_mcbsp_set_threshold(substream, pkt_size); }
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Based on the original patch by Tony Lindgren Link: https://patchwork.kernel.org/patch/9305867/
Cc: Tony Lindgren tony@atomide.com Cc: Peter Ujfalusi peter.ujfalusi@ti.com Signed-off-by: Matt Ranostay matt@ranostay.consulting
Changes from v1:
- add calculations for latency per number of FIFO locations
Changes from v2:
- add missing mcbsp.h header change
Changes from v3:
- base the latency calculations on threshold, buffer size, sample rate, and channels
Changes from v4:
- using Peter Ujfalusi's suggestions for restoring a higher latency on audio stream completion, or if not applicable remove the QoS request
sound/soc/omap/mcbsp.c | 37 +++++++++++++++++++++++++++++++++++++ sound/soc/omap/mcbsp.h | 3 +++ sound/soc/omap/omap-mcbsp.c | 11 ++++++++++- 3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c index 06fec5699cc8..f079650b71e3 100644 --- a/sound/soc/omap/mcbsp.c +++ b/sound/soc/omap/mcbsp.c @@ -25,6 +25,7 @@ #include <linux/io.h> #include <linux/slab.h> #include <linux/pm_runtime.h> +#include <linux/pm_qos.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
@@ -640,9 +641,28 @@ void omap_mcbsp_free(struct omap_mcbsp *mcbsp) */ void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx) {
struct pm_qos_request *pm_qos_req = &mcbsp->pm_qos_req;
int stream1 = tx ? SNDRV_PCM_STREAM_PLAYBACK : SNDRV_PCM_STREAM_CAPTURE;
int stream2 = tx ? SNDRV_PCM_STREAM_CAPTURE : SNDRV_PCM_STREAM_PLAYBACK; int enable_srg = 0;
int latency; u16 w;
/* Prevent omap hardware from hitting off between FIFO fills */
if (!mcbsp->latency[stream2] ||
mcbsp->latency[stream1] < mcbsp->latency[stream2])latency = mcbsp->latency[stream1];else
latency = mcbsp->latency[stream2];if (latency) {
if (pm_qos_request_active(pm_qos_req))pm_qos_update_request(pm_qos_req, latency);elsepm_qos_add_request(pm_qos_req, PM_QOS_CPU_DMA_LATENCY,latency);}
if (mcbsp->st_data) omap_st_start(mcbsp);
@@ -731,6 +751,20 @@ void omap_mcbsp_stop(struct omap_mcbsp *mcbsp, int tx, int rx)
if (mcbsp->st_data) omap_st_stop(mcbsp);
- if (pm_qos_request_active(&mcbsp->pm_qos_req)) {
int stream1 = tx ? SNDRV_PCM_STREAM_PLAYBACK :SNDRV_PCM_STREAM_CAPTURE;int stream2 = tx ? SNDRV_PCM_STREAM_CAPTURE :SNDRV_PCM_STREAM_PLAYBACK;mcbsp->latency[stream1] = 0;if (mcbsp->latency[stream2])pm_qos_update_request(&mcbsp->pm_qos_req,mcbsp->latency[stream2]);elsepm_qos_remove_request(&mcbsp->pm_qos_req);- }
}
int omap2_mcbsp_set_clks_src(struct omap_mcbsp *mcbsp, u8 fck_src_id) @@ -1098,6 +1132,9 @@ int omap_mcbsp_init(struct platform_device *pdev)
void omap_mcbsp_cleanup(struct omap_mcbsp *mcbsp) {
- if (pm_qos_request_active(&mcbsp->pm_qos_req))
pm_qos_remove_request(&mcbsp->pm_qos_req);- if (mcbsp->pdata->buffer_size) sysfs_remove_group(&mcbsp->dev->kobj, &additional_attr_group);
diff --git a/sound/soc/omap/mcbsp.h b/sound/soc/omap/mcbsp.h index 61e93b1c185d..46ae1269a698 100644 --- a/sound/soc/omap/mcbsp.h +++ b/sound/soc/omap/mcbsp.h @@ -323,8 +323,11 @@ struct omap_mcbsp {
unsigned int fmt; unsigned int in_freq;
- unsigned int latency[2]; int clk_div; int wlen;
- struct pm_qos_request pm_qos_req;
};
void omap_mcbsp_config(struct omap_mcbsp *mcbsp, diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index d018e966e533..7e00938271c6 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -226,6 +226,7 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, int wlen, channels, wpf; int pkt_size = 0; unsigned int format, div, framesize, master;
unsigned int buffer_size = mcbsp->pdata->buffer_size;
dma_data = snd_soc_dai_get_dma_data(cpu_dai, substream); channels = params_channels(params);
@@ -240,7 +241,9 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, default: return -EINVAL; }
- if (mcbsp->pdata->buffer_size) {
- if (buffer_size) {
int latency;- if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) { int period_words, max_thrsh; int divider = 0;
@@ -271,6 +274,12 @@ static int omap_mcbsp_dai_hw_params(struct snd_pcm_substream *substream, /* Use packet mode for non mono streams */ pkt_size = channels; }
latency = ((((buffer_size - pkt_size) / channels) * 1000)/ (params->rate_num / params->rate_den));mcbsp->latency[substream->stream] = latency;- omap_mcbsp_set_threshold(substream, pkt_size); }
* Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:21 in_atomic(): 1, irqs_disabled(): 128, pid: 351, name: mpg123 2 locks held by mpg123/351: #0: (snd_pcm_link_rwlock){......}, at: [<bf0667dc>] snd_pcm_stream_lock+0x20/0x50 [snd_pcm] #1: (&(&substream->self_group.lock)->rlock){......}, at: [<bf06dd70>] snd_pcm_lib_write1+0x1ac/0x30c [snd_pc] irq event stamp: 20082 hardirqs last enabled at (20081): [<bf0668e8>] snd_pcm_stream_unlock_irq+0x20/0x28 [snd_pcm] hardirqs last disabled at (20082): [<bf066834>] snd_pcm_stream_lock_irq+0x28/0x38 [snd_pcm] softirqs last enabled at (17808): [<c013f124>] __do_softirq+0x240/0x564 softirqs last disabled at (17767): [<c013f7e0>] irq_exit+0xe4/0x160 CPU: 0 PID: 351 Comm: mpg123 Not tainted 4.10.0-rc2-next-20170109+ #726 Hardware name: Generic OMAP36xx (Flattened Device Tree) [<c0110238>] (unwind_backtrace) from [<c010c2a8>] (show_stack+0x10/0x14) [<c010c2a8>] (show_stack) from [<c04be4a0>] (dump_stack+0xac/0xe0) [<c04be4a0>] (dump_stack) from [<c0165d60>] (___might_sleep+0x17c/0x2a4) [<c0165d60>] (___might_sleep) from [<c0879444>] (down_read+0x20/0x90) [<c0879444>] (down_read) from [<c015f62c>] (__blocking_notifier_call_chain+0x2c/0x60) [<c015f62c>] (__blocking_notifier_call_chain) from [<c015f678>] (blocking_notifier_call_chain+0x18/0x20) [<c015f678>] (blocking_notifier_call_chain) from [<c01a1c98>] (pm_qos_update_target+0x120/0x34c) [<c01a1c98>] (pm_qos_update_target) from [<bf247188>] (omap_mcbsp_start+0x2a8/0x334 [snd_soc_omap_mcbsp]) [<bf247188>] (omap_mcbsp_start [snd_soc_omap_mcbsp]) from [<bf24533c>] (omap_mcbsp_dai_trigger+0x5c/0x90 [snd_) [<bf24533c>] (omap_mcbsp_dai_trigger [snd_soc_omap_mcbsp]) from [<bf09bfa0>] (soc_pcm_trigger+0xd0/0x11c [snd_) [<bf09bfa0>] (soc_pcm_trigger [snd_soc_core]) from [<bf066368>] (snd_pcm_action_single+0x38/0x78 [snd_pcm]) [<bf066368>] (snd_pcm_action_single [snd_pcm]) from [<bf06de8c>] (snd_pcm_lib_write1+0x2c8/0x30c [snd_pcm]) [<bf06de8c>] (snd_pcm_lib_write1 [snd_pcm]) from [<bf06df30>] (snd_pcm_lib_write+0x60/0x74 [snd_pcm]) [<bf06df30>] (snd_pcm_lib_write [snd_pcm]) from [<bf0692bc>] (snd_pcm_playback_ioctl1+0x38c/0x6f0 [snd_pcm]) [<bf0692bc>] (snd_pcm_playback_ioctl1 [snd_pcm]) from [<c02cbab8>] (do_vfs_ioctl+0x90/0xa0c) [<c02cbab8>] (do_vfs_ioctl) from [<c02cc4a0>] (SyS_ioctl+0x6c/0x7c) [<c02cc4a0>] (SyS_ioctl) from [<c01079a8>] (__sys_trace_return+0x0/0x10)
Any ideas?
Tony
On Mon, Jan 9, 2017 at 11:21 AM, Tony Lindgren tony@atomide.com wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
Didn't notice that happening for me. But haven't rebased for the last couple days. Does this happen 100% of the time?
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:21 in_atomic(): 1, irqs_disabled(): 128, pid: 351, name: mpg123 2 locks held by mpg123/351: #0: (snd_pcm_link_rwlock){......}, at: [<bf0667dc>] snd_pcm_stream_lock+0x20/0x50 [snd_pcm] #1: (&(&substream->self_group.lock)->rlock){......}, at: [<bf06dd70>] snd_pcm_lib_write1+0x1ac/0x30c [snd_pc] irq event stamp: 20082 hardirqs last enabled at (20081): [<bf0668e8>] snd_pcm_stream_unlock_irq+0x20/0x28 [snd_pcm] hardirqs last disabled at (20082): [<bf066834>] snd_pcm_stream_lock_irq+0x28/0x38 [snd_pcm] softirqs last enabled at (17808): [<c013f124>] __do_softirq+0x240/0x564 softirqs last disabled at (17767): [<c013f7e0>] irq_exit+0xe4/0x160 CPU: 0 PID: 351 Comm: mpg123 Not tainted 4.10.0-rc2-next-20170109+ #726 Hardware name: Generic OMAP36xx (Flattened Device Tree) [<c0110238>] (unwind_backtrace) from [<c010c2a8>] (show_stack+0x10/0x14) [<c010c2a8>] (show_stack) from [<c04be4a0>] (dump_stack+0xac/0xe0) [<c04be4a0>] (dump_stack) from [<c0165d60>] (___might_sleep+0x17c/0x2a4) [<c0165d60>] (___might_sleep) from [<c0879444>] (down_read+0x20/0x90) [<c0879444>] (down_read) from [<c015f62c>] (__blocking_notifier_call_chain+0x2c/0x60) [<c015f62c>] (__blocking_notifier_call_chain) from [<c015f678>] (blocking_notifier_call_chain+0x18/0x20) [<c015f678>] (blocking_notifier_call_chain) from [<c01a1c98>] (pm_qos_update_target+0x120/0x34c) [<c01a1c98>] (pm_qos_update_target) from [<bf247188>] (omap_mcbsp_start+0x2a8/0x334 [snd_soc_omap_mcbsp]) [<bf247188>] (omap_mcbsp_start [snd_soc_omap_mcbsp]) from [<bf24533c>] (omap_mcbsp_dai_trigger+0x5c/0x90 [snd_) [<bf24533c>] (omap_mcbsp_dai_trigger [snd_soc_omap_mcbsp]) from [<bf09bfa0>] (soc_pcm_trigger+0xd0/0x11c [snd_) [<bf09bfa0>] (soc_pcm_trigger [snd_soc_core]) from [<bf066368>] (snd_pcm_action_single+0x38/0x78 [snd_pcm]) [<bf066368>] (snd_pcm_action_single [snd_pcm]) from [<bf06de8c>] (snd_pcm_lib_write1+0x2c8/0x30c [snd_pcm]) [<bf06de8c>] (snd_pcm_lib_write1 [snd_pcm]) from [<bf06df30>] (snd_pcm_lib_write+0x60/0x74 [snd_pcm]) [<bf06df30>] (snd_pcm_lib_write [snd_pcm]) from [<bf0692bc>] (snd_pcm_playback_ioctl1+0x38c/0x6f0 [snd_pcm]) [<bf0692bc>] (snd_pcm_playback_ioctl1 [snd_pcm]) from [<c02cbab8>] (do_vfs_ioctl+0x90/0xa0c) [<c02cbab8>] (do_vfs_ioctl) from [<c02cc4a0>] (SyS_ioctl+0x6c/0x7c) [<c02cc4a0>] (SyS_ioctl) from [<c01079a8>] (__sys_trace_return+0x0/0x10)
Any ideas?
Tony
* Matt Ranostay matt@ranostay.consulting [170109 13:46]:
On Mon, Jan 9, 2017 at 11:21 AM, Tony Lindgren tony@atomide.com wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
Didn't notice that happening for me. But haven't rebased for the last couple days. Does this happen 100% of the time?
Yeah seems to based on three attempts. This with 4.10.0-rc2-next-20170109.
Tony
On Mon, Jan 9, 2017 at 1:56 PM, Tony Lindgren tony@atomide.com wrote:
- Matt Ranostay matt@ranostay.consulting [170109 13:46]:
On Mon, Jan 9, 2017 at 11:21 AM, Tony Lindgren tony@atomide.com wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
Didn't notice that happening for me. But haven't rebased for the last couple days. Does this happen 100% of the time?
Yeah seems to based on three attempts. This with 4.10.0-rc2-next-20170109.
Ok I'll test this myself this evening and report back.
Tony
* Matt Ranostay matt@ranostay.consulting [170109 14:11]:
On Mon, Jan 9, 2017 at 1:56 PM, Tony Lindgren tony@atomide.com wrote:
- Matt Ranostay matt@ranostay.consulting [170109 13:46]:
On Mon, Jan 9, 2017 at 11:21 AM, Tony Lindgren tony@atomide.com wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote:
We can get audio errors if hitting deeper idle states on omaps:
[alsa.c:230] error: Fatal problem with alsa output, error -5. [audio.c:614] error: Error in writing audio (Input/output error?)!
This seems to happen with off mode idle enabled as power for the whole SoC may get cut off between filling the McBSP fifo using DMA. While active DMA blocks deeper idle states in hardware, McBSP activity does not seem to do so.
Basing the QoS latency calculation on the FIFO size, threshold, sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
Didn't notice that happening for me. But haven't rebased for the last couple days. Does this happen 100% of the time?
Yeah seems to based on three attempts. This with 4.10.0-rc2-next-20170109.
Ok I'll test this myself this evening and report back.
Oh and this is with omap2plus_defconfig with the following also enabled:
CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y
Tony
On Mon, Jan 9, 2017 at 3:56 PM, Tony Lindgren tony@atomide.com wrote:
- Matt Ranostay matt@ranostay.consulting [170109 14:11]:
On Mon, Jan 9, 2017 at 1:56 PM, Tony Lindgren tony@atomide.com wrote:
- Matt Ranostay matt@ranostay.consulting [170109 13:46]:
On Mon, Jan 9, 2017 at 11:21 AM, Tony Lindgren tony@atomide.com wrote:
- Peter Ujfalusi peter.ujfalusi@ti.com [170109 05:13]:
On 01/05/2017 03:59 AM, Matt Ranostay wrote: > We can get audio errors if hitting deeper idle states on omaps: > > [alsa.c:230] error: Fatal problem with alsa output, error -5. > [audio.c:614] error: Error in writing audio (Input/output error?)! > > This seems to happen with off mode idle enabled as power for the > whole SoC may get cut off between filling the McBSP fifo using DMA. > While active DMA blocks deeper idle states in hardware, McBSP > activity does not seem to do so. > > Basing the QoS latency calculation on the FIFO size, threshold, > sample rate, and channels.
Looks good to me, thank you!
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Noticed the following about 10 seconds into playing an mp3 file with mpg123 though:
Didn't notice that happening for me. But haven't rebased for the last couple days. Does this happen 100% of the time?
Yeah seems to based on three attempts. This with 4.10.0-rc2-next-20170109.
Ok I'll test this myself this evening and report back.
Oh and this is with omap2plus_defconfig with the following also enabled:
CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y
Yeah I can reproduce the issue you are mentioning. Anyone have a suggestion how on to resolve? Guessing the QoS function calls need to be in an atomic context and the omap_mcbsp_* functions can sleep
Tony
On 01/10/2017 05:23 AM, Matt Ranostay wrote:
Yeah I can reproduce the issue you are mentioning. Anyone have a suggestion how on to resolve? Guessing the QoS function calls need to be in an atomic context and the omap_mcbsp_* functions can sleep
I think it is the other way around: we call a sleeping function from atomic context. pcm_trigger is atomic.
Most probably we should add the .prepare callback to mcbsp_dai_ops and do the QoS update which is done in omap_mcbsp_start() there. The things we do in omap_mcbsp_stop() then can be moved to omap_mcbsp_dai_shutdown().
I think the code would handle cases when user space stops the stream, re-configures it and starts it with different parameters w/o closing it.
On Mon, Jan 9, 2017 at 11:38 PM, Peter Ujfalusi peter.ujfalusi@ti.com wrote:
On 01/10/2017 05:23 AM, Matt Ranostay wrote:
Yeah I can reproduce the issue you are mentioning. Anyone have a suggestion how on to resolve? Guessing the QoS function calls need to be in an atomic context and the omap_mcbsp_* functions can sleep
I think it is the other way around: we call a sleeping function from atomic context. pcm_trigger is atomic.
Most probably we should add the .prepare callback to mcbsp_dai_ops and do the QoS update which is done in omap_mcbsp_start() there. The things we do in omap_mcbsp_stop() then can be moved to omap_mcbsp_dai_shutdown().
Seems reasonable. Will rework patchset and retest.
Thanks,
Matt
I think the code would handle cases when user space stops the stream, re-configures it and starts it with different parameters w/o closing it.
-- Péter
participants (3)
-
Matt Ranostay -
Peter Ujfalusi -
Tony Lindgren