Re: So, what's the status on the recent patches here?

On Thu, 2006-08-31 at 15:22 -0400, ext Preece Scott-PREECE wrote:
> > [mailto:linux-pm-bounces <at> lists.osdl.org] On Behalf Of Amit Kucheria
> > 
> > > >
> > > > - latency is not an attribute of a certain operating point but a
> > > function of
> > > > two arguments - current operating point and a point we 
> > are goint to 
> > > > switch to. Therefor latency just does not belong to 
> > 'struct powerop'
> > > 
> > > I disagree.
> > 
> > Problem is that you disagree without giving your reasons. 
> > Here is another reason putting latency into your operating 
> > point definition isn't going to fly:
> > 
> > http://lwn.net/Articles/196900/ <--- An API for specifying 
> > latency constraints
> > 
> > http://lwn.net/Articles/197282/
> ---

<snip>

> So, if a driver had set acceptable_latency to 300ms, the
> Power-Management policy manager could look at the range of
> available Ops and pick the lowest-power OP that met the
> expected load and would also meet the required latency
> guarantee. [And note that the acceptable latency has to include

Re: So, what's the status on the recent patches here?

| From Amit.Kucheria <at> nokia.com Fri Sep  1 03:14:57 2006
| 
| On Thu, 2006-08-31 at 15:22 -0400, ext Preece Scott-PREECE wrote:
| ...
| > So, if a driver had set acceptable_latency to 300ms, the
| > Power-Management policy manager could look at the range of
| > available Ops and pick the lowest-power OP that met the
| > expected load and would also meet the required latency
| > guarantee. [And note that the acceptable latency has to include
| > both the resume time and whatever part of suspend happens with
| > interrupts blocked and can't be aborted.]
| 
| Thinking of it that way, latency is possibly useful. Needs more
| thinking. But what latency values are associated with the OP? The values
| from the spec sheet provided by the silicon vendor do not take into
| account the other operations necessary before you can safely switch to a
| new OP. Some of these operations require indeterminate amount of time.
---

That's something the system designer would have to work out and provide
as part of the information associated with each possible OP transtion
(that is, it would potentially be different for each (currentOP, newOP)
pair).

The system designer would also need to decide whether the latencies had
to be worst-case guarantees or whether the system could tolerate
occasionally missing a latency deadline. This would vary depending on
the system (a heart pacemaker might find deadlines to be more important
than a PDA).

[patch 2.6.18-rc-mm] PM: platform_bus and late_suspend/early_resume

Teach platform_bus about the new suspend_late/resume_early PM calls,
issued with IRQs off.  Do we really need sysdev and friends any more,
or can janitors start switching its users over to platform_device so
we can do a minor code-ectomy?

Signed-off-by: David Brownell <dbrownell <at> users.sourceforge.net>

Index: g26/drivers/base/platform.c
===================================================================
--- g26.orig/drivers/base/platform.c	2006-06-28 22:02:04.000000000 -0700
+++ g26/drivers/base/platform.c	2006-08-31 19:36:07.000000000 -0700
 <at>  <at>  -505,12 +505,36  <at>  <at>  static int platform_match(struct device 
 	return (strncmp(pdev->name, drv->name, BUS_ID_SIZE) == 0);
 }

-static int platform_suspend(struct device * dev, pm_message_t state)
+static int platform_suspend(struct device *dev, pm_message_t mesg)
 {
 	int ret = 0;

 	if (dev->driver && dev->driver->suspend)
-		ret = dev->driver->suspend(dev, state);
+		ret = dev->driver->suspend(dev, mesg);
+
+	return ret;
+}
+
+static int platform_suspend_late(struct device *dev, pm_message_t mesg)
+{

Re: [patch 2.6.18-rc-mm] PM: platform_bus and late_suspend/early_resume

On Fri, Sep 01, 2006 at 08:51:14PM -0700, David Brownell wrote:
> 
> Teach platform_bus about the new suspend_late/resume_early PM calls,
> issued with IRQs off.  Do we really need sysdev and friends any more,
> or can janitors start switching its users over to platform_device so
> we can do a minor code-ectomy?

I don't think we need it anymore, but you should ask the cpu people,
they seem to love sysdev for some odd reason (probably because they
finally get to create a sysfs file, like all the cool driver kids have
been doing for years...)

If you get their ok, I'm fine with getting rid of it.

thanks,

greg k-h

linux-pm list AWOL?

Just checking ... I've not received any postings on this list
since maybe 12-August.  Yet I see the list archive gets updated.

- Dave

Re: So, what's the status on the recent patches here?

Hi!

On Thu 2006-08-31 16:44:12, Amit Kucheria wrote:
> On Thu, 2006-08-31 at 00:36 +0200, ext Pavel Machek wrote:
> > On Wed 2006-08-30 14:00:53, Amit Kucheria wrote:
> > > But PowerOP would allow SoC-based systems to tune the operating points
> > > to get the most out of their top-10 use-cases and sleep modes.
> > 
> > Question is: can we get similar savings without ugly interface powerop
> > presents?
> 
> If I have understood correctly, your main objection is to defining new
> operating points from userspace?

Well, that is big objection, but not my main one. I believe that "new
operating points from userspace" are non-starter. "So obviously wrong
that noone would merge that".

> The only other interface is the actually setting of a (named) operating
> point and that is _required_ to do anything useful.

No, they are not.

We already have interface for selecting cpu frequency. Lets keep it.

We may need new interface for selecting DSP frequency. If that is
needed, lets *add* that interface.

We may need new interface to say if usb needs to be enabled or
not. How to do that interface right is a question, but lets say we

Re: linux-pm list AWOL?

On Thu, 31 Aug 2006, David Brownell wrote:

> Just checking ... I've not received any postings on this list
> since maybe 12-August.  Yet I see the list archive gets updated.
> 
> - Dave
> _______________________________________________
> linux-pm mailing list
> linux-pm <at> lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm

I've been getting plenty of messages from the list reflector.  In fact, 
that's how I received this one.

Alan Stern

[PATCH] PowerOP, Intro 0/2

The PowerOP Core provides completely arch independent interface
to create and control operating points which consist of arbitrary
subset of power parameters available on a certain platform.

PowerOP Core upper layer interface provides the following capabilities:
- to register an operating point by passing an identifier of the point
represented by a string and arbitrary subset of power parameters available on a
certain platform by a string (parameter name) and value pairs.
- to unregister operating point by name
- to set operating point by name
- to get values of arbitrary subset of platform power parameters associated
this  a point (point is passed by name or NULL to get current parameter values
from hw)
- _optional_ SysFS interface. If SysFs interface is enabled each operating point
registered with PowerOP core appears under /sys/power/. /sys/power/≤op>/ will
contain an attribute for each power parameter. Power parameters are rw. An
operating point may be activated by writing its name to /sys/power/active. The
hardware power parameters currently set may be read via /sys/power/hw/, a
special operating point that reads parameter attribute values from hardware, for
diagnostic purposes.
Operating points creation with help of SysFS interface is _optional_
_configurable_ feature. Operating points are created by writing the name of the
operating point to /sys/power/new.  This may be a job for configfs.

PowerOP get and register point APIs use name/value pairs for the power
parameters which eliminate the need for data structure sharing between
the PM core and consumers of the PowerOP API.   Earlier versions
required include/asm-xxx/power_params.h to be included in both places.

This also enables a variable argument list for the registration and get

[PATCH] PowerOP, PowerOP Core, 1/2

The PowerOP Core provides completely arch independent interface
to create and control operating points which consist of arbitrary
subset of power parameters available on a certain platform.
Also, PowerOP Core provides optional SysFS interface to access
operating point from userspace.

The PowerOP Core provides completely arch independent interface
to create and control operating points which consist of arbitrary
subset of power parameters available on a certain platform.
Also, PowerOP Core provides optional SysFS interface to access
operating point from userspace.

PowerOP, Whatchanged/Issues/TODO 2/2

whatchanged:
- optional sysfs interface is added
- code is moved under kernel/power
- Greg's comments on kobject and coding style are addressed

todo/issues:
- better implementation for getting registered operating point names
- move string parsing into powerop generic code
- configfs for operating points creation from user space