[alsa-devel] [PATCH] ASoC: wm8994: Add clock bindings to the device tree
From: Mark Brown broonie@linaro.org
Due to the variable availability of the clock API there is no code in the driver to use these at present, for the time being the machine drivers will need to handle requesting clocks.
Signed-off-by: Mark Brown broonie@linaro.org --- Documentation/devicetree/bindings/sound/wm8994.txt | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt index f2f3e80..e045e90 100644 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ b/Documentation/devicetree/bindings/sound/wm8994.txt @@ -32,6 +32,10 @@ Optional properties: The second cell is the flags, encoded as the trigger masks from Documentation/devicetree/bindings/interrupts.txt
+ - clocks : A list of up to two phandle and clock specifier pairs + - clock-names : A list of clock names sorted in the same order as clocks. + Valid clock names are "MCLK1" and "MCLK2". + - wlf,gpio-cfg : A list of GPIO configuration register values. If absent, no configuration of these registers is performed. If any value is over 0xffff then the register will be left as default. If present 11
On Thu, Jul 25, 2013 at 03:31:08PM +0100, Mark Brown wrote:
From: Mark Brown broonie@linaro.org
Due to the variable availability of the clock API there is no code in the driver to use these at present, for the time being the machine drivers will need to handle requesting clocks.
Signed-off-by: Mark Brown broonie@linaro.org
Do these two clock inputs exist for all of wm1811, wm8994, and wm8958?
If I've read the context correctly, these are optional. Does this mean that if not listed that an OS can assume they are already configured and active? It would be nice to document that.
Otherwise, this looks sensible:
Acked-by: Mark Rutland mark.rutland@arm.com
Thanks, Mark.
Documentation/devicetree/bindings/sound/wm8994.txt | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/wm8994.txt b/Documentation/devicetree/bindings/sound/wm8994.txt index f2f3e80..e045e90 100644 --- a/Documentation/devicetree/bindings/sound/wm8994.txt +++ b/Documentation/devicetree/bindings/sound/wm8994.txt @@ -32,6 +32,10 @@ Optional properties: The second cell is the flags, encoded as the trigger masks from Documentation/devicetree/bindings/interrupts.txt
- clocks : A list of up to two phandle and clock specifier pairs
- clock-names : A list of clock names sorted in the same order as clocks.
Valid clock names are "MCLK1" and "MCLK2".
- wlf,gpio-cfg : A list of GPIO configuration register values. If absent, no configuration of these registers is performed. If any value is over 0xffff then the register will be left as default. If present 11
-- 1.8.3.2
On Thu, Jul 25, 2013 at 04:46:27PM +0100, Mark Rutland wrote:
Do these two clock inputs exist for all of wm1811, wm8994, and wm8958?
Yes.
If I've read the context correctly, these are optional. Does this mean that if not listed that an OS can assume they are already configured and active? It would be nice to document that.
The clocks are both optional but even if they were assumed to be present they aren't usable without knowing the rate which can vary widely. It is possible that the system may be able to infer their presence and rates from other information such as the audio system integration compatible string but that's out of scope for this and doesn't seem like a particularly good idea to encorage anyway.
On Thu, Jul 25, 2013 at 06:56:42PM +0100, Mark Brown wrote:
On Thu, Jul 25, 2013 at 04:46:27PM +0100, Mark Rutland wrote:
Do these two clock inputs exist for all of wm1811, wm8994, and wm8958?
Yes.
If I've read the context correctly, these are optional. Does this mean that if not listed that an OS can assume they are already configured and active? It would be nice to document that.
The clocks are both optional but even if they were assumed to be present they aren't usable without knowing the rate which can vary widely. It is possible that the system may be able to infer their presence and rates from other information such as the audio system integration compatible string but that's out of scope for this and doesn't seem like a particularly good idea to encorage anyway.
Ok, that sounds sensible.
Thanks, Mark.
On 07/25/2013 08:31 AM, Mark Brown wrote:
From: Mark Brown broonie@linaro.org
Due to the variable availability of the clock API there is no code in the driver to use these at present, for the time being the machine drivers will need to handle requesting clocks.
Presumably before considering any/most CODEC bindings complete, we need to make a similar change?
On Fri, Jul 26, 2013 at 09:41:52AM -0600, Stephen Warren wrote:
On 07/25/2013 08:31 AM, Mark Brown wrote:
Due to the variable availability of the clock API there is no code in the driver to use these at present, for the time being the machine drivers will need to handle requesting clocks.
Presumably before considering any/most CODEC bindings complete, we need to make a similar change?
Yeah, ideally. I was going to go through the ones I know about at some point. On the other hand it's not really a big deal given how far off we are being able to rely on the clock API and we still need to work out what to do with hooking the audio buses in too.
participants (3)
-
Mark Brown -
Mark Rutland -
Stephen Warren