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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAPtuhTissRRQ6bPG0pp_e-NZ+ReaMtxWefAGq2kjFEcdmh_LEg@mail.gmail.com>
Date:	Fri, 16 May 2014 12:23:37 -0700
From:	Mike Turquette <mturquette@...aro.org>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Jim Quinlan <jim2101024@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] Linux common clock framework: device with many clocks

On Wed, Apr 30, 2014 at 4:13 PM, Mark Rutland <mark.rutland@....com> wrote:
> Hi,

Thanks for Cc'ing me Mark.

>
> 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.

Jim emailed me privately. Here is my response for posterity:



On Wed, May 7, 2014 at 8:59 AM, Jim Quinlan <jquinlan@...adcom.com> wrote:
> Hi Mike,

Hi Jim,

<snip>

> 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 on/off
> clocks to the device, it loops through all 13 clocks.

Is it possible for you to share a data sheet or TRM for this part? I'd
like to better understand your 13 clock requirement.

Is your device driver upstream? If not, can you share a link to bcom's
public vendor git tree with the driver in question?

> 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.

I oppose "software clocks", "virtual clocks" or any kind of struct clk
that doesn't map onto real clock hardware directly.

> Enabling would effect clk_enable() on all 13.  This would make the driver
> writer's life a little simpler.

What you are asking for is an abstraction. We already have this in the
form of Runtime PM where a driver calls pm_runtime_get() and
pm_runtime_put() without having to worry about the details of enabling
and disabling those 13 clocks. Runtime PM is *the* abstraction you are
looking for.

You should check out the RPM stuff as well as the power_domain and
gen_pd stuff. OMAP, SH-Mobile and Ux500 have interesting
implementations of all of this stuff for rather complex SoCs.

> 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?

Can you elaborate on "multiple active parents"? What does that mean?

Regards,
Mike



>
> 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/