linux-kernel - Re: [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider API

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]

Date:	Wed, 27 Aug 2014 02:35:27 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Mike Turquette <mturquette@...aro.org>
Cc:	Andrew Lunn <andrew@...n.ch>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Viresh Kumar <viresh.kumar@...aro.org>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	linux-kernel@...r.kernel.org, Rabin Vincent <rabin@....in>,
	Tomasz Figa <t.figa@...sung.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v7 3/8] cpufreq: kirkwood: Remove use of the clk provider
 API

> One final thought I have had is that it might be a good idea to have a
> mux clock which represents the clock signal that feeds into the cpu. It
> seems that a mux is exactly what is going on here with cpuclk rate and
> ddrclk rate.

I did think of this when i implemented the cpufreq driver. What makes
it hard is that this bit is mixed in the same 32 bit register as the
gate clocks. It would mean two clock providers sharing the same
register, sharing a spinlock, etc. And the gating provider is shared
with all mvebu platforms, dove, kirkword, orion5x, and four different
armada SoCs. So i'm pushing complexity into this shared code, which
none of the others need. Does the standard mux clock do what is
needed? Or would i have to write a new clock provider?

> I even wonder if it is even appropriate to model this transition with a
> clock enable operation? Maybe it is only a multiplex operation, or
> perhaps a combination of enabling the powersave clock and changing the
> parent input to the cpu?
> 
> My idea is instead of relying on a cpufreq driver to parse the state of
> your clocks and understand the multiplexing, you can use the clock
> framework for that. In fact that might help you get one step closer to
> using the cpufreq-cpu0.c/cpufreq-generic.c implementation.

So you want the whole disabling of interrupt delivery to the cpu,
flipping the mux, wait for interrupt and re-enabling of interrupt
delivery to the cpu inside the clock provider? That is way past a
simple mux clock.

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