community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel,

Pavel Machek wrote:
 >
[snip]
 >> Are you arguing that the cpufreq interface be morphed to support power
 >> op applications?
 >
 > No. I'm arguing that
 >
 > * cpufreq interface should be used for changing cpu frequency
the patch set i sent out has cpufreq used for changing cpu frequency,
hasn't it?
 > * additional interfaces should be created for changing memory clock
 > etc.
the patch set I sent out allows to extend cpufreq interface to control
memory clock, etc by building all necessary additional pieces on top of
PowerOP Core layer which in conjunction with PM Core and clock/voltage
framework layers provides PM stack with well defined loosely coupled
interfaces between layers and PM functionality logically spread across
the layers instead if having everything mixed in one piece as cpufreq
does.
 > * existing interfaces should be used for turning devices on/off (and
 > new ones created when old ones do not exist)
PowerOP patch set for now is presenting just main basic block but
integration with devices suspend/resume, constraints, etc is next steps.
For now exactly existing interfaces for turning devices on/off may be used
in conjunction with poweop patch set although the interfaces may be
improved in the future if necessary
 > * powerop should take a look what userspace wants, and just close
 > closest point to that.
PowerOP is interface which allows wide range of interfaces to be built on
top of it including the interface you mentioned here. PowerOP/cpufreq
integration patch demonstrates this.

can we eventually start talking more close to the code rather than
speculating without it?

Pavel, if you feel that comments I put here don't correspond
to what my code is doing please show this by commenting the patch set
code.

Thanks,
	Eugeny
 > 							Pavel
 >

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

On Mon 2006-09-11 11:57:28, Eugeny S. Mints wrote:
> [snip]
> >> Are you arguing that the cpufreq interface be morphed to support power
> >> op applications?
> >
> > No. I'm arguing that
> >
> > * cpufreq interface should be used for changing cpu frequency
> the patch set i sent out has cpufreq used for changing cpu frequency,
> hasn't it?

I was talking about kernel<->user interface.

You did echo low > something to change CPU frequency, IIRC.

> can we eventually start talking more close to the code rather than
> speculating without it?

Lets get kernel<->user interface right, first. You'll need to create
Documentation/ entries for your interfaces, eventually, so lets do
that, first, and then talk about code. Oh and it would be nice to cc
lkml on that document, too. New kernel<->user interface is not
decision taken lightly.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
> Hi!
> 
> On Mon 2006-09-11 11:57:28, Eugeny S. Mints wrote:
>> [snip]
>>>> Are you arguing that the cpufreq interface be morphed to support power
>>>> op applications?
>>> No. I'm arguing that
>>>
>>> * cpufreq interface should be used for changing cpu frequency
>> the patch set i sent out has cpufreq used for changing cpu frequency,
>> hasn't it?
> 
> I was talking about kernel<->user interface.
me too. PowerOP is inkernel interface but which _allows_ to build various
different kernel<->user interfaces on top of it. This PowerOP _advantage_ allows 
community to experiment with various kernel<->user interfaces on top and 
eventually end up with the best solution. The solution can be either one 
universal, agreed by community kernel<-> user interface on top or I can imaging 
the approach when kernel<-> user interfaces on top are configurable feature and 
system designer choses kernel<->user interface which fits best the systems 
he/she builds.
> 
> You did echo low > something to change CPU frequency, IIRC.
My patch set presents two different interfaces built on top of PowerOP - cpufreq 
and sysfs interfaces. So _no_, PowerOP is not all about 'echo low > something'. 
Such kernel<-> user interface is  an _option_. PowerOP supports full _legacy_ 
cpufreq interface as another option - please check out PowerOP/cpufreq 
integration patch set. The goal is either to end up with one kernel<->user 
interface which addresses both pc world and embedded world requirements to 
user<->kernel interface _or_ - as an alternative I'd prefer - have these 
kernel<->user interfaces configurable: if you build laptop  system - chose 
cpufreq interface on top of PowerOP; if you build embedded - chose sysfs 
interface. But with the approach when everything is built on top PowerOP[PM 
Core, Clock framework] you just eliminate all unnecessary duplication if PM 
functionality in PM  stack.

Just in case you are confused by the fact I didn;t send out PowerOP/cpufreq 
integration patch along with the last PowerOP Core take: PowereOP Core patch I 
sent out in the last take is a standalone functional piece. PowerOP/cpufreq 
integration patch is just a further extension and applies to the most recent 
POwerOP Core without any changes so there was no reason to resend 
PowerOP/cpufreq integration.
> 
>> can we eventually start talking more close to the code rather than
>> speculating without it?
> 
> Lets get kernel<->user interface right, first. You'll need to create
> Documentation/ entries for your interfaces, eventually, so lets do
> that, first, and then talk about code.
Documentation/ piece is fine, I will add it. But I feel I put quite detailed 
comments along with the patches at least to explain interfaces.
> Oh and it would be nice to cc
> lkml on that document, too. New kernel<->user interface is not
> decision taken lightly.
PowerOP Core and PowerOP/cpufreq integration patch sets present two clear and 
configurable kernel<->user interfaces. I personally feel that interfaces 
configuration feature allows graceful interface discussion and possibility to 
get a decision smoothly instead of a flame on a list. If you argue against 
configuration feature please put comments on exactly configuration feature. 
Otherwise please explicitly list the requirements for kernel<->user interface 
you have which are not addressed by these two interfaces assuming you can chose 
either interface having PowerOP underneath.

Thanks,
	Eugeny
> 									Pavel

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

I know its confusing having oppoint (from Dave Singleton) and powerop 
being discussed at the same time.  However, I believe we (PowerOP) have 
already address most of the concerns/requirements from the community 
and the embedded folks.  Here is a summary of PowerOP that will 
(hopefully) clear up our approach:

- PowerOP is only one layer (towards the bottom) in a power management 
solution.
- PowerOP does *not* replace cpufreq
- PowerOP can replace the cpufreq_driver layer of cpufreq but cpufreq 
integration not required.
- in kernel cpufreq governors are not directly affect by integrating 
cpufreq and powerop. (Can be extended and/or ported to more 
architectures and operating points)
- Again, cpufreq userspace and kernel interfaces can continue to be 
used as they are today.
- PowerOP defines the parameters you want to change on a per 
architecture/board basis.
- The PowerOP interface was discussed in detail on this list and we 
haven't heard any negative comments.
- We are not advocating the integration with sleep states.  We want to 
get the PowerOP interface accepted and then we can build on it.
- PowerOP is *required* by the embedded folks.

We have a few more comments from Greg to take care of and  we can add a 
Documentation/ file. Then I think its time to get the PowerOP patches 
in the queue for acceptance.    Any comments about this?

btw,  PowerOP<->Cpufreq integration discussion can wait until Dominik 
and Dave Jones have time for more discussion.

On Sep 11, 2006, at 1:20 AM, Pavel Machek wrote:

> Hi!
>
> On Mon 2006-09-11 11:57:28, Eugeny S. Mints wrote:
>> [snip]
>>>> Are you arguing that the cpufreq interface be morphed to support 
>>>> power
>>>> op applications?
>>>
>>> No. I'm arguing that
>>>
>>> * cpufreq interface should be used for changing cpu frequency
>> the patch set i sent out has cpufreq used for changing cpu frequency,
>> hasn't it?
>
> I was talking about kernel<->user interface.
>
> You did echo low > something to change CPU frequency, IIRC.
>
>> can we eventually start talking more close to the code rather than
>> speculating without it?
>
> Lets get kernel<->user interface right, first. You'll need to create
> Documentation/ entries for your interfaces, eventually, so lets do
> that, first, and then talk about code. Oh and it would be nice to cc
> lkml on that document, too. New kernel<->user interface is not
> decision taken lightly.
> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> >>>>Are you arguing that the cpufreq interface be morphed to support power
> >>>>op applications?
> >>>No. I'm arguing that
> >>>
> >>>* cpufreq interface should be used for changing cpu frequency
> >>the patch set i sent out has cpufreq used for changing cpu frequency,
> >>hasn't it?
> >
> >I was talking about kernel<->user interface.
> me too. PowerOP is inkernel interface but which _allows_ to build various
> different kernel<->user interfaces on top of it. This PowerOP _advantage_ 
> allows community to experiment with various kernel<->user interfaces
>on top 

Kernel interface is not something to be experimented with.

> and eventually end up with the best solution. The solution can be either 
> one universal, agreed by community kernel<-> user interface on top or I can 
> imaging the approach when kernel<-> user interfaces on top are configurable 
> feature and system designer choses kernel<->user interface which fits best 
> the systems he/she builds.

...and configurable kernel interfaces are very bad idea.

> >You did echo low > something to change CPU frequency, IIRC.
> My patch set presents two different interfaces built on top of PowerOP - 
> cpufreq and sysfs interfaces. So _no_, PowerOP is not all about

Okay, drop sysfs interface, and we may have something that can be
reviewed.

Actually that's good idea. Submit powerop without doing _any_ kernel
interface changes, so we can see that it makes sense...

> embedded - chose sysfs interface. But with the approach when everything is 
> built on top PowerOP[PM Core, Clock framework] you just eliminate all 
> unnecessary duplication if PM functionality in PM  stack.

...bonus points if your submission actually deletes more code than it
adds.

> >Oh and it would be nice to cc
> >lkml on that document, too. New kernel<->user interface is not
> >decision taken lightly.
> PowerOP Core and PowerOP/cpufreq integration patch sets present two clear 
> and configurable kernel<->user interfaces. I personally feel that 
> interfaces configuration feature allows graceful interface discussion and 
> possibility to get a decision smoothly instead of a flame on a
>list. 

Your code should be good enough to survive some flaming. I do not
think it is, so yes, I think submitting it to lkml is good
idea. You'll have to do that at some point, anyway.

(And note lkml only flames you when you are doing something wrong.)

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:

>>> You did echo low > something to change CPU frequency, IIRC.
>> My patch set presents two different interfaces built on top of 
>> PowerOP -
>> cpufreq and sysfs interfaces. So _no_, PowerOP is not all about
>
> Okay, drop sysfs interface, and we may have something that can be
> reviewed.
>

Sysfs is a separate patch that can rejected.  Nothing is stopping 
people from reviewing.


> Actually that's good idea. Submit powerop without doing _any_ kernel
> interface changes, so we can see that it makes sense...


Just to be clear this is the approach we did and are doing.
> Your code should be good enough to survive some flaming. I do not
> think it is, so yes, I think submitting it to lkml is good
> idea. You'll have to do that at some point, anyway.
>
> (And note lkml only flames you when you are doing something wrong.)


Isn't this (linux-pm) the place to discuss power management patches and 
interfaces?  I thought we would get ACK's from the power management 
maintainers and then the patches go into -mm.  Who on lkml needs to be 
in this discussion that is not on this list?

btw, if people on this list are not ready to ACK PowerOP, I would like 
to hear why before we go elsewhere.   It looks like all major issues 
have been addressed by our approach and implementation.

>
> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> I know its confusing having oppoint (from Dave Singleton) and powerop 
> being discussed at the same time.  However, I believe we (PowerOP)
> have 

Yes, it is.

> - PowerOP is only one layer (towards the bottom) in a power management 
> solution.
> - PowerOP does *not* replace cpufreq

PowerOP provides userland interface for changing processor
frequency. That's bad -- duplicate interface.

> - The PowerOP interface was discussed in detail on this list and we 
> haven't heard any negative comments.

Eh? Was I on different list?

> - We are not advocating the integration with sleep states.  We want to 
> get the PowerOP interface accepted and then we can build on it.

Good.

> We have a few more comments from Greg to take care of and  we can add a 
> Documentation/ file. Then I think its time to get the PowerOP patches 
> in the queue for acceptance.    Any comments about this?

Well, you'll only get good interface review when you have
Documentation/ , and it needs to go to lkml before it goes to any
queues.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
> On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
> 
> >>>You did echo low > something to change CPU frequency, IIRC.
> >>My patch set presents two different interfaces built on top of 
> >>PowerOP -
> >>cpufreq and sysfs interfaces. So _no_, PowerOP is not all about
> >
> >Okay, drop sysfs interface, and we may have something that can be
> >reviewed.
> 
> Sysfs is a separate patch that can rejected.  Nothing is stopping 
> people from reviewing.

