* [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
@ 2017-01-05 1:59 Matt Ranostay
2017-01-09 13:12 ` Peter Ujfalusi
0 siblings, 1 reply; 10+ messages in thread
From: Matt Ranostay @ 2017-01-05 1:59 UTC (permalink / raw)
To: alsa-devel, linux-omap; +Cc: Tony Lindgren, Peter Ujfalusi, Matt Ranostay
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);
}
--
2.10.2
^ permalink raw reply related [flat|nested] 10+ messages in thread* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-05 1:59 [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Matt Ranostay
@ 2017-01-09 13:12 ` Peter Ujfalusi
2017-01-09 19:21 ` Tony Lindgren
0 siblings, 1 reply; 10+ messages in thread
From: Peter Ujfalusi @ 2017-01-09 13:12 UTC (permalink / raw)
To: Matt Ranostay, alsa-devel, linux-omap; +Cc: Tony Lindgren
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);
> + 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);
> }
>
>
--
Péter
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 13:12 ` Peter Ujfalusi
@ 2017-01-09 19:21 ` Tony Lindgren
2017-01-09 21:46 ` Matt Ranostay
0 siblings, 1 reply; 10+ messages in thread
From: Tony Lindgren @ 2017-01-09 19:21 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: alsa-devel, linux-omap, Matt Ranostay
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 19:21 ` Tony Lindgren
@ 2017-01-09 21:46 ` Matt Ranostay
2017-01-09 21:56 ` Tony Lindgren
0 siblings, 1 reply; 10+ messages in thread
From: Matt Ranostay @ 2017-01-09 21:46 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Peter Ujfalusi, alsa-devel, Linux OMAP List
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
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 21:46 ` Matt Ranostay
@ 2017-01-09 21:56 ` Tony Lindgren
2017-01-09 22:11 ` Matt Ranostay
0 siblings, 1 reply; 10+ messages in thread
From: Tony Lindgren @ 2017-01-09 21:56 UTC (permalink / raw)
To: Matt Ranostay; +Cc: Peter Ujfalusi, alsa-devel, Linux OMAP List
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 21:56 ` Tony Lindgren
@ 2017-01-09 22:11 ` Matt Ranostay
2017-01-09 23:56 ` Tony Lindgren
0 siblings, 1 reply; 10+ messages in thread
From: Matt Ranostay @ 2017-01-09 22:11 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Peter Ujfalusi, alsa-devel, Linux OMAP List
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 22:11 ` Matt Ranostay
@ 2017-01-09 23:56 ` Tony Lindgren
2017-01-10 3:23 ` Matt Ranostay
0 siblings, 1 reply; 10+ messages in thread
From: Tony Lindgren @ 2017-01-09 23:56 UTC (permalink / raw)
To: Matt Ranostay; +Cc: Peter Ujfalusi, alsa-devel, Linux OMAP List
* 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-09 23:56 ` Tony Lindgren
@ 2017-01-10 3:23 ` Matt Ranostay
2017-01-10 7:38 ` Peter Ujfalusi
0 siblings, 1 reply; 10+ messages in thread
From: Matt Ranostay @ 2017-01-10 3:23 UTC (permalink / raw)
To: Tony Lindgren; +Cc: Peter Ujfalusi, alsa-devel, Linux OMAP List
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-10 3:23 ` Matt Ranostay
@ 2017-01-10 7:38 ` Peter Ujfalusi
2017-01-10 17:27 ` Matt Ranostay
0 siblings, 1 reply; 10+ messages in thread
From: Peter Ujfalusi @ 2017-01-10 7:38 UTC (permalink / raw)
To: Matt Ranostay, Tony Lindgren; +Cc: alsa-devel, Linux OMAP List
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.
--
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
2017-01-10 7:38 ` Peter Ujfalusi
@ 2017-01-10 17:27 ` Matt Ranostay
0 siblings, 0 replies; 10+ messages in thread
From: Matt Ranostay @ 2017-01-10 17:27 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: Tony Lindgren, alsa-devel, Linux OMAP List
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-01-10 17:27 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-05 1:59 [PATCH v5] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Matt Ranostay
2017-01-09 13:12 ` Peter Ujfalusi
2017-01-09 19:21 ` Tony Lindgren
2017-01-09 21:46 ` Matt Ranostay
2017-01-09 21:56 ` Tony Lindgren
2017-01-09 22:11 ` Matt Ranostay
2017-01-09 23:56 ` Tony Lindgren
2017-01-10 3:23 ` Matt Ranostay
2017-01-10 7:38 ` Peter Ujfalusi
2017-01-10 17:27 ` Matt Ranostay
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).