Re: [RFC] A New Power Management API

David Brownell
2005-04-17T22:29:17Z

[-- Attachment #1: Type: text/plain, Size: 6478 bytes --]

On Sunday 17 April 2005 1:48 pm, Adam Belay wrote:
> On Sat, 2005-04-16 at 11:24 -0700, David Brownell wrote:
> > On Friday 15 April 2005 11:54 am, Adam Belay wrote:
> > >
> > > I'm not familiar with how we would control such a device from software.
> > > If you think more than _ON and _OFF would be necessary, I could
> > > certainly revise this code.
> >
> > Other similar devices include the TI TPS6501x series:
> > ...
> > Yes, more than "on" and "off" is necessary. ...
>
> Ok, so I think each power plane (or LDO or whatever) would be a power
> resource, not the controller itself.

Maybe. I suspect packaging it that way would seem like "extra"
work, but I won't pretend to know all the right answers for how
to talk to such chips. One person asking me how to handle a
similar chip on a Motorola platform told me he expected to get
more than a few arrows in his back ... and I was kind of worried
about starting a new drivers/i2c/power subtree! ;)

What I've seen so far is that the LDO setup is just board-specific
init logic of the "write once and forget" variety. Which means
that software basically ignores it later ... although it's possible
that some LDOs might be adjusted to lower voltages during certain
system states.

Likewise with GPIOs used to switch power supplied through the LDOs:
board-specific logic kicking when the various drivers need to do
their thing.

> > One small point to notice: this is an I2C driver, but it needs
> > to initialize quite early on most boards, since it's used to power
> > up other devices (including often the DSP). So the system init
> > sequence has been adjusted to make that behave: I2C initializes
> > early (subsys_initcall), as does this specific I2C driver.
>
> Yeah, sounds like that could get rather tricky.

Not really, but I thought it was worth pointing out. It's an example
of a case where PC-ish assumptions can cause surprises. (Another
would be assuming PM registers can be accessed in IRQ context... or
that ACPI handles any of that!)

> > > I could see something like having a clock put at a slower
> > > speed, so maybe we do need more than on and off.
> >
> > How would you handle the ARM clock trees? E.g. the stuff you'll
> > find in arch/arm/mach-omap/clock.c in 2.6.12-rc2? (Older versions
> > are very similar, the latest version in the linux-omap tree above
> > can be made to disable unused clocks at boot time.) My initial
> > thought was that these specific resources wouldn't show up as any
> > kind of power resource, since they're already managed properly
> > (by clk_use/clk_unuse) as drivers activate and de-activate.
>
> So I think each clock could be a power resource. It looks like the
> current code isn't doing much more than turning them on and off.

They should clk_use()/clk_unuse(), and automatically handle the
activation/deactivation of parent clocks. Some clocks are shared
between multiple devices ... so "on/off" doesn't suffice, those
devices' drivers rely on the clock framework to coordinate. (Or
were you thinking that on/off would match use/unuse? There's no
point to separate enable/disable calls IMO.)

If there were strong advantages to fitting those into a new resource
framework, that could surely be done. I think any driver actually
touching a clock will be platform-specific, but there's not much
point to having different clock APIs on every platform. (Other
than experimenting, which could be useful for a while yet.)

> I'm
> curious about changing the frequency. In what cases might this happen?

One example I noticed recently: the driver for an audio codec needed
to change the frequency driving that chip. That's for a clock that goes
off-chip. Likewise setting clocks used to drive LCD controllers at a
specific speed; and in another case, setting the clock to match what
was used on an internal bus. Again this mostly seems like init-and-forget.

There's also cpufreq style stuff. If someone implements that for OMAP
it'll need to account for a variety of constraints. For now it seems
that just idling the CPU -- or putting it into big sleep -- is enough
of a win for power saving that cpufreq may not be much wanted.

> Would it be related to power state of the device, or could the frequency
> be changed without changing the state?

Frequency affects power consumption in device-specific ways, but so
far the focus in Linux is just to affect it by ensuring that clocks
are off unless they're needed. That includes enabling hardware clock
gating support. (OMAP automates clock gating a lot more than other chips
I've had occasion to look at.) I suspect _most_ boards expect a single
frequency for each device (plus zero-Hertz).

> Is the frequency a specific
> requirement of the device that isn't intended to be changed at all?

That's specific to the device and its driver. There are lots of drivers
that don't much care about details of frequencies ... only that clocks
fed to their various busses and bridges are all in "safe" ratios. And
there are sometimes also external constraints, e.g. with that codec or
with USB.

> I think adding more than on and off might get to be too complicated, but
> clearly every power resource we're interested in has an on/off
> capability. If we really need this sort of functionality to be handled
> by the power management subsystem, then maybe we could have a "struct
> power_clock" with a "struct power_resource" inside of it? Maybe the
> drivers should be handling these sort of things on their own? I'm
> interested in how drivers will be interacting with this.

Me too. I think ARM has the best-worked Linux clock infrastructure
just now, and the model there is that drivers manage their clocks
explicitly and without any formal platform_device.resource entries.
(Should power resources be treated like any other resources?)

That's one reason I pointed you at OMAP's clock code. It's working
reasonably well right now, and it's a case where simple APIs to clock
trees won't work well ... e.g. PXA, or AT91, chips have really simple
clock trees. More like mach-s3c2410/clock.c in 2.6.current.

OMAP's is complex (deep hierarchy, autogating, very flexible) and is
also chip-specific at the detail level. For example, the USB host
clock is set up differently on 1510/590 vs later chips; and those
later ones have two different MMC controllers, independently clocked.
So it's a rich enough real-world-Linux example to chew on a while. :)

- Dave