If you submit patch series with one bad patch, you are very unlikely
to get feedback for the good patches.

> >Actually that's good idea. Submit powerop without doing _any_ kernel
> >interface changes, so we can see that it makes sense...
> 
> Just to be clear this is the approach we did and are doing.

That's not what I remember. Please resubmit, then. And cc lkml this
time.

> btw, if people on this list are not ready to ACK PowerOP, I would like 
> to hear why before we go elsewhere.   It looks like all major issues 
> have been addressed by our approach and implementation.

No, I'm not ready to ACK. Actually I'd describe it as "broken piece of
code noone needs". And IIRC Greg's last question was "what is it good
for?". Dave Jones was not too pleased with cpufreq/powerop
integration. Intel people explained you broke centrino
speedstep. Shall I continue?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-11 22:06:36, Pavel Machek wrote:
> On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
> > On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:

> > btw, if people on this list are not ready to ACK PowerOP, I would like 
> > to hear why before we go elsewhere.   It looks like all major issues 
> > have been addressed by our approach and implementation.

Oh and I am pretty tired of teaching you 'how to submit a patch', so
if I'm quiet, do not take it as an "ACK".
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
> Hi!
> 
>>>>>> Are you arguing that the cpufreq interface be morphed to support power
>>>>>> op applications?
>>>>> No. I'm arguing that
>>>>>
>>>>> * cpufreq interface should be used for changing cpu frequency
>>>> the patch set i sent out has cpufreq used for changing cpu frequency,
>>>> hasn't it?
>>> I was talking about kernel<->user interface.
>> me too. PowerOP is inkernel interface but which _allows_ to build various
>> different kernel<->user interfaces on top of it. This PowerOP _advantage_ 
>> allows community to experiment with various kernel<->user interfaces
>> on top 
> 
> Kernel interface is not something to be experimented with.
it is since current interface (cpufreq in conjunction with /sys/power/state, 
etc) does not address all requirements to the interface. PowerOP approach helps 
to figure out best interface gracefully since there is no common opinion in the 
community yet.
> 
>> and eventually end up with the best solution. The solution can be either 
>> one universal, agreed by community kernel<-> user interface on top or I can 
>> imaging the approach when kernel<-> user interfaces on top are configurable 
>> feature and system designer choses kernel<->user interface which fits best 
>> the systems he/she builds.
> 
> ...and configurable kernel interfaces are very bad idea.
it's not an argument. the ideal goal to end up with one universal interface. but 
until you personally stuck with cpufreq interface this is the only way to 
proceed towards universal interface design. let people to investigate advantages 
and disadvantages of this and that interfaces on a working system since we can't 
convince each other by this flame.
> 
>>> You did echo low > something to change CPU frequency, IIRC.
>> My patch set presents two different interfaces built on top of PowerOP - 
>> cpufreq and sysfs interfaces. So _no_, PowerOP is not all about
> 
> Okay, drop sysfs interface, and we may have something that can be
> reviewed.
previous take of PowerOP did not contain sysfs part but I have not received any 
you comment on this. Sysfs is completely optional feature after all.
 >
> Actually that's good idea. Submit powerop without doing _any_ kernel
> interface changes, so we can see that it makes sense...
It was submitted this way several times.

Eugeny

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 1:06 PM, Pavel Machek wrote:

> On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
>> On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
>>
>>>>> You did echo low > something to change CPU frequency, IIRC.
>>>> My patch set presents two different interfaces built on top of
>>>> PowerOP -
>>>> cpufreq and sysfs interfaces. So _no_, PowerOP is not all about
>>>
>>> Okay, drop sysfs interface, and we may have something that can be
>>> reviewed.
>>
>> Sysfs is a separate patch that can rejected.  Nothing is stopping
>> people from reviewing.
>
> If you submit patch series with one bad patch, you are very unlikely
> to get feedback for the good patches.
>
>>> Actually that's good idea. Submit powerop without doing _any_ kernel
>>> interface changes, so we can see that it makes sense...
>>
>> Just to be clear this is the approach we did and are doing.
>
> That's not what I remember. Please resubmit, then. And cc lkml this
> time.
>
>> btw, if people on this list are not ready to ACK PowerOP, I would like
>> to hear why before we go elsewhere.   It looks like all major issues
>> have been addressed by our approach and implementation.
>
> No, I'm not ready to ACK. Actually I'd describe it as "broken piece of
> code noone needs".

But people on this list from TI, Nokia, and Motorola have explained why 
its needed.  Also, we explained why in the f2f linux-pm summit.  Can 
you give some concrete reasons why its not needed that have not been 
addressed already?

> And IIRC Greg's last question was "what is it good
> for?".

That was a long time ago and again many people from the embedded 
community have provided lots of answers.

> Dave Jones was not too pleased with cpufreq/powerop
> integration.

Really?!  I don't think he has reviewed our latest integration patches. 
  Our first submission was a result of discussion with Dominik at the 
linux-pm summit.  The latest submission is a result of Dave Jones 
comments.  I think we have addressed all expressed concerns.  I can't 
force anybody to review this stuff and I'm sure Dave is still catching 
up from his vacation.

>  Intel people explained you broke centrino
> speedstep.

I didn't see that.  Was it off-list?  We did not break centrino.  In 
fact we use both the acpi and hardcoded tables just as  cpufreq does.  
If its broken, then it was already broken.

>  Shall I continue?

Please.  Again,  I still say we have addressed all expressed 
concerns/questions/issues.  If you don't feel we have, please give some 
concrete statements that you are concerned about or don't understand.  
As you can see, many people are happy to help explain.

PowerOP is necessary to build the power management software required 
for embedded mobile devices, so we need to reach an understanding.  If 
the power management guys on this list don't understand PowerOP, then 
moving this discussion to lkml isn't going to help.  I much prefer to 
work together to figure out something than throw it over the wall.

>
> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 1:09 PM, Pavel Machek wrote:

> On Mon 2006-09-11 22:06:36, Pavel Machek wrote:
>> On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
>>> On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
>
>>> btw, if people on this list are not ready to ACK PowerOP, I would 
>>> like
>>> to hear why before we go elsewhere.   It looks like all major issues
>>> have been addressed by our approach and implementation.
>
> Oh and I am pretty tired of teaching you 'how to submit a patch', so
> if I'm quiet, do not take it as an "ACK".

Tired of teaching me?  We are following the same process documented and 
that everyone else is doing.  I just don't understand your reasons for 
not ACKing and requesting we move this discussion to lkml before people 
on this list are ready to ACK.  That has nothing to do with the process 
for submitting a patch.  No teaching involved or necessary.

What does your going quiet mean?  You have had some good feedback so I 
much prefer we reach some sort of understanding.  If your final 
statement is that PowerOP is not needed and you are never going to like 
it or ACK It, let us know.  We can agree to disagree.

> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Tue 2006-09-12 00:24:25, Eugeny S. Mints wrote:
> Pavel Machek wrote:

> >>>I was talking about kernel<->user interface.
> >>me too. PowerOP is inkernel interface but which _allows_ to build various
> >>different kernel<->user interfaces on top of it. This PowerOP _advantage_ 
> >>allows community to experiment with various kernel<->user interfaces
> >>on top 
> >
> >Kernel interface is not something to be experimented with.
> it is since current interface (cpufreq in conjunction with 
> /sys/power/state, etc) does not address all requirements to the
>interface.

Removing kernel interface takes 2+ years. So no, kernel interface is
not something to be experimented with, at least not on mainline.

> >Actually that's good idea. Submit powerop without doing _any_ kernel
> >interface changes, so we can see that it makes sense...
> It was submitted this way several times.

So try again, and cc lkml this time.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
> Hi!
> 
>> I know its confusing having oppoint (from Dave Singleton) and powerop 
>> being discussed at the same time.  However, I believe we (PowerOP)
>> have 
> 
> Yes, it is.
> 
>> - PowerOP is only one layer (towards the bottom) in a power management 
>> solution.
>> - PowerOP does *not* replace cpufreq
> 
> PowerOP provides userland interface for changing processor
> frequency. That's bad -- duplicate interface.
Basically the biggest problem with cpufreq interface is that cpufreq has "chose
predefined closest to a given frequency" functionality implemented in the
kernel while there is _no_ any reason to have this functionality implemented in
the kernel if we have sysfs interface exported by PowerOP in place - you just
_have_ to keep all possible functionality out of the kernel. CPufreq interface
is just subset of sysfs interface provided by PowerOP and _must_ be implemented
in userspace on top of sysfs interface - this is the proper way to scape
duplication. Such issue with cpufreq<->kernel userspace interface is consequence
of the fact that cpufreq implements incorrect design of PM stack layers and
interfaces. PowerOP solves this issues as well.
> 
>> - The PowerOP interface was discussed in detail on this list and we 
>> haven't heard any negative comments.
> 
> Eh? Was I on different list?vb dfgdfv
> 
>> - We are not advocating the integration with sleep states.  We want to 
>> get the PowerOP interface accepted and then we can build on it.
> 
> Good.
> 
>> We have a few more comments from Greg to take care of and  we can add a 
>> Documentation/ file. Then I think its time to get the PowerOP patches 
>> in the queue for acceptance.    Any comments about this?
> 
> Well, you'll only get good interface review when you have
> Documentation/ , and it needs to go to lkml before it goes to any
> queues.
PM stack is too complex and heavy part to go in such pieces thru lkml. i expect 
all linux  pm experts to be on this list

Eugeny
> 								Pavel
> 

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

> >>- PowerOP is only one layer (towards the bottom) in a power management 
> >>solution.
> >>- PowerOP does *not* replace cpufreq
> >
> >PowerOP provides userland interface for changing processor
> >frequency. That's bad -- duplicate interface.
> Basically the biggest problem with cpufreq interface is that cpufreq has 
> "chose
> predefined closest to a given frequency" functionality implemented in the
> kernel while there is _no_ any reason to have this functionality 
> implemented in
> the kernel if we have sysfs interface exported by PowerOP in place - you 
> just

No, there is reason to keep that in kernel -- so that cpufreq
userspace interface can be kept, and so that resulting kernel<->user
interface is not ugly.

> of the fact that cpufreq implements incorrect design of PM stack layers and
> interfaces. PowerOP solves this issues as well.

Actually I believe that cpufreq implements correct design and PowerOP
got it wrong.

> >Well, you'll only get good interface review when you have
> >Documentation/ , and it needs to go to lkml before it goes to any
> >queues.
> PM stack is too complex and heavy part to go in such pieces thru lkml. i 
> expect all linux  pm experts to be on this list

"We are too lazy to make the code clean enough / well enough explained
to survive lkml review".

Your interface impacts everyone, so everyone should have chance to
comment on it.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > Shall I continue?
> 
> Please.  Again,  I still say we have addressed all expressed 
> concerns/questions/issues.  If you don't feel we have, please give some 
> concrete statements that you are concerned about or don't understand.  
> As you can see, many people are happy to help explain.

YOU GOT THE KERNEL<->USER INTERFACE WRONG.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-11 13:33:00, Matthew Locke wrote:
> On Sep 11, 2006, at 1:09 PM, Pavel Machek wrote:
> >On Mon 2006-09-11 22:06:36, Pavel Machek wrote:
> >>On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
> >>>On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
> >
> >>>btw, if people on this list are not ready to ACK PowerOP, I would 
> >>>like
> >>>to hear why before we go elsewhere.   It looks like all major issues
> >>>have been addressed by our approach and implementation.
> >
> >Oh and I am pretty tired of teaching you 'how to submit a patch', so
> >if I'm quiet, do not take it as an "ACK".
...
> What does your going quiet mean?  You have had some good feedback so I 
> much prefer we reach some sort of understanding.  If your final 
> statement is that PowerOP is not needed and you are never going to like 
> it or ACK It, let us know.  We can agree to disagree.

You got the interfaces wrong. While I believe that something like
powerop can indeed be useful for system-on-chip platforms, I do not
think it should be exposed outside of kernel.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Preece Scott-PREECE]

