linux-kernel - Re: [PATCH 02/26] clk: Replace __clk_get_num_parents with clk_hw_get_num

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 19 Sep 2015 21:03:36 -0500
From:	Scott Wood <scottwood@...escale.com>
To:	Stephen Boyd <sboyd@...eaurora.org>
CC:	Mike Turquette <mturquette@...libre.com>,
	<linux-kernel@...r.kernel.org>, <linux-clk@...r.kernel.org>,
	Boris Brezillon <boris.brezillon@...e-electrons.com>,
	Chao Xie <chao.xie@...vell.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	Tomasz Figa <tomasz.figa@...il.com>,
	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Emilio López <emilio@...pez.com.ar>,
	Tero Kristo <t-kristo@...com>,
	Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH 02/26] clk: Replace __clk_get_num_parents with
 clk_hw_get_num_parents()

On Fri, 2015-09-18 at 16:18 -0700, Stephen Boyd wrote:
> On 09/18, Scott Wood wrote:
> > On Fri, 2015-09-18 at 08:56 -0700, Stephen Boyd wrote:
> > > Is there any reason why we can't use DT OPPs for the code that
> > > you're patching here? At a quick glance it looks like we could
> > > leave this driver behind and move to cpufreq-dt.c and then use
> > > OPPs to populate the possible frequencies and affinity.
> > 
> > One reason is that I want to maintain compatibility with existing device 
> > trees.
> > 
> > However, even ignoring that, cpufreq-dt doesn't seem like a good fit.  It 
> > requires specifying voltage, which is beyond the scope of the DFS 
> > mechanism 
> > on these chips. 
> 
> Hm.. cpufreq-dt doesn't mandate voltage setting. Maybe I'm
> reading the code wrong though.

I was referring to the device tree binding, but didn't look far enough to see 
the v2 binding.

> > It also requires assembling a list of valid frequencies in the device 
> > tree, 
> > which is not knowable at compile-time as it depends on how PLLs were 
> > configured in the reset control words, and in some cases the revision of 
> > the 
> > SoC due to errata -- and even if that information were constant, it would 
> > be 
> > extra maintenance work to keep the redundant information accurate, and if 
> > errors were introduced into the device tree we'd have the same sort of 
> > compatibility problems I'm trying to fix with
> > http://patchwork.ozlabs.org/patch/507621/
> > 
> 
> Ok, fair enough. The v2 bindings for OPPs are still progressing
> and they're moving towards a way to consolidate data that might
> work here. I'm not sure though, Viresh is probably better to ask.

If you mean operating-points-v2, based on the current binding document, I'm 
not sure how that addresses the above issues.

> Just one more final thought, but what if the clock provider
> populated the OPPs for the CPU devices and the cpufreq-dt was
> used? I don't know how the code is structured or if this QorIQ
> clock controller is used for more than just CPU clocks, but that
> may be another option where provider APIs are available.

I'm not sure how to do that, and it's not clear what the benefit would be on 
this hardware.  Pretty much all we need the cpufreq driver to do is to look 
at a clock with multiple parents, and select from the options that are 
available.

-Scott

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