[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120531120057.GA15786@sirena.org.uk>
Date: Thu, 31 May 2012 13:00:58 +0100
From: Mark Brown <broonie@...nsource.wolfsonmicro.com>
To: Peter De Schrijver <pdeschrijver@...dia.com>
Cc: Felipe Balbi <balbi@...com>, Russell King <linux@....linux.org.uk>,
Stephen Boyd <sboyd@...eaurora.org>,
"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 11:31:31AM +0300, Peter De Schrijver wrote:
> > 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)
One option which doesn't really need anything from the clock API is for
the module resets to restore these registers so the clock API never
notices anything changed.
--
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/
Powered by blists - more mailing lists