All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Matt Ranostay <matt@ranostay.consulting>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	alsa-devel@alsa-project.org, inux-omap@vger.kernel.org
Subject: Re: [PATCH v7] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
Date: Fri, 13 Jan 2017 07:20:49 -0800	[thread overview]
Message-ID: <20170113152049.GD5696@atomide.com> (raw)
In-Reply-To: <20170113035432.6723-1-matt@ranostay.consulting>

* Matt Ranostay <matt@ranostay.consulting> [170112 19:55]:
> 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>
> Acked-by: 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
> 
> Changes from v5:
> * clean up latency checking logic
> * move logic to .prepare and .shutdown to avoid functions that can sleep
> 
> Changes from v6:
> * move QoS removal to asoc_mcbsp_remove from omap_mcbsp_cleanup
> * also remove header include that is unneeded

Hmm now I'm seeing these when starting or stopping playback:

WARNING: CPU: 0 PID: 373 at kernel/power/qos.c:534 omap_mcbsp_dai_shutdown+0x6c/0x70 [snd_soc_omap_mcbsp]
pm_qos_remove_request() called for unknown object
Modules linked in: snd_soc_omap_twl4030 snd_soc_twl4030 snd_soc_omap_mcbsp evdev mwifiex_sdio mwifiex leds_gpio
 snd_soc_omap cfg80211 bq27xxx_battery_i2c leds_pca963x bq27xxx_battery led_class bq24190_charger phy_twl4030_usb omap2430 mus
 b_hdrc usbcore snd_soc_core twl4030_wdt snd_pcm_dmaengine rtc_twl snd_pcm snd_timer snd soundcore twl4030_pwrbutton pwm_twl_le
 d twl4030_keypad pwm_twl matrix_keymap omap_ssi hsi ledtrig_timer usb_f_serial usb_f_rndis usb_f_mass_storage usb_f_ecm u_ethe
 r usb_f_acm libcomposite u_serial udc_core usb_common autofs4 [last unloaded: snd_soc_omap_mcbsp]
 [   51.542541] CPU: 0 PID: 373 Comm: mpg123 Not tainted 4.10.0-rc2-next-20170109+ #751
 [   51.550231] Hardware name: Generic OMAP36xx (Flattened Device Tree)
 [   51.556579] [<c0110198>] (unwind_backtrace) from [<c010c208>] (show_stack+0x10/0x14)
 [   51.564361] [<c010c208>] (show_stack) from [<c04be0a0>] (dump_stack+0xac/0xe0)
 [   51.571655] [<c04be0a0>] (dump_stack) from [<c0137428>] (__warn+0xd8/0x104)
 [   51.578643] [<c0137428>] (__warn) from [<c0137488>] (warn_slowpath_fmt+0x34/0x44)
 [   51.586212] [<c0137488>] (warn_slowpath_fmt) from [<bf3538f4>] (omap_mcbsp_dai_shutdown+0x6c/0x70 [snd_soc_omap_mcbsp])
 [   51.597351] [<bf3538f4>] (omap_mcbsp_dai_shutdown [snd_soc_omap_mcbsp]) from [<bf11037c>] (soc_pcm_close+0xa0/0x2b8 [snd_so
 c_core])
 [   51.609497] [<bf11037c>] (soc_pcm_close [snd_soc_core]) from [<bf0d0654>] (snd_pcm_release_substream.part.13+0x48/0xac [snd
 _pcm])
 [   51.621337] [<bf0d0654>] (snd_pcm_release_substream.part.13 [snd_pcm]) from [<bf0d0764>] (snd_pcm_release+0x94/0xb4 [snd_pc
 m])
 [   51.632843] [<bf0d0764>] (snd_pcm_release [snd_pcm]) from [<c02b91d8>] (__fput+0x94/0x1e4)
 [   51.641174] [<c02b91d8>] (__fput) from [<c015b768>] (task_work_run+0xcc/0x104)
 [   51.648437] [<c015b768>] (task_work_run) from [<c010bb38>] (do_work_pending+0xbc/0xc0)
 [   51.656402] [<c010bb38>] (do_work_pending) from [<c01077c8>] (slow_work_pending+0xc/0x20)


Regards,

Tony

  reply	other threads:[~2017-01-13 15:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-13  3:54 [PATCH v7] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Matt Ranostay
2017-01-13 15:20 ` Tony Lindgren [this message]
2017-01-13 17:57   ` Matt Ranostay
2017-01-14  5:15   ` Matt Ranostay
2017-01-16 17:17     ` Tony Lindgren
2017-01-16 19:30       ` Matt Ranostay
2017-01-17 12:34         ` Peter Ujfalusi
2017-01-17 23:04           ` Matt Ranostay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170113152049.GD5696@atomide.com \
    --to=tony@atomide.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=inux-omap@vger.kernel.org \
    --cc=matt@ranostay.consulting \
    --cc=peter.ujfalusi@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.