mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Matthew Locke <matt@nomadgs.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-pm@lists.osdl.org, "Scott E. Preece" <preece@motorola.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [linux-pm] [PATCH] PowerOP, PowerOP Core, 1/2
Date: Sun, 24 Sep 2006 14:33:23 -0700	[thread overview]
Message-ID: <6c3c9c9fa4961ca081c2742684201418@nomadgs.com> (raw)
In-Reply-To: <20060923111805.GF20778@elf.ucw.cz>


On Sep 23, 2006, at 4:18 AM, Pavel Machek wrote:

> Hi!
>
>> Note that I don't think PowerOp would cover all devices. In fact, I
>> think most devices would remain autonomous or controlled as part of
>> specific subsystems. The only things that PowerOp would bundle 
>> together
>> would be things that aren't independent (and may not even be visible 
>> as
>> "devices" in the usual Linux sense), but that have to be managed
>> together in changing frequency/voltage. At least, that's the way I
>> imagined it would work.
>
> Well, two objections to that
>
> a) current powerop code does not handle 256 CPU machine, because that
> would need 256 independend bundles, and powerop has hardcoded "only
> one bundle" rule.

The 256 is only a temporary implementation limitation.

>
> b) having some devices controlled by powerop and some by specific
> subsystem is indeed ugly. I'd hope powerop would cover all the
> devices. (Or maybe cover _no_ devices). Userland should not need to
> know if touchscreen is part of SoC or if it happens to be independend
> on given machine.

PowerOP does *not* cover devices.  It covers system level parameters 
such clocks, buses, voltages.

>
> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
>


  reply	other threads:[~2006-09-24 21:33 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-22 20:34 Scott E. Preece
2006-09-23 11:18 ` Pavel Machek
2006-09-24 21:33   ` Matthew Locke [this message]
2006-09-24 21:45     ` Pavel Machek
  -- strict thread matches above, loose matches on Subject: below --
2006-09-22 21:10 Woodruff, Richard
2006-09-22 20:28 Scott E. Preece
2006-09-22 21:18 ` Vitaly Wool
2006-09-19 21:37 Scott E. Preece
2006-09-22 14:11 ` Pavel Machek
2006-09-22 14:48   ` Igor Stoppa
2006-09-19 19:46 Scott E. Preece
2006-09-19 20:06 ` Eugeny S. Mints
2006-09-22 14:09 ` Pavel Machek
2006-09-26 21:45   ` Matthew Locke
2006-09-14 14:37 Eugeny S. Mints
2006-09-18 10:44 ` [linux-pm] " Pavel Machek
2006-09-18 11:32   ` Eugeny S. Mints
2006-09-18 19:58     ` Eugeny S. Mints
2006-09-18 20:07       ` Vitaly Wool
2006-09-19 18:22     ` Pavel Machek

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=6c3c9c9fa4961ca081c2742684201418@nomadgs.com \
    --to=matt@nomadgs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=pavel@ucw.cz \
    --cc=preece@motorola.com \
    /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®