> From: Pavel Machek [mailto:pavel@ucw.cz] 
> 
> > >>- PowerOP is only one layer (towards the bottom) in a power 
> > >>management solution.
> > >>- PowerOP does *not* replace cpufreq
> > >
> > >PowerOP provides userland interface for changing processor 
> frequency. 
> > >That's bad -- duplicate interface.
> > Basically the biggest problem with cpufreq interface is 
> that cpufreq 
> > has "chose predefined closest to a given frequency" functionality 
> > implemented in the kernel while there is _no_ any reason to 
> have this 
> > functionality implemented in the kernel if we have sysfs interface 
> > exported by PowerOP in place - you just
> 
> No, there is reason to keep that in kernel -- so that cpufreq 
> userspace interface can be kept, and so that resulting 
> kernel<->user interface is not ugly.
---

Just as a data point, "keeping the cpufreq interface" is
irrelevant to a number of us, because we configure it out
of the system.  I'm not really arguing that we should get
rid of an existing kernel interface, but I don't see any
reason why we shouldn't be able to have a separately
configurable interface if cpufreq doesn't meet our needs.

Note that Matthew is not arguing even that and expresses
apparent contentment with cpufreq's interface.

Regards,
scott

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-11 17:36:33, Preece Scott-PREECE wrote:
> 
> > From: Pavel Machek [mailto:pavel@ucw.cz] 
> > 
> > > >>- PowerOP is only one layer (towards the bottom) in a power 
> > > >>management solution.
> > > >>- PowerOP does *not* replace cpufreq
> > > >
> > > >PowerOP provides userland interface for changing processor 
> > frequency. 
> > > >That's bad -- duplicate interface.
> > > Basically the biggest problem with cpufreq interface is 
> > that cpufreq 
> > > has "chose predefined closest to a given frequency" functionality 
> > > implemented in the kernel while there is _no_ any reason to 
> > have this 
> > > functionality implemented in the kernel if we have sysfs interface 
> > > exported by PowerOP in place - you just
> > 
> > No, there is reason to keep that in kernel -- so that cpufreq 
> > userspace interface can be kept, and so that resulting 
> > kernel<->user interface is not ugly.
> ---
> 
> Just as a data point, "keeping the cpufreq interface" is
> irrelevant to a number of us, because we configure it out
> of the system.  I'm not really arguing that we should get
> rid of an existing kernel interface, but I don't see any
> reason why we shouldn't be able to have a separately
> configurable interface if cpufreq doesn't meet our needs.

Configurable interfaces are evil, and I do not think you can push such
patch. You have developed your own little interface that suits your
needs -- and that's fine -- but now you are trying to push it into
mainline... and that is not, because those interfaces were not really
designed to work together.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 2:06 PM, Pavel Machek wrote:

> On Mon 2006-09-11 13:33:00, Matthew Locke wrote:
>> On Sep 11, 2006, at 1:09 PM, Pavel Machek wrote:
>>> On Mon 2006-09-11 22:06:36, Pavel Machek wrote:
>>>> On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
>>>>> On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
>>>
>>>>> btw, if people on this list are not ready to ACK PowerOP, I would
>>>>> like
>>>>> to hear why before we go elsewhere.   It looks like all major 
>>>>> issues
>>>>> have been addressed by our approach and implementation.
>>>
>>> Oh and I am pretty tired of teaching you 'how to submit a patch', so
>>> if I'm quiet, do not take it as an "ACK".
> ...
>> What does your going quiet mean?  You have had some good feedback so I
>> much prefer we reach some sort of understanding.  If your final
>> statement is that PowerOP is not needed and you are never going to 
>> like
>> it or ACK It, let us know.  We can agree to disagree.
>
> You got the interfaces wrong. While I believe that something like
> powerop can indeed be useful for system-on-chip platforms, I do not
> think it should be exposed outside of kernel.


Ok.  I don't think its wrong because its designed from understanding 
the requirements of pm software for embedded mobile devices.   I think 
the embedded folk all agree that the type of interface submitted is 
required.  I don't understand why you think its wrong.  Just to be 
clear, your previous email made it very clear you don't like the 
userspace interface but this email says interfaces generically.  I am 
assuming your only objection at this point is the userspace interface.  
  We are more than willing to work this out.  The current sysfs 
interface is surrounded by ifdefs and is optional.  If there is no 
exposure to userspace, then testing/debuging will be more difficult.

Greg, Pavel, Dominik, Dave J and Dave B,

I would like to get a plan in place for acceptance with the power 
management guys before we move this to lkml.  I propose that we submit 
the current set of PowerOP patches plus final few changes (from Greg's 
comments and a Documentation/ file).  The patches do not affect anyone 
else.  The sysfs interface is optional.  If necessary Eugeny and I will 
maintain userspace interface patches outside the mainline for now.  
Will any of the power management maintainers ACK this plan and then ACK 
the patches?  If no one here is willing to ACK, then I don't see what 
will change by submitting to lkml.


> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Mark Gross]

On Mon, Sep 11, 2006 at 10:20:25AM +0200, Pavel Machek wrote:
> Hi!
> 
> On Mon 2006-09-11 11:57:28, Eugeny S. Mints wrote:
> > [snip]
> > >> Are you arguing that the cpufreq interface be morphed to support power
> > >> op applications?
> > >
> > > No. I'm arguing that
> > >
> > > * cpufreq interface should be used for changing cpu frequency
> > the patch set i sent out has cpufreq used for changing cpu frequency,
> > hasn't it?
> 
> I was talking about kernel<->user interface.
> 
> You did echo low > something to change CPU frequency, IIRC.
> 
> > can we eventually start talking more close to the code rather than
> > speculating without it?
> 
> Lets get kernel<->user interface right, first. You'll need to create
> Documentation/ entries for your interfaces, eventually, so lets do
> that, first, and then talk about code. Oh and it would be nice to cc
> lkml on that document, too. New kernel<->user interface is not
> decision taken lightly.

Is this just trying delay power op getting into the kernel?  We are
building up / evolving a PM stack from bottom up and you want to the
high level interface to be well defined and agreed upon first?  

I think the kernel user interface is important too but you are asking
for a complete solution stack when we are following an evolutionary
development process.  

--mgross

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Mark Gross]

On Mon, Sep 11, 2006 at 10:06:36PM +0200, Pavel Machek wrote:
> On Mon 2006-09-11 12:53:27, Matthew Locke wrote:
> > On Sep 11, 2006, at 12:36 PM, Pavel Machek wrote:
> > 
> > >>>You did echo low > something to change CPU frequency, IIRC.
> > >>My patch set presents two different interfaces built on top of 
> > >>PowerOP -
> > >>cpufreq and sysfs interfaces. So _no_, PowerOP is not all about
> > >
> > >Okay, drop sysfs interface, and we may have something that can be
> > >reviewed.
> > 
> > Sysfs is a separate patch that can rejected.  Nothing is stopping 
> > people from reviewing.
> 
> If you submit patch series with one bad patch, you are very unlikely
> to get feedback for the good patches.
> 
> > >Actually that's good idea. Submit powerop without doing _any_ kernel
> > >interface changes, so we can see that it makes sense...
> > 
> > Just to be clear this is the approach we did and are doing.
> 
> That's not what I remember. Please resubmit, then. And cc lkml this
> time.
> 
> > btw, if people on this list are not ready to ACK PowerOP, I would like 
> > to hear why before we go elsewhere.   It looks like all major issues 
> > have been addressed by our approach and implementation.
> 
> No, I'm not ready to ACK. Actually I'd describe it as "broken piece of
> code noone needs". And IIRC Greg's last question was "what is it good
> for?". Dave Jones was not too pleased with cpufreq/powerop
> integration. Intel people explained you broke centrino
> speedstep. Shall I continue?
> 

Those where directed to the other patch that David Singleton posted.


> 								Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
>>>> - PowerOP is only one layer (towards the bottom) in a power management 
>>>> solution.
>>>> - PowerOP does *not* replace cpufreq
>>> PowerOP provides userland interface for changing processor
>>> frequency. That's bad -- duplicate interface.
>> Basically the biggest problem with cpufreq interface is that cpufreq has 
>> "chose
>> predefined closest to a given frequency" functionality implemented in the
>> kernel while there is _no_ any reason to have this functionality 
>> implemented in
>> the kernel if we have sysfs interface exported by PowerOP in place - you 
>> just
> 
> No, there is reason to keep that in kernel -- so that cpufreq
> userspace interface can be kept, and so that resulting kernel<->user
> interface is not ugly.
Cpuferq defines cpufreq_frequency_table structure in arch independent header 
while it's arch dependent data structure. A lot of code is built around this 
invalid basic brick and therefore is invalid: cpufreq tables, interface with cpu 
freq drivers, etc. Notion of transition latency as it defined by cpufreq is 
wrong because it's not a function of cpu type but function of current and next 
operating point. no runtime control on operating points set. it's always the 
same set of operating points for all system cpus in smp case and no way to 
define different sets or track any dependencies in case say multi core cpus. 
insufficient kernel<->user space interface to handle embedded requirements and 
no way to extend it within current design. Shall I continue?  Why should then 
anyone want to keep cpufreq userspace interface just due to keep it?
> 
>> of the fact that cpufreq implements incorrect design of PM stack layers and
>> interfaces. PowerOP solves this issues as well.
> 
> Actually I believe that cpufreq implements correct design and PowerOP
> got it wrong.
PowerOP/cufreq integration patch set contains very details explanation of the 
cpufreq design issues and POwerOP solutions. Comment there is you feel it's wrong.

Eugeny
> 
>>> Well, you'll only get good interface review when you have
>>> Documentation/ , and it needs to go to lkml before it goes to any
>>> queues.
>> PM stack is too complex and heavy part to go in such pieces thru lkml. i 
>> expect all linux  pm experts to be on this list
> 
> "We are too lazy to make the code clean enough / well enough explained
> to survive lkml review".
> 
> Your interface impacts everyone, so everyone should have chance to
> comment on it.
> 								Pavel

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 3:00 PM, Mark Gross wrote:

> On Mon, Sep 11, 2006 at 10:06:36PM +0200, Pavel Machek wrote:
>> No, I'm not ready to ACK. Actually I'd describe it as "broken piece of
>> code noone needs". And IIRC Greg's last question was "what is it good
>> for?". Dave Jones was not too pleased with cpufreq/powerop
>> integration. Intel people explained you broke centrino
>> speedstep. Shall I continue?
>>
>
> Those where directed to the other patch that David Singleton posted.
>

Right.

  Pavel and others,  I know its confusing having the two.  Let's focus 
on just PowerOP.  The PowerOP patches are just powerop and do not 
affect other subsystems or existing PM code.  The other stuff (cpufreq 
integration, suspend/resume integration) can come later.   Nothing in 
PowerOP prevents us from adding more later.

>
>> 								Pavel
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
> On Mon 2006-09-11 17:36:33, Preece Scott-PREECE wrote:
>>> From: Pavel Machek [mailto:pavel@ucw.cz] 
>>>
>>>>>> - PowerOP is only one layer (towards the bottom) in a power 
>>>>>> management solution.
>>>>>> - PowerOP does *not* replace cpufreq
>>>>> PowerOP provides userland interface for changing processor 
>>> frequency. 
>>>>> That's bad -- duplicate interface.
>>>> Basically the biggest problem with cpufreq interface is 
>>> that cpufreq 
>>>> has "chose predefined closest to a given frequency" functionality 
>>>> implemented in the kernel while there is _no_ any reason to 
>>> have this 
>>>> functionality implemented in the kernel if we have sysfs interface 
>>>> exported by PowerOP in place - you just
>>> No, there is reason to keep that in kernel -- so that cpufreq 
>>> userspace interface can be kept, and so that resulting 
>>> kernel<->user interface is not ugly.
>> ---
>>
>> Just as a data point, "keeping the cpufreq interface" is
>> irrelevant to a number of us, because we configure it out
>> of the system.  I'm not really arguing that we should get
>> rid of an existing kernel interface, but I don't see any
>> reason why we shouldn't be able to have a separately
>> configurable interface if cpufreq doesn't meet our needs.
> 
> Configurable interfaces are evil,
Are you saying that not having sysfs attribute nodes for entities which don't 
exist in a certain configuration is evil?

