Cross-Layer Frameworks for Constrained Power and Resources Management of Embedded Systems
-
Upload
patrick-bellasi -
Category
Technology
-
view
682 -
download
0
description
Transcript of Cross-Layer Frameworks for Constrained Power and Resources Management of Embedded Systems
Cross-Layer Frameworks forConstrained Power and Resources Management
of Embedded Systems
Final PhD Dissertation of:
Patrick Bellasi
Politecnico di Milano
Dipartimento di Elettronica e Informazione
Advisor:Prof. William Fornaciari
Industrial tutor (STMicroelectronics):
Ing. David Siorpaes
March, 3 - 2010
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Motivation Proposal Results Conclusions
Focusing the topic of this research
What is Resources and Power Management?
• Focus on modern MPSoC architectures◦ implicit architectural inter-dependencies◦ resource sharing and competition
• many resources impact on performancese.g., clocks, memories, communication channels
• energy is the most precious resource
Find the optimal trade-off between power
consumption and perceived performance
• hardware support is not enough◦ simple software support is required
• consider upcoming many-core architectures
HWBlock
HWBlock
HWBlock
HWBlock
HW
Block
HW
Block
HW
Block
HWBlock
Peripherials’ Interfaces and Memory
Application Oriented Cores
Specialized Hardware
Multi−core Host Processor(CortexA9)
Core#1
Core#2
Core#3
Core#4
General Purpose
Core Host
Asymmetric Processing
Peripherials’ Interfaces and Memory
Symmetric Computation Fabric
High Density
Programmable Fabric
Core#1
Core#2
Core#3
Core#4
Multi−core Host Processor(CortexA9)General Purpose
Core Host
Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model
“configuration space explosion”
distributed control: multiple local policies
“risk of conflicting decisions”
Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model
“configuration space explosion”
The change on a single sub-system
requires a complete policy redesign
distributed control: multiple local policies
“risk of conflicting decisions”
Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model
“configuration space explosion”
The change on a single sub-system
requires a complete policy redesign
Cannot handle the complexity of new
generation platforms
distributed control: multiple local policies
“risk of conflicting decisions”
Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model
“configuration space explosion”
The change on a single sub-system
requires a complete policy redesign
Cannot handle the complexity of new
generation platforms
distributed control: multiple local policies
“risk of conflicting decisions”
The composition of independent
optimization policies cannot grant a
system-wide optimization
Motivation Proposal Results Conclusions
Previous Approaches to Power Management
Centralized vs Distributed Control Models
centralized control: complex global model
“configuration space explosion”
The change on a single sub-system
requires a complete policy redesign
Cannot handle the complexity of new
generation platforms
distributed control: multiple local policies
“risk of conflicting decisions”
The composition of independent
optimization policies cannot grant a
system-wide optimization
Cannot achieve system-wide optimization
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
FSC
LayerModel
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
QoS
RequirementsGlobal Optimization
policies
OptimizationLayer
FSC
LayerModel
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
Operating System
TasksResourceManager
QoS
RequirementsGlobal Optimization
policies
OptimizationLayer
FSC
LayerModel
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
System−Wide
Constraints
Operating System
TasksResourceManager
QoS
RequirementsGlobal Optimization
policies
OptimizationLayer
FSC
LayerModel
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Motivation Proposal Results Conclusions
CPM in a Nutshell
Abstract from Reality, Model the Abstraction
• Constraint local policies
• Model optimization◦ global multi-objective optimization
strategy◦ considering QoS requirements
• Modeling Abstraction◦ identification of system-wide
feasible configurations (FSCs)
• Abstracting reality◦ portability and fine-details◦ represent resources (PSM/ASM)
and working modes (DWR)
• Devices local control
System−Wide
Constraints
Operating System
TasksResourceManager
QoS
RequirementsGlobal Optimization
policies
OptimizationLayer
FSC
LayerModel
ASM
PSM
LayerAbstraction
DWR
HW Platform
Local Optimization
policies
Silicon and Architectural
mechanisms
Devices
DriversPlatform Code
Hierarchical Distributed Control
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer C12C11
C21
C23
C22
C32
C33
C31
m1
m2
FSC2
FSC1
FSC3
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hull
FSC2
FSC1
FSC3
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Motivation Proposal Results Conclusions
The optimization approach
A Formal Optimization Model
• The global optimization rely on Linear Programming (LP)◦ well known mathematical multi-objective optimization framework
• Optimization Space (mi )◦ Resources availability◦ Abstraction layer (SWM)
• Constraints (vi )◦ QoS requirements◦ Model layer (DWR ⇒ FSC)
• Objective Function (−→og )◦ Optimization layer C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
• to identify a solution-equivalent and efficient optimization strategy◦ guide the design of an efficient implementation◦ exploit problem specificities
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
The optimization approach
A Concrete Optimization Framework
• Translate the formal (LP based) model into an efficientimplementation
• Exploit three different time domains◦ platform description => FSC Identification (FI) System boot
i.e., devices probing and framework subscription (DWR)
◦ optimization goals update => FSC Ordering (FO) Policy updatei.e., use-case or operating conditions change
◦ constraint assertion => FSC Selection (FS) QoS requirementi.e., application functionality change
• Support complexity partitioning◦ high-overhead operations are executed less frequently
• Modular design◦ split operations between different modules◦ better support optimization of each operation
• off-line computation (FI)• HW acceleration, e.g. look-up based implementation (FO, FS)
Motivation Proposal Results Conclusions
Overheads Analysis (Worst-Case)
Overheads analysis
Low run-time overhead is the key for actual use
• FSC Identification◦ Upper-bound O(DWRD)
~300 FSC
~10ms => +1% overhead
Optimal Boot-Time requirements
• could be “constant”◦ off-line identification
• ACET ≪ WCET
• FSC Selection◦ Lower-bound O(FI )
• undefined relative overhead◦ f(user-space)
• could be HW accelerated
Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation◦ Using a Nomadik board based on the STn8815 SoC◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload◦ Two concurrent application: Youtube streamer and Torrent client◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation◦ Using a Nomadik board based on the STn8815 SoC◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload◦ Two concurrent application: Youtube streamer and Torrent client◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
Motivation Proposal Results Conclusions
Correctness Assessment
Definition of a Real Use-Case
• Real implementation◦ Using a Nomadik board based on the STn8815 SoC◦ Integrating drivers and Linux platform code
• Considering network and multimedia workload◦ Two concurrent application: Youtube streamer and Torrent client◦ 5 SWM:
• ASM: acodec, vcodec, band
• PSM: cpu clk, dsp clk
◦ 5 devices (with different working modes each one):
• modem(5), vcodec(4), acodec(4), cpu(7), platform(7)
• Straightway drivers integration
• 415 automatically identified FSC (≃70ms)◦ ≈10% out of 3920 of worst case analysis
• Properly tracking of functional dependencies (CPU vs DSP clock)
Motivation Proposal Results Conclusions
Dissemination
Achievements and Dissemination
• Main conference publications◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “Constrained Power Management:
Application to a Multimedia Mobile Platform”. DATE - Dresden, 03/2010.◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “A Hierarchical Distributed Control for
Power and Performances Optimization of Embedded Systems”. ARCS -Hannover, 02/2010. (Runner-up for Best Paper Award)
◦ P. Bellasi, S. Bosisio, M. Carnevali, W. Fornaciari, D. Siorpaes, “Cross-LayerConstrained Power Management: Application to Multimedia Mobile Platforms”.LASCAS - Iguacu Falls, 02/2010.
◦ P. Bellasi, W. Fornaciari, D. Siorpaes, “Predictive Models for MultimediaApplications Power Consumption Based on Use-Case and OS Level Analysis”.DATE - Nice, 04/2009
• US patent pending (by STMicroelectronics)◦ “Power Management Using Constraints in Multi-Dimensional Parameter Space”
• Book Chapter◦ Run-time Resource Management at the Operating System level in
“Multi-objective design space exploration of multiprocessor SoC architectures: theMULTICUBE approach”, edited by Springer. (to be published)
• Collaboration on EU sponsored projects◦ Dynamic Power and Resource Management
2PARMA - 7FP (STREP) and COMPLEX - 7FP (IP)
Motivation Proposal Results Conclusions
Conclusions and Future Work
Lesson Learned
Hierarchical Power and Resource Management is foreseen as a validapproach to keep in pace with complexity of upcoming architectures
• Distributed approach for performances vs power trade-off control◦ automatic identification of feasible configurations◦ supports the constraint based power management model◦ scalable on upcoming more and more complex architectures◦ provides multi-objective optimizations◦ layered design to improved code reuse◦ exploits platform and devices fine-details
Motivation Proposal Results Conclusions
Conclusions and Future Work
Outlook
• The implementation is going to be released in ML for RFC◦ Push the constrained PM concept to the Linux community
• P.Bellasi, D. Siorpaes “Constrained Power Management”.ELC-E - Grenoble, 10/2009.
• L. De Marchi, P. Bellasi, W.Betz, “Multi-core Scheduling Optimizations forSoft Real-time Multi-threaded Applications – A Cooperation AwareApproach”. ELC - San Francisco, 04/2010.
• Improve the user-space interface◦ OS-level automatic application behaviors extraction◦ automate QoS requirement assertion (work in progress)
• Integrate more interesting real-world applicationse.g., Scalable Video Coding, Cognitive Radio, Multi-View Image Processing
• Integration with other resource manager
e.g., memory access, and tasks scheduling
• Investigate on HW acceleration opportunity
Thanks for your attention!
I am not to blame for putting forward, in the course of
my work on science, any general rule derived from a
previous conclusion.
Leonardo Da Vinci
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Application proac-tive
Being able to collect applications requirements to bet-ter support their processing expectations and to givefeed-back on effective resources availability.
3 7
Approach CPM in a Nutshell Implementation
Requirements
Main Goals for Effective Resources and Power Management
Goal Motivation Centralized Distributed
Scalability
Smoothly apply to more and more complex architec-tures such as the up-coming many-core based systems,without impacting too much on design and run-timecomplexity.
7 3
PortabilitySmoothly adapt to local changes on devices of the sys-tem without requiring a complete redesign of the con-trol solution.
7 3
Fine-detailsExploit all the low-level knowledge about each devicein order to improve the fine tuning capabilities of thecontrol policy.
3 7
System-wide
Exploit the global view on: system resources availabil-ity, power-vs-performances trade-off of each device andall the applications requirements in order to achieve asystem-wide optimal configuration.
3 7
Time adaptabilityTune the control policy to changing usage scenarios inorder to better track user expected performance.
7 3
Application proac-tive
Being able to collect applications requirements to bet-ter support their processing expectations and to givefeed-back on effective resources availability.
3 7
Linux Support
Provide a complete support at least for the Linux op-erating system by means of a well designed frameworkthat should be accepted by the community for mergingin mainline kernel
DPM QoSPM
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
Fundamental approach:
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
identification
FSC
Fundamental approach:
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
FSC
orderingidentification
FSC
Fundamental approach:
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
selection
FSCFSC
orderingidentification
FSC
Fundamental approach:
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
The proposed approach
Our Fundamental Approach
and conquere
divide
selection
FSCFSC
orderingidentification
FSC
Fundamental approach:
Applications assert
QoS requirements
control
Hierarchical
optimization policy
System−Wide
In−Kernel
framework
Drivers
define working modes
and
available resources
Decisions:
Requirements:
System−Wide Fine−Details Dynamic Low−Overhead Scalable
Context:
applications
of multi−threaded
increase due to advent
System’s complexity Major opportunity
of optimizations
are related to
HW capabilities use−case
frequently changing
devices with
Multifunction Control cannot
impact on
system
performances architectures
evolving
to different
Easily adapt
• Motivations
• Approach
• Implementation
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Hierarchical
Power
Manager
5 5
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
Approach CPM in a Nutshell Implementation
An Overview of the proposed solution
Constrained Power Management
1. Drivers’ local policies◦ targeted to power reduction◦ fine-details, low-overhead
2. Coordination entity◦ exploit system-wide view◦ track resource availability and
devices interdependencies
3. User-space interface◦ collects QoS requirements◦ feedback on resource availability
4. Global optimization policy◦ multi-objective, low frequency
5. Constraint assertion◦ QoS requirements◦ set constraint on local policies
Hierarchical
Power
Manager
5 5
Execution
Context
QoS Requirements 3
Applications
Libraries Buses
global
policy4
Framework
2
Device
Local
Control
Platform Code
Driver
local
policy
1
Device
Driver
Device
local
policy
1
The global policy is used to
fine-tune the local ones
Approach CPM in a Nutshell Implementation
The Abstraction Layer
System-Wide Metric (SWM)
A parameter describing the behaviors of a running system and usedto track resources availability
• QoS requirements are expressed as validity ranges on SWMmainly upper/lower bounds
• Different abstraction levels◦ Abstract System-wide Metric (ASM), platform independent
exposed to user-lande.g. ambient light/noise, power source, specific application requirements
◦ Platform System-wide Metric (PSM), platform dependentprivate to platform code and platform driverse.g. bus bandwidth, devices’ latency
• Allow to track QoS inter-dependencies◦ platform code and drivers can translate ASM’s requirements into
PSM’s constraints
Code Example
Approach CPM in a Nutshell Implementation
The Abstraction Layer
Device Working Region (DWR)
The mapping of a deviceoperating mode on SWMs’ ranges
• A device could have differentworking modes◦ different QoS => different
SWM range
• Defined by the device driver
• Support tracking of devicesfunctional dependencies
µ21
µ24
µ25
µ26
µ23
µ22
µ12µ11 µ13 µ14
C32
C33
C31
m1
m2
A device with 3 DWR (cdm) mapping 2 SWM (mi )
Code Example
Approach CPM in a Nutshell Implementation
The Modelling Layer
Feasible System-wide Configurations (FSC)
The intersection of at least aDWR for each device
• identify all and only the feasiblesystem’s working modes◦ all devices can support the
required QoS level◦ no functional conflicts
• all the possible solutions for thePM optimization problem◦ abstract model for system-wide
optimizations
C12C11
C22
C21
C23
C32
C33
C31
m1
m2
FSC 3
FSC 2
FSC 1
The 3 FSCs existing on this system
Approach CPM in a Nutshell Implementation
The Optimization Layer
Linear Programming (LP) Formulation
• The PM optimization problem can be formulated as an LP problem
• LP elements:◦ solution space – SWMs Domain◦ objective function – vector representing QoS optimization directions◦ constraints – QoS requirements
• dynamically reduce the number of valid FSCs
◦ convex hall – the smallest convex polygon including all valid FSCs◦ valid solution – every point inside the convex hall◦ optimal solutions – vertexes or edges of the convex hall
• can always be mapped to 1 or 2 FSCs
Go to Motivations
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
m1
m2
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
m1
m2
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hull
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
The Optimization Layer
Putting it All Together
1. DWRs registration
2. FSC identification
3. Constraint aggregation
4. FSC validation
5. FSC selection◦ optimization policy −→og
• Different time domains◦ boot-time: steps 1-2◦ run-time: steps 3-5
• step 5 can be simplifiedby FSC pre-ordering◦ policy defined
e.g. FSC3, FSC1, FSC2
C12C11
C21
C23
C22
C32
C33
C31
µ1M
µ2M
µ1c
v1
v2
v3
m1
m2
Convex−Hullog
o2
o1
O
O’
FSC2
FSC1
FSC3
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API
• platform code◦ PSM definition
• device drivers◦ DWR definition◦ constraints auth.
• governor◦ FSC identification
• policy◦ FSC ordering◦ constraints auth.
cpm_core
cpm_sysfs
cpm_policy
cpm_governor
platform_code
cpm_data
4 update
2 register
7 monitor
1 register 3 subscribe
driver
5 update_request
6 notify
Device Drivers
export framework
data
require framework
integration
provide framework
implementation
indirect calldirect callfunctional dependency
Legend
Platform Code
CPM Framework
CPM Policies
Main framework components and their relationship
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API
• platform code◦ PSM definition
• device drivers◦ DWR definition◦ constraints auth.
• governor◦ FSC identification
• policy◦ FSC ordering◦ constraints auth.
cpm_core
cpm_sysfs
cpm_policy
cpm_governor
platform_code
cpm_data
4 update
2 register
7 monitor
1 register 3 subscribe
driver
5 update_request
6 notify
Device Drivers
export framework
data
require framework
integration
provide framework
implementation
indirect calldirect callfunctional dependency
Legend
Platform Code
CPM Framework
CPM Policies
Main framework components and their relationship
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API
• platform code◦ PSM definition
• device drivers◦ DWR definition◦ constraints auth.
• governor◦ FSC identification
• policy◦ FSC ordering◦ constraints auth.
cpm_core
cpm_sysfs
cpm_policy
cpm_governor
platform_code
cpm_data
4 update
2 register
7 monitor
1 register 3 subscribe
driver
5 update_request
6 notify
Device Drivers
export framework
data
require framework
integration
provide framework
implementation
indirect calldirect callfunctional dependency
Legend
Platform Code
CPM Framework
CPM Policies
Main framework components and their relationship
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API
• platform code◦ PSM definition
• device drivers◦ DWR definition◦ constraints auth.
• governor◦ FSC identification
• policy◦ FSC ordering◦ constraints auth.
cpm_core
cpm_sysfs
cpm_policy
cpm_governor
platform_code
cpm_data
4 update
2 register
7 monitor
1 register 3 subscribe
driver
5 update_request
6 notify
Device Drivers
export framework
data
require framework
integration
provide framework
implementation
indirect calldirect callfunctional dependency
Legend
Platform Code
CPM Framework
CPM Policies
Main framework components and their relationship
Approach CPM in a Nutshell Implementation
Design
Framework Design
• framework core◦ data types, ASM◦ glue code◦ user-space API
• platform code◦ PSM definition
• device drivers◦ DWR definition◦ constraints auth.
• governor◦ FSC identification
• policy◦ FSC ordering◦ constraints auth.
cpm_core
cpm_sysfs
cpm_policy
cpm_governor
platform_code
cpm_data
4 update
2 register
7 monitor
1 register 3 subscribe
driver
5 update_request
6 notify
Device Drivers
export framework
data
require framework
integration
provide framework
implementation
indirect calldirect callfunctional dependency
Legend
Platform Code
CPM Framework
CPM Policies
Main framework components and their relationship
Approach CPM in a Nutshell Implementation
Design
Implementation Summary
$ git diff 4be3bd78.. --stat
Documentation/cpm/00-INDEX.txt | 61 +
Documentation/cpm/core.txt | 264 +++
Documentation/cpm/governors.txt | 146 ++
Documentation/cpm/overview.txt | 131 ++
Documentation/cpm/platform.txt | 123 ++
Documentation/cpm/policies.txt | 131 ++
Documentation/cpm/testing.txt | 67 +
Documentation/cpm/user-guide.txt | 139 ++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/cpm/Kconfig | 112 ++
drivers/cpm/Makefile | 10 +
drivers/cpm/cpm_core.c | 3402 +++++++++++++++++++++++++++++++++
drivers/cpm/cpm_governor_exhaustive.c | 420 ++++
drivers/cpm/cpm_policy_dummy.c | 122 ++
drivers/cpm/cpm_policy_performance.c | 199 ++
drivers/cpm/test/Kconfig | 38 +
drivers/cpm/test/Makefile | 7 +
drivers/cpm/test/cpm_test_bandwidth.c | 218 +++
drivers/cpm/test/cpm_test_dummy.c | 459 +++++
drivers/cpm/test/cpm_test_mp3gsm.c | 316 +++
include/linux/cpm.h | 491 +++++
22 files changed, 6859 insertions(+), 0 deletions(-)
Approach CPM in a Nutshell Implementation
Usage examples
Example - System-Wide Metrics Definitions
// SWM Identifiers definitions
#define SWM_AMBA_BANDWIDTH CPM_ASM_TOT+0
#define SWM_ADSP_CLK CPM_ASM_TOT+1
// Platform specific SWM (PSM) definition
struct cpm_swm cpm_platform_psm[] = {
CPM_PLATFORM_SWM("AMBA_BANDWIDTH", CPM_TYPE_GIB, CPM_USER_RW,
CPM_COMPOSITION_ADDITIVE, 0, 8000),
CPM_PLATFORM_SWM("ADSP_CLK", CPM_TYPE_GIB, CPM_USER_RO,
CPM_COMPOSITION_ADDITIVE, 0, 266),
};
// PSM Registration
struct cpm_platform_data cpm_platform_data = {
.swms = cpm_platform_psm,
.count = ARRAY_SIZE(cpm_platform_psm),
};
cpm_register_platform_psms(&cpm_platform_data);
Go to Definition
Approach CPM in a Nutshell Implementation
Usage examples
Example - Device Working Region
struct cpm_swm_range vdsp_dwr0_ranges[] = { /* V-DSP MPEG4 decoding mode */
DEV_DWR_ASM(CPM_VCODEC, 1, 1, CPM_ASM_TYPE_RANGE),
DEV_DWR_ASM(CPM_DSP_CLK, 40, 132, CPM_ASM_TYPE_RANGE),
};
struct cpm_swm_range vdsp_dwr1_ranges[] = { /* V-DSP OFF mode */
DEV_DWR_ASM(CPM_VCODEC, 0, 0, CPM_ASM_TYPE_RANGE),
DEV_DWR_ASM(CPM_DSP_CLK, 0, 132, CPM_ASM_TYPE_RANGE),
};
struct cpm_dev_dwr vdsp_dwrs_list[] = { /* V-DSP working mode */
DEV_DWR("Mpeg4", vdsp_dwr0_ranges, ARRAY_SIZE(vdsp_dwr0_ranges)),
DEV_DWR("OFF", vdsp_dwr1_ranges, ARRAY_SIZE(vdsp_dwr1_ranges)),
};
static struct cpm_dev_data vdsp_data = { /* V-DSP DWR’s registration */
.notifier_callback = vdsp_cpm_callback,
.dwrs = vdsp_dwrs_list,
.dwrs_count = ARRAY_SIZE(vdsp_dwrs_list),
};
ret = cpm_register_device(&vdsp.dev, &vdsp_data);
Go to Definition