Dynanic On-The-Fly Operating points for PowerOP
Subsystems (8)
The patches provided in the following three emails continue the unified,
simplified PowerOp concept of power management. The patches can be found at:
http://source.mvista.com/~dsingleton
powerop-core.patch powerop-cpufreq.patch powerop-x86-centrino.patch
The patches break the working PowerOP feature into
three logical parts. The first patch is the powerop-core.patch that adds support for an operating point in the standard linux power management infrastructure (CONFIG_PM) and adds a new function to perform transitioning to operating points other than suspend to memory or disk.
The second patch, powerop-cpufreq.patch, adds the cpufreq
portion of the patch that makes cpufreq tables a set of PowerOp operating points.
The third patch, powerop-x86-centrino.patch, adds
operating points for all the centrino-speedstep processors.
This set of patches has changed in the following ways.
1) The patch is now broken out of the cpufreq code and implements operating points for whatever speedstep-centrino the system detects upon boot.
2) The naming scheme for operating points has been unified to provide a better interface to the PowerOp power manager daemon. The names range from:
highest
high
medhigh
medium
medlow
low
lowest
PowerOp maps the supported processor frequencies onto this namespace list. The set of centrino processors it supports have supported sets of between four and six different operating points.
The PowerOP daemon, coming soon, can simply read the supported set of operating points and make some simple rules based decisions about when to transition to various operating points.
The goal of a unified name space is to provide a PowerOp manager that runs out of the box, with very little setup by the user.
3) This patch supports the ability to provide dynamic, on-the-fly operating points to the framework via a loadable module. The
operating
point parameters of frequency, voltage and transition latency can be passed at insmod time to create any new operating point the centrino hardware will support.
I think I finally understand the 'why' of hardware vendors asking for a requirement of dynamic, on the fly, operating points.
I have two sets of hardware that support a wide range of processor speeds and voltages depending on:
a) the rotary and dip switch setting of the board (the mainstone).
or
b) the revision or stepping of the hardware on the board.
Certain revs of hardware support different frequencies and
voltages.
Some steppings won't run all the frequencies.
The hardware vendors want to provide support for all the frequencies and voltages that the system could support, depending on the switch settings or rev of hardware without having to change kernel code and recompile the kernel.
The new dynamic, on the fly, operating point module will allow for this feature.
David
Dave,
I think we need to focus on defining a powerop interface that will work for all (or as close to all as possible) architectures and devices
types including embedded, laptop, server. As discussed in previous
emails, some of the goals for powerop are:
- Architecture/board independent interface
- Integrate with clk framework (and a voltage framework in the future) for SoC/Board register setting abstraction
- Provide a layer that knows the SoC and board specifics about relationship between voltage and frequency and setting operating points (we call it PM Core)
- Provide a clean interface to build on top of (for cpu freq governors, etc).
I think we can defer the discussion around creation of op points from userspace, suspend/resume integration and transition notifiers. Once we get the basics submitted we can add features piece by piece.
Rather than continue submitting different powerop patches I would encourage you to join in the discussion about the interface. I think Eugeny's latest patches are pretty close to satisfying the points made so far. However, we are eagerly waiting feedback because there always tradeoffs that need to be made when trying to satisfy the goals listed above.
Thanks
Matt
Quoted 105 lines · David Singleton
The patches provided in the following three emails continue the unified,
simplified PowerOp concept of power management. The patches can be found at:http://source.mvista.com/~dsingleton
powerop-core.patch powerop-cpufreq.patch powerop-x86-centrino.patch
The patches break the working PowerOP feature into
three logical parts. The first patch is the powerop-core.patch that adds support for an operating point in the standard linux power management infrastructure (CONFIG_PM) and adds a new function to perform transitioning to operating points other than suspend to memory or disk.The second patch, powerop-cpufreq.patch, adds the
cpufreq
portion of the patch that makes cpufreq tables a set of PowerOp operating points.The third patch, powerop-x86-centrino.patch, adds
operating points for all the centrino-speedstep processors.This set of patches has changed in the following ways.
1) The patch is now broken out of the cpufreq code and
implements
operating points for whatever speedstep-centrino the system detects upon boot.2) The naming scheme for operating points has been unified to provide a better interface to the PowerOp power manager daemon. The names range from:
highest
high
medhigh
medium
medlow
low
lowestPowerOp maps the supported processor frequencies onto this namespace list. The set of centrino processors it supports
have
supported sets of between four and six different operating
points.The PowerOP daemon, coming soon, can simply read the supported set of operating points and make some simple rules based decisions about when to transition to various operating points.
The goal of a unified name space is to provide a PowerOp
manager
that runs out of the box, with very little setup by the user.3) This patch supports the ability to provide dynamic,
on-the-fly
operating points to the framework via a loadable module. The
operating
point parameters of frequency, voltage and transition latency can be passed at insmod time to create any new operating point the centrino hardware will support.I think I finally understand the 'why' of hardware vendors
asking
for a requirement of dynamic, on the fly, operating points.I have two sets of hardware that support a wide range of processor speeds and voltages depending on:
a) the rotary and dip switch setting of the board (the
mainstone).or
b) the revision or stepping of the hardware on the board.
Certain revs of hardware support different frequencies and
voltages.
Some steppings won't run all the frequencies.The hardware vendors want to provide support for all the frequencies and voltages that the system could support, depending on the switch settings or rev of hardware without having to change kernel code and recompile the kernel.
The new dynamic, on the fly, operating point module will allow for this feature.
David
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm
Quoted 6 lines · Matthew Locke
Dave,
I think we need to focus on defining a powerop interface that will work for all (or as close to all as possible) architectures and
devices types including embedded, laptop, server. As discussed in
previous emails, some of the goals for powerop are:
Matt,
I'd hoped I had joined the discussion about the interface. Is
linux-pm not the right mailing list to discuss this? I asked Todd and he pointed me at linux-pm.
I find sending patches that actually work and that people can apply
and try makes it easier to discuss and evaluate the
concepts and interfaces. I find it necessary to actually have working code to prove a concept.
I also thought the powerop write up and patches I had sent out did address the goals discussed so far:
Quoted 2 lines
- Architecture/board independent interface
It has an architecture/board independent interface, /sys/power/state, /sys/power/supported_states, which presents
a simplified interface to the user (and power manager). These two files present the entire interface to the user.
The powerop struct provides the independent interface to the routines to prepare_transition, transition andfinish_transition is arch independent, through the prepare_transition, transition and finish_transition function pointers.
The powerop struct also provides the void *md_data pointer which keeps the details an arch/board's clocks, their divisors/multipliers, etc. in the arch/board pieces of code.
The powerop struct is arch/board independent. The functions to
control clocks, frequencies, voltages, etc are very arch/board dependent, but have an arch independent interface through their op_vector in the powerop struct.
Quoted 2 lines
- Integrate with clk framework (and a voltage framework in the future) for SoC/Board register setting abstraction
This is the patch I'm working on now. I want to actually integrate it and keep the boundary between arch independent
and arch/board dependent clear.
Quoted 3 lines
- Provide a layer that knows the SoC and board specifics about relationship between voltage and frequency and setting operating points (we call it PM Core)
The patch I'm working on now shows the clock/register abstraction for SoC/board stuff.
The centrino abstraction examle I sent out is quite simple since the perfctl register msr bits can be calculated from the frequency
and voltage. For a more complex board there will be a lot more
information, like clocks, their divisors/multipliers for each operating point, etc.
But the abstraction is the same for simple or complex boards. Each operating point has an md_data pointer that
points to a struct of arch/board dependent data that the transition routines need. The rest of the abstraction lies
within the three routines to prepare_transition, transition and finish_transition. These routines handle thearch/board details while the interface remains the same, the function pointers in each operating point
Quoted 2 lines
- Provide a clean interface to build on top of (for cpu freq governors, etc).
The point of the powerop patches I've sent is to make a simple interface for power daemons and move all the policy, class and governor code out of the kernel and into user space, where I believe it belongs.
Quoted 4 lines
I think we can defer the discussion around creation of op points from userspace, suspend/resume integration and transition notifiers. Once we get the basics submitted we can add features piece by piece.
I'd prefer not to. One of the points of sending patches that work is to make sure any new requirements still work without breaking the existing framework.
Quoted 7 lines
Rather than continue submitting different powerop patches I would encourage you to join in the discussion about the interface. I think Eugeny's latest patches are pretty close to satisfying the points made so far. However, we are eagerly waiting feedback because there always tradeoffs that need to be made when trying to satisfy the goals listed above.
My hope is that by sending patches that work for more and more boards people will see that the concepts and interfaces work across a wide range of platforms, from embedded to servers.
David
Quoted 116 lines
Thanks
Matt
Quoted 109 lines · David Singleton
The patches provided in the following three emails continue the unified,
simplified PowerOp concept of power management. The patches can be found at:http://source.mvista.com/~dsingleton
powerop-core.patch powerop-cpufreq.patch powerop-x86-centrino.patch
The patches break the working PowerOP feature into
three logical parts. The first patch is the
powerop-core.patch
that adds support for an operating point in the standard linux power management infrastructure (CONFIG_PM) and adds a new function to perform transitioning to operating points other than suspend to memory or disk.The second patch, powerop-cpufreq.patch, adds the
cpufreq
portion of the patch that makes cpufreq tables a set of
PowerOp
operating points.The third patch, powerop-x86-centrino.patch, adds
operating points for all the centrino-speedstep processors.This set of patches has changed in the following ways.
1) The patch is now broken out of the cpufreq code and
implements
operating points for whatever speedstep-centrino the system detects upon boot.2) The naming scheme for operating points has been unified to provide a better interface to the PowerOp power manager
daemon.
The names range from:highest
high
medhigh
medium
medlow
low
lowestPowerOp maps the supported processor frequencies onto this namespace list. The set of centrino processors it supports
have
supported sets of between four and six different operating
points.The PowerOP daemon, coming soon, can simply read the supported set of operating points and make some simple rules based decisions about when to transition to various operating
points.The goal of a unified name space is to provide a PowerOp
manager
that runs out of the box, with very little setup by the user.3) This patch supports the ability to provide dynamic,
on-the-fly
operating points to the framework via a loadable module. The
operating
point parameters of frequency, voltage and transition latency can be passed at insmod time to create any new operating point the centrino hardware will support.I think I finally understand the 'why' of hardware vendors
asking
for a requirement of dynamic, on the fly, operating points.I have two sets of hardware that support a wide range of processor speeds and voltages depending on:
a) the rotary and dip switch setting of the board (the
mainstone).or
b) the revision or stepping of the hardware on the board.
Certain revs of hardware support different frequencies and
voltages.
Some steppings won't run all the frequencies.The hardware vendors want to provide support for all the frequencies and voltages that the system could support, depending on the switch settings or rev of hardware without having to change kernel code and recompile the kernel.
The new dynamic, on the fly, operating point module will allow for this feature.
David
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm
Quoted 11 lines · david singleton
Quoted 6 lines · Matthew Locke
Dave,
I think we need to focus on defining a powerop interface that will work for all (or as close to all as possible) architectures and
devices types including embedded, laptop, server. As discussed in
previous emails, some of the goals for powerop are:
Quoted 4 lines
Matt,
I'd hoped I had joined the discussion about the interface. Is
linux-pm not the right mailing list to discuss this? I asked Todd and he pointed me at linux-pm.
Well, that is not what I meant. Clearly this is the right list - at least I hope so because I haven't seen any of the cpufreq developers respond to yours or Eugney's patches:)
Quoted 6 lines
I find sending patches that actually work and that people can apply
and try makes it easier to discuss and evaluate the
concepts and interfaces. I find it necessary to actually have working code to prove a concept.
Yes, which is why Eugeny and I sent out the take 3 PowerOP patches. A good discussion ensued and our updated patches are a result of that discussion. If you disagree with our approach or think something is missing, give us some specific feedback. Simply sending out a separate set of PowerOP patches is not joining in the current discussion. It is
confusing and probably turning people off to the ideas. Is there
something specific missing or wrong with the patches we submitted that required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information. If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.
Quoted 3 lines
I also thought the powerop write up and patches I had sent out did address the goals discussed so far:
Um, I thought the powerop write up and patches already sent out addressed the goals discussed so far. We (everyone on the list) need to collaborate on the powerop effort. Isolated development and attempting to discuss two separate implementations won't get us very far.
Quoted 9 lines
Quoted 3 lines
- Architecture/board independent interface
It has an architecture/board independent interface,
/sys/power/state,/sys/power/supported_states, which presents
a simplified interface to the user (and power manager). These two files present the entire interface to the user.
Quoted 7 lines
The powerop struct provides the independent interface to the routines to
prepare_transition, transition andfinish_transitionis arch independent, through theprepare_transition, transition andfinish_transitionfunction pointers.
The powerop struct also provides the void*md_datapointer which keeps the details an arch/board's clocks, their divisors/multipliers, etc. in thearch/boardpieces of code.
The transition callbacks are not needed in every operating point and has nothing to do with the operating point definition. Again, if something is missing from the PowerOP patches, let us know.
Quoted 7 lines
The powerop struct is
arch/boardindependent. The functions to
control clocks, frequencies, voltages, etc are veryarch/boarddependent, but have an arch independent interface through theirop_vectorin the powerop struct.
Quoted 6 lines
Quoted 2 lines
- Integrate with clk framework (and a voltage framework in the future) for SoC/Board register setting abstraction
This is the patch I'm working on now. I want to actually integrate it and keep the boundary between arch independent
andarch/boarddependent clear.
We already have done this. Why duplicate design and implementation effort?
Quoted 7 lines
Quoted 4 lines
- Provide a layer that knows the SoC and board specifics about relationship between voltage and frequency and setting operating points (we call it PM Core)
The patch I'm working on now shows the clock/register abstraction for SoC/board stuff.
The kernel already has a clk framework that provides an API to set frequencies by clk name. It probably could be made even more architecture independent. There is no reason to start from scratch.
Quoted 6 lines
The centrino abstraction examle I sent out is quite simple since the perfctl register msr bits can be calculated from the frequency
and voltage. For a more complex board there will be a lot more
information, like clocks, their divisors/multipliers for each operating point, etc.
Right, we chose OMAP1 for the first implementation to show an example SoC with the lot more information.
Quoted 9 lines
But the abstraction is the same for simple or complex boards. Each operating point has an
md_datapointer that
points to a struct ofarch/boarddependent data that the transition routines need. The rest of the abstraction lies
within the three routines toprepare_transition, transition andfinish_transition. These routines handle thearch/boarddetails while the interface remains the same, the function pointers in each operating point
The transition callbacks in the operating point are not necessary. Take a look at how we did this and I think you will find it much more flexible and applicable to a wider range of situations. For example, by including frequency and voltage in the generic operating point structure, you are already violating the architecture/board independence. Embedded SoC's, SMP systems, and MP systems will have multiple frequency and voltages parameters.
Quoted 9 lines
Quoted 4 lines
- Provide a clean interface to build on top of (for cpu freq governors, etc).
The point of the powerop patches I've sent is to make a simple interface for power daemons and move all the policy, class and governor code out of the kernel and into user space, where I believe it belongs.
Agreed. The patches we sent have the same goal.
Quoted 9 lines
Quoted 5 lines
I think we can defer the discussion around creation of op points from userspace, suspend/resume integration and transition notifiers. Once we get the basics submitted we can add features piece by piece.
I'd prefer not to. One of the points of sending patches that work is to make sure any new requirements still work without breaking the existing framework.
The API isn't going to freeze. Kernel internals change all the time. Once we have a solid first pass at the kernel portion of powerop we can build features and userspace interfaces on top of it. If you have followed the powerop threads, then you know everyone agrees to this approach.
Quoted 9 lines
Quoted 8 lines
Rather than continue submitting different powerop patches I would encourage you to join in the discussion about the interface. I think Eugeny's latest patches are pretty close to satisfying the points made so far. However, we are eagerly waiting feedback because there always tradeoffs that need to be made when trying to satisfy the goals listed above.
Quoted 3 lines
My hope is that by sending patches that work for more and more boards people will see that the concepts and interfaces work across a wide range of platforms, from embedded to servers.
My goal is to get PowerOP into the mainline kernel. If everyone submits a different powerop implementation for those boards, then people will see a fragmented concept that can not be generalized. The possibility of Andrew and Linus accepting PowerOP will go from high to
never. Again, I don't see any reason for two separate development
efforts and patchsets. Please stop submitting separate patches and at least attempt to collaborate on the current PowerOP patchsets under discussion. We should be able to agree since we are both from an embedded background:)
I agree that we need a few more boards to prove the interface work and I want to see tighter integration of our PowerOP patches and cpufreq. Also we do need a centrino port. If you don't have any issues with the interface we've presented, let's start collaborating. Perhaps you could start from the next rev of patches and add centrino support?
btw, I would like see feedback on Eugeny's last set of patches.
Matt
Quoted 124 lines
David
Quoted 120 lines
Thanks
Matt
Quoted 113 lines · David Singleton
The patches provided in the following three emails continue the unified,
simplified PowerOp concept of power management. The patches can be found at:http://source.mvista.com/~dsingleton
powerop-core.patch powerop-cpufreq.patch powerop-x86-centrino.patch
The patches break the working PowerOP feature into
three logical parts. The first patch is the
powerop-core.patch
that adds support for an operating point in the standard
linux
power management infrastructure (CONFIG_PM) and adds a new function to perform transitioning to operating points other than suspend to memory or disk.The second patch, powerop-cpufreq.patch, adds the
cpufreq
portion of the patch that makes cpufreq tables a set of
PowerOp
operating points.The third patch, powerop-x86-centrino.patch, adds
operating points for all the centrino-speedstep processors.This set of patches has changed in the following ways.
1) The patch is now broken out of the cpufreq code and
implements
operating points for whatever speedstep-centrino the system detects upon boot.2) The naming scheme for operating points has been unified to provide a better interface to the PowerOp power manager
daemon.
The names range from:highest
high
medhigh
medium
medlow
low
lowestPowerOp maps the supported processor frequencies onto this namespace list. The set of centrino processors it supports
have
supported sets of between four and six different operating
points.The PowerOP daemon, coming soon, can simply read the
supported
set of operating points and make some simple rules based decisions about when to transition to various operating
points.The goal of a unified name space is to provide a PowerOp
manager
that runs out of the box, with very little setup by the user.3) This patch supports the ability to provide dynamic,
on-the-fly
operating points to the framework via a loadable module. The
operating
point parameters of frequency, voltage and transition latency can be passed at insmod time to create any new operating
point
the centrino hardware will support.I think I finally understand the 'why' of hardware vendors
asking
for a requirement of dynamic, on the fly, operating points.I have two sets of hardware that support a wide range of processor speeds and voltages depending on:
a) the rotary and dip switch setting of the board (the
mainstone).or
b) the revision or stepping of the hardware on the board.
Certain revs of hardware support different frequencies and
voltages.
Some steppings won't run all the frequencies.The hardware vendors want to provide support for all the frequencies and voltages that the system could support, depending on the switch settings or rev of hardware without having to change kernel code and recompile the kernel.
The new dynamic, on the fly, operating point module will
allow
for this feature.David
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm
Quoted 4 lines
Yes, which is why Eugeny and I sent out the take 3 PowerOP patches. A good discussion ensued and our updated patches are a result of that discussion. If you disagree with our approach or think something is missing, give us some specific feedback. Simply sending out a separate
Quoted 8 lines
set of PowerOP patches is not joining in the current discussion. It is
confusing and probably turning people off to the ideas. Is there
something specific missing or wrong with the patches we submitted that required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information. If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.
May I disagree? Having an alternative implementation is never a bad thing, unless the sides are unable to co-operate ;)
Let's try to compare implementations and their concepts, and benefit from both.
Quoted 5 lines
Um, I thought the powerop write up and patches already sent out addressed the goals discussed so far. We (everyone on the list) need to collaborate on the powerop effort. Isolated development and attempting to discuss two separate implementations won't get us very far.
I would like to suggest both sides to think over what the main differences of the concurring implementations are and share the thoughts with this list. That should really be helpful to work out the common solution.
Quoted 8 lines
My goal is to get PowerOP into the mainline kernel. If everyone submits a different powerop implementation for those boards, then people will see a fragmented concept that can not be generalized. The possibility of Andrew and Linus accepting PowerOP will go from high to
never. Again, I don't see any reason for two separate development
efforts and patchsets. Please stop submitting separate patches and at least attempt to collaborate on the current PowerOP patchsets under discussion.
I wouldn't say so. I would just like to see both implementations converging, but that is not to happen immediately. Anyway, this implies that both authors pay more attention to the other implementation.
Vitaly
Quoted 15 lines · Vitaly Wool
Quoted 6 lines
Yes, which is why Eugeny and I sent out the take 3 PowerOP patches. A good discussion ensued and our updated patches are a result of that discussion. If you disagree with our approach or think something is missing, give us some specific feedback. Simply sending out a separate
set of PowerOP patches is not joining in the current discussion. ItQuoted 8 lines
is
confusing and probably turning people off to the ideas. Is there
something specific missing or wrong with the patches we submitted that required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information. If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.
Quoted 4 lines
May I disagree? Having an alternative implementation is never a bad thing, unless the sides are unable to co-operate ;)
Let's try to compare implementations and their concepts, and benefit from both.
I agree that an alternative implementation is a good way to compare and contrast ideas. And Matt knows that I'm easy to work with.
The ideas I'm trying to get across are that the different power management
infrastructures can be unified in such a way as to benefit the kernel. I believe the kernel would benefit from a unified power management infrastructure and from a simplified approach to power management.
The second idea is that all operating states can be encapsulated into a simple operating point concept. And operating points are created from data supplied from the hardware vendor and validated, just as cpufreq does today.
The encapsulated operating point mechanism I'm presenting provides an architecture independent interface to the kernel's power management framework while providing the necessary architecture specific functions and data to individual platforms and individual operating points.
The powerop structure provides the architecture independent interface to the framework. The ops vectors provides the architecture, platform and operating point specific interface to individual systems. The void *md_data pointer provides a simple way to get architecture dependent data to the operating point functions.
The patch I have ready today shows how these architecture independent and dependent pieces work on an x86 centrino and on an ARM Xscale platform.
I've convinced myself that an encapsulated operating point concept can work across different architectures and even on very complex power management capable hardware.
Both platforms have frequency and voltage management capability, but the Xscale has a much more complex set of information necessary to scale frequencies.
The last idea I'm trying to present is that the simplified interface to use the operating points will benefit the user and the
power manager daemon. The user is presented a list of supported operating points and uses them by writing their name into the /sys/power/state file and the powerop framework automagically transitions to the named operating point.
The patches are available at
http://source.mvista.com:~dsingleton/
There is the original set that worked on the x86 centrino for 2.6.18-rc1 and a new set that's incorporated suggestions added the Xscale mainstone platform and been rolled to 2.6.18-rc4.
I'll send the individual patches out inlined in a bit.
David
I
Quoted 27 lines
Quoted 6 lines
Um, I thought the powerop write up and patches already sent out addressed the goals discussed so far. We (everyone on the list) need to collaborate on the powerop effort. Isolated development and attempting to discuss two separate implementations won't get us very far.
I would like to suggest both sides to think over what the main differences of the concurring implementations are and share the thoughts with this list. That should really be helpful to work out the common solution.
Quoted 8 lines
My goal is to get PowerOP into the mainline kernel. If everyone submits a different powerop implementation for those boards, then people will see a fragmented concept that can not be generalized. The possibility of Andrew and Linus accepting PowerOP will go from high to
never. Again, I don't see any reason for two separate development
efforts and patchsets. Please stop submitting separate patches and at least attempt to collaborate on the current PowerOP patchsets under discussion.I wouldn't say so. I would just like to see both implementations converging, but that is not to happen immediately. Anyway, this implies that both authors pay more attention to the other implementation.
Vitaly
Here is the patch the implements PowerOp for the Intel Xscale mainstone platform, as it exists in 2.6.18-rc4.
This patch implements sets of operating points that are instantiated on boot after the system detects the processor type and dip and rotary switch settings that affect the clock speeds.
I'm working on a patch that goes along with this patch to add the driver scaling callbacks for drivers whose driving clocks are affected by frequency changes in the system. Examples are the framebuffer and LCD, serial, pcmcia and mmc drivers.
I hope to add the PowerOp driver patch to the mainstone (pxa27x) patch in a day or so.
David
arch/arm/mach-pxa/Makefile | 3 arch/arm/mach-pxa/mainstone_freq.c | 211 +++ arch/arm/mach-pxa/mainstone_powerop.c | 1891 ++++++++++++++++++++++++++++++++++ arch/arm/mach-pxa/mainstone_volt.c | 364 ++++++ include/asm-arm/arch-pxa/powerop.h | 119 ++ include/asm-arm/arch-pxa/pxa-regs.h | 12 6 files changed, 2595 insertions(+), 5 deletions(-)
arch/arm/mach-pxa/Makefile +2 -1
@@ -10,7 +10,8 @@ obj-$(CONFIG_PXA27x) += pxa27x.o # Specific board support obj-$(CONFIG_ARCH_LUBBOCK) += lubbock.o obj-$(CONFIG_MACH_LOGICPD_PXA270) += lpd270.o -obj-$(CONFIG_MACH_MAINSTONE) += mainstone.o +obj-$(CONFIG_MACH_MAINSTONE) += mainstone.o mainstone_powerop.o \ +mainstone_freq.o mainstone_volt.o obj-$(CONFIG_ARCH_PXA_IDP) += idp.o obj-$(CONFIG_MACH_TRIZEPS4) += trizeps4.o obj-$(CONFIG_PXA_SHARP_C7xx) += corgi.o corgi_ssp.o corgi_lcd.o sharpsl_pm.o corgi_pm.o
arch/arm/mach-pxa/mainstone_freq.c new file +211 -0
211 lines not on this page · raw message
arch/arm/mach-pxa/mainstone_powerop.c new file +1891 -0
1,891 lines not on this page · raw message
arch/arm/mach-pxa/mainstone_volt.c new file +364 -0
364 lines not on this page · raw message
include/asm-arm/arch-pxa/powerop.h new file +119 -0
119 lines not on this page · raw message
include/asm-arm/arch-pxa/pxa-regs.h +8 -4
@@ -13,7 +13,6 @@#ifndef __PXA_REGS_H#define __PXA_REGS_H -/* * PXA Chip selects */
@@ -25,7 +24,6 @@#define PXA_CS4_PHYS 0x10000000#define PXA_CS5_PHYS 0x14000000 -/* * Personal Computer Memory Card International Association (PCMCIA) sockets */
@@ -64,8 +62,6 @@#define _PCMCIA1Attr _PCMCIAAttr (1)/* PCMCIA 1 Attribute */ #define _PCMCIA1Mem _PCMCIAMem (1)/* PCMCIA 1 Memory */ - -/* * DMA Controller */
@@ -2042,6 +2038,14 @@#define MDMRS __REG(0x48000040)/* MRS value to be written to SDRAM */ #define BOOT_DEF __REG(0x48000044)/* Read-Only Boot-Time Register. Contains BOOT_SEL and PKG_SEL */ +#define MDREFR_DRI 0xFFF +#define MSC0_RDF (0xF << 20) +#define MSC0_RDN (0xF << 24) +#define MSC0_RRR (0x7 << 12) +#define MDREFR_RFU 0xC0200000 +#define MDCNFG_DTC0 (0x3 << 8) +#define MDCNFG_DTC2 (0x3 << 24) +/* * More handy macros for PCMCIA *
Here's the Powerop-core patch (again). It hasn't changed much since the 2.6.18-rc1 version. It's rolled forward to 2.6.18-rc4 and incorporated suggestions. The /sys/power/supported_states file only shows the names of the supported states instead of additional, table-like, information.
David
Documentation/power/powerop.txt | 212 ++++++++++++++++++++++++++++++++++++++++ drivers/base/core.c | 5 drivers/base/driver.c | 1 drivers/base/power/Makefile | 2 drivers/base/power/powerop.c | 103 +++++++++++++++++++ drivers/base/power/resume.c | 3 drivers/base/power/suspend.c | 2 include/linux/device.h | 1 include/linux/pm.h | 56 ++++++++++ kernel/power/main.c | 189 ++++++++++++++++++++++++++++------- kernel/power/power.h | 2 11 files changed, 532 insertions(+), 44 deletions(-)
kernel/power/main.c +149 -40
@@ -49,7 +49,7 @@ void pm_set_ops(struct pm_ops * ops)* the platform can enter the requested state. */ -static int suspend_prepare (suspend_state_t state) +static int suspend_prepare (struct powerop * state) {int error =0 ;unsigned int free_pages;
@@ -82,7 +82,7 @@ static int suspend_prepare(suspend_state }if (pm_ops->prepare) { -if ((error = pm_ops->prepare (state))) +if ((error = pm_ops->prepare (state->type))) goto Thaw; }
@@ -94,7 +94,7 @@ static int suspend_prepare(suspend_statereturn 0 ; Finish:if (pm_ops->finish) - pm_ops->finish (state); + pm_ops->finish (state->type); Thaw:thaw_processes (); Enable_cpu:
@@ -104,7 +104,7 @@ static int suspend_prepare(suspend_state } -int suspend_enter (suspend_state_t state) +int suspend_enter (struct powerop * state) {int error =0 ;unsigned long flags;
@@ -115,7 +115,7 @@ int suspend_enter(suspend_state_t state)printk (KERN_ERR "Some devices failed to power down\n" ); goto Done; } - error = pm_ops->enter (state); + error = pm_ops->enter (state->type);device_power_up (); Done:local_irq_restore (flags);
@@ -131,36 +131,99 @@ int suspend_enter(suspend_state_t state)* console that we've allocated. This is not called for suspend-to-disk. */ -static void suspend_finish (suspend_state_t state) +static void suspend_finish (struct powerop * state) {device_resume ();resume_console ();thaw_processes ();enable_nonboot_cpus ();if (pm_ops && pm_ops->finish) - pm_ops->finish (state); + pm_ops->finish (state->type);pm_restore_console (); } +struct powerop *current_state; +struct powerop pm_states = { + .name ="default" , + .type =PM_SUSPEND_ON , +}; + +static struct powerop standby = { + .name ="standby" , + .description ="Power-On Suspend ACPI State: S1" , + .type =PM_SUSPEND_STANDBY , +}; +struct powerop *powerop_standby; +static struct powerop mem = { + .name ="mem" , + .description ="Suspend-to-RAM ACPI State: S3" , + .type =PM_SUSPEND_MEM , +}; +struct powerop *powerop_mem; -static const char *const pm_states[PM_SUSPEND_MAX ] = { - [PM_SUSPEND_STANDBY ] ="standby" , - [PM_SUSPEND_MEM ] ="mem" ,#ifdef CONFIG_SOFTWARE_SUSPEND - [PM_SUSPEND_DISK ] ="disk" , -#endif +struct powerop disk = { + .name ="disk" , + .description ="Suspend-to-disk ACPI State: S4" , + .type =PM_SUSPEND_DISK , }; +struct powerop *powerop_disk; +#endif -static inline int valid_state (suspend_state_t state) +/* +* +*/ +static int pm_change_state (struct powerop *state) +{ +int error = -EINVAL ; +int len =strlen (state->name); +struct powerop *this, *next; +struct list_head *head = &pm_states.list; + +/* +* list_find new operating point. +* compare to current operating point. +* if different change to new operating point. +*/ +list_for_each_entry_safe (this, next, head, list) { +if (strncmp (state->name, this->name, len) ==0 ) { +if ((strcmp (current_state->name, this->name)) ==0 ) { +return 0 ; + } + +if (this->prepare_transition (current_state, this)) { +break ; + } + +if (this->transition (current_state, this)) { +break ; + } + +/* +* now lets wait for the transition latency +*/ +udelay (this->latency); + + error = this->finish_transition (current_state, this); + +if (error ==0 ) + current_state = this; +break ; + } + } +return error; +} + +static inline int valid_state (struct powerop * state) {/* Suspend-to-disk does not really need low-level support. * It can work with reboot if needed. */ -if (state ==PM_SUSPEND_DISK ) +if (state->type ==PM_SUSPEND_DISK )return 1 ; -if (pm_ops && pm_ops->valid && !pm_ops->valid (state)) +if (pm_ops && pm_ops->valid && !pm_ops->valid (state->type))return 0 ;return 1 ; }
@@ -168,7 +231,7 @@ static inline int valid_state(suspend_st/** * enter_state - Do common work of entering low-power state. -* @state: pm_state structure for state we're entering. +* @state: powerop structure for state we're entering. * * Make sure we're the only ones trying to enter a sleep state. Fail * if someone has beat us to it, since we don't want anything weird to
@@ -177,7 +240,7 @@ static inline int valid_state(suspend_st* we've woken up). */ -static int enter_state (suspend_state_t state) +static int enter_state (struct powerop *state) {int error;
@@ -186,16 +249,21 @@ static int enter_state(suspend_state_t sif (down_trylock (&pm_sem))return -EBUSY ; -if (state ==PM_SUSPEND_DISK ) { +if (state->type ==PM_SUSPEND_DISK ) { error =pm_suspend_disk (); goto Unlock; } -pr_debug ("PM: Preparing system for %s sleep\n" , pm_states[state]); +if (state->type ==PM_FREQ_CHANGE ) { + error =pm_change_state (state); + goto Unlock; + } + +pr_debug ("PM: Preparing system for %s sleep\n" , state->name);if ((error =suspend_prepare (state))) goto Unlock; -pr_debug ("PM: Entering %s sleep\n" , pm_states[state]); +pr_debug ("PM: Entering %s sleep\n" , state->name); error =suspend_enter (state);pr_debug ("PM: Finishing wakeup.\n" );
@@ -211,7 +279,15 @@ static int enter_state(suspend_state_t s*/ int software_suspend (void ) { -return enter_state (PM_SUSPEND_DISK ); +struct powerop *this, *next; +struct list_head *head = &pm_states.list; +int error =0 ; + +list_for_each_entry_safe (this, next, head, list) { +if (this->type ==PM_SUSPEND_DISK ) + error=enter_state (this); + } +return error; }
@@ -223,16 +299,44 @@ int software_suspend(void)* structure, and enter (above). */ -int pm_suspend (suspend_state_t state) +int pm_suspend (struct powerop * state) { -if (state >PM_SUSPEND_ON && state <=PM_SUSPEND_MAX ) +if (state->type >PM_SUSPEND_ON && state->type <=PM_SUSPEND_MAX )return enter_state (state);return -EINVAL ; } +decl_subsys (power,NULL ,NULL ); +/** +* supported_states - control system power state. +* +* show() returns what states are supported, which are no longer +* hard-coded to just 'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), +* and *'disk' (Suspend-to-Disk), but show all the power states. +* +* store() unwritable +*/ -decl_subsys (power,NULL ,NULL ); +static ssize_t supported_states_show (struct subsystem * subsys,char * buf) +{ +struct powerop *this, *next; +struct list_head *head = &pm_states.list; +char * s = buf; + +list_for_each_entry_safe (this, next, head, list) { + s +=sprintf (s,"%s\n" , this->name); + } + +return (s - buf); +} + +static ssize_t supported_states_store (struct subsystem * subsys,const char *buf,size_t n) +{ +return -EINVAL ; +} + +power_attr (supported_states);/**
@@ -248,36 +352,28 @@ decl_subsys(power,NULL,NULL);static ssize_t state_show (struct subsystem * subsys,char * buf) { -int i;char * s = buf; -for (i =0 ; i <PM_SUSPEND_MAX ; i++) { -if (pm_states[i] &&valid_state (i)) - s +=sprintf (s,"%s " , pm_states[i]); - } - s +=sprintf (s,"\n" ); + s +=sprintf (s,"%s\n" , current_state->name);return (s - buf); }static ssize_t state_store (struct subsystem * subsys,const char * buf,size_t n) { -suspend_state_t state =PM_SUSPEND_STANDBY ; -const char *const *s; +struct powerop *this, *next; +struct list_head *head = &pm_states.list;char *p; -int error; +int error = -EINVAL ;int len; p =memchr (buf,'\n' , n); len = p ? p - buf : n; - -for (s = &pm_states[state]; state <PM_SUSPEND_MAX ; s++, state++) { -if (*s && !strncmp (buf, *s, len)) +list_for_each_entry_safe (this, next, head, list) { +if (!strncmp (buf, this->name, len)) { + error =enter_state (this);break ; + } } -if (state <PM_SUSPEND_MAX && *s) - error =enter_state (state); -else - error = -EINVAL ;return error ? error : n; }
@@ -285,6 +381,7 @@ power_attr(state);static struct attribute * g[] = { &state_attr.attr, + &supported_states_attr.attr,NULL , };
@@ -295,9 +392,21 @@ static struct attribute_group attr_groupstatic int __init pm_init (void ) { +int error =subsystem_register (&power_subsys);if (!error) error =sysfs_create_group (&power_subsys.kset.kobj,&attr_group); + +INIT_LIST_HEAD (&pm_states.list); + +#ifdef CONFIG_SOFTWARE_SUSPEND +list_add (&disk.list, &pm_states.list); + powerop_disk = &disk; +#endif +list_add (&mem.list, &pm_states.list); +list_add (&standby.list, &pm_states.list); + current_state = &pm_states; +return error; }
include/linux/pm.h +54 -2
68 lines not on this page · raw message
kernel/power/power.h +1 -1
@@ -113,4 +113,4 @@ extern int swsusp_resume(void);extern int swsusp_read (void );extern int swsusp_write (void );extern void swsusp_close (void ); -extern int suspend_enter (suspend_state_t state); +extern int suspend_enter (struct powerop * state);
Documentation/power/powerop.txt new file +212 -0
212 lines not on this page · raw message
drivers/base/core.c +5 -0
@@ -15,6 +15,7 @@#include <linux/slab.h> #include <linux/string.h> #include <linux/kdev_t.h> +#include <linux/pm.h> #include <asm/semaphore.h>
@@ -362,6 +363,8 @@ int device_add(struct device *dev)up (&dev->class->sem); } +assert_constraints (dev->constraints); +/* notify platform of device entry */ if (platform_notify)platform_notify (dev);
@@ -467,6 +470,8 @@ void device_del(struct device * dev) }device_remove_file (dev, &dev->uevent_attr); +deassert_constraints (dev->constraints); +/* Notify the platform of the removal, in case they * need to do anything... */
drivers/base/driver.c +1 -0
@@ -12,6 +12,7 @@#include <linux/module.h> #include <linux/errno.h> #include <linux/string.h> +#include <linux/pm.h> #include "base.h" #define to_dev (node) container_of(node, struct device, driver_list)
drivers/base/power/resume.c +3 -0
@@ -10,6 +10,7 @@#include <linux/device.h> #include <linux/resume-trace.h> +#include <linux/pm.h> #include "../base.h" #include "power.h"
@@ -37,6 +38,8 @@ int resume_device(struct device * dev)if (dev->bus && dev->bus->resume) {dev_dbg (dev,"resuming\n" ); error = dev->bus->resume (dev); +if (!error) +assert_constraints (dev->constraints); }up (&dev->sem);TRACE_RESUME (error);
drivers/base/power/suspend.c +2 -0
@@ -75,6 +75,8 @@ int suspend_device(struct device * dev, ); error = dev->bus->suspend (dev, state);suspend_report_result (dev->bus->suspend, error); +if (!error) +deassert_constraints (dev->constraints); }up (&dev->sem);return error;
include/linux/device.h +1 -0
@@ -333,6 +333,7 @@ struct device {struct dma_coherent_mem *dma_mem;/* internal for coherent mem override */ +struct constraints *constraints;/* class_device migration path */ struct list_head node;
drivers/base/power/powerop.c new file +103 -0
103 lines not on this page · raw message
drivers/base/power/Makefile +1 -1
@@ -1,4 +1,4 @@ -obj-y := shutdown.o +obj-y := shutdown.o powerop.o obj-$(CONFIG_PM) += main.o suspend.o resume.o runtime.o sysfs.o obj-$(CONFIG_PM_TRACE) += trace.o
Here's the powerop-cpufreq.patch. It hasn't changed from the 2.6.18-rc1 version (I think).
David
drivers/cpufreq/cpufreq.c | 40 ++++++++++++++++++++++++++++++++++++++-- include/linux/cpufreq.h | 2 ++ 2 files changed, 40 insertions(+), 2 deletions(-)
drivers/cpufreq/cpufreq.c +38 -2
@@ -213,19 +213,48 @@ static void adjust_jiffies(unsigned longif (!l_p_j_ref_freq) { l_p_j_ref = loops_per_jiffy; l_p_j_ref_freq = ci->old; -dprintk ("saving %lu as reference value for loops_per_jiffy; freq is %u kHz\n" , l_p_j_ref, l_p_j_ref_freq); +printk ("saving %lu as reference value for loops_per_jiffy; freq is %u kHz\n" , l_p_j_ref, l_p_j_ref_freq); }if ((val ==CPUFREQ_PRECHANGE && ci->old < ci->new) || (val ==CPUFREQ_POSTCHANGE && ci->old > ci->new) || (val ==CPUFREQ_RESUMECHANGE || val ==CPUFREQ_SUSPENDCHANGE )) { loops_per_jiffy =cpufreq_scale (l_p_j_ref, l_p_j_ref_freq, ci->new); -dprintk ("scaling loops_per_jiffy to %lu for frequency %u kHz\n" , loops_per_jiffy, ci->new); +printk ("scaling loops_per_jiffy to %lu for frequency %u kHz\n" , loops_per_jiffy, ci->new); } }#else static inline void adjust_jiffies (unsigned long val,struct cpufreq_freqs *ci) {return ; }#endif +int cpufreq_prepare_transition (struct powerop *cur,struct powerop *new) +{ +struct cpufreq_freqs freqs; + + freqs.old = cur->frequency; + freqs.new = new->frequency; + freqs.cpu =0 ; + freqs.flags = cpufreq_driver->flags; +blocking_notifier_call_chain (&cpufreq_transition_notifier_list, +CPUFREQ_PRECHANGE , &freqs); +adjust_jiffies (CPUFREQ_PRECHANGE , &freqs); +return 0 ; +} +EXPORT_SYMBOL (cpufreq_prepare_transition); + +int cpufreq_finish_transition (struct powerop *cur,struct powerop *new) +{ +struct cpufreq_freqs freqs; + + freqs.old = cur->frequency; + freqs.new = new->frequency; + freqs.cpu =0 ; + freqs.flags = cpufreq_driver->flags; +adjust_jiffies (CPUFREQ_POSTCHANGE , &freqs); +blocking_notifier_call_chain (&cpufreq_transition_notifier_list, +CPUFREQ_POSTCHANGE , &freqs); +return 0 ; +} +EXPORT_SYMBOL (cpufreq_finish_transition);/** * cpufreq_notify_transition - call notifier chain and adjust_jiffies
@@ -920,6 +949,12 @@ static void cpufreq_out_of_sync(unsigned } +#ifdef CONFIG_PM +unsigned int cpufreq_quick_get (unsigned int cpu) +{ +return (current_state->frequency *1000 ); +} +#else /** * cpufreq_quick_get - get the CPU frequency (in kHz) frpm policy->cur * @cpu: CPU number
@@ -941,6 +976,7 @@ unsigned int cpufreq_quick_get(unsigned return (ret); } +#endif EXPORT_SYMBOL (cpufreq_quick_get);
include/linux/cpufreq.h +2 -0
@@ -268,6 +268,8 @@ static inline unsigned int cpufreq_quick return 0; }#endif +int cpufreq_prepare_transition (struct powerop *cur,struct powerop *new); +int cpufreq_finish_transition (struct powerop *cur,struct powerop *new);/*********************************************************************
Here's the powerop-x86-centrino.patch. It's only change from the 2.6.18-rc1 version
is to change names of operating points from med to medium, etc.
David
arch/i386/kernel/cpu/Makefile | 1 arch/i386/kernel/cpu/powerop/Makefile | 2 arch/i386/kernel/cpu/powerop/centrino-dynamic-powerop.c | 71 ++ arch/i386/kernel/cpu/powerop/centrino-powerop.c | 465 ++++++++++++++++ arch/i386/kernel/i386_ksyms.c | 4 5 files changed, 543 insertions(+)
arch/i386/kernel/cpu/Makefile +1 -0
@@ -17,3 +17,4 @@ obj-$(CONFIG_X86_MCE) += mcheck/ obj-$(CONFIG_MTRR) += mtrr/ obj-$(CONFIG_CPU_FREQ) += cpufreq/ +obj-$(CONFIG_PM) += powerop/
arch/i386/kernel/cpu/powerop/Makefile new file +2 -0
@@ -0,0 +1,2 @@ +obj-$(CONFIG_X86_SPEEDSTEP_CENTRINO) += centrino-powerop.o +obj-m += centrino-dynamic-powerop.o
arch/i386/kernel/cpu/powerop/centrino-dynamic-powerop.c new file +71 -0
71 lines not on this page · raw message
arch/i386/kernel/cpu/powerop/centrino-powerop.c new file +465 -0
465 lines not on this page · raw message
arch/i386/kernel/i386_ksyms.c +4 -0
@@ -28,3 +28,7 @@ EXPORT_SYMBOL(__read_lock_failed);#endif EXPORT_SYMBOL (csum_partial); +#ifdef CONFIG_PM +#include <linux/pm.h> +EXPORT_SYMBOL (pm_states); +#endif
Quoted 4 lines · Vitaly Wool
May I disagree? Having an alternative implementation is never a bad thing, unless the sides are unable to co-operate ;)
Let's try to compare implementations and their concepts, and benefit from both.
What are you disagreeing with? Re-read my statement below. I don't
see the reason for another implementation. Rather than guess, I would prefer that Dave tell us why he is submitting a different powerop interface. There must be something driving him to do so.
Quoted 8 lines
Quoted 8 lines
Is there
something specific missing or wrong with the patches we submitted that required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information. If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.
Matt
I'd say that David's recent note provides some useful information about why his implementation is different. I don't mind seeing an alternate implementation if there's a reason for it, but I have to say that it would have been nice to have the exegesis with or before the patches.
scott
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Locke
Sent: Saturday, August 12, 2006 6:15 PM
To: Vitaly Wool
Cc: [email protected]; david singleton
Subject: Re: [linux-pm] Dynanic On-The-Fly Operating points for PowerOP
Quoted 3 lines · Vitaly Wool
May I disagree? Having an alternative implementation is never a bad thing, unless the sides are unable to co-operate ;) Let's try to compare implementations and their concepts, and benefit from both.
What are you disagreeing with? Re-read my statement below. I don't
see the reason for another implementation. Rather than guess, I would prefer that Dave tell us why he is submitting a different powerop interface. There must be something driving him to do so.
Quoted 9 lines
Quoted 9 lines
Is there
something specific missing or wrong with the patches we submitted that required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information.If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.
Matt
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.osdl.org/mailman/listinfo/linux-pm
Quoted 11 lines · Matthew Locke
Quoted 4 lines · Vitaly Wool
May I disagree? Having an alternative implementation is never a bad thing, unless the sides are unable to co-operate ;)
Let's try to compare implementations and their concepts, and benefit from both.What are you disagreeing with? Re-read my statement below. I don't
see the reason for another implementation. Rather than guess, I would prefer that Dave tell us why he is submitting a different powerop interface. There must be something driving him to do so.
Okay, let me see if I can clarify a bit. I presented the alternative implementation to compare and contrast ideas, and because I believe this implementation is a better solution for the following reasons:
I believe this interface between the kernel and user space is cleaner. The
system presents the list of supported operating points to the user and the
user invokes them by their name.
/sys/power/state is used for setting and displaying the current operating point
and /sys/power/supported_states presents the names of the supported operating
points to the user. That's the entire user interface.
I believe the moving of policies, classes and governors out of the kernel
and into user space is a better solution. The user, or power manager daemon,
should make the decisions about when and what operating point to set, and
which devices to suspend or resume.
The user does not pass in information needed to construct an operating point
and let the kernel try and validate the data and protect against incorrect
or malicious data that would hang the system. Operating points are constructed
from the hardware vendor supplied data sheets and validated, just like cpufreqs,
and tested before the code is integrated into the mainstream.
I believe the architecture independent interface between the kernel and powerop framework is better and I believe the architecture dependent/board
specific interface is better because:
The entire design revolves around operating points and operating points can be encapsulated into two data structures and three functions. The powerop
structure contains the architecture independent data and function pointers
to the platform dependent routines to transition to the operating point. The md_data pointer in the powerop structure points to any kind of platform
specific data needed by the transition routines.
The platform dependent interface not only lets each platform have its own
information and functions for operating state transition, but it also lets
individual operating points on the same platform have operating point specific data and functions.
By encapsulating an operating point into two data structures new operating
points can easily be constructed.
Lets consider for a moment the case where Intel creates a new revision of the
pxa27x processor for the mainstone. To implement support for the new processor
one would only have to create a set of powerop structures and md_opt structures
that contain the information for the new processor's operating points.
The next step would be to insert the new processor identification into the case statement where the system deteremines the processor id and the new operating points would be linked into the system you'd be done implementing a new set of operating points for a new processor.
This would take a matter of hours to create and test new operating points
instead of days or weeks. And with the dynamic on-the-fly loadable module
for an operating points creation and testing of new processors would take a very short time, something the SoC manufacturers might like.
And by doing the mainstone patch wthout having to change any of the framework
or interfaces I've convinced myself that the concept, framework and interfaces
will work across different architectures and platforms.
Its simple but enormously flexible.
David
Quoted 13 lines
Quoted 10 lines
Quoted 10 lines
Is there
something specific missing or wrong with the patches we submitted that
required another set of patches to be developed? By joining in the discussion, I mean that you should let us know this information. If patches are your method for doing so, then at least provide a description of what your patches address that ours does not. Right now, its just unclear why there are two different powerop patchsets.Matt
Hi!
Quoted 16 lines
2) The naming scheme for operating points has been unified to provide a better interface to the PowerOp power manager daemon. The names range from:
highest
high
medhigh
medium
medlow
low
lowestPowerOp maps the supported processor frequencies onto this namespace list. The set of centrino processors it supports have supported sets of between four and six different operating points.
Quoted 6 lines
The PowerOP daemon, coming soon, can simply read the supported set of operating points and make some simple rules based decisions about when to transition to various operating points.
The goal of a unified name space is to provide a PowerOp manager that runs out of the box, with very little setup by the user.
Well, we already have perfectly working API for frequency management, why not use that?
Signature · 1 line
Thanks for all the (sleeping) penguins.
Quoted 1 line · david singleton
Here's the powerop-x86-centrino.patch.
Please do not propagate the hard coded tables and control word formats from speedstep-centrino.c. The ACPI tables are preferred, and the hard-coded tables and control word formats in speedstep-centrino are known to be inaccurate and unsupported.
Also, there needs to be a mechanism where the tables can change at run-time.
-Len