linux-kernel - Re: [PATCH 7/8] ASoC: atmel: document clock properties of the wm8904 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140319102800.GW11706@sirena.org.uk>
Date:	Wed, 19 Mar 2014 10:28:00 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Bo Shen <voice.shen@...el.com>
Cc:	<nicolas.ferre@...el.com>,
	Boris BREZILLON <b.brezillon@...rkiz.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	"Mark Rutland" <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Rob Landley <rob@...dley.net>, <devicetree@...r.kernel.org>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] ASoC: atmel: document clock properties of the wm8904
 driver

On Wed, Mar 19, 2014 at 01:57:23PM +0800, Bo Shen wrote:
> On 03/17/2014 07:55 PM, Mark Brown wrote:

> >If this is a clock for the CODEC it should be documented as part of the
> >binding for the CODEC and connected to the CODEC in the device tree
> >rather than being part of a machine driver binding.

> This is a optional clock for CODEC which depends on hardware design. There
> are 3 options for this clock, wm8904 as an example.
> 1. Using internal FLL, so won't use this clock.
> 2. Using external oscillator, no need to retrieve this clock.
> 3. Using SoC provide this clock (we use this case).

> After considering these 3 options, if we put this into CODEC driver to do
> it, I think it will be more complicate to do logic judgement. Do you think
> so?

There shouldn't be any meaningful complexity from the above cases -
cases 2 and 3 are the same and if the clock isn't used at all then it
can be omitted.  If the FLL is clocked from MCLK then the CODEC driver
should be able to work out how to configure it easily, the device isn't 
like a digital hub CODEC with lots of clocking options.

> And, in machine driver, it will depends on the clock option to decide
> whether to call snd_soc_dai_set_pll and snd_soc_dai_set_sysclk.

Some if not all of this logic can be eaten by the CODEC driver,
especially with a simple device like this.  Realistically the device is
either going to be clocked from MCLK (with the rate telling us if we
need the FLL) or from BCLK (if it's slave and there's no MCLK).

> And also the <Documentation/soud/alsa/soc/machine.txt> mentions the machine
> drivers responsibility (one is for clocking) as following:
> --->8---
> The ASoC machine (or board) driver is the code that glues together all the
> component drivers (e.g. codecs, platforms and DAIs). It also describes the
> relationships between each componnent which include audio paths, GPIOs,
> interrupts, clocking, jacks and voltage regulators.
> ---8<---

That's a Linux specific consideration which shouldn't play any part in
DT design.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)