From mboxrd@z Thu Jan  1 00:00:00 1970
From: voice.shen@atmel.com (Bo Shen)
Date: Mon, 24 Mar 2014 10:15:51 +0800
Subject: [RFC PATCH] ASoC: wm8904: add CCF support
In-Reply-To: <20140321115511.GM11706@sirena.org.uk>
References: <1395370262-23305-1-git-send-email-voice.shen@atmel.com>
 <20140321103747.GK23372@e106331-lin.cambridge.arm.com>
 <20140321115511.GM11706@sirena.org.uk>
Message-ID: <532F9557.2000402@atmel.com>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

Hi Mark,

On 03/21/2014 07:55 PM, Mark Brown wrote:
> 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.

I really don't know how it decided by kernel (hardcode in machine driver 
?), can you point me directly? Thanks.

>>> +    - 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 will check it. If some hints about this, will be appreciated.
Thanks.

Best Regards,
Bo Shen