From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH v3] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Date: Mon, 5 Dec 2016 07:30:29 -0800 Message-ID: <20161205153028.GK4705@atomide.com> References: <1480555145-8300-1-git-send-email-matt@ranostay.consulting> <730ed491-ebe7-86c1-b131-5d9441ae2b7c@ti.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 A3A8D266D2A for ; Mon, 5 Dec 2016 16:30:33 +0100 (CET) Content-Disposition: inline In-Reply-To: <730ed491-ebe7-86c1-b131-5d9441ae2b7c@ti.com> 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: Peter Ujfalusi Cc: alsa-devel@alsa-project.org, Linux OMAP List , Matt Ranostay List-Id: alsa-devel@alsa-project.org * Peter Ujfalusi [161205 01:35]: > On 12/04/2016 03:33 AM, Matt Ranostay wrote: > >>> + * > >>> + * Also setting of the QoS latency for the FIFO which varies upon the buffer > >>> + * size. Approximately 2.3 milliseconds per FIFO location. > >>> */ > >>> void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx) > >>> { > >>> int enable_srg = 0; > >>> + int latency = mcbsp->pdata->buffer_size * 23; > >> > >> I think this is not correct. > >> The McBSP FIFO time depends on the sample rate and on the number of > >> channels the audio is using. With 8KHz mono you have 12 times more time > >> per FIFO element compared to 48KHz stereo. > >> > >> As it has been discussed with Tony we should calculate the QoS latency > >> in hw_params: > >> > > > > Ok yeah missed that part of the thread but it makes sense. Just one > > question should the latency value be only based on the TX FIFO > > threshold? I assume capture and transmit have two different settings. > > Yes, I believe we should apply the lowest QoS when both direction is > active. If the second stream needs lower QoS, we should switch to use > that, if it would need longer, we should keep the QoS placed for the > first stream. Sounds good to me. Regards, Tony