linux-kernel - Re: [RFC] Linux common clock framework: device with many 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-next>] [day] [month] [year] [list]

Message-ID: <20140430231307.GA10250@e106331-lin.cambridge.arm.com>
Date:	Thu, 1 May 2014 00:13:07 +0100
From:	Mark Rutland <mark.rutland@....com>
To:	Jim Quinlan <jim2101024@...il.com>
Cc:	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"mike.turquette@...aro.org" <mike.turquette@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Linux common clock framework: device with many clocks

Hi,

On Wed, Apr 30, 2014 at 09:39:11PM +0100, Jim Quinlan wrote:
> In most examples of .dtsi files I have perused, a device is associated with
> typically one clock, maybe two.  In the SoC I'm working on, some devices
> need to turn off multiple clocks for PM, as many as 13.   The driver gets
> the clocks from the device tree, and when the driver wants to turn off
> clocks to the device, it loops through all 13 clocks.
> 
> I'm wondering if is possible to abstract a group of many clocks into one
> "software clock". Invoking clk_disable() on said software clock would
> effect the iteration of clk_disable() on all 13 of the clocks it governs.
>  Enabling would effect clk_enable() on all 13.  This would make the driver
> writer's life a little simpler.
> 
> I've looked at the Linux Common Clock Framework, and it doesn't really
> accommodate multiple active parents as it's somewhat contrary to its
> design.  Also, playing with the innards of clk.c is ill-advised.  Should I
> just stick to putting iteration over the clocks in all my drivers, or is
> there a better way?

This doesn't strike me as a DT issue. The DT should describe all the
clocks that a given block takes, and the representation of said clocks
in the DT is completely separate matter from the management of said
clocks in any given driver.

If you want a helpful abstraction for combining clocks for management
purposes you'd be better off talking to Mike Turquette (CC'd), as he's
in charge of the common clock framework.

Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/