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: <acd2a5930609132230u2e8fff88gc172da2504c854de@mail.gmail.com>
Date:	Thu, 14 Sep 2006 09:30:33 +0400
From:	"Vitaly Wool" <vitalywool@...il.com>
To:	"David Singleton" <daviado@...il.com>
Cc:	"Greg KH" <greg@...ah.com>, 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]

On 9/14/06, David Singleton <daviado@...il.com> wrote:

> OpPoint constructs operating points for all supported frequency, voltage
> and suspend states for PC and SoC solutions running Linux.

...producing very hard-to-manage and long-to-search lists (did you
consider using trees for that BTW?)
Also, you'll have to maintain different lists for differemt
modifications of the same SoC. That will complicate the code prety
much.

> (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).

PXA is a hi-end stuff for embedded, so that might be not very illustrative.

> 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.

So do you say there's no *kernel* interface to create OPs even?
Assume you've got a device which needs scaling and which driver may be
compiled as a module. Thus, you'll have to include OPs that reflect
this driver's clock scaling at the kernel compile time. Which is
nonsense in a way because the clock itself should be switched on
during probe() operation of the device driver.

> 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.

That sounds nice :)

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

Can you please list the SoCs which this solution has been tested on?

Thanks,
   Vitaly
-
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/