Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932249AbcDVQsQ (ORCPT ); Fri, 22 Apr 2016 12:48:16 -0400 Received: from mail.xenotropic.com ([198.178.136.20]:34887 "EHLO mail.xenotropic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754584AbcDVQsL convert rfc822-to-8bit (ORCPT ); Fri, 22 Apr 2016 12:48:11 -0400 X-Greylist: delayed 474 seconds by postgrey-1.27 at vger.kernel.org; Fri, 22 Apr 2016 12:48:11 EDT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: [alsa-devel] [PATCH 2/3] ASoC: simple-card: Add support jack detection via codec From: Jeremy McDermond In-Reply-To: <20160422092250.GA3217@sirena.org.uk> Date: Fri, 22 Apr 2016 09:40:09 -0700 Cc: Xing Zheng , Mark Rutland , Andrew Lunn , alsa-devel@alsa-project.org, Mengdong Lin , heiko@sntech.de, Liam Girdwood , Takashi Iwai , Rob Herring , Aaro Koskinen , sugar.zhang@rock-chips.com, linux-rockchip@lists.infradead.org, jay.xu@rock-chips.com, devicetree@vger.kernel.org, Pawel Moll , Ian Campbell , Jyri Sarha , Arnaud Pouliquen , linux-kernel@vger.kernel.org, Adam.Thomson@diasemi.com, Kumar Gala , Jun Nie Content-Transfer-Encoding: 8BIT Message-Id: <3EB722B2-2818-459C-8640-A3C2FC713F05@nh6z.net> References: <1460967452-24574-1-git-send-email-zhengxing@rock-chips.com> <1460967452-24574-3-git-send-email-zhengxing@rock-chips.com> <20160421141921.GA25900@rob-hp-laptop> <57197BBA.50304@rock-chips.com> <20160422092250.GA3217@sirena.org.uk> To: Mark Brown X-Mailer: Apple Mail (2.3096.5) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1842 Lines: 43 > On Apr 22, 2016, at 2:22 AM, Mark Brown wrote: > > On Fri, Apr 22, 2016 at 09:17:46AM +0800, Xing Zheng wrote: > >> Hi Mark, the other question here, how do we make sense to use the >> simple-card to call the "snd_soc_dai_set_pll" if the codec (like da7219) >> requires do this? > > What we should do there is move the CODEC clocking to be represented > using the clock API and then there are common clock bindings that > already exist for configuring clocks. I’m a little bit curious about this. I’m working with the clocking on the tlv320aic32x4 driver because I’m dealing with a platform that will be clocking it from a dynamic clock controlled by the CCF. That presents some problems because the aic32x4 driver has a table of clock parameters and those rely on the mclk rate being a precise value. The mclk might not be able to provide those exact values, so the aic32x4 driver needs to set its PLLs and dividers accordingly. The hardware has a couple of clock muxes, a few dividers and the PLL. It seems to be able to be modeled by the current CCF components fairly well. I’m just trying to wrap my head around where this all would fit in. Should the codec driver just register a bunch of clock components in its initialization somewhere? I’m thinking that it can’t have its own CCF driver separate from the codec driver because you won’t have proper access to the registers over I2C or SPI. I don’t find a lot of examples in the codec drivers, and there aren’t very many other drivers in the tree that seem to register clocks with CCF that I can find. I’m happy to work through this with the aic32x4 driver. I just need some guidance on how to do it so it fits in well with everything else surrounding it. -- Jeremy McDermond (NH6Z) Xenotropic Systems mcdermj@xenotropic.com