In x86 configuration you'd like to have just one attribute - frequency? It's 
just subset of common case when all power parameters available on a platform are 
exported. In x86 configuration you'd like to echo arbitrary frequency value into 
'sys/something' and have underneath logic to chose "closest" predefine 
frequency? No any reason to handle this in the kernel once frequency attribute 
is exported.
> and I do not think you can push such
> patch. You have developed your own little interface that suits your
> needs -- and that's fine -- but now you are trying to push it into
> mainline... and that is not, because those interfaces were not really
> designed to work together.
once cpufreq userland interface functionality which does not belong to the 
kernel is moved out of the kernel cpufreq interface becomes a subset of PowerOP 
  sysfs interface. In other words this means that improvements of PM stack 
layers/interfaces design will allow to design/develop an universal userspace 
interface. We'd prefer to move gracefully in this direction though.

	Eugeny
> 								Pavel

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-11 14:53:03, Mark Gross wrote:
> On Mon, Sep 11, 2006 at 10:20:25AM +0200, Pavel Machek wrote:
> > Lets get kernel<->user interface right, first. You'll need to create
> > Documentation/ entries for your interfaces, eventually, so lets do
> > that, first, and then talk about code. Oh and it would be nice to cc
> > lkml on that document, too. New kernel<->user interface is not
> > decision taken lightly.
> 
> Is this just trying delay power op getting into the kernel?  We are
> building up / evolving a PM stack from bottom up and you want to the
> high level interface to be well defined and agreed upon first?

As long as you do not introduce _any_ user<->kernel interfaces within
patch series, going without Documentation is okay. But IIRC that was
not the case.


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

> >>What does your going quiet mean?  You have had some good feedback so I
> >>much prefer we reach some sort of understanding.  If your final
> >>statement is that PowerOP is not needed and you are never going to 
> >>like
> >>it or ACK It, let us know.  We can agree to disagree.
> >
> >You got the interfaces wrong. While I believe that something like
> >powerop can indeed be useful for system-on-chip platforms, I do not
> >think it should be exposed outside of kernel.
> 
> 
> Ok.  I don't think its wrong because its designed from understanding 
> the requirements of pm software for embedded mobile devices.   I
>think 
> the embedded folk all agree that the type of interface submitted is 
> required.  I don't understand why you think its wrong.  Just to be 

So you'll have to do lots of explaining. On lkml.

> clear, your previous email made it very clear you don't like the 
> userspace interface but this email says interfaces generically.  

I meant user<->kernel interface.

> assuming your only objection at this point is the userspace interface.  
>  We are more than willing to work this out.  The current sysfs 
> interface is surrounded by ifdefs and is optional.  If there is no 
> exposure to userspace, then testing/debuging will be more difficult.

Having interface surrounded by #ifdefs is evil. You can test it
separately, then just remove that code before submission. Or maybe
move it to debugfs.

> Greg, Pavel, Dominik, Dave J and Dave B,
> 
> I would like to get a plan in place for acceptance with the power 
> management guys before we move this to lkml.  

Documentation/SubmittingPatches says:
#5) Select your CC (e-mail carbon copy) list.
#
#Unless you have a reason NOT to do so, CC
#linux-kernel@vger.kernel.org.

and sorry, but I insist on using proper procedure here. And no, "we
are afraid of being flamed" is not good enough reason not to.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Mark Gross]

On Tue, Sep 12, 2006 at 12:43:13AM +0200, Pavel Machek wrote:
> On Mon 2006-09-11 14:53:03, Mark Gross wrote:
> > On Mon, Sep 11, 2006 at 10:20:25AM +0200, Pavel Machek wrote:
> > > Lets get kernel<->user interface right, first. You'll need to create
> > > Documentation/ entries for your interfaces, eventually, so lets do
> > > that, first, and then talk about code. Oh and it would be nice to cc
> > > lkml on that document, too. New kernel<->user interface is not
> > > decision taken lightly.
> > 
> > Is this just trying delay power op getting into the kernel?  We are
> > building up / evolving a PM stack from bottom up and you want to the
> > high level interface to be well defined and agreed upon first?
> 
> As long as you do not introduce _any_ user<->kernel interfaces within
> patch series, going without Documentation is okay. But IIRC that was
> not the case.
> 

I don't think providing Documentation on whatever interface will be a
problem.

--mgross

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Greg KH]

On Mon, Sep 11, 2006 at 01:25:42PM -0700, Matthew Locke wrote:
> On Sep 11, 2006, at 1:06 PM, Pavel Machek wrote:
> >And IIRC Greg's last question was "what is it good
> >for?".
> 
> That was a long time ago and again many people from the embedded 
> community have provided lots of answers.

I'm still not convinced.  You can't break the current cpufreq interface,
and to claim that it is irrelevant is just ignoring 95% of the Linux
market right now :)

So, you all better work with the cpufreq people, otherwise this code is
going to go nowhere.

I'm with Pavel here, in my opinion, he is correct.

thanks,

greg k-h

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Greg KH]

On Mon, Sep 11, 2006 at 02:50:04PM -0700, Matthew Locke wrote:
> 
> I would like to get a plan in place for acceptance with the power 
> management guys before we move this to lkml.

Sure, let's see something here that we all agree on.  You have yet to
achieve that, so you still have work to do.

> I propose that we submit the current set of PowerOP patches plus final
> few changes (from Greg's comments and a Documentation/ file).

Nothing is keeping you from sending these to the list now.  Please do
so.

> The patches do not affect anyone else.  The sysfs interface is
> optional.

If so, it will be interesting to see why the code is even needed, I
await the patches :)

> If necessary Eugeny and I will maintain userspace interface patches
> outside the mainline for now.

Why?  What good would the in-kernel patches be then if it can't be used
except for some external patches?  That's not acceptable.  And the user
interface has been tied to the other kernel code, so I think you need
them both, but am willing to be convinced otherwise.

> Will any of the power management maintainers ACK this plan and then
> ACK the patches?

Let's see the code please.

> If no one here is willing to ACK, then I don't see what will change by
> submitting to lkml.

Let's get this agreed on first, I feel that you still have some way to
go here.

Sending stuff to lkml is fine too, you should be doing that for such a
core change anyway.  I don't see why you can't do that at the same time,
it's just an extra email on the CC: line...

thanks,

greg k-h

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 11, 2006, at 8:31 PM, Greg KH wrote:

> On Mon, Sep 11, 2006 at 02:50:04PM -0700, Matthew Locke wrote:
>>
>> I would like to get a plan in place for acceptance with the power
>> management guys before we move this to lkml.
>
> Sure, let's see something here that we all agree on.  You have yet to
> achieve that, so you still have work to do.
>
>> I propose that we submit the current set of PowerOP patches plus final
>> few changes (from Greg's comments and a Documentation/ file).
>
> Nothing is keeping you from sending these to the list now.  Please do
> so.

The only thing stopping us is time:)  It will happen soon.

>
>> The patches do not affect anyone else.  The sysfs interface is
>> optional.
>
> If so, it will be interesting to see why the code is even needed, I
> await the patches :)

PowerOP patches have been submitted to this list several times for 
review.  You even reviewed a version or two.  The main comments we are 
addressing are small issues such as add a file in Documentation and 
module reference counting.  Not much else will change so you have the 
code.  The cpufreq<->PowerOP integration patches have also been 
submitted but no one has responded to those.

Just read the other emails.  I will stop here.  It's time to reset the 
discussion again.

>
>> If necessary Eugeny and I will maintain userspace interface patches
>> outside the mainline for now.
>
> Why?  What good would the in-kernel patches be then if it can't be used
> except for some external patches?  That's not acceptable.  And the user
> interface has been tied to the other kernel code, so I think you need
> them both, but am willing to be convinced otherwise.

I think so too.  This offer is in response to Pavel's comment that 
PowerOP is ok for in-kernel usage but not userspace.

>
>> Will any of the power management maintainers ACK this plan and then
>> ACK the patches?
>
> Let's see the code please.
>
>> If no one here is willing to ACK, then I don't see what will change by
>> submitting to lkml.
>
> Let's get this agreed on first, I feel that you still have some way to
> go here.
>
> Sending stuff to lkml is fine too, you should be doing that for such a
> core change anyway.  I don't see why you can't do that at the same 
> time,
> it's just an extra email on the CC: line...
>
> thanks,
>
> greg k-h
>

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[David Brownell]

Hi Matt,

> From matt@nomadgs.com  Mon Sep 11 14:56:58 2006
>
> Greg, Pavel, Dominik, Dave J and Dave B,
>
> I would like to get a plan in place for acceptance with the power 
> management guys before we move this to lkml.  I propose that we submit 
> the current set of PowerOP patches plus final few changes (from Greg's 
> comments and a Documentation/ file).  The patches do not affect anyone 
> else.  The sysfs interface is optional.  If necessary Eugeny and I will 
> maintain userspace interface patches outside the mainline for now.  
> Will any of the power management maintainers ACK this plan and then ACK 
> the patches?  If no one here is willing to ACK, then I don't see what 
> will change by submitting to lkml.

The Linux-PM list booted me off itself for a while, and I just got
back on and haven't gotten through the backlog yet.  Right now the
distinctions and relationships between any of the "recent patches"
and system-wide mechanisms like

    - lowpower idle tasks;

    - multiple run states ... cpufreq doing an inadequte subset,
      even if you're only interested in CPUs;

    - multiple sleep states ... /sys/power/state listing "standby"
      and/or "mem" (kind of weak for embedded systems) and "disk"
      (which is checkpoint/resume, not really sleep);

are not fully evident to me, so acking anything seems premature.
Plus there's an "ACPI way" to do so much of that, which doesn't
much help most non-x86 systems.

I thought I saw patches generalizing both sleep and run states
(separate patch sets!) ... plus a good comment from Greg that
a short (!) "elevator pitch" seemed to be lacking.

- Dave

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[David Brownell]

> Date: Mon, 11 Sep 2006 21:36:37 +0200
> From: Pavel Machek <pavel@ucw.cz>
>
> Kernel interface is not something to be experimented with.

Disagree.  How else to get it right??
Try, learn, improve.  That's experimentation.
Linux has no "stable API nonsense" ...

The point of "cathedral vs bazaar" was that experimentation
and evolution are more successful processes than "get it right
the first time".


> (And note lkml only flames you when you are doing something wrong.)

Or sometimes, when you post on a day whose name (in English)
ends with a "y"... depends on the topic! ;)

- Dave

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Preece Scott-PREECE]

 
> From: David Brownell [mailto:david-b@pacbell.net] 
> 
> > Date: Mon, 11 Sep 2006 21:36:37 +0200
> > From: Pavel Machek <pavel@ucw.cz>
> >
> > Kernel interface is not something to be experimented with.
> 
> Disagree.  How else to get it right??
> Try, learn, improve.  That's experimentation.
> Linux has no "stable API nonsense" ...
> 
> The point of "cathedral vs. bazaar" was that experimentation 
> and evolution are more successful processes than "get it 
> right the first time".
---

