From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v7] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Date: Mon, 16 Jan 2017 09:17:44 -0800 Message-ID: <20170116171743.GB7403@atomide.com> References: <20170113035432.6723-1-matt@ranostay.consulting> <20170113152049.GD5696@atomide.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from muru.com (muru.com [72.249.23.125]) by alsa0.perex.cz (Postfix) with ESMTP id 42B6A2671C7 for ; Mon, 16 Jan 2017 18:17:49 +0100 (CET) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Matt Ranostay Cc: Peter Ujfalusi , alsa-devel@alsa-project.org, Linux OMAP List List-Id: alsa-devel@alsa-project.org * Matt Ranostay [170113 21:16]: > On Fri, Jan 13, 2017 at 7:20 AM, Tony Lindgren wrote: > > * Matt Ranostay [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 > >> Cc: Peter Ujfalusi > >> Acked-by: Peter Ujfalusi > >> Signed-off-by: Matt Ranostay > >> --- > >> 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: > > Ok I can't reproduce but I have an idea why it is happening. There is > likely a race condition between pm_qos_remove_request() and > omap_mcbsp_dai_shutdown()... Should we do a pm_qos_request_active > check in omap_mcbsp_dai_shutdown? That seems to be hacking around the > issue. OK. Again this is with next using omap2plus_defconfig and: CONFIG_DEBUG_LOCKDEP=y CONFIG_DEBUG_ATOMIC_SLEEP=y Regards, Tony