linux-kernel - Re: [RFC PATCH] clk: add extension 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120531083131.GQ8026@tbergstrom-lnx.Nvidia.com>
Date:	Thu, 31 May 2012 11:31:31 +0300
From:	Peter De Schrijver <pdeschrijver@...dia.com>
To:	Felipe Balbi <balbi@...com>
CC:	Stephen Boyd <sboyd@...eaurora.org>,
	Russell King <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Mike Turquette <mturquette@...com>
Subject: Re: [RFC PATCH] clk: add extension API

On Thu, May 31, 2012 at 10:18:42AM +0200, Felipe Balbi wrote:
> * PGP Signed by an unknown key
> 
> On Thu, May 31, 2012 at 10:51:25AM +0300, Peter De Schrijver wrote:
> > On Wed, May 30, 2012 at 10:52:31AM +0200, Stephen Boyd wrote:
> > > On 5/29/2012 2:58 AM, Peter De Schrijver wrote:
> > > > Add an extension API for clocks. This allows clocktypes to provide extensions
> > > > for features which are uncommon and cannot be easily mapped onto normal clock
> > > > framework concecpts. eg: resetting blocks, configuring clock phase etc.
> > > 
> > > This seems rather generic. Why not add more specific APIs/concepts like
> > > clk_reset(), clk_set_phase(), etc.? If they don't map, maybe we should
> > > make them map.
> > > 
> > 
> > Some of those might be very SoC specific. Eg OMAP doesn't need software
> > controlled modulereset. I don't think we should add a new function to the
> 
> it depends on what you call modulereset. We have soft-reset logic hidden
> under the hood, it's done before device creation, so drivers (most of
> them) assume we're probe with the IP in reset state.
> 
> What I wonder most is if this should be done at the clock level or at
> the device level. In the end you reset the IP block, not the clock,
> right ?

Yes. but, every block has at least 1 clock and thus the mapping is identical
down to the register level. Ie. we could do this outside the clockframework,
but then we would have the keep a list of IDs (1 per module) which the drivers
can use to call some tegra reset function which would in the end use registers
in the same memory area to cause a reset. (the registers controlling
modulereset are interleaved with those controlling the enable/disable of the
main moduleclock and bitpositions are identical)

Cheers,

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