From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932897AbdCUOa1 (ORCPT ); Tue, 21 Mar 2017 10:30:27 -0400 Received: from mx0b-001ae601.pphosted.com ([67.231.152.168]:47259 "EHLO mx0b-001ae601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932173AbdCUOa0 (ORCPT ); Tue, 21 Mar 2017 10:30:26 -0400 Authentication-Results: ppops.net; spf=none smtp.mailfrom=ckeepax@opensource.wolfsonmicro.com Date: Tue, 21 Mar 2017 14:31:17 +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: <20170321143117.GZ6986@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> <20170321142018.GY6986@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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703210127 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 21, 2017 at 04:25:40PM +0200, Daniel Baluta wrote: > On Tue, Mar 21, 2017 at 4:20 PM, Charles Keepax > wrote: > > 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: > >> >> * 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. > > Oh, I see. So we still use the PLL when no exact or relaxed match > is found. Yeah exactly or in the case that it is requested directly. Thanks, Charles From mboxrd@z Thu Jan 1 00:00:00 1970 From: Charles Keepax Subject: Re: [PATCH v2 2/2] ASoC: codec: wm8960: Relax bit clock computation Date: Tue, 21 Mar 2017 14:31:17 +0000 Message-ID: <20170321143117.GZ6986@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> <20170321142018.GY6986@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx0b-001ae601.pphosted.com (mx0b-001ae601.pphosted.com [67.231.152.168]) by alsa0.perex.cz (Postfix) with ESMTP id 287DF266718 for ; Tue, 21 Mar 2017 15:30:13 +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: Daniel Baluta Cc: alsa-devel@alsa-project.org, shengjiu.wang@freescale.com, patches@opensource.wolfsonmicro.com, Linux Kernel Mailing List , Liam Girdwood , Mark Brown , viorel.suman@nxp.com, mihai.serban@nxp.com, Takashi Iwai , Daniel Baluta List-Id: alsa-devel@alsa-project.org On Tue, Mar 21, 2017 at 04:25:40PM +0200, Daniel Baluta wrote: > On Tue, Mar 21, 2017 at 4:20 PM, Charles Keepax > wrote: > > 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: > >> >> * 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. > > Oh, I see. So we still use the PLL when no exact or relaxed match > is found. Yeah exactly or in the case that it is requested directly. Thanks, Charles