public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Amit Kucheria <amit.kucheria@nokia.com>
To: ext Jon Loeliger <jdl@freescale.com>
Cc: Matthew Locke <matthew.a.locke@comcast.net>,
	pm list <linux-pm@lists.osdl.org>,
	kernel list <linux-kernel@vger.kernel.org>
Subject: Re: PowerOP vs OPpoint
Date: Tue, 19 Sep 2006 10:44:05 +0300	[thread overview]
Message-ID: <1158651846.14353.8.camel@localhost> (raw)
In-Reply-To: <1158610046.6962.186.camel@cashmere.sps.mot.com>

On Mon, 2006-09-18 at 15:07 -0500, ext Jon Loeliger wrote:
> On Thu, 2006-09-14 at 04:22, Matthew Locke wrote:
> > Unfortunately, there are two efforts underway that makes this confusing 
> > and I think require a bit more than the short summary requested.  A one 
> > paragraph summary can't address the why and how.  This email briefly 
> > describes the why and the differences.
> > 
> > There are two main reasons for both these efforts:
> > - existing power management interfaces do not enable the power 
> > management features on the latest SOC's used in embedded mobile  
> > devices
> > - existing power management interfaces do not provide the API necessary 
> > to build power managers (userspace and/or kernel space) that optimize 
> > power consumption to level required by embedded mobile devices
> 
> So does it make sense to re-unify these two patch-sets
> into one common, more general patch-set first?  Might
> it make sense to do so in small, incremental steps that
> everyone can agree on as we go along?

That has been the idea. Maybe if you have better way to 'communicate'
with David Singleton (oppoint) since he refuses to be drawn into the
merge discussions.

> For example, maybe the very first thing to do is define
> some notion of general "operating point" that is a super-set
> of the cpufreq definition.   If we can define that structure
> maybe we can progress towards introducing and using it.

Yes, it is a good first step. Please comment on the PowerOP patches to
see if there is something in the OP notion that is missing in your
opinion.

> Totally side-step the kernel-user level stuff for a bit...
> Totally side-step the suspend/resume issues for a bit...

I believe the PowerOP patches from Eugeny and Matt do not touch
suspend-resume issues and make the kernel-userspace interface to define
OP as an optional patch.

Oppoing patches on the other hand touch those issues.

Regards,
Amit

-- 
Amit Kucheria <amit.kucheria@nokia.com>
Nokia

      reply	other threads:[~2006-09-19  7:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-14  9:22 PowerOP vs OPpoint Matthew Locke
2006-09-18 20:07 ` [linux-pm] " Jon Loeliger
2006-09-19  7:44   ` Amit Kucheria [this message]

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=1158651846.14353.8.camel@localhost \
    --to=amit.kucheria@nokia.com \
    --cc=jdl@freescale.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.osdl.org \
    --cc=matthew.a.locke@comcast.net \
    /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