Re: [RFC PATCH] clk: add extension API

[Peter De Schrijver <pdeschrijver@nvidia.com>]

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.