linux-kernel - Re: [alsa-devel] [RFC PATCH] mfd: arizona: Add gating of external MCLKn clocks

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:   Tue, 23 Aug 2016 18:44:57 +0200
From:   Sylwester Nawrocki <s.nawrocki@...sung.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
        alsa-devel@...a-project.org, lee.jones@...aro.org,
        linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel] [RFC PATCH] mfd: arizona: Add gating of external
 MCLKn clocks

On 08/22/2016 07:41 PM, Mark Brown wrote:
> On Mon, Aug 22, 2016 at 07:22:47PM +0200, Sylwester Nawrocki wrote:
> 
>> If we provided an interface like:
> 
>> struct clk * arizona_get_mclk(struct arizona *arizona, int id);
>> void arizona_put_mclk(struct clk *clk);
> 
>> the machine driver would need to get hold of struct arizona*,
>> which is not that straightforward if we are given only CODEC
>> of_node (it can be a child of I2C or SPI bus).
> 
> We could add an interface for the machine driver to retrieve a clock
> from the CODEC as a transition measure...

That works for me. Is the long term plan to control the CODEC's clocks
through the common clock API in machine drivers and phase out calls
like snd_soc_codec_set_pll(), snd_soc_codec_set_sysclk()?

>> Then how about specifying MCLK in the sound node and using
>> regular devm_clk_get()?
> 
> This is what we're trying to avoid?

Indeed, sorry, I just started getting confused of what are acceptable
tradeoffs here.