mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vitaly Wool" <vitalywool@gmail.com>
To: "David Singleton" <daviado@gmail.com>
Cc: "Greg KH" <greg@kroah.com>,
	linux-pm@lists.osdl.org,
	"kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: [linux-pm] cpufreq terminally broken [was Re: community PM requirements/issues and PowerOP]
Date: Thu, 14 Sep 2006 09:30:33 +0400	[thread overview]
Message-ID: <acd2a5930609132230u2e8fff88gc172da2504c854de@mail.gmail.com> (raw)
In-Reply-To: <b324b5ad0609131650q1b7a78cfsa90e3fbe8d7b4093@mail.gmail.com>

On 9/14/06, David Singleton <daviado@gmail.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

  reply	other threads:[~2006-09-14  5:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <450516E8.9010403@gmail.com>
     [not found] ` <20060911082025.GD1898@elf.ucw.cz>
     [not found]   ` <b0623b9bb79afacc77cddc6e39c96b62@nomadgs.com>
     [not found]     ` <20060911195546.GB11901@elf.ucw.cz>
     [not found]       ` <4505CCDA.8020501@gmail.com>
     [not found]         ` <20060911210026.GG11901@elf.ucw.cz>
     [not found]           ` <4505DDA6.8080603@gmail.com>
2006-09-11 22:56             ` Pavel Machek
2006-09-12  0:17               ` Mark Gross
2006-09-12  3:37                 ` Greg KH
2006-09-13 23:50                   ` [linux-pm] " David Singleton
2006-09-14  5:30                     ` Vitaly Wool [this message]
2006-09-14  5:55                     ` OpPoint summary Greg KH
2006-09-14  7:35                       ` [linux-pm] " Vitaly Wool
2006-09-14 16:55                       ` David Singleton
2006-09-14 17:03                       ` David Singleton
2006-09-14 17:07                       ` David Singleton
2006-09-14 17:25                         ` Auke Kok
2006-09-14 18:15                           ` [linux-pm] " Vitaly Wool
2006-09-14 18:17                           ` David Singleton
2006-09-17 17:48                         ` Pavel Machek
2006-09-18 14:33                           ` [linux-pm] " Richard A. Griffiths
2006-09-18 16:13                             ` Matthew Locke
2006-09-14 17:11                       ` David Singleton
2006-09-17  5:07                       ` David Singleton
2006-09-17 12:56                         ` Pavel Machek
2006-09-17 12:58                         ` Pavel Machek
2006-09-17 22:43                         ` [linux-pm] " Matthew Locke
2006-09-12  8:33                 ` cpufreq terminally broken [was Re: community PM requirements/issues and PowerOP] Pavel Machek
2006-09-12  9:10                   ` [linux-pm] " Vitaly Wool
2006-09-12  9:16                     ` Pavel Machek
2006-09-12  9:23                       ` Vitaly Wool
2006-09-14 15:04                     ` Mark Gross
2006-09-14 14:58                   ` Mark Gross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acd2a5930609132230u2e8fff88gc172da2504c854de@mail.gmail.com \
    --to=vitalywool@gmail.com \
    --cc=daviado@gmail.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®