[PATCH] ASoC: wm8994: Add clock bindings to the device tree

[PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Mark Brown]

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
-- 
1.8.3.2

Re: [PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Mark Rutland]

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
> 
> 

Re: [PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 733 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Mark Rutland]

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.

Re: [PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Stephen Warren]

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?

Re: [PATCH] ASoC: wm8994: Add clock bindings to the device tree

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]