Re: [alsa-devel] [PATCH] ASoC: rt5640: add master clock handling for rt5640

[Pierre-Louis Bossart <pierre-louis.bossart-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>]

On 2/23/16 9:32 PM, Mark Brown wrote:
> On Wed, Feb 24, 2016 at 12:08:31AM +0100, Heiko Stuebner wrote:
>> Am Dienstag, 23. Februar 2016, 08:50:04 schrieb Pierre-Louis
>> Bossart:
>
>>> This patch assumes that the information on mclk comes from
>>> DeviceTree. The mclk may also be enabled/disabled in the machine
>>> driver with an explicit transition to use an internal clock when
>>> the codec is not used. I hope this patch doesn't preclude such
>>> usages or there will be a conflict with the patches we are about
>>> to upstream for Baytrail/cht devices.
>
>> As you can see, the clock property itself is optional and the
>> clk_get below acts accordingly of also continuing if the clock is
>> not present. So it won't affect any users doing it otherwise.
>
> That said we really do need x86 to transition to use the clock API
> in order to integrate with external devices, where the machine driver
> does manage clocks we want that to move to being done using the clock
> API rather than custom APIs.

For Baytrail audio we have a single platform clock that can be turned
on/off and set to 19.2 MHz or 25 MHz. No other controls are available,
no multipliers or complicated dependencies on other clocks, parents or 
children and no other users for this clock but the audio subsystem.
I looked at the clock framework and couldn't figure out how it would 
simply map the hardware so for now the use of the MCLK is only enabled 
with an on/off or set-rate(19.2|25) custom API. I am not an expert here 
so if this clock framework becomes a requirement to upstream code I 
would appreciate any pointers to do the right thing. I really couldn't 
find a simple example with 'Put your code here' comments to use this 
framework.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html