Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753807AbdCOPMS (ORCPT ); Wed, 15 Mar 2017 11:12:18 -0400 Received: from mail-it0-f68.google.com ([209.85.214.68]:34707 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbdCOPLe (ORCPT ); Wed, 15 Mar 2017 11:11:34 -0400 MIME-Version: 1.0 In-Reply-To: <20170315133318.qo7fpoffmyh2chmz@sirena.org.uk> References: <1489510622-30981-1-git-send-email-daniel.baluta@nxp.com> <20170315091901.GF6986@localhost.localdomain> <20170315133318.qo7fpoffmyh2chmz@sirena.org.uk> From: Daniel Baluta Date: Wed, 15 Mar 2017 17:11:32 +0200 Message-ID: Subject: Re: [alsa-devel] [RFC PATCH] ASoC: wm8960: Use physical width for bclk To: Mark Brown Cc: Charles Keepax , alsa-devel@alsa-project.org, shengjiu.wang@freescale.com, patches@opensource.wolfsonmicro.com, Linux Kernel Mailing List , lgirdwood@gmail.com, viorel.suman@nxp.com, mihai.serban@nxp.com, Takashi Iwai , Daniel Baluta Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1177 Lines: 28 On Wed, Mar 15, 2017 at 3:33 PM, Mark Brown wrote: > On Wed, Mar 15, 2017 at 09:19:01AM +0000, Charles Keepax wrote: >> On Tue, Mar 14, 2017 at 06:57:02PM +0200, Daniel Baluta wrote: > >> > - wm8960->bclk = snd_soc_params_to_bclk(params); >> > + wm8960->bclk = params_physical_width(params) * >> > + params_channels(params) * params_rate(params); >> > if (params_channels(params) == 1) >> > wm8960->bclk *= 2; > >> Would quite like to see Mark's thoughts on this. Feels a bit to >> me (although I am not certain) like we are solving the problem in >> the wrong place, isn't this really setting the desired BCLK and >> then in wm8960_configure_clocking we should set the lowest BCLK >> we can that is greater than or equal to the desired. > > Exactly, this is the wrong fix in the wrong place - if this is something > we want to do we should be doing it in the shared functions so all > CODECs get the same behaviour but really I think Charles' suggestion > makes more sense. I see your point. Thanks a lot for feedback. I already have an implementation for Charles' suggestion. Will send the patches asap. thanks, Daniel.