linux-kernel - RE: [PATCH F 06/12] OMAP2/3 clock: every clock must have a clkdm

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

Message-ID: <alpine.DEB.2.00.0902050201250.8567@utopia.booyaka.com>
Date:	Thu, 5 Feb 2009 02:03:43 -0700 (MST)
From:	Paul Walmsley <paul@...an.com>
To:	"Woodruff, Richard" <r-woodruff2@...com>
cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.arm.linux.org.uk" 
	<linux-arm-kernel@...ts.arm.linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>
Subject: RE: [PATCH F 06/12] OMAP2/3 clock: every clock must have a clkdm

Hi Richard,

On Tue, 3 Feb 2009, Woodruff, Richard wrote:

> > Virtual clocks should soon be eliminated from the OMAP clock tree.  (
> > "Virtual clocks" is here used to refer a clock that does not have a
> > referent in the hardware; the usage of the term in the code is loose.)
> > So far as I know, all of the OMAP virtual clocks have either turned out to
> > be superfluous (and prone to spinlock recursion bugs), or to be better
> > implemented outside of the clock framework (such as the virtual OPP
> > clocks).  We've eliminated the former.  We should be able to eliminate the
> > latter in a few months.
> 
> What is your idea for replacement of virtual OPPs?
> 
> Especially on OMAP2 they were useful with tightly coupled clock sets.  
> Some later versions of 2420 were characterized such that some of the 
> dependencies could be ignored but that is not the case for all of them.  
> The centerline design as I understand it wasn't for this. It just 
> happened that enough margin was there in some binn'ed lots to do this.

The rates and voltages would still be tightly coupled; the OPP change just 
wouldn't be handled by the clock framework.  Will send patches to you once 
the code is fully baked, the patches would probably the best thing to 
comment on...


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