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:	Fri, 26 Feb 2016 09:43:15 -0600
From:	Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	Oder Chiou <oder_chiou@...ltek.com>,
	alsa-devel@...a-project.org, Heiko Stuebner <heiko@...ech.de>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	linux-kernel@...r.kernel.org, Liam Girdwood <lgirdwood@...il.com>,
	Takashi Iwai <tiwai@...e.com>,
	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/25/16 7:08 PM, Mark Brown wrote:
> On Wed, Feb 24, 2016 at 10:10:05AM -0600, Pierre-Louis Bossart wrote:
>> On 2/23/16 9:32 PM, Mark Brown wrote:
>
>>> 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.
>
> There's a lot of helpers like -fixed, -gate and so on - this sounds like
> you could probably use those helpers (there should be lots of examples
> in the kernel) or just implement a simple provider (see clk-provider.h)
> depending on how the control is mapped in.  If it's that simple just
> open coding a provider ought to do the job.  Then set up the client
> linkage with clkdev in some way that makes sense for your platform.

Yes there are documentation and helpers I looked into, but to the best 
of my limited knowledge not for the gate + dual-rate case. Then you jump 
to complicated configurations combining multiple base clocks that don't 
really make sense here. After one frustrating day of trying to wrap 100 
lines of code into the clock framework I gave up and kept the simple 
custom driver. There is a single client for this clock so I don't quite 
see the benefits/ROI of mapping a simple piece of hardware with a 
complex model.