I think Pavel's point was that the userspace interface to 
the kernel (at least the syscall interface) is stable (open to
Extension by addition of syscalls, but closed to modification
or deletion of existing and that any experimentation needs to 
happen before functionality goes into the mainstream. 

That said, I do think we probably need to add a new interface to
cover operating points, because some of believe that policy needs
to be in user space and the whole point of the OP abstraction is 
that operating points are atomic. You can't just add knobs to
control more factors, because all those knobs need to be turned
at the same time. Setting an operating point is inherently an
atomic operation, not n separate operations that can be taken
serially.

scott
 

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > > Date: Mon, 11 Sep 2006 21:36:37 +0200
> > > From: Pavel Machek <pavel@ucw.cz>
> > >
> > > Kernel interface is not something to be experimented with.
> > 
> > Disagree.  How else to get it right??
> > Try, learn, improve.  That's experimentation.
> > Linux has no "stable API nonsense" ...
> > 
> > The point of "cathedral vs. bazaar" was that experimentation 
> > and evolution are more successful processes than "get it 
> > right the first time".
> ---
> 
> I think Pavel's point was that the userspace interface to 
> the kernel (at least the syscall interface) is stable (open to
> Extension by addition of syscalls, but closed to modification
> or deletion of existing and that any experimentation needs to 
> happen before functionality goes into the mainstream. 

Yes, that was my point. (And I'd add "plus you can't get around that
by introducing interface hidden by #ifdef").

> That said, I do think we probably need to add a new interface to
> cover operating points, because some of believe that policy needs
> to be in user space and the whole point of the OP abstraction is 
> that operating points are atomic. You can't just add knobs to
> control more factors, because all those knobs need to be turned
> at the same time. Setting an operating point is inherently an
> atomic operation, not n separate operations that can be taken
> serially.

Ok, "needs to be atomic" is first real argument for OP abstraction. I
wonder if we can get around that by delaying the transaction until
userspace tells us it made all the changes... otoh that is going to be
messy.

But do you have some reasonable way to integrate OP with cpufreq?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

Hi,

On 9/14/06, Pavel Machek <pavel@ucw.cz> wrote:

> But do you have some reasonable way to integrate OP with cpufreq?

Do we really need to integrate OP with cpufreq at this point?

Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 14, 2006, at 2:12 AM, Pavel Machek wrote:

> Hi!
>
>>>> Date: Mon, 11 Sep 2006 21:36:37 +0200
>>>> From: Pavel Machek <pavel@ucw.cz>
>>>>
>>>> Kernel interface is not something to be experimented with.
>>>
>>> Disagree.  How else to get it right??
>>> Try, learn, improve.  That's experimentation.
>>> Linux has no "stable API nonsense" ...
>>>
>>> The point of "cathedral vs. bazaar" was that experimentation
>>> and evolution are more successful processes than "get it
>>> right the first time".
>> ---
>>
>> I think Pavel's point was that the userspace interface to
>> the kernel (at least the syscall interface) is stable (open to
>> Extension by addition of syscalls, but closed to modification
>> or deletion of existing and that any experimentation needs to
>> happen before functionality goes into the mainstream.
>
> Yes, that was my point. (And I'd add "plus you can't get around that
> by introducing interface hidden by #ifdef").
>
>> That said, I do think we probably need to add a new interface to
>> cover operating points, because some of believe that policy needs
>> to be in user space and the whole point of the OP abstraction is
>> that operating points are atomic. You can't just add knobs to
>> control more factors, because all those knobs need to be turned
>> at the same time. Setting an operating point is inherently an
>> atomic operation, not n separate operations that can be taken
>> serially.
>
> Ok, "needs to be atomic" is first real argument for OP abstraction. I
> wonder if we can get around that by delaying the transaction until
> userspace tells us it made all the changes... otoh that is going to be
> messy.
>
> But do you have some reasonable way to integrate OP with cpufreq?

Yes, it was presented in the PowerOP/cpufreq integration patches.  The 
cpufreq_driver layer is the natural integration point.

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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Matthew Locke]

On Sep 14, 2006, at 2:12 AM, Pavel Machek wrote:

> Hi!
>
>>>> Date: Mon, 11 Sep 2006 21:36:37 +0200
>>>> From: Pavel Machek <pavel@ucw.cz>
>>>>
>>>> Kernel interface is not something to be experimented with.
>>>
>>> Disagree.  How else to get it right??
>>> Try, learn, improve.  That's experimentation.
>>> Linux has no "stable API nonsense" ...
>>>
>>> The point of "cathedral vs. bazaar" was that experimentation
>>> and evolution are more successful processes than "get it
>>> right the first time".
>> ---
>>
>> I think Pavel's point was that the userspace interface to
>> the kernel (at least the syscall interface) is stable (open to
>> Extension by addition of syscalls, but closed to modification
>> or deletion of existing and that any experimentation needs to
>> happen before functionality goes into the mainstream.
>
> Yes, that was my point. (And I'd add "plus you can't get around that
> by introducing interface hidden by #ifdef").
>
>> That said, I do think we probably need to add a new interface to
>> cover operating points, because some of believe that policy needs
>> to be in user space and the whole point of the OP abstraction is
>> that operating points are atomic. You can't just add knobs to
>> control more factors, because all those knobs need to be turned
>> at the same time. Setting an operating point is inherently an
>> atomic operation, not n separate operations that can be taken
>> serially.
>
> Ok, "needs to be atomic" is first real argument for OP abstraction. I
> wonder if we can get around that by delaying the transaction until
> userspace tells us it made all the changes... otoh that is going to be
> messy.
>
> But do you have some reasonable way to integrate OP with cpufreq?

Yes, it was presented in the PowerOP/cpufreq integration patches.  The 
cpufreq_driver layer is the natural integration point.

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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Matthew Locke wrote:
> On Sep 14, 2006, at 2:12 AM, Pavel Machek wrote:
> 
>> Hi!
>>
>>>>> Date: Mon, 11 Sep 2006 21:36:37 +0200
>>>>> From: Pavel Machek <pavel@ucw.cz>
>>>>>
>>>>> Kernel interface is not something to be experimented with.
>>>> Disagree.  How else to get it right??
>>>> Try, learn, improve.  That's experimentation.
>>>> Linux has no "stable API nonsense" ...
>>>>
>>>> The point of "cathedral vs. bazaar" was that experimentation
>>>> and evolution are more successful processes than "get it
>>>> right the first time".
>>> ---
>>>
>>> I think Pavel's point was that the userspace interface to
>>> the kernel (at least the syscall interface) is stable (open to
>>> Extension by addition of syscalls, but closed to modification
>>> or deletion of existing and that any experimentation needs to
>>> happen before functionality goes into the mainstream.
>> Yes, that was my point. (And I'd add "plus you can't get around that
>> by introducing interface hidden by #ifdef").
>>
>>> That said, I do think we probably need to add a new interface to
>>> cover operating points, because some of believe that policy needs
>>> to be in user space and the whole point of the OP abstraction is
>>> that operating points are atomic. You can't just add knobs to
>>> control more factors, because all those knobs need to be turned
>>> at the same time. Setting an operating point is inherently an
>>> atomic operation, not n separate operations that can be taken
>>> serially.
>> Ok, "needs to be atomic" is first real argument for OP abstraction. I
>> wonder if we can get around that by delaying the transaction until
>> userspace tells us it made all the changes... otoh that is going to be
>> messy.
>>
>> But do you have some reasonable way to integrate OP with cpufreq?
> 
> Yes, it was presented in the PowerOP/cpufreq integration patches.  The 
> cpufreq_driver layer is the natural integration point.
Exactly.

Separate or one universal user space<->kernel interface is another story. 
Universal is preferred of course and in two words to achieve universal interface 
current cpufreq interface needs to be improved - but remains unchanged for user 
space !!!! - in the way to handle "chose closet predefined frequency to an 
arbitrary freq value echo'ed into /sys/cpufreq/cpuN/freq" functionality in user 
space instead of in the kernel. Assuming that frequency attribute is exported 
for all available operating points it is possible to implement the "cpufreq 
frequency selection logic" in user space and having such functionality in the 
kernel just violates the main rule of having everything possible outside of the 
kernel.

More details here:
http://lists.osdl.org/pipermail/linux-pm/2006-September/003660.html
and here
http://lists.osdl.org/pipermail/linux-pm/2006-September/003671.html

Paval, plz NOTE, that  you don't have lkml in CC on this thread and I personally 
feel that you've brought a really terrible confusion to everyone with your lkml 
step. I'm wondering whether you are braking "no cross postings" rule as well.....

Eugeny
> 
>> 								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
>>
> 
> _______________________________________________
> linux-pm mailing list
> linux-pm@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/linux-pm
> 

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> operating points it is possible to implement the "cpufreq frequency 
> selection logic" in user space and having such functionality in the kernel 
> just violates the main rule of having everything possible outside of the 
> kernel.

You got the rules wrong. "Keep the code out of kernel" is important
rule, but probably not the main one.

> Paval, plz NOTE, that  you don't have lkml in CC on this thread and I 
> personally feel that you've brought a really terrible confusion to everyone 
> with your lkml step. I'm wondering whether you are braking "no cross 
> postings" rule as well.....

Cc-ing lkml is considered okay.

Anyway, please do _proper_ submission, cc-ing lkml, explaining why it
is needed so that me and lkml actually know what is going on. Include
those "elevator pitches".
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Pavel Machek wrote:
> Hi!
> 
>> operating points it is possible to implement the "cpufreq frequency 
>> selection logic" in user space and having such functionality in the kernel 
>> just violates the main rule of having everything possible outside of the 
>> kernel.
> 
> You got the rules wrong. "Keep the code out of kernel" is important
> rule, but probably not the main one.
funny. not to mention that it was not the only argument I presented but please 
tell us explicitly what's your reason to blow out kernel footprint by the code 
which can be handled outside the kernel. I'd prefer to see technical reasons a 
kind of latencies, etc but not  the constant refrain "don't touch cpufreq 
interface". Especially considering that proposed improvements _do_ _not_ 
_change_ the interface.

And just FYI kernel footprint was stated as one of main current issues at least 
on the last OLS.
> 
>> Paval, plz NOTE, that  you don't have lkml in CC on this thread and I 
>> personally feel that you've brought a really terrible confusion to everyone 
>> with your lkml step. I'm wondering whether you are braking "no cross 
>> postings" rule as well.....
> 
> Cc-ing lkml is considered okay.
> 
> Anyway, please do _proper_ submission, 
I already did _proper_ submissions several time on IMO the _proper_ list.
>cc-ing lkml, explaining why it
> is needed so that me and lkml actually know what is going on. 
will do

Eugeny
>Include
> those "elevator pitches".
> 									Pavel
> 

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

Eugeny,

On 9/14/06, Eugeny S. Mints <eugeny.mints@gmail.com> wrote:

> Separate or one universal user space<->kernel interface is another story.
> Universal is preferred of course and in two words to achieve universal interface
> current cpufreq interface needs to be improved - but remains unchanged for user
> space !!!! - in the way to handle "chose closet predefined frequency to an
> arbitrary freq value echo'ed into /sys/cpufreq/cpuN/freq" functionality in user
> space instead of in the kernel. Assuming that frequency attribute is exported
> for all available operating points it is possible to implement the "cpufreq
> frequency selection logic" in user space and having such functionality in the
> kernel just violates the main rule of having everything possible outside of the
> kernel.

Let's not be in a hurry, if possible.
I wonder why not to present PowerOP with a _separate_ *kernel* API at
the moment.

> More details here:
> http://lists.osdl.org/pipermail/linux-pm/2006-September/003660.html
> and here
> http://lists.osdl.org/pipermail/linux-pm/2006-September/003671.html

Again, let's first make PowerOP accepted in mainline and then start
talking about integration with cpufreq.
Looking again at the links you've provided, I'd guess BTW that you
meant configfs not sysfs in some cases.

Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

Pavel,

On 9/14/06, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > operating points it is possible to implement the "cpufreq frequency
> > selection logic" in user space and having such functionality in the kernel
> > just violates the main rule of having everything possible outside of the
> > kernel.
>
> You got the rules wrong. "Keep the code out of kernel" is important
> rule, but probably not the main one.

from aside, it looks like you're choosing 'rules' and assign then
'priorities' in a too arbitrary way which is by a strange accident
fits your point of view best of all.
May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)

Thanks,
   Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Eugeny S. Mints]

Vitaly,

Vitaly Wool wrote:
> Eugeny,
> 
> On 9/14/06, Eugeny S. Mints <eugeny.mints@gmail.com> wrote:
> 
>> Separate or one universal user space<->kernel interface is another story.
>> Universal is preferred of course and in two words to achieve universal 
>> interface
>> current cpufreq interface needs to be improved - but remains unchanged 
>> for user
>> space !!!! - in the way to handle "chose closet predefined frequency 
>> to an
>> arbitrary freq value echo'ed into /sys/cpufreq/cpuN/freq" 
>> functionality in user
>> space instead of in the kernel. Assuming that frequency attribute is 
>> exported
>> for all available operating points it is possible to implement the 
>> "cpufreq
>> frequency selection logic" in user space and having such functionality 
>> in the
>> kernel just violates the main rule of having everything possible 
>> outside of the
>> kernel.
> 
> Let's not be in a hurry, if possible.
> I wonder why not to present PowerOP with a _separate_ *kernel* API at
> the moment.
it is exactly how PowerOP submission is positioned - it was submitted as a 
standalone patch without any relationship to cpufreq integration patch.

Cpufreq patch was submitted mostly for reference and discussion; to demonstrate 
that future integration with cpufreq is in mind and outline that PowerOP will 
not require cpufreq _interface_ to be changed.
> 
>> More details here:
>> http://lists.osdl.org/pipermail/linux-pm/2006-September/003660.html
>> and here
>> http://lists.osdl.org/pipermail/linux-pm/2006-September/003671.html
> 
> Again, let's first make PowerOP accepted in mainline and then start
> talking about integration with cpufreq.

that's exactly our understanding of an evolutionary development process.

> Looking again at the links you've provided, I'd guess BTW that you
> meant configfs not sysfs in some cases.
configfs is in my TODO list.

	Eugeny
> 
> Vitaly
> 

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

> Pavel,

> > > operating points it is possible to implement the "cpufreq frequency
> > > selection logic" in user space and having such functionality in the kernel
> > > just violates the main rule of having everything possible outside of the
> > > kernel.
> >
> > You got the rules wrong. "Keep the code out of kernel" is important
> > rule, but probably not the main one.
> 
> from aside, it looks like you're choosing 'rules' and assign then
> 'priorities' in a too arbitrary way which is by a strange accident
> fits your point of view best of all.
> May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)

Actually, laptops and zauruses seem to be the only "interesting"
machines from pm perspective. Then there are Motorola cellphones, but
Motorola tried hard not to enable users changing kernel... so they are
irrelevant.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Thu 2006-09-14 15:03:11, Pavel Machek wrote:
> 
> > Pavel,
> 
> > > > operating points it is possible to implement the "cpufreq frequency
> > > > selection logic" in user space and having such functionality in the kernel
> > > > just violates the main rule of having everything possible outside of the
> > > > kernel.
> > >
> > > You got the rules wrong. "Keep the code out of kernel" is important
> > > rule, but probably not the main one.
> > 
> > from aside, it looks like you're choosing 'rules' and assign then
> > 'priorities' in a too arbitrary way which is by a strange accident
> > fits your point of view best of all.
> > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
> 
> Actually, laptops and zauruses seem to be the only "interesting"
> machines from pm perspective. Then there are Motorola cellphones, but
> Motorola tried hard not to enable users changing kernel... so they are
> irrelevant.

Make that "mostly irrelevant"... as community will find a way to flash
them, eventually. Still 2.6-based machine with more advanced power
management would be nice. AFAICT zaurus are best machines today...
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

Pavel,

On 9/14/06, Pavel Machek <pavel@ucw.cz> wrote:
>
> > Pavel,
>
> > > > operating points it is possible to implement the "cpufreq frequency
> > > > selection logic" in user space and having such functionality in the kernel
> > > > just violates the main rule of having everything possible outside of the
> > > > kernel.
> > >
> > > You got the rules wrong. "Keep the code out of kernel" is important
> > > rule, but probably not the main one.
> >
> > from aside, it looks like you're choosing 'rules' and assign then
> > 'priorities' in a too arbitrary way which is by a strange accident
> > fits your point of view best of all.
> > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
>
> Actually, laptops and zauruses seem to be the only "interesting"
> machines from pm perspective. Then there are Motorola cellphones, but
> Motorola tried hard not to enable users changing kernel... so they are
> irrelevant.

Well, I never said Zaurus was no good :)
Please don't forget about Nokia 770 and its possible follow-ups.
Also, please keep in mind that if we come to a joint PM solution that
is in mainline, Motorola will use it... and will be contributing
changes back to the community. If there was a PM solution adopted in
mainline which fit the needs of embedded devices, more vendors would
turn to using Linux.
I. e., what prevents Sharp from making a open-code Lnux-based cell
phone? I do think that the absense of PM framework suitable for
embedded is one of the main engineering reasons... So let us broaden
our views and work together :)

Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> >> from aside, it looks like you're choosing 'rules' and assign then
> >> 'priorities' in a too arbitrary way which is by a strange accident
> >> fits your point of view best of all.
> >> May I remind you that Linux world is not only laptops and Sharp Zaurus? 
> >;)
> >
> >Actually, laptops and zauruses seem to be the only "interesting"
> >machines from pm perspective. Then there are Motorola cellphones, but
> >Motorola tried hard not to enable users changing kernel... so they are
> >irrelevant.
> 
> Well, I never said Zaurus was no good :)
> Please don't forget about Nokia 770 and its possible follow-ups.

Well, for now, Nokia 770 is zaurus with wifi but without keyboard
(mostly). It seems to be very similar to zaurus pm-wise.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

On 9/14/06, Pavel Machek <pavel@suse.cz> wrote:

> Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> (mostly). It seems to be very similar to zaurus pm-wise.

Yea, but AFAIK from FOSDEM/OLS Nokia folks are not satisfied with that
and would like to have a more comprehensive PM framework... like
PowerOP, for instance :)
That's my impression.

Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[David Brownell]

> > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
>
> Actually, laptops and zauruses seem to be the only "interesting"
> machines from pm perspective. Then there are Motorola cellphones, but
> Motorola tried hard not to enable users changing kernel... so they are
> irrelevant.

Get yourself some OMAP hardware then; your blinders are way too effective!

OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
battery powered already, without the hardware mods...

- Dave

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[David Brownell]

> Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> (mostly). It seems to be very similar to zaurus pm-wise.

Not hardly.  I suggest you _start_ by looking at the clock tree
specs for the OMAP5912 (very similar to the OMAP1710 in N770) ...

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Jon Loeliger]

On Thu, 2006-09-14 at 08:03, Pavel Machek wrote:

> Actually, laptops and zauruses seem to be the only "interesting"
> machines from pm perspective.

Well, and future parts and machines that are in the works.

>  Then there are Motorola cellphones, but
> Motorola tried hard not to enable users changing kernel... so they are
> irrelevant.
> 								Pavel

That might be a bit unfair.  Those engineers at Motorola
who put linux on the cellphones and mobile devices do
need to have the PM support.  They are NOT irrelevant.

jdl

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Scott E. Preece]

| From pavel@ucw.cz Thu Sep 14 08:03:52 2006
| Date: Thu, 14 Sep 2006 15:03:11 +0200
| From: Pavel Machek<pavel@ucw.cz>
| Cc: Matthew Locke<matthew.a.locke@comcast.net>,
| User-Agent: Mutt/1.5.11+cvs20060126
| 
| 
| > Pavel,
| 
| > > > operating points it is possible to implement the "cpufreq frequency
| > > > selection logic" in user space and having such functionality in the kernel
| > > > just violates the main rule of having everything possible outside of the
| > > > kernel.
| > >
| > > You got the rules wrong. "Keep the code out of kernel" is important
| > > rule, but probably not the main one.
| > 
| > from aside, it looks like you're choosing 'rules' and assign then
| > 'priorities' in a too arbitrary way which is by a strange accident
| > fits your point of view best of all.
| > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
| 
| Actually, laptops and zauruses seem to be the only "interesting"
| machines from pm perspective. Then there are Motorola cellphones, but
| Motorola tried hard not to enable users changing kernel... so they are
| irrelevant.
---

It would be interesting to see a breakdown by numbers as to where most
copies of Linux are. If embedded devices aren't the leader now, they
will be soon.

I do not speak for Motorola, so I won't respond to the dig...

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Scott E. Preece]

| From: "Vitaly Wool"<vitalywool@gmail.com>
| 
| Pavel,
| 
| On 9/14/06, Pavel Machek <pavel@ucw.cz> wrote:
| >
| > > Pavel,
| >
| > > > > operating points it is possible to implement the "cpufreq frequency
| > > > > selection logic" in user space and having such functionality in the kernel
| > > > > just violates the main rule of having everything possible outside of the
| > > > > kernel.
| > > >
| > > > You got the rules wrong. "Keep the code out of kernel" is important
| > > > rule, but probably not the main one.
| > >
| > > from aside, it looks like you're choosing 'rules' and assign then
| > > 'priorities' in a too arbitrary way which is by a strange accident
| > > fits your point of view best of all.
| > > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
| >
| > Actually, laptops and zauruses seem to be the only "interesting"
| > machines from pm perspective. Then there are Motorola cellphones, but
| > Motorola tried hard not to enable users changing kernel... so they are
| > irrelevant.
| 
| Well, I never said Zaurus was no good :)
| Please don't forget about Nokia 770 and its possible follow-ups.
| Also, please keep in mind that if we come to a joint PM solution that
| is in mainline, Motorola will use it... and will be contributing
| changes back to the community. If there was a PM solution adopted in
| mainline which fit the needs of embedded devices, more vendors would
| turn to using Linux.
| I. e., what prevents Sharp from making a open-code Lnux-based cell
| phone? I do think that the absense of PM framework suitable for
| embedded is one of the main engineering reasons... So let us broaden
| our views and work together :)
| 
| Vitaly
---

Source for the power management in current Motorola products is
available on opensource.motorola.com. However, mainstream power
management did not meet our needs, so what's there is a replacement,
rather than modifications. Because it's product-specific, it's not
particularly generalized and probably wouldn't be suitable for use
in a laptop...

scott

-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Scott E. Preece]

| From: David Brownell<david-b@pacbell.net>
| 
| > > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
| >
| > Actually, laptops and zauruses seem to be the only "interesting"
| > machines from pm perspective. Then there are Motorola cellphones, but
| > Motorola tried hard not to enable users changing kernel... so they are
| > irrelevant.
| 
| Get yourself some OMAP hardware then; your blinders are way too effective!
| 
| OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
| battery powered already, without the hardware mods...
---

And, if you don't want to buy a target board, you can use the CE Linux
Forum's on-line test lab to build and test kernels on target hardware
remotely.

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Amit Kucheria]

On Thu, 2006-09-14 at 15:20 +0200, ext Pavel Machek wrote:
> Hi!
> 
> > >> from aside, it looks like you're choosing 'rules' and assign then
> > >> 'priorities' in a too arbitrary way which is by a strange accident
> > >> fits your point of view best of all.
> > >> May I remind you that Linux world is not only laptops and Sharp Zaurus? 
> > >;)
> > >
> > >Actually, laptops and zauruses seem to be the only "interesting"
> > >machines from pm perspective. Then there are Motorola cellphones, but
> > >Motorola tried hard not to enable users changing kernel... so they are
> > >irrelevant.
> > 
> > Well, I never said Zaurus was no good :)
> > Please don't forget about Nokia 770 and its possible follow-ups.
> 
> Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> (mostly). It seems to be very similar to zaurus pm-wise.

You have conveniently chosen to forget that Nokia 770 does not support
suspend-to-disk - it is a S-T-R device. In fact, personally I agree with
Linus' comments elsewhere about S-T-D being irrelevant.

Regards,
Amit

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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
> >
> > Actually, laptops and zauruses seem to be the only "interesting"
> > machines from pm perspective. Then there are Motorola cellphones, but
> > Motorola tried hard not to enable users changing kernel... so they are
> > irrelevant.
> 
> Get yourself some OMAP hardware then; your blinders are way too effective!
> 
> OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
> battery powered already, without the hardware mods...

Well, I already have zaurus, and nokia 770 is inferior AFAICT. So the
next one will be linux cellphone...

(And IIRC zaurus lasts longer on batteries than 770 does... or at
least comparable. Maybe OMAP is more complex, but is it actually good
thing?)
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> | > > You got the rules wrong. "Keep the code out of kernel" is important
> | > > rule, but probably not the main one.
> | > 
> | > from aside, it looks like you're choosing 'rules' and assign then
> | > 'priorities' in a too arbitrary way which is by a strange accident
> | > fits your point of view best of all.
> | > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
> | 
> | Actually, laptops and zauruses seem to be the only "interesting"
> | machines from pm perspective. Then there are Motorola cellphones, but
> | Motorola tried hard not to enable users changing kernel... so they are
> | irrelevant.
> 
> It would be interesting to see a breakdown by numbers as to where most
> copies of Linux are. If embedded devices aren't the leader now, they
> will be soon.

