[RFC PATCH] ASoC: wm8904: add CCF support

[b.brezillon.dev@gmail.com (Boris BREZILLON)]

Le 21/03/2014 12:55, Mark Brown a ?crit :
> On Fri, Mar 21, 2014 at 10:37:47AM +0000, Mark Rutland wrote:
>> On Fri, Mar 21, 2014 at 02:51:02AM +0000, Bo Shen wrote:
>>> +  - wlf,sysclk-from-mclk: set the sys clock is driven from mclk,
>> Why can the kernel not decide this?
> It can.
>
>>> +    - wlf,mclk-use-xtal: if the mclk is generated by crystal.
>>> +      if without this property, the mclk is generated from SOC.
>> Huh? What exact property do you actually are about here?
> This should just be omitted - based on the previous posting it's saying
> if this is a fixed or variable rate clock.
>
>>> +    - wlf,mclk-freq: mclk's frequency
>> If you expect mclk, you should be able to query this from it. You don't
>> need a separate property.
>> Unless this is a frequency to set it to? If so, why can the kernel not
>> choose this?
> Yes, quite - and even if it needs to be set explicitly the clock API
> generic bindings should be able to support this (I *think* that is due
> to go in during the next merge window but iddn't check yet).
I guess you're talking about this: https://lkml.org/lkml/2014/3/3/324.
AFAIK this has not been accepted yet, but this is definitely the way to
go if we need to specify a default-rate from the DT.

On the whole subject, I'd like to have your opinion on how we should
implement clk handling within the wm8904 driver.

 From my point of view we have 2 choices:

1) Expose the wm8904 clock tree using the CCF (and its DT bindings)

 From what I read in the datasheet this would give the following DT
definition:

wm8904 at xx {
     compatible="wm8904";
     [...]

     clocks {
         fll {
             compatible = "wolfson,wm8904-fll"
             #clock-cells = <0>;
             clocks = <&pck0>;
             clock-output-names = "wm8904-fll";
         };

         sysclk {
             compatible = "wolfson,wm8904-sysclk"
             clocks = <&pck0 &fll>;
             clock-output-names = "wm8904-sysclk";
         };

         /* other clk derived from sysclk */
     };
};

If we use the CCF in the wm8904 driver, we'll have to move all users
of this chip to the CCF too (in other terms, we need to move the sam9n12
SoC and boards to the CCF).


2) keep the driver as it is except for the mclk retrieval.

wm8904 at xx {
     compatible="wm8904";
     clocks = <&pck0>;
     clock-names = "mclk";
     clock-rates = <32768>;
};


The first solution is obviously more complicated to implement (and 
requires the
CCF), but in the other hand, it gives fine-grained control over clk 
configuration
and use a standard way to expose/manipulate clks.

Best Regards,

Boris