Re: So, what's the status on the recent patches here?

Igor Stoppa
2006-08-16T12:58:09Z

On Tue, 2006-08-15 at 22:04 +0300, ext Dave Jones wrote:
> On Tue, Aug 15, 2006 at 01:35:15PM +0300, Amit Kucheria wrote:
>
> > Here is my shot at providing a 10,000ft view:
> >
> > a. For embedded platforms, cpufreq just does not cut it when
> specifying
> > an operating point for the device. These platforms use tuples such
> as
> >
> > <voltage, pll_freq, core1_freq, core2_freq, interconnect_freq>
> >
> > to signify an 'operating point'. Note that core1 and core2 can be
> > totally different processors e.g. ARM and DSP. x86 platforms hide
> this
> > complexity behind ACPI.
>
> If there are dependancies inherently linking core1 and core2, cpufreq
> should already be programming both parts. For example, the SA1100
> driver programs both CPU and SDRAM controller. If there isn't any
> dependancy
> between them, I don't see the attraction of creating an artificial one
> in the way suggested for no real purpose.
>
> Things like voltage and frequency are closely tied together, so
> offering
> any means of controlling them independantly makes no sense afaics.
Yet a certain subsystem (for example an onboard camera, in a phone)
might require a higher voltage when it's active, effectively loosening
the tight coupling between freq and voltage that the porcessor is
enforcing.
>
> > b. The clocking and voltage dependency tree in embedded devices can
> be
> > summarised in the clock framework ( find ./arch -name clock* ) and
> > soon-to-be-available voltage framework. These is again done to
> large
> > extent by ACPI on x86.
>
> Of the 14 x86 cpufreq drivers, 3 of them _optionally_ use ACPI.
> powernow-k7 for example doesn't use it, and is possibly one of the
> most
> stable cpufreq drivers we've had in the tree (for x86 at least).
>
> > d. In the end, all this is leading to an interface for a user-space
> > policy manager that will control _system_ power state based on
> > constraints imposed by HW peripherals or on policies implemented by
> > device manufacturer/distro maintainer.
>
> How does that interface look from a userspace point of view ?
> Hopefully not anything like the tuple described above.
> Why would userspace ever care about "interconnect freq" ?
>
> Userspace cares about "save power" or "go fast".
> Historically, I wish we had never exposed frequencies, but instead
> a performance percentage, so that the various userspace tools
> didn't have to care about things like 'what frequencies are
> available'.
> Adding the same mistake for voltages doesn't strike me as a fantastic
> idea.

Such generic definitions are not enough for embedded userspace, the
complexity of the tuning is expected and accepted as long as it allows
to leverage the HW performance.
>
> > At this point, PowerOP is an optional component in mainline tree.
> > Cpufreq drivers can _choose_ to use it or not. But now embedded
> > platforms can do the PM dance in a consistent way.
>
> That's about the only part I really like so far. The option to opt-out
> where it makes absolutely no sense to pointlessly abstract stuff
> (which for x86 seems to be the case). For ARM, I'm going to leave
> Russell to comment/review.
>
> Dave
>
> --
> http://www.codemonkey.org.uk
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>
>
--
Cheers,
Igor

Igor Stoppa (Nokia M - OSSO / Tampere)