"Relevant" devices are those where the end-users can change the
kernel. Because that's where the developers are and this area
desperately needs more developers.

Of course, *most* copies are eventually going to end up in linux-based
smartcards. But as those are not going to be hackable, so they are
irrelevant.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Thu 2006-09-14 14:25:32, Jon Loeliger wrote:
> On Thu, 2006-09-14 at 08:03, Pavel Machek wrote:
> 
> > Actually, laptops and zauruses seem to be the only "interesting"
> > machines from pm perspective.
> 
> Well, and future parts and machines that are in the works.
> 
> >  Then there are Motorola cellphones, but
> > Motorola tried hard not to enable users changing kernel... so they are
> > irrelevant.
> 
> That might be a bit unfair.  Those engineers at Motorola
> who put linux on the cellphones and mobile devices do
> need to have the PM support.  They are NOT irrelevant.

Of course I am unfair. It is nice that motorola ships linux-based
cellphones, but they made really sure that users can't hack
them... which is considered anti-social by the community. 

So it would be nice if kernel matched requirements by Motorola, but it
is *way* more important that it matches requirements by Sharp and
notebook requirements... because Sharp & notebook manufacturers
actually play fair.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> | > > May I remind you that Linux world is not only laptops and Sharp Zaurus? ;)
> | >
> | > Actually, laptops and zauruses seem to be the only "interesting"
> | > machines from pm perspective. Then there are Motorola cellphones, but
> | > Motorola tried hard not to enable users changing kernel... so they are
> | > irrelevant.
> | 
> | Get yourself some OMAP hardware then; your blinders are way too effective!
> | 
> | OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
> | battery powered already, without the hardware mods...
> ---
> 
> And, if you don't want to buy a target board, you can use the CE Linux
> Forum's on-line test lab to build and test kernels on target hardware
> remotely.

I'll get linux-based cellphone sooner or later; debugging hardware
remotely sucks, as does my current internet connection (latency wise).

Plus it should be motorola / CE manufacturers doing this work, not me.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Vitaly Wool]

On 9/17/06, Pavel Machek <pavel@ucw.cz> wrote:
> (And IIRC zaurus lasts longer on batteries than 770 does... or at
> least comparable. Maybe OMAP is more complex, but is it actually good
> thing?)

Well, it might as well depend on the batteries' volume :)
Also, WiFi needs more power.

Vitaly

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > > >> from aside, it looks like you're choosing 'rules' and assign then
> > > >> 'priorities' in a too arbitrary way which is by a strange accident
> > > >> fits your point of view best of all.
> > > >> May I remind you that Linux world is not only laptops and Sharp Zaurus? 
> > > >;)
> > > >
> > > >Actually, laptops and zauruses seem to be the only "interesting"
> > > >machines from pm perspective. Then there are Motorola cellphones, but
> > > >Motorola tried hard not to enable users changing kernel... so they are
> > > >irrelevant.
> > > 
> > > Well, I never said Zaurus was no good :)
> > > Please don't forget about Nokia 770 and its possible follow-ups.
> > 
> > Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> > (mostly). It seems to be very similar to zaurus pm-wise.
> 
> You have conveniently chosen to forget that Nokia 770 does not support
> suspend-to-disk - it is a S-T-R device. In fact, personally I agree with
> Linus' comments elsewhere about S-T-D being irrelevant.

Now I do not understand... this was power savings debate, no? Zaurus
basically does not support S-T-D either (or at least I do not use it
there), and I agree that S-T-D is irrelevant in the long term. And it
is hardly relevant for non-PC machines _now_.

								Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Amit Kucheria]

On Sun, 2006-09-17 at 15:18 +0200, ext Pavel Machek wrote:
>  
> > > Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> > > (mostly). It seems to be very similar to zaurus pm-wise.
> > 
> > You have conveniently chosen to forget that Nokia 770 does not support
> > suspend-to-disk - it is a S-T-R device. In fact, personally I agree with
> > Linus' comments elsewhere about S-T-D being irrelevant.
> 
> Now I do not understand... this was power savings debate, no? Zaurus
> basically does not support S-T-D either (or at least I do not use it
> there), and I agree that S-T-D is irrelevant in the long term. And it
> is hardly relevant for non-PC machines _now_.
> 
> 								Pavel

I was referring to the default method of power save on Zaurus on the
Sharp ROMs. It was S-T-D (Flash), IIRC. I do not recall drivers doing
runtime power management on Zaurus; that is a major difference from
Nokia 770.

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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Sun 2006-09-17 16:28:23, Amit Kucheria wrote:
> On Sun, 2006-09-17 at 15:18 +0200, ext Pavel Machek wrote:
> >  
> > > > Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> > > > (mostly). It seems to be very similar to zaurus pm-wise.
> > > 
> > > You have conveniently chosen to forget that Nokia 770 does not support
> > > suspend-to-disk - it is a S-T-R device. In fact, personally I agree with
> > > Linus' comments elsewhere about S-T-D being irrelevant.
> > 
> > Now I do not understand... this was power savings debate, no? Zaurus
> > basically does not support S-T-D either (or at least I do not use it
> > there), and I agree that S-T-D is irrelevant in the long term. And it
> > is hardly relevant for non-PC machines _now_.
> 
> I was referring to the default method of power save on Zaurus on the
> Sharp ROMs. It was S-T-D (Flash), IIRC. I do not recall drivers doing
> runtime power management on Zaurus; that is a major difference from
> Nokia 770.

I'm pretty sure Zauruses do s-t-ram. Flash is read only during normal
operation.

I'm very sure Sharp zaurus sl-5500 does s-t-ram. After all, it has
16MB of flash and 64MB of ram. Suspend-to-flash is not an option.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Amit Kucheria]

(Modified recipient list)

On Sun, 2006-09-17 at 15:40 +0200, ext Pavel Machek wrote:
> On Sun 2006-09-17 16:28:23, Amit Kucheria wrote:
> > On Sun, 2006-09-17 at 15:18 +0200, ext Pavel Machek wrote:
> > >  
> > > > > Well, for now, Nokia 770 is zaurus with wifi but without keyboard
> > > > > (mostly). It seems to be very similar to zaurus pm-wise.
> > > > 
> > > > You have conveniently chosen to forget that Nokia 770 does not support
> > > > suspend-to-disk - it is a S-T-R device. In fact, personally I agree with
> > > > Linus' comments elsewhere about S-T-D being irrelevant.
> > > 
> > > Now I do not understand... this was power savings debate, no? Zaurus
> > > basically does not support S-T-D either (or at least I do not use it
> > > there), and I agree that S-T-D is irrelevant in the long term. And it
> > > is hardly relevant for non-PC machines _now_.
> > 
> > I was referring to the default method of power save on Zaurus on the
> > Sharp ROMs. It was S-T-D (Flash), IIRC. I do not recall drivers doing
> > runtime power management on Zaurus; that is a major difference from
> > Nokia 770.
> 
> I'm pretty sure Zauruses do s-t-ram. Flash is read only during normal
> operation.
> 
> I'm very sure Sharp zaurus sl-5500 does s-t-ram. After all, it has
> 16MB of flash and 64MB of ram. Suspend-to-flash is not an option.
> 
> 								Pavel

If that is the case, I stand corrected. Did the drivers support dynamic
idling?

Although something about the time it took to resume still bothers me....
I will try to find time to flash it and check.


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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Preece Scott-PREECE]

> From: Pavel Machek [mailto:pavel@ucw.cz] 
> 
> On Thu 2006-09-14 14:25:32, Jon Loeliger wrote:
> > On Thu, 2006-09-14 at 08:03, Pavel Machek wrote:
> > 
> > > Actually, laptops and zauruses seem to be the only "interesting"
> > > machines from pm perspective.
> > 
> > Well, and future parts and machines that are in the works.
> > 
> > >  Then there are Motorola cellphones, but Motorola tried 
> hard not to 
> > > enable users changing kernel... so they are irrelevant.
> > 
> > That might be a bit unfair.  Those engineers at Motorola 
> who put linux 
> > on the cellphones and mobile devices do need to have the PM 
> support.  
> > They are NOT irrelevant.
> 
> Of course I am unfair. It is nice that motorola ships 
> linux-based cellphones, but they made really sure that users 
> can't hack them... which is considered anti-social by the community. 
> 
> So it would be nice if kernel matched requirements by 
> Motorola, but it is *way* more important that it matches 
> requirements by Sharp and notebook requirements... because 
> Sharp & notebook manufacturers actually play fair.
---

Depends, of course, on your definition of "fair". The CE 
manufacturers are investing a lot of work in Linux, either
directly or through hiring developers and working through
distributors. And they're giving their enhancements back
to the community, which is what was generally considered
"fair" for open-source development. The power management
stuff may be too narrow to be interesting to laptop-based
developers,but things like reduced boot time ought to be
Of more general interest.

I expect modifiable kernels in the future, but that requires
a lot of extra engineering (beyond just making the device
work) to harden the non-open elements so that malicious
kernel changes couldn't compromise them. None of the
manufacturers is going to build a cellphone or DVR that
service providers won't allow on their networks...

scott

Re: community PM requirements/issues and PowerOP[Was: Re: So, what's the status on the recent patches here?]

[Preece Scott-PREECE]

 > From:  Amit Kucheria
> 
> On Sun, 2006-09-17 at 15:40 +0200, ext Pavel Machek wrote:
> > On Sun 2006-09-17 16:28:23, Amit Kucheria wrote:
> > > On Sun, 2006-09-17 at 15:18 +0200, ext Pavel Machek wrote:
...
> > > I was referring to the default method of power save on 
> Zaurus on the 
> > > Sharp ROMs. It was S-T-D (Flash), IIRC. I do not recall drivers 
> > > doing runtime power management on Zaurus; that is a major 
> difference 
> > > from Nokia 770.
> > 
> > I'm pretty sure Zauruses do s-t-ram. Flash is read only 
> during normal 
> > operation.
> > 
> > I'm very sure Sharp zaurus sl-5500 does s-t-ram. After all, it has 
> > 16MB of flash and 64MB of ram. Suspend-to-flash is not an option.
> > 
> > 								Pavel
> 
> If that is the case, I stand corrected. Did the drivers 
> support dynamic idling?
> 
> Although something about the time it took to resume still 
> bothers me....
> I will try to find time to flash it and check.

Google provided a reference to what appears to be a student
paper on power management in the Zaurus, at:
<http://personals.ac.upc.edu/mpericas/zaurus_project-final.pdf#search=%2
2%22power%20management%22%20zaurus%20linux%22>.

>From the paper, it sounds like it has cpufreq 
scaling and a sleep mode that is basically suspend-to-RAM.
This was apparently done via backporting stuff to 2.4.

Scott

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

> (Modified recipient list)

> > I'm pretty sure Zauruses do s-t-ram. Flash is read only during normal
> > operation.
> > 
> > I'm very sure Sharp zaurus sl-5500 does s-t-ram. After all, it has
> > 16MB of flash and 64MB of ram. Suspend-to-flash is not an option.
> 
> If that is the case, I stand corrected. Did the drivers support dynamic
> idling?

Not sure about that one.

> Although something about the time it took to resume still bothers me....
> I will try to find time to flash it and check.

Well, in 2.6.X suspend-to-RAM means console switch and process
freezing. (Yes, it would be nice to fix that).
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Amit Kucheria]

On Sun, 2006-09-17 at 14:34 +0200, ext Pavel Machek wrote:

> > OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
> > battery powered already, without the hardware mods...
> 
> Well, I already have zaurus, and nokia 770 is inferior AFAICT. So the
> next one will be linux cellphone...
> 
> (And IIRC zaurus lasts longer on batteries than 770 does... or at
> least comparable. Maybe OMAP is more complex, but is it actually good
> thing?)
> 								Pavel

Wifi + Significantly higher resolution display tend to play a 'small'
role in this.

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

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

On Mon 2006-09-18 13:46:04, Amit Kucheria wrote:
> On Sun, 2006-09-17 at 14:34 +0200, ext Pavel Machek wrote:
> 
> > > OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
> > > battery powered already, without the hardware mods...
> > 
> > Well, I already have zaurus, and nokia 770 is inferior AFAICT. So the
> > next one will be linux cellphone...
> > 
> > (And IIRC zaurus lasts longer on batteries than 770 does... or at
> > least comparable. Maybe OMAP is more complex, but is it actually good
> > thing?)
> 
> Wifi + Significantly higher resolution display tend to play a 'small'
> role in this.

