PM Summit fall out

2 CE Vendors Spoke at Summit  CELF presented  TI presented  Free Scale presented  Nokia presented  MLI represented

3 The Messages where consistent  CE PM is more complex than laptops  CPUFREQ isn’t good enough on technical and practical grounds  We all need tick-less idle  DPM is a useable baseline for CE users. Lets try to get those types of capabilities in mainline. –Getting DPM into main line would be good enough for CE folks. –Getting powerOP into main line is also a very good step.  We are stepping up to make contributions.

4 The Established Kernel folks Listened  Dominic acknowledged that CPUFREQ cannot handle adding voltage governors, let alone SOC voltage, clock and power domains.  We should consider a new PM framework for PM control and policy that will provide for CPUFREQ and DPM types of power control.  Dominic gave me the AR to make the first cut at a PM framework design as a starting point and then we’ll start iterating on the design and implementations.

5 Other notes from the PM summit  I don’t have the complete list as I was mostly focused on CE related issues but: –Device Power Management interfaces got a lot of attention –OSV PM configuration and UI got attention. –Suspend / Resume was addressed, but it looks like Pavel is fairly satisfied with the way things are in the latest kernels. If we are not, then we’ll have to push him to get changes through. –Google is a supporter of the PM Framework for non-CE applications.

6 CE related things to follow up on.  Tick less idle needs moral support and encouragement. Someone should help Thomas Gliexner (SP?)  Taking a control theory look at PM requirements / design and providing a proper vocabulary to use when talking about the different aspects of the design.  Tracing CPU execution bloat.  More PM governors!

7 Plans for PM interface and framework  I’ve captured the input from the summit and have put it in some simple documents that are out for review by the PM-Summit group.  I’m going to keep the communication between the group going as best as I can. Planning on monthly or every other week calls, to bring the parties together.  I’m designing an initial framework that meets the target requirement as captured from the PM-Summit.  Identify target platforms and implementation owners for arch/platform specific work.

8

9 Design Goals for PM frameworks  Enable policy drivers and interfaces for setting platform dependent control variables.  Extensible WRT platform specific control variables.  Policy drivers and interfaces need to be “arch- independent” as far a the kernel build is concerned, but; –Policy drivers that control platform specific parameters not available at load time, should do no harm. –Perhaps use compile time and kbuild to control the policy driver options that are built to avoid building such drivers?  No implicit constraints on policy algorithms or logic.  Keep policy implementation in user space (DPM style), or architecture independent policy driver code (CPUFREQ style).  Platform constraints on control variables are enforced by arch code

10 High level components, issues and structure the design needs to accommodate  driver notifications for operating point changes : need a prepare and finish notification  need to be able to run some type of install for loading kernel driver exposing platform specific PM knobs when setting up the PM framework  When active there will be –idle process / policy management –run time / governor based policy management –Run time user space policy assertion  The Framework will wrap power-op and HW clock managers as well as voltage managers… somehow.

11 Implementation Plan  Capture ideas and high level design concepts for quick review.  Identify the implementation partners in crime. (Nokia, TI, FreeScale, google, Intel, google, Matt Locke, Todd Poynor - MV, Dominik Brodowski, Adam Belay)  Identify the initial target development platforms, i386, pxa???, Omap???, Frescale???  Do a quick design prototype, including more than one architecture and platform.  Have periodic discussions and exchanges.  put out RFC (where? linux-pm, cpufreq?, other...)  Take feed back and turn an initial patch set  post, get feed back, repeat...