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