640x480 display vs. 800x480 display does not sound like _that_ big
deal to me. You are right with wifi, that beasts eat 1W-or-so. (and it
would be great if someone implemented wifi power saving...)

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Igor Stoppa]

On Mon, 2006-09-18 at 12:53 +0200, ext Pavel Machek wrote:
> On Mon 2006-09-18 13:46:04, Amit Kucheria wrote:
> > On Sun, 2006-09-17 at 14:34 +0200, ext Pavel Machek wrote:
> > 
> > > > OMAP1 hardware is easily had; an OSK, or a Nokia N770.  The latter is
> > > > battery powered already, without the hardware mods...
> > > 
> > > Well, I already have zaurus, and nokia 770 is inferior AFAICT. So the
> > > next one will be linux cellphone...
> > > 
> > > (And IIRC zaurus lasts longer on batteries than 770 does... or at
> > > least comparable. Maybe OMAP is more complex, but is it actually good
> > > thing?)
> > 
> > Wifi + Significantly higher resolution display tend to play a 'small'
> > role in this.
> 
> 640x480 display vs. 800x480 display does not sound like _that_ big
> deal to me. You are right with wifi, that beasts eat 1W-or-so. (and it
> would be great if someone implemented wifi power saving...)
> 
> 								Pavel

wifi power saving does exist and you have it already in 770
and also color depth probably affects performance: do they have the same
number of bits per pixel?
-- 
Cheers,
           Igor

Igor Stoppa (Nokia M - OSSO / Tampere)

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > Of course I am unfair. It is nice that motorola ships 
> > linux-based cellphones, but they made really sure that users 
> > can't hack them... which is considered anti-social by the community. 
> > 
> > So it would be nice if kernel matched requirements by 
> > Motorola, but it is *way* more important that it matches 
> > requirements by Sharp and notebook requirements... because 
> > Sharp & notebook manufacturers actually play fair.
> ---
> 
> Depends, of course, on your definition of "fair". The CE 
> manufacturers are investing a lot of work in Linux, either
> directly or through hiring developers and working through
> distributors. And they're giving their enhancements back
> to the community, which is what was generally considered
> "fair" for open-source development. The power management

Well, CE equipment usually uses obsolete, heavily modified kernels,
and developed in-house (as opposed by community). Yes, it is nice that
Motorola uses Linux and not WindowsCE...

> stuff may be too narrow to be interesting to laptop-based
> developers,but things like reduced boot time ought to be
> Of more general interest.

Yep, boottime reductions are always nice... if they are not too specialized.

> I expect modifiable kernels in the future, but that requires
> a lot of extra engineering (beyond just making the device
> work) to harden the non-open elements so that malicious
> kernel changes couldn't compromise them. None of the

What is the issue here? I thought that GSM stack runs on separate CPU,
anyway? And in practice, it is probably possible to flash your
equipment... Like small shops offering "unlocking" do it all the time.

> manufacturers is going to build a cellphone or DVR that
> service providers won't allow on their networks...

What is the issue? I can do whatever I want (including modifying
phone-side firmware so that phone works without SIMcard, just with Ki)
with siemens ME45 already. Of course Siemens will not support me doing
that... That should not be too different with Motorola...?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Preece Scott-PREECE]

> From: Pavel Machek [mailto:pavel@ucw.cz] 
> 
> ... because Sharp & notebook manufacturers 
> > > actually play fair.
> > ---
> > 
> > Depends, of course, on your definition of "fair". The CE 
> manufacturers 
> > are investing a lot of work in Linux, either directly or through 
> > hiring developers and working through distributors. And 
> they're giving 
> > their enhancements back to the community, which is what was 
> generally 
> > considered "fair" for open-source development. The power management
> 
> Well, CE equipment usually uses obsolete, heavily modified 
> kernels, and developed in-house (as opposed by community). 
> Yes, it is nice that Motorola uses Linux and not WindowsCE...
---

There are perfectly sensible business reasons why device manufacturers
need to freeze their development on old kernels (and other components)
for long periods of time. Are you saying this is "unfair" to the
developers? I understand that it makes the patches less useful, in
many cases, but unfair?

I do hope that Motorola, and other CE manufacturers, will start working
more closely with the community.  The CE Linux Forum was set up in part
to make that easier and more effective. I believe it would be better 
for both the manufacturers and the community.

---
> ... 
> > I expect modifiable kernels in the future, but that 
> requires a lot of 
> > extra engineering (beyond just making the device
> > work) to harden the non-open elements so that malicious 
> kernel changes 
> > couldn't compromise them. None of the
> 
> What is the issue here? I thought that GSM stack runs on 
> separate CPU, anyway? And in practice, it is probably 
> possible to flash your equipment... Like small shops offering 
> "unlocking" do it all the time.
---
[NOTE again that I do not speak for Motorola in this mailing list;
these comments are not based on direct knowledge of policy, and
IANAL!]

The issue is "due diligence" - a manufacturer could be held liable
for damage done by a modified device if they have not made a good
faith effort to make such modification either (a) safe or
(b) very difficult. Yes, this is non-value-add work, but there are
people in the world who do malicious things, and manufacturers are
very worried about courts finding that they were negligent in
not making a greater effort to stop such malicious people.

There is also a liability issue with non-malicious changes, in that
manufacturers can sometimes be held liable for things that users
do to themselves. [If you believe that disclaimers of liability or 
warranty will actually protect you in court, you're probably 
being naïve.]

There are also, of course, contractual issues with carriers and
content owners, who could also sue if a manufacturer didn't make a
sufficient effort to protect the terms of the contract. The
carriers and content owners are continually raising the bar on the
level of protection they require.

---
> 
> > manufacturers is going to build a cellphone or DVR that service 
> > providers won't allow on their networks...
> 
> What is the issue? I can do whatever I want (including 
> modifying phone-side firmware so that phone works without 
> SIMcard, just with Ki) with siemens ME45 already. Of course 
> Siemens will not support me doing that... That should not be 
> too different with Motorola...?
---

While legal specifics may vary from country to country, for US
Manufacturers, the same issues as above...

scott

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Pavel Machek]

Hi!

> > ... because Sharp & notebook manufacturers 
> > > > actually play fair.
> > > ---
> > > 
> > > Depends, of course, on your definition of "fair". The CE 
> > manufacturers 
> > > are investing a lot of work in Linux, either directly or through 
> > > hiring developers and working through distributors. And 
> > they're giving 
> > > their enhancements back to the community, which is what was 
> > generally 
> > > considered "fair" for open-source development. The power management
> > 
> > Well, CE equipment usually uses obsolete, heavily modified 
> > kernels, and developed in-house (as opposed by community). 
> > Yes, it is nice that Motorola uses Linux and not WindowsCE...
> ---
> 
> There are perfectly sensible business reasons why device manufacturers
> need to freeze their development on old kernels (and other components)
> for long periods of time. Are you saying this is "unfair" to the
> developers? I understand that it makes the patches less useful, in
> many cases, but unfair?

No, I call "you may not use your own kernel on your own hardware",
even if manufacturer of that hardware is using your code and code is
GPLed "unfair". Being locked onto old kernel is unfortunate, but fair.

> I do hope that Motorola, and other CE manufacturers, will start working
> more closely with the community.  The CE Linux Forum was set up in

Yep, I hope so, too.

> > ... 
> > > I expect modifiable kernels in the future, but that 
> > requires a lot of 
> > > extra engineering (beyond just making the device
> > > work) to harden the non-open elements so that malicious 
> > kernel changes 
> > > couldn't compromise them. None of the
> > 
> > What is the issue here? I thought that GSM stack runs on 
> > separate CPU, anyway? And in practice, it is probably 
> > possible to flash your equipment... Like small shops offering 
> > "unlocking" do it all the time.
> 
> The issue is "due diligence" - a manufacturer could be held liable
> for damage done by a modified device if they have not made a good
> faith effort to make such modification either (a) safe or
> (b) very difficult. Yes, this is non-value-add work, but there are
> people in the world who do malicious things, and manufacturers are
> very worried about courts finding that they were negligent in
> not making a greater effort to stop such malicious people.

Well, I believe Motorola is going a bit further than "due
diligence". Making directories inaccessible on running system (not
even read only!) was probably not mandatory, right? And even M$
smartphones support end-user updating of firmware.

> There are also, of course, contractual issues with carriers and
> content owners, who could also sue if a manufacturer didn't make a
> sufficient effort to protect the terms of the contract. The
> carriers and content owners are continually raising the bar on the
> level of protection they require.

Yep, I see it sucks being phone manufacturer. But you have separate
CPU doing GSM stack in current cellphones, right? I believe you even
use AT commands for communication... That should be about as hard as
pcmcia card to "harden", and yes, people are routinelly selling pcmcia
GSM cards.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Scott E. Preece]

| From pavel@ucw.cz Sat Sep 23 18:42:14 2006
| 
| Hi!
| 
| > There are also, of course, contractual issues with carriers and
| > content owners, who could also sue if a manufacturer didn't make a
| > sufficient effort to protect the terms of the contract. The
| > carriers and content owners are continually raising the bar on the
| > level of protection they require.
| 
| Yep, I see it sucks being phone manufacturer. But you have separate
| CPU doing GSM stack in current cellphones, right? I believe you even
| use AT commands for communication... That should be about as hard as
| pcmcia card to "harden", and yes, people are routinelly selling pcmcia
| GSM cards.
---

Yes, as I've said elsewhere, I believe the modem software and
communication between the applications and modem processors could be
hardened to a point where it would be safe to make the kernel
replaceable. However, the folks who designed the current product didn't
have that as a requirement, so it wasn't designed that way...

scott
-- 
scott preece
motorola mobile devices, il67, 1800 s. oak st., champaign, il  61820  
e-mail:	preece@motorola.com	fax:	+1-217-384-8550
phone:	+1-217-384-8589	cell: +1-217-433-6114	pager: 2174336114@vtext.com

Re: community PM requirements/issues and PowerOP [Was: Re: So, what's the status on the recent patches here?]

[Dominik Brodowski]

Hi,

Just to set the record straight:

On Tue, Sep 12, 2006 at 02:05:26AM +0400, Eugeny S. Mints wrote:
> Cpuferq defines cpufreq_frequency_table structure in arch independent header 
> while it's arch dependent data structure.

cpufreq_frequency_table is an _optional_ library architectures _may_ use if
they consider it useful to them. It's useful for most of them, but it is not
required at the core level. For a reason.

> A lot of code is built around this 
> invalid basic brick and therefore is invalid: cpufreq tables, interface with cpu 
> freq drivers, etc.

cpufreq tables? what do you mean with that?

And the interface with cpufreq drivers does not rely on
cpufreq_frequency_table. That's one of the fun things in cpufreq. You don't
need to define a pre-defined table for the >10^5 states at least one cpufreq
driver offers.

> Notion of transition latency as it defined by cpufreq is 
> wrong because it's not a function of cpu type but function of current and next 
> operating point.

That may be, but it may serve as the "maximum latency" at the moment; if
needed, it could be expanded, e.g. using or on top of the interfaces
described in http://lwn.net/Articles/197299/ .

> no runtime control on operating points set. it's always the 
> same set of operating points for all system cpus in smp case and no way to 
> define different sets or track any dependencies in case say multi core cpus. 

You can define different min, current, and max frequencies (for this is all
the cpufreq core cares about) for multiple cores. How the freq_table
interactions work then, I cannot say without checking the source -- but as
it is only an _optional_ library an arch can use, that doesn't count.

> insufficient kernel<->user space interface to handle embedded requirements and 
> no way to extend it within current design.

Nobody tried to do so yet, to my knowledge.

> PowerOP/cufreq integration patch set contains very details explanation of the 
> cpufreq design issues and POwerOP solutions. Comment there is you feel it's wrong.

I'll gladly do so soon, and I'll also comment further on the PowerOP patches -- but
not today, sorry.


Thanks,
	Dominik