[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <532931C3.4080909@atmel.com>
Date: Wed, 19 Mar 2014 13:57:23 +0800
From: Bo Shen <voice.shen@...el.com>
To: Mark Brown <broonie@...nel.org>
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
Hi Mark,
On 03/17/2014 07:55 PM, Mark Brown wrote:
> On Mon, Mar 17, 2014 at 05:45:40PM +0800, Bo Shen wrote:
>
>> - compatible: "atmel,asoc-wm8904"
>> - atmel,model: The user-visible name of this sound complex.
>> + - clocks: A list of clocks needed by the wm8904 chip.
>> + - clock-output-names: Driver related clock names. Shall contain "pck0".
>
> 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?
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.
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<---
So, I think put this into machine driver will be better. Do you have any
other idea? Or if I misunderstand something, please point it out.
Thanks.
Best Regards,
Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists