Prev: [OOPS] apbuart.c: Two problems related to grlib_apbuart_configure()
Next: Resierfs random corruptions (probably related to cryptsetup or LVM)
From: Mark Brown on 27 May 2010 03:00
On Thu, May 27, 2010 at 12:01:00PM +0900, Paul Mundt wrote:

> Having said that, building on top of the regulator API for these cases
> wouldn't be that much work either, since it largely has all of the
> infrastructure in place (ie, the static consumer case).

On the other hand given that all you're really getting here is the
enable/disable tracking it's also pretty easy to just copy.

> > It's perfectly sensible for the power domain to be a regulator consumer,
> > but having the individual consumer devices be regulator consumers seems
> > non-obvious.

> The common case on SH is that certain blocks are only available in
> certain power domains, while the on/off control remains uniform (albeit
> periodically ineffectual) regardless of state. We also don't have any
> ability to regulate voltage outside of things like PCMCIA.

That's also the case for the power domains on ARMs at the minute, though
the bus control element is pretty common and sometimes gets rolled in to
the operating modes since it's the same IP blocks that share the
resources.

> On/off control in this context is completely orthoganol from clock
> control in that many peripherals without a specific input clock still
> implement power gating in the same way as those that do (this is the case
> for things like the L2 cache, TLB, breakpoint controller, etc). These are
> presently handled through the clock API largely because there was really
> no better fit for them at the time.

Yup, that's pretty common. The clocking stuff mostly comes into play
when your operating points also include an element of control for the
buses that the devices are hanging off - you end up doing DVFS for the
blocks, normally over the full block rather tha individual blocks. It's
this stuff that usually has some crossover with regulators, though
mostly as consumers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3 4
Prev: [OOPS] apbuart.c: Two problems related to grlib_apbuart_configure()
Next: Resierfs random corruptions (probably related to cryptsetup or LVM)