linux-kernel - Re: [linux-pm] cpufreq terminally broken [was Re: community PM requirements/issues and PowerOP]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b324b5ad0609131650q1b7a78cfsa90e3fbe8d7b4093@mail.gmail.com>
Date:	Wed, 13 Sep 2006 16:50:43 -0700
From:	"David Singleton" <daviado@...il.com>
To:	"Greg KH" <greg@...ah.com>
Cc:	linux-pm@...ts.osdl.org,
	"kernel list" <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] cpufreq terminally broken [was Re: community PM requirements/issues and PowerOP]

Greg,
   here's a few paragraphs about the power management code I'm working on.
The OpPoint patch set is a fully functionaly power management solution,
from kernel operating state support to userland power manager.

OpPoint constructs operating points for all supported frequency, voltage
and suspend states for PC and SoC solutions running Linux.  OpPoint
does not break or replace cpufreq.  It leverages cpufreq code to provide
the same driver scaling functions when cpu frequency changes affect drivers.

(The ARM pxa27x patch uses the cpufreq scaling routines to scale the LCD
when frequencies are changed and works well when playing mpeg movies on
the LCD during frequency scaling operations).

The Operating Points in OpPoint are simply created at compile time, in
the same manner cpufreq tables are, and registered in
/sys/power/operating_states directory when the cpu is identified at boot time.

The states are ordered by name on their power consumption level from lowest
to highest so the power manager can operate correctly regardless of what
frequencies or voltages are associated with the lowest or highest
operating points.

There is no kernel interface to parse and create all the parameters
needed to create an operating point.  Platform specific information
is supplied to the oppoint structure through an ops vector of three
routines and a void * pointer to supply the platform specific data,
in the same manner drivers have a void * for their private data.

The ops vectors provide operating point specific functions to prepare
to change to a new operating point, transition to the target operating
point, and a finish transition routine to either notify driver that
the clocks have scaled and operation of bus and DMA traffic may continue.

OpPoint draws the line about what's needed in the kernel a bit differently
than Matt's PowerOp code.  OpPoint only puts operating point support in
the kernel.  Polices for operting states and classes of operating states
are left to the power manager, in userland.  This simplifies the
kernel code, no string parsers for operating point parameter construction,
and makes it easier to customize a solution by customizing the power
manager.

A power manager is supplied with the OpPoint patch set as well.  I borrowed
the cpuspeed deamon and made a simple patch that uses the new OpPoint
sysfs interface.  The daemon can be compiled as the original cpuspeed or
oppointd deamon depending on the users choice.  The daemon provides the
same functions as the cpuspeed daemon.

OpPoint is a fully functional solution ready for testing and evaluation
in Andrew's or your tree.

The kernel patches are available at:

        http://source.mvista.com/~dsingleton/2.6.1-rc6

the power manager source code and patch is available at:

        http://source.mvista.com/~dsingleton/oppointd

David
-
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/