Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932866AbdCUO1J (ORCPT ); Tue, 21 Mar 2017 10:27:09 -0400 Received: from mx0a-001ae601.pphosted.com ([67.231.149.25]:36307 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932846AbdCUO1G (ORCPT ); Tue, 21 Mar 2017 10:27:06 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.wolfsonmicro.com Date: Tue, 21 Mar 2017 14:20:18 +0000 From: Charles Keepax To: Daniel Baluta CC: Daniel Baluta , , , , "Liam Girdwood" , Linux Kernel Mailing List , Mark Brown , , , Takashi Iwai Subject: Re: [alsa-devel] [PATCH v2 2/2] ASoC: codec: wm8960: Relax bit clock computation Message-ID: <20170321142018.GY6986@localhost.localdomain> References: <1490090976-25877-1-git-send-email-daniel.baluta@nxp.com> <1490090976-25877-3-git-send-email-daniel.baluta@nxp.com> <20170321125207.GX6986@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703210126 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2199 Lines: 49 On Tue, Mar 21, 2017 at 04:05:15PM +0200, Daniel Baluta wrote: > On Tue, Mar 21, 2017 at 2:52 PM, Charles Keepax > wrote: > > On Tue, Mar 21, 2017 at 12:09:36PM +0200, Daniel Baluta wrote: > >> WM8960 derives bit clock from sysclock using BCLKDIV[3:0] of R8 > >> clocking register (See WM8960 datasheet, page 71). > >> > >> There are use cases, like this: > >> aplay -Dhw:0,0 -r 48000 -c 1 -f S20_3LE -t raw audio48k20b_3LE1c.pcm > >> > >> where no BCLKDIV applied to sysclock can give us the exact requested > >> bitclk, so driver fails to configure clocking and aplay fails to run. > >> > >> Fix this by relaxing bitclk computation, so that when no exact value > >> can be derived from sysclk pick the closest value greater than > >> expected bitclk. > >> > >> Suggested-by: Charles Keepax > >> Signed-off-by: Daniel Baluta > >> --- > >> Changes since v1: > >> * use a marker to check if a match is found > >> * didn't removed PLL as Charles suggested because there is > >> a special PLL mode which explictly uses PLL. We could start > >> a discussion on not using PLL when deriving bitclk, but this > >> is to be done in another patch. > >> > > > > Could you elaborate on this a little more am I not sure I follow > > 100%? There is a mode which explictly requires the PLL to be used > > (WM8960_SYSCLK_PLL) but in that case your wm8960_configure_sysclk > > code will not be called so I don't see what is causing that to have > > an effect on this patch? > > My doubt is, what happens if wm8960_configure_clocking is called with > wm8960->clk_id = WM8960_SYSCLK_PLL and we remove the PLL > as suggested. I wasn't suggesting removing the PLL just that if we find a "relaxed match" we don't need to then check the PLL for a better match, as I suspect that a slightly higher than needed bit clock has less power/performance impact than firing up the PLL. Which removes the need to differenciate between a relaxed and bang on match in wm8960_configure_sysclk and means you don't have to do the caching the values across the PLL code that you do now. Thanks, Charles