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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 24 Feb 2016 10:10:05 -0600
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	Mark Brown <broonie@...nel.org>, Heiko Stuebner <heiko@...ech.de>
Cc:	Mark Rutland <mark.rutland@....com>,
	Oder Chiou <oder_chiou@...ltek.com>,
	alsa-devel@...a-project.org, Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	Takashi Iwai <tiwai@...e.com>, linux-kernel@...r.kernel.org,
	Sugar Zhang <sugar.zhang@...k-chips.com>,
	devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
	Kumar Gala <galak@...eaurora.org>,
	Bard Liao <bardliao@...ltek.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: rt5640: add master clock handling for
 rt5640

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.