Resource Power Manager (RPM - BF) : User Guide

Resource Power Manager (RPM.
BF)
User Guide
80-NA157-15 E
April 17, 2014
Submit technical questions at:

https://support.cdmatech.com/
Confidential and Proprietary – Qualcomm Technologies, Inc.

NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites
to: DocCtrlAgent@qualcomm.com.
Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm or its
subsidiaries without the express approval of Qualcomm’s Configuration Management.
Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others
without the express written permission of Qualcomm Technologies, Inc.
Qualcomm reserves the right to make changes to the product(s) or information contained herein without notice. No
liability is assumed for any damages arising directly or indirectly by their use or application. The information
provided in this document is provided on an “as is” basis.
This document contains confidential and proprietary information and must be shredded when discarded.
Qualcomm is a trademark of QUALCOMM Incorporated, registered in the United States and other countries. All
QUALCOMM Incorporated trademarks are used with permission. Other product and brand names may be
trademarks or registered trademarks of their respective owners.
This technical data may be subject to U.S. and international export, re-export, or transfer (“export”) laws. Diversion
contrary to U.S. and international law is strictly prohibited.
Qualcomm Technologies, Inc.

5775 Morehouse Drive
San Diego, CA 92121
U.S.A.
© 2012-2014 Qualcomm Technologies, Inc.

All rights reserved.
Contents
1 Introduction...................................................................................................... 7
1.1 Purpose.......................................................................................................................... 7
1.2 Scope............................................................................................................................. 7
1.3 Conventions .................................................................................................................. 7
1.4 References..................................................................................................................... 7
1.5 Technical assistance ...................................................................................................... 7
1.6 Acronyms ...................................................................................................................... 7
2 RPM Overview .................................................................................................. 8

2.1 Hardware overview ....................................................................................................... 8
2.1.1 RPM processor................................................................................................... 8
2.1.2 AHB ................................................................................................................... 9
2.1.3 Boot ROM ......................................................................................................... 9
2.1.4 Code RAM ......................................................................................................... 9
2.1.5 Data/log RAM ................................................................................................... 9
2.1.6 Message RAM ................................................................................................. 10
2.1.7 Interrupt controller ........................................................................................... 10
2.1.8 Timers .............................................................................................................. 10
2.1.9 CSR.................................................................................................................. 10
2.2 RPM software overview ............................................................................................. 11
2.2.1 Kernel .............................................................................................................. 11
2.2.2 RPM handler .................................................................................................... 12
2.2.3 Drivers ............................................................................................................. 12
3 RPM Build Instructions ................................................................................. 14
4 RPM Scheduling ............................................................................................ 15

4.1 Task............................................................................................................................. 15
4.2 Dispatcher ................................................................................................................... 16
4.3 Scheduler .................................................................................................................... 17
4.4 Schedule collision – Stack up example ....................................................................... 18
4.5 Concurrency – Next awake set ................................................................................... 20
4.6 Schedule code layout .................................................................................................. 22
4.7 Example of scheduling with preemption .................................................................... 23
80-NA157-15 E 2 Confidential and Proprietary – Qualcomm Technologies, Inc.

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Contents
5 RPM Messaging ............................................................................................. 24

5.1 RPM message infrastructure ....................................................................................... 24
5.2 RPM message RAM ................................................................................................... 25
5.3 Transport layer – SMD Lite ........................................................................................ 25
5.3.1 SMD Lite data structures ................................................................................. 25
5.3.2 SMD Lite functions ......................................................................................... 26
5.4 Message format – Key Value Pairs (KVPs)................................................................ 26
5.4.1 Example of request to change LDO3 voltage and current ............................... 27
5.4.2 KVP usage ....................................................................................................... 27
6 RPM Railway .................................................................................................. 28

6.1 Railway-related components....................................................................................... 28
6.1.1 RPM server ...................................................................................................... 28
6.1.2 PMIC driver ..................................................................................................... 28
6.1.3 Railway ............................................................................................................ 28
6.1.4 SVS .................................................................................................................. 28
6.1.5 Clock driver ..................................................................................................... 29
6.1.6 CPR driver ....................................................................................................... 29
6.1.7 DDR driver ...................................................................................................... 29
6.1.8 Sleep ................................................................................................................ 29
6.2 Interfaces and dependencies ....................................................................................... 30
7 RPM RBCPR ................................................................................................... 31

7.1 RPM CPR ................................................................................................................... 31
7.2 CPR initialization ........................................................................................................ 32
7.3 CPR measurement and adjustment ............................................................................. 34
7.4 CPR voltage switching................................................................................................ 35
7.5 CPR driver source code .............................................................................................. 35
7.6 CPR debug .................................................................................................................. 36
7.6.1 Enable/disable CPR at runtime ........................................................................ 36
7.6.2 Retrieve the RBCPR log .................................................................................. 36
8 RPM Debugging ............................................................................................. 38

8.1 Trace32 scripts ............................................................................................................ 38
8.1.1 Save RAM dump – rpm_dump.cmm ............................................................... 38
8.1.2 Load RAM dump – rpm_load_dump.cmm...................................................... 38
8.1.3 Restore a crash – rpm_restore_core.cmm ........................................................ 38
8.1.4 Parse log – rpm_parse_faults.cmm .................................................................. 38
8.1.5 Examine the preempted process – rpm_m3_unstack.cmm .............................. 39
8.2 Getting the RPM log ................................................................................................... 39
8.2.1 Using T32 ........................................................................................................ 39

Contents
9 Software Events ............................................................................................. 40

9.1 RPM SWEvent range table ......................................................................................... 40
9.2 Adding RPM SWEvents ............................................................................................. 41
9.2.1 Add new SWEvent to tech area SConscript .................................................... 41
9.2.2 Add SWEVENT calls for new SConscript ...................................................... 41
9.2.3 Add SWEVENT RAM post-parsing................................................................ 42
10 RPM Master User Guide .............................................................................. 43

10.1 Active mode usage .................................................................................................... 43
10.2 Sleep mode usage...................................................................................................... 44
10.2.1 RPM.AF→RPM.BF RPM sleep interaction differences ............................... 44

Contents
Figures
Figure 2-1 RPM example block diagram ..................................................................................................... 8
Figure 2-2 RPM software topology ........................................................................................................... 11
Figure 4-1 Scheduling with preemption..................................................................................................... 23
Figure 5-1 RPM message RAM partition .................................................................................................. 25
Figure 6-1 Interfaces and dependencies ..................................................................................................... 30
Figure 7-1 RBCPR core with master and sensors ...................................................................................... 31
Figure 7-2 Two-point STEP_QUOT calculation during boot.................................................................... 32
Figure 7-3 STEP_QUOT is the number of QUOT units per PMIC step ................................................... 33
Figure 7-4 CPR measurement/adjustment ................................................................................................. 34
Figure 7-5 CPR voltage switching flow..................................................................................................... 35
Tables
Table 1-1 Reference documents and standards ............................................................................................ 7
Table 2-1 Example RPM messaging masters ............................................................................................ 10
Table 9-1 Software event entry .................................................................................................................. 40

Revision history
Revision Date Description

A Jul 2012 Initial release
B Oct 2012 Numerous changes were made to this document; it should be
read in its entirety
C Nov 2013 Added MDM9x35
D Apr 2014 Numerous changes were made to this document; it should be
read in its entirety.
E Apr 2014 Updated Sections 1.1 and 1.2

1 1 Introduction
2 1.1 Purpose
3 This document describes the Resource Power Manager (RPM) for chipsets that use the RPM.BF
4 subsystem.
5 1.2 Scope
6 This document is intended for customers who must understand details about RPM.BF.
7 1.3 Conventions
8 Function declarations, function names, type declarations, and code samples appear in a different
9 font, e.g., #include.
10 Code variables appear in angle brackets, e.g., <number>.
11 Shading indicates content that has been added or changed in this revision of the document.
12 1.4 References
13 Reference documents are listed in Table 1-1. Reference documents that are no longer applicable
14 are deleted from this table; therefore, reference numbers may not be sequential.
15 Table 1-1 Reference documents and standards

Ref. Document
Qualcomm Technologies
Q1 Application Note: Software Glossary for Customers CL93-V3077-1
16
17 1.5 Technical assistance

18 For assistance or clarification on information in this document, submit a case to Qualcomm
19 Technologies, Inc. (QTI) at https://support.cdmatech.com/.
20 If you do not have access to the CDMATech Support Service website, register for access or send
21 email to support.cdmatech@qti.qualcomm.com.
22 1.6 Acronyms
23 For definitions of terms and abbreviations, see [Q1].

1 2 RPM Overview
2 2.1 Hardware overview

3 Figure 2-1 shows the top-level example block diagram of the RPM.
5 Figure 2-1 RPM example block diagram
6 2.1.1 RPM processor

7 The RPM core consists of:
8  Cortex-M3 processor with integrated NVIC
9  128 KB multibank code RAM
10  64 KB multibank data/log RAM
11  16 KB message RAM

RPM Overview
1 The RPM processor has a native Advanced High-performance Bus (AHB) Lite interface and
2 built-in ETM/ITM and DAP support. The processor target frequency is 100 MHz. The Cortex-M3
3 supports a native SWFI instruction, which allows the processor to turn off its own clock when the
4 clock is not needed.
5 The Cortex-M3 processor uses a Harvard architecture, enabling simultaneous instruction fetch
6 with data load/store. It supports thumb2, single-cycle 32-bit multiply, and hardware divide.
7 2.1.2 AHB
8 The RPM AHB is synchronous to the RPM processor. It instantiates an aPU, which is configured
9 to protect the code RAM and mPU. The code RAM and mPU are configured to protect different
10 predecoded address space within the RPM. The RPM AHB has Cortex-M3 as the default master
11 for the bus. The RPM AHB allows byte, half-word, and word accesses for the code and data/log
12 RAM. The RPM AHB allows only word accesses for CSR registers.
13 2.1.3 Boot ROM

14 The RPM boot ROM block houses the actual ROM that the RPM processor uses to boot out of on
15 system reset, along with the AHB logic to access it through the RPM AHB bus. The main
16 purpose of the boot ROM is to store the Primary Boot Loader (PBL). The PBL is the first piece of
17 code that the chip executes and is responsible for initial hardware setup to a point where further
18 bootup can proceed from the Flash. The PBL must reside in an internal boot ROM to guarantee
19 that the chip always boots from a known trusted code.
20 2.1.4 Code RAM

21 The RPM instantiates a 128-KB code RAM. It is a single-port compiler memory. The RPM code
22 RAM operates at a clock frequency that is synchronous to the RPM AHB. The RPM code RAM
23 allows single-cycle read access and is 32 bits wide. The Cortex-M3 core data accesses can spill
24 into code RAM space if the software chooses, though this is at the loss of optimal performance.
25 2.1.5 Data/log RAM

26 The RPM instantiates a 64-KB data/log RAM. This RAM is a single-port compiler memory. The
27 RPM data RAM operates at a clock frequency that is synchronous to the RPM AHB. The RPM
28 data RAM allows single-cycle read access and is 32 bits wide. The Cortex-M3 core instruction
29 accesses can spill into data RAM space if the software chooses, though this is at the loss of
30 optimal performance.

RPM Overview
1 2.1.6 Message RAM

2 The RPM message RAM provides memory for sending messages to and from the RPM core. The
3 messaging masters use this memory to communicate with the RPM. See Table 2-1 for examples.
4 Table 2-1 Example RPM messaging masters

Chipset MSM8974 MDM9x25 MDM9x35
Messaging masters  APSS (Krait)  APSS (A5)  APSS

 Modem  Modem  Modem
 LPASS  LPASS  LPASS
 WCNSS  Pronto
 TZ
5 2.1.7 Interrupt controller

6 The Cortex-M3 has a built-in Nested Vectored Interrupt Controller (NVIC), with a configurable
7 number of interrupts. The RPM is configured to use 64 interrupts. Sources external to the RPM
8 include MPM, SPM, messaging, and nonmessaging masters. Sources internal to the RPM include
9 general-purpose timers, WDOG timer bark, and CTI interrupts. The RPM interrupt controller
10 provides priority queuing of interrupts and supports both edge-sensitive and level-sensitive
11 interrupts.
12 The NVIC can only be fully accessed from Privileged mode, but interrupts can pend in User
13 mode if they are enabled via the Configuration Control Register (CCR). Any other user mode
14 access causes a bus fault. All NVIC registers are accessible using byte, half-word, and word,
15 unless otherwise stated. All NVIC registers and system debug registers are little-endian,
16 regardless of the endianess state of the processor.
17 2.1.8 Timers
18 The RPM instantiates the QTimer with two frames, one for the kernel and one for the user. The
19 QTimer keeps track of real time in every power mode.
20 The RPM also has a WDOG timer running on the SLEEP clock, with a configurable bark and bite
21 expiration.
22 2.1.9 CSR
23 The RPM Control/Status Register (CSR) provides IPC and GPO registers to generate IPC
24 interrupts and general-purpose pulses respectively. The RPM CSR provides a WFI_CONFIG
25 register to generate requests to turn off the RPM bus clocks and CHIP_SLEEP_EN, also known
26 as SW_DONE, to signal the MSM™ Power Manager (MPM) that the MSM is ready for sleep.
27 WDOG timer software interface registers, test bus configuration registers, and other
28 miscellaneous use registers are supported.

RPM Overview
1 2.2 RPM software overview

2 The RPM software topology is shown in Figure 2-2.
Master 1 Master 2 Master 3 Master N
RPM
RPM HANDLER
NPA
SLEEP
CLK DDR PMIC BUS MPM
WDOG SPMI
DRIVERS
KERNAL (DALSYS Native)
Master 1 Master 1 Master N Master N

Master 2
Core 0 Core 1 Core 0 Core N
SPM
SPM SPM SPM SPM
3
4 Figure 2-2 RPM software topology
5 2.2.1 Kernel
6 The kernel for the RPM supports:
7  Interrupts
8  Intlock, priorities, and configuration
9  Busy waits
10  Timers
11  SWFI
12  Reduced code size
13 The kernel is implemented using DALSYS to the metal, providing the RPM with a lightweight
14 kernel and allowing for easier driver porting.

RPM Overview
1 2.2.2 RPM handler

2 The RPM handler abstracts the RPM message protocol away from other software. The driver
3 handles the RPM-side client and server portions of the RPM messaging and hands data to the rest
4 of the drivers via callbacks.
5 2.2.3 Drivers
6 Drivers for each resource supported by the RPM register with the RPM handler to request
7 notification when requests are received for the resource that the driver controls. Upon receiving
8 this notification, the drivers perform arbitration that must be performed between the new request
9 and previous requests from other masters. Based on the arbitration results, the driver determines
10 how to modify the hardware resource.
11 2.2.3.1 NPA
12 A driver may use the Node Power Architecture (NPA) to represent resources controlled by the
13 driver. NPA is a generic framework that allows nodes to represent resources. Each node has
14 clients and is responsible for aggregating workload requirements on their resources while
15 optimizing power usage. The nodes make up a distributed graph, allowing one node to be a client
16 of another node.
17 2.2.3.2 Clock driver

18 The clock driver consists of two parts. One part resides on each master and the other part resides
19 on the RPM.
20 The RPM clock driver directly handles aggregating requests from each master for the system-
21 wide clock resources controlled by the RPM. The driver also handles RPM-specific clocks.
22 2.2.3.3 Bus arbitration driver

23 The bus arbiter driver consists of multiple parts. One part resides on each master and one part
24 resides on the RPM.
25 The RPM bus arbiter driver takes bus arbiter settings as requests from the different masters in the
26 system and aggregates them to represent the frequency-independent system settings. From these
27 settings, the frequency required to meet the settings is calculated.
28 Using the calculated value, the bus arbiter driver makes a request of the RPM clock driver. The
29 clock driver request sets a floor for the frequency at which the buses/FABRICs can operate. The
30 system settings are then converted into frequency-dependent settings, and the driver configures
31 the bus arbiter hardware with those settings.
32 2.2.3.4 PMIC driver

33 The PMIC driver consists of multiple parts. One part resides on each master and the other part
34 resides on the RPM.
35 The RPM PMIC driver directly aggregates requests from each master for the system-wide PMIC
36 resources controlled by the RPM.

RPM Overview
1 2.2.3.5 WDOG driver

2 The WDOG is a fail-safe for incorrect or stuck code. If a register is not written within a specific
3 time period, an interrupt occurs that allows the software to attempt to recover. If the register is
4 still not written within a specific time period, the system resets.
5 For the RPM subsystem, only the scheduler has the capability to pet the WDOG and reset the
6 WDOG counter. There is no software task monitoring other software tasks for stuck conditions.
7 Dealing with the WDOG during scheduler operations should meet the fail-safe needs. The
8 software does not have to explicitly deal with the WDOG in most scenarios.
9 The WDOG also supports a freeze, stopping the countdown, for scenarios where the scheduler
10 does not run within a given timeframe. Examples of scenarios requiring freeze support include
11 long memory or hardware accesses. Such scenarios should be avoided in most cases by the
12 software design. Freeze is supported when the RPM enters Sleep mode.
13 The RPM watchdog driver cannot reset the system.
14 2.2.3.6 MPM driver

15 The MPM driver is used to program the MPM hardware block during systemwide sleep. This
16 driver resides on the RPM and is responsible for programming the MPM to do the following:
17  Vdd_Dig retention – Puts the system-wide power rail in the Retention state
18  Vdd_Dig collapse – Puts the system-wide power rail in the Collapse state
19  Vdd_Mem retention – Puts the system-wide power rail in the Retention state
20  Vdd_Mem collapse – Puts the system-wide power rail in the Collapse state
21  CXO shutdown – Turns off CXO
22 The driver must support programming of the MPM timer hardware and the MPM interrupt
23 controller.
24 The MPM driver must also initialize several configuration registers to properly handle the
25 hardware combination and configuration needs of the system.

1 3 RPM Build Instructions
2 See the appropriate software user manual or build and integration documentation for detailed
3 instructions of building the RPM subsystem. Additional information may also be found in the
4 software release notes.
5 NOTE: To build the RPM, install ARMCT 5.01 build 94 on your machine.

1 4 RPM Scheduling
2 4.1 Task
3 An RPM task is an instance of the class Task. The class Task is defined in rpm_task.h and
4 rpm_task.cpp and has the following interface:
5  Get task name:
6
7 const char *get_name() const;

8
9  Get task priority:

10
11 uint8_t get_priority() const;

12
13  Set the deadline by which the execution should complete:

14
15 void set_deadline(uint64_t deadline);

16
17  Get the deadline by which the execution should complete:

18
19 bool get_deadline(uint64_t& deadline) const;

20
21  Get the estimate of how long this task takes to execute:

22
23 virtual uint64_t get_length() const = 0;

24
25  Get the time the task should start by in order to finish on time:
26
27 uint64_t get_start() const;

28
29  Set the time the task should start by in order to finish on time:
30
31 void set_start(uint64_t start_time);

32
33  Check if the task has immediate work to do:

34
35 virtual bool hasImmediateWork() const = 0;

RPM Scheduling
1  Check if the task has scheduled work to do:

2
3 virtual bool hasScheduledWork() const;

4
5  Run this task until it completes, stops, or is preempted:

6
7 void execute(volatile bool &preempt, uint64_t stop_time);

8
9 There are two tasks created for each master: one of RPMFWRequestHandler which handles
10 resource requests from the master; and one of RPMFWSetChanger which handles set transitions
11 when the master enters or exits sleep.
12 The task priority is inherited from its master: MPSS has the highest priority, APPS has the
13 intermediate, and LPASS has the lowest priority.
14 4.2 Dispatcher
15 A dispatcher is an object embedded in a task. The dispatcher executes the batches of work
16 associated with the task. The class RPMFWDispatcher is defined in DalRPMFWDispatcher.h and
17 DalRPMFWDispatcher.cpp, which has the following interface:
18  Set up a new batch of work to be executed:
19
20 void set_work(const DAL_rpm_ResourceIndType &changed_resources,

21 DAL_rpm_ConfigSetType changed_set);
22
23  Get the estimate worst-case execution time:

24
25 uint64_t get_length() const;

26
27  Perform the dispatching until all tasks are done, run out of time, or be preempted:
28
29 bool dispatch(volatile bool &preempt,

30 uint64_t stop_time,
31 bool &rejected,
32 RPMResourceDataLayout &new_req,
33 bool save_req,
34 RPMResourceDataLayout *acknowledgement);

RPM Scheduling
1 4.3 Scheduler
2 The scheduler is the static instance of the class Sched which implements cooperative multiple
3 tasking. The class Sched is defined in rpm_sched.h and rpm_sched.cpp.
4 The scheduler has three private members:
5  Immediate task list – Tasks with immediate work is kept in this binary heap.
6
7 TaskHeap immediateQ_;
8
9  Scheduled task list – Tasks with scheduled work is added into this sorted list.
10
11 TaskList scheduledQ_;
12
13  Preemption flag – The dispatcher checks this flag periodically to see if it should stop current
14 work prematurely and yield the processor for higher priority task.
15
16 volatile bool preempt_;

17
18 The scheduler provides the following interfaces:

19  Retrieve the single scheduler instance:
20
21 friend Sched &theSchedule();

22
23  Add a new task to be scheduled, causing the task be added to the immediate or scheduled list
24 and the preemption flag be updated as needed:
25
26 void schedule_task(Task &new_task,

27 ScheduleType schedule_type = DEFAULT);
28
29  Run the next outstanding task, returning only when there is no immediate work to do:
30
31 void run();
32
33  Return the time by which the scheduler should run next:

34
35 uint64_t get_next_start() const;

36
37  Return the estimated duration of the scheduler’s next run:

38
39 uint64_t get_next_duration() const;

RPM Scheduling
1 4.4 Schedule collision – Stack up example

2 Every scheduled conflict has either been explored or is just another permutation of what has been
3 covered. What about immediate work? How should it interact with the scheduled timeline? An
4 example follows.
5 1. Task A, task B, and task D are on the schedule, each with their own deadline – deadline A,
6 deadline B, and deadline D.
A’s
estimated
work B’s estimated work D’s estimated work
time
deadline ‘A’ deadline ‘B’ deadline ‘D’

7
8 2. A new task, task C, comes in with a new deadline, deadline C.
A’s
estimated
time
deadline ‘A’ deadline ‘B’ deadline ‘D’
C’s estimated work
deadline ‘C’
9

RPM Scheduling
1 3. Task C is inserted; based on the deadline, task C now conflicts with task D in the queue, so
2 the execution time for task C is pushed out.
A’s
estimated
deadline ‘A’ deadline ‘B’ deadline ‘C’ deadline ‘D’

3
4 Now, task A conflicts with task B, so the execution time for task B is pushed out.
A’s
estimated
work
B’s estimated
work
D’s estimated work
deadline ‘A’ deadline ‘B’ deadline ‘C’ deadline ‘D’

5

RPM Scheduling
1 4. Task D’s original schedule remains unchanged. The rest of the schedule needed
2 modifications. This is called stack up when the problem occurs, and the resolution is called
3 schedule fix up.
A’s
estimated
work
B’s estimated
work
D’s estimated work
5 4.5 Concurrency – Next awake set

6 Wake-up information from the modem goes from time to deadline; missing the deadline is
7 considered a failure. Allow the modem to avoid a resource double state change by storing a next
8 awake set into memory before sleep to save the handshake time cost as described in the following
9 steps.
10 1. When going to sleep, a new sleep set is written and sent to the RPM. The settings for the next
11 wake-up are then left as an unsent request in message RAM.
WCDMA
GPS
Active set Sleep set Message RAM
12

RPM Scheduling
1 2. Once the RPM detects a sleep transition on a master, it checks to see if there is an unsent
2 message in message RAM.
WCDMA
GPS
5 3. If there is an unsent message, it schedules the application of that request just before the
6 wake-up of that master.
WCDMA
GPS

RPM Scheduling
1 4. At wake-up, the active set is updated. This allows the active set to be changed ahead of time
2 and to skip double-state changes upon wake-ups.
WCDMA
GPS
4 4.6 Schedule code layout

5  Request handling algorithms:
6  DalRPMFWHandler.cpp
7  DalRPMFWHandler.h
8  Set transition algorithms:
9  DalRPMFWSetChanger.cpp
10  DalRPMFWSetChanger.h
11  Common code between request handling and set transitions – Iterating over a list of resource
12 requests and sending them off to drivers:
13  DalRPMFWDispatcher.cpp
14  DalRPMFWDispatcher.h
15  Schedule code – Code that is responsible for keeping track of how long each resource will
16 take to transition:
17  DalRPMFWEstimator.cpp
18  DalRPMFWEstimator.h
19  Schedule framework:
20  rpm_sched.cpp
21  rpm_task.cpp
22  rpm_timeservice.cpp
23  task_heap.cpp
24  task_list.cpp

RPM Scheduling
1 4.7 Example of scheduling with preemption

2 Figure 4-1 shows an example of scheduling with preemption.
5 Figure 4-1 Scheduling with preemption

1 5 RPM Messaging
2 5.1 RPM message infrastructure

3 RPM messaging is built around three core concepts:
4  Masters – These are the subsystems that make requests to the RPM. The messaging masters
5 for different targets are given in Table 2-1.
6  Resources – These are the physical components that the RPM is responsible for controlling:
7  Clocks
8  Bus arbitration
9  PMIC
10  DDR (DMM)
11  Chip sleep wakeup interrupts
12  Processor wakeup deadlines
13  Configuration sets – These are a collection of settings, one for each resource, that fits a
14 logical use case. Three sets are currently provided for each master:
15  Active set – This set contains the settings used when the subsystem is awake.
16  Sleep set – This set contains the settings used when the subsystem is sleeping (when an
17 SPM handshake occurs).
18  Next active set – This set contains the settings used when the subsystem is awake and
19 before the active set.

RPM Messaging
1 5.2 RPM message RAM

2 Messaging is the main method for each system master to communicate with the RPM. The
3 message RAM is partitioned into several regions, using an RPU with 512-byte granularity. A
4 majority of the partitions are dedicated for master/RPM pairs. These partitions are only accessible
5 by that master and the RPM. See Figure 5-1.
7 Figure 5-1 RPM message RAM partition
8 5.3 Transport layer – SMD Lite

9 SMD Lite is a message-oriented FIFO transport layer selected to replace the previous register
10 emulation.
11 SMD Lite is a lightweight interprocessor communication layer available on the most recent chips.
12 It is focused on the mechanism of moving data between processors and tries to remain entirely
13 ignorant of the policy of what that data means and of higher-level constructs, e.g., queuing.
14 The SMD Lite API is documented in the smd_lite.h header file that is available with the build.
15 Since the API has evolved over time, the header file that ships with the build is considered to be
16 the canonical documentation. It defines the structures and functions in Sections 5.3.1 and 5.3.2.
17 5.3.1 SMD Lite data structures

18 The SMD Lite data structures are:
19  smdl_handle_type
20  smdl_iovec_type
21  smdl_event_type
22  smdl_sig_type
23  smdl_callback_t

RPM Messaging
1 5.3.2 SMD Lite functions

2 The SMD Lite functions are:
3  smdl_init()
4  smdl_open()
5  smdl_close()
6  smdl_rx_peek()
7  smdl_tx_peek()
8  smdl_read()
9  smdl_write()
10  smdl_readv()
11  smdl_writev()
12 5.4 Message format – Key Value Pairs (KVPs)

13 The messages are formatted as KVP. The KVP format was selected for better compatibility and
14 expandability, low overhead, and because it can be incrementally parsed easily.
15 At a high level, a KVP structure is simply:
16  What you are talking about
17  Blob of data that you are saying
18 At a lower level, this is just 2+n words of data.
19  One word for key – Generally used as a 4-byte string (uv\0\0, clk\0, etc.)
20  One word for length – Describes how many bytes follow
21  Blob of data
22 This structuring is repeated recursively to build full messages.
23 Internally, a request to an RPM is a concatenated array of KVP objects. KVP objects are simple
24 in their layout in memory:
25
26 <4 bytes of key> <4 bytes of length> <0..* bytes of value>

27
28 Therefore, a request to the microvolts key (“uv”) of a regulator might be laid out in memory, e.g.,
29 shown byte-by-byte:
30
31 75 76 00 00 | 04 00 00 00 | e0 c8 10 00
32
33 The pipe symbol (|) separates the fields for visual effect. The first field is the little-endian
34 rendering of 0x7675, which is the transliteration of “uv” as explained above. The second field
35 indicates that the request is a 4-byte data buffer. The final field is the 4-byte data buffer
36 containing a little-endian rendering of the value 1,100,000 µV (or 1.1 V).

RPM Messaging
1 5.4.1 Example of request to change LDO3 voltage and current

2 {
3 “req\0” : {
4 {“rsrc” : “ldo\0”}
5 {“id” : 3}
6 {“set” : 0}
7 {“data” : {
8 {“uv\0\0” : 1100000}
9 {“mA\0\0” : 130}
10 }
11 }
12 }
13 }
14 5.4.2 KVP usage

15 In practice, there is a kvp module which is used to build these buffers of KVP objects. A brief
16 overview of the API follows.
17 First, a kvp instance is created. KVP instances contain an internally managed, dynamically
18 expanding buffer that holds the requests and their data.
19
20 kvp_t *cxo_request = kvp_create(12);

21
22 The magic number 12 above is a hint about how much data will be placed in the stream. This
23 example case uses 12; if you know in advance what your requests will look like, use the
24 following rules to pick a guideline number:
25  8 bytes of overhead per call to kvp_put(), plus however many bytes of data you are “putting,”
26 rounded up to a 4-byte boundary on each put()
27  0 is always an acceptable hint; the kvp object always reallocates a larger buffer as required
28 Next, put the KVP into the buffer:
29
30 unsigned nCXORequirement = 1;
31 unsigned units_Enab = 0x62616e45; // = "Enab" -- the units for CXO
32 kvp_put(cxo_request, units_Enab, sizeof(nCXORequirement),
33 &nCXORequirement);
34
35 Every time you pass a kvp object to an RPM function call, its contents are “consumed.” To reuse
36 the kvp object later on, make sure to take the following cleanup actions:
37  To reuse the buffer to resend the exact same data, call kvp_reset(<your object>).
38  To reuse the buffer to send /different/ data, call kvp_clear(<your object>). Do not forget to
39 use kvp_put() to add new data before sending.
40 Of course, if there is no further required use of the buffer, kvp_destroy(<your object>) can be
41 used to clean it up entirely.

1 6 RPM Railway
2 6.1 Railway-related components
3 6.1.1 RPM server

4 The RPM server routes requests from masters and internal clients to the correct resource in the
5 RPM.
6 6.1.2 PMIC driver

7 The PMIC driver processes voltage transition requests from masters and internal clients on the
8 RPM. All knowledge of the power grid for the specific target is contained within the PMIC
9 driver.
10 6.1.3 Railway
11  Manages the Vdd_Mx, Vdd_Cx, and Vdd_Gfx rails and their dependencies
12  Vdd_Mx must be greater than or equal to Vdd_Cx and Vdd_Gfx at all times
13  Vdd_Mx must never be more than 370 mV higher than any logical rail
14  Provides notifications to registered clients when one of the ‘managed’ rails changes voltage
15  Provides notification to the sleep module regarding whether it is possible to go into Vdd
16 minimization based on the aggregated votes on Vdd_Cx and Vdd_Mx
17  Allows the Core Power Reduction (CPR) driver to override the default corner values with the
18 dynamic values that are recommended by the CPR (Vdd_Cx and Vdd_Gfx)
19  Provides NPA nodes to allow the clock driver to vote on voltages for Vdd_Cx and Vdd_Gfx
20  Allows internal RPM clients to make nonsuppressible requests for voltages on any of the
21 managed rails; these nonsuppressible requests influence whether Vdd minimization can occur
22 6.1.4 SVS
23  Tracks the Vdd_Cx voltage and votes on the RPM CPU clock to be maximum speed that is
24 available at the current Vdd_Cx voltage
25  Can also vote to raise Vdd_Cx in order to boost the CPU frequency should the current
26 scheduler workload make that the sensible thing to do

RPM Railway
1 6.1.5 Clock driver

2 The clock driver manages all of the shared clocks on the system; it votes via NPA to raise
3 voltages as required to scale clock frequencies.
4 6.1.6 CPR driver

5 The CRP driver manages the CPR hardware for the Vdd_Cx and Vdd_Gfx rails, provides a table
6 of dynamic corner voltages to the railway, and updates this table (per rail) as the CPR hardware
7 notifies it that the voltage should be raised/lowered to maintain timing.
8 6.1.7 DDR driver

9 The DDR driver manages the DDR settings and updates the DDR controller hardware as Vdd_Cx
10 and Vdd_Mx change.
11 6.1.8 Sleep
12 Sleep code is executed whenever the RPM is idle. The sleep code will put the RPM into halt/Vdd
13 minimization/XO shutdown depending on a number of factors:
14  How long it expects the RPM to be idle
15  The state of the masters; any master being active prevents XO shutdown and Vdd
16 minimization
17  Depending on what railway votes for the sleep target of various rails, Vdd minimization may
18 or may not be possible

RPM Railway
1 6.2 Interfaces and dependencies

2 Figure 6-1 illustrates the interfaces and dependencies of the RPM railway.
4 Figure 6-1 Interfaces and dependencies
5 The following numbered steps correspond to Figure 6-1:

6 1. The PMIC driver registers with the RPM server to receive all PMIC requests
7 (RPM_SMPS_A_REQ, RPM_LDO_A_REQ, etc.).
8 2. Railway registers with the RPM server to receive PMIC requests for specific resources, i.e.,
9 Vdd_Cx, Vdd_Mx, Vdd_Gfx. These override the registration done by the PMIC driver; the
10 PMIC driver receives no notification for votes on these resources. For these resources, the
11 RPM server routes both the xlate and apply functions to the overrider, i.e., railway.
12 3. Railway makes requests for voltages on the rails it manages directly to the PMIC driver. The
13 PMIC driver is responsible for understanding the power grid of the specific target being run
14 on and adjusting the parent regulators as required.
15 4. SVS registers with railway for notifications on when Vdd_Cx changes. It also uses the
16 railway API for voting for Vdd_Cx up when it wants to boost the CPU speed.
17 5. Clock driver registers with railway for notifications on when Vdd_Cx or Vdd_Gfx changes. It
18 also votes on /pmic/client/clk_regime_dig and /pmic/client/gfxnodes for when it wants to
19 change voltages on Vdd_Cx and Vdd_Gfx respectively; these nodes are implemented by the
20 railway component.
21 6. CPR registers with railway for notifications when either Vdd_Cx or Vdd_Gfx change (so that
22 it can reinitialize the CPR hardware to the new corner). It also uses an API on railway to
23 initiate a voltage change when the dynamic CPR-derived voltage for the current corner has
24 been updated.
25 7. DDR driver registers with railway for notifications on when Vdd_Cx and Vdd_Mx change.
26 8. Railway is responsible for updating the /sleep/uber node depending on whether there are any
27 nonsuppressible votes for Vdd_Cx, which would prevent Vdd minimization.

1 7 RPM RBCPR
2 7.1 RPM CPR

3 CPR is a system that embeds into the SoC and is used to control the VDD level of a chip. CPR
4 consists of a CPR master core and satellite sensors that are integrated into blocks on the SoC. It
5 utilizes sensors to estimate whether the chip is relatively fast or slow, then produces a result that
6 can be interpreted and used to send a VDD modification command to the PMIC. The CPR driver
7 was added in the RPM to control the Vdd DIG, Vdd GPU, etc.
8 The RapidBridge Core Power Reduction (RBCPR) core consists of one master and a number of
9 sensors, shown in green in Figure 7-1. There is additional QTI wrapper logic called rbif, shown in
10 blue in Figure 7-1. The software can program registers in the rbif_csr block, in the QTI rbif.
11 There are no programmable registers in the RapidBridge logic.
rbcpr_wrapper
rbif rbif_csr
msm bus msm bus
xo IF irq_ctl
hispeed_clk
clk mux
CSRs
action
cgc rbif_decision
(up/down decision pmic request

logic)
timer
bsr_chn_in rbif_bsr bsr_chn_out

cont_ack
loop_en
step_up
step_dn
rbif_clk
target
busy
gcnt
refclk cpr_sense_chain
cpr_master_v2
sys_cpr_sense
snext
sprev snext
sprev
snext
sprev
sys_cpr_sense
sys_cpr_sense sys_cpr_sense
snext sprev snext sprev
cpr_sense_chain
cpr_master_sense_chain
12
13 Figure 7-1 RBCPR core with master and sensors

RPM RBCPR
1 7.2 CPR initialization

2 The software must configure some registers prior to using RBCPR. One of the register values,
3 STEP_QUOT, determines how many PMIC voltage steps should be taken to compensate for
4 changes in the quotient (QUOT). The QUOT is basically the raw count of the slowest sensor and
5 is taken while the cpr_master is counting GCNT cycles of the reference clock. If the silicon is on
6 the slow side, the QUOT value is lower; if the silicon is on the fast side, the QUOT is higher.
7 During RBCPR operation, the QUOT is subtracted from the target value (TARG) to determine an
8 error value. This error value is converted to some number of PMIC steps by factoring in the
9 STEP_QUOT. See Figure 7-2.
Power ON Boot ROM
2-point
STEP_QUOT
calculation
Adjust VDD
Secondary Boot
Loader
SBL1
Continue
Boot Sequence
10
11 Figure 7-2 Two-point STEP_QUOT calculation during boot

RPM RBCPR
1 RPM performs an arithmetic calculation in the software to derive STEP_QUOT as shown in

2 Figure 7-3.
STEP_QUOT
is the slope
1.05 V
@ 12.5 mV each
8 PMIC steps
Vdd
0.95 V
quot1 quot2
Quot
4 Figure 7-3 STEP_QUOT is the number of QUOT units per PMIC step
5 Division by 8 is used because the two quotients were measured at Vdd points that are eight PMIC
6 steps apart. Each PMIC step is 12.5 mV; quot_1 was measured at 1.05 V and quot_2 at 0.95 V.
7 The STEP_QUOT shows how many QUOT units correspond to one PMIC step.
8  quot1 – quot2 = delta_quot
9  delta_quot / 8 = STEP_QUOT

RPM RBCPR
1 7.3 CPR measurement and adjustment

2 This section describes how the CPR takes measurements and makes adjustments.
3 1. Configure the CPR interrupts.
4 2. Receive the CPR interrupt, look at RBCPR_STATUS, and make the PMIC adjustment.
5 a. If step_up is 1, increase the PMIC Vdd by one step.
6 b. If step_down is 1, decrease the PMIC Vdd by one step.
7 3. Tell the CPR to take another RBCPR measurement.
8 See Figure 7-4.
Configure RBCPR interrupts
Begin first RBCPR

measurement
Receive IRQ
Run Interrupt Service Routine
Clear interrupt
Make Vdd adjustment
Tell cpr_master to take

another measurement
10 Figure 7-4 CPR measurement/adjustment

RPM RBCPR
1 7.4 CPR voltage switching

2 The RPM runs in one of three modes:
3  Nominal
4  Turbo
5  SVS
6 Figure 7-5 shows the CPR voltage switching modes.
Turbo
Mode
Nominal
Power ON Boot Flow
Mode
SVS
Mode
8 Figure 7-5 CPR voltage switching flow
9 When there is a requirement to switch the core voltage for a mode change, RBCPR callbacks are
10 called before and after the voltage to:
11  Disable the RBCPR block and interrupts
12  Set new Vdd through the software (not RBCPR)
13  Perform two-point STEP_QUOT calculation
14  Configure RBCPR with the new GCNT/TARG pairs
15  Re-enable the block and interrupts
16 7.5 CPR driver source code

17 The CPR driver source code resides in the folder rpm_proc\core\power\rbcpr\ and has the
18 following properties:
19  The read-only data is present in HAL_rbcpr_bsp.c and rbcpr_bsp.c, depending on whether the
20 data applies to the hardware register settings or the software algorithm respectively.
21  The driver code is in rbcpr.c.
22  Cx rail voltage is adjusted by the CPR driver. Mx voltage is always set to a static, or safe,
23 voltage for the operating corner.
24  The recommendation provided by CPR is in terms of PMIC steps:
25 One step = 12.5 mV

RPM RBCPR
1 7.6 CPR debug
2 7.6.1 Enable/disable CPR at runtime

3 RBCPR is enabled by default during rpm_init() and can be disabled/enabled at runtime in
4 rpm_ctl.c by using the DISABLE bit in RPM_CTL.
5 7.6.1.1 Enable/disable CPR with the DISABLE bit in RPM_CTL

6 To enable/disable CPR with the DISABLE bit in RPM_CTL:
7  Set the bit − Disable CPR
8  Clear the bit − Enable CPR
9 7.6.1.2 Enable/disable CPR in the Linux kernel

10 To enable/disable CPR in the Linux kernel:
11  Disable CPR
12
13 adb shell “echo 8 > /sys/module/rpm_resources/mode/rpm_ctl”

14
15  Enable CPR
16
17 adb shell “echo 0 > /sys/module/rpm_resources/mode/rpm_ctl”
18 7.6.2 Retrieve the RBCPR log

19 RBCPR statistics are used to collect information about the voltage scaling recommendations from
20 the RBCPR hardware:
21  Fuse voltage (CPR starting point)
22  For each mode (SVS/Nominal/Turbo):
23  Number of mode interrupts
24  Latest recommendations with timestamps
25  Programmed voltage to railway
26  Exception events – Recommended voltage hitting Min or Max
27  Mode and voltage of the last interrupt
28  Ability to turn on/off statistics
29 RBCPR statistics are placed in a dedicated location of the RPM MSG RAM to make it always
30 available for the HLOS to read and send out through a diagnostic mechanism.
31 On the Android™ side, the debugfs can be mounted to read the RBCPR information.
32
33 mount -t debugfs none /sys/kernel/debug

34 cat /sys/kernel/debug/rpm_rbcpr

RPM RBCPR
1 Example
2
3 :RBCPR Platform Data (upside_steps: 1)(downside_steps:2)(svs_voltage:

4 1050000)(nominal_voltage: 1162500)(turbo_voltage: 1287500)
5 :RBCPR Stats (status_counter: 8) (current_corner:
6 RBCPR_CORNER_TURBO)(current_timestamp: 0x2646943) (railway_voltage:1100000)
7 : RBCPR Corner Data (name: RBCPR_CORNER_SVS) (efuse_adjustment: -
8 37500)(programmed_voltage: 912500(isr_counter:1)(min_counter: 0)(max_counter:0)
9 : Voltage History[0] (voltage: 0) (timestamp: 0x0)
10 : Voltage History[1] (voltage: 0) (timestamp: 0x0)
11 : Voltage History[2] (voltage: 912500) (timestamp: 0x12b209)
12 : RBCPR Corner Data (name: RBCPR_CORNER_NOMINAL) (efuse_adjustment: -
13 37500)(programmed_voltage: 1112500)(isr_counter: 4)(min_counter:
14 0)(max_counter:0)
15 : Voltage History[0] (voltage: 1062500) (timestamp: 0x10ca11)
16 : Voltage History[1] (voltage: 1087500) (timestamp: 0x10ca1c)
17 : Voltage History[2] (voltage: 1112500) (timestamp: 0x10ca26)
18 : RBCPR Corner Data (name: RBCPR_CORNER_TURBO) (efuse_adjustment: -
19 37500)(programmed_voltage: 1100000)(isr_counter: 3)(min_counter:
20 1)(max_counter:0)
21 : Voltage History[0] (voltage: 1162500) (timestamp: 0x1d5ac)
22 : Voltage History[1] (voltage: 1125000) (timestamp: 0x13fd6a)
23 : Voltage History[2] (voltage: 1087500) (timestamp: 0x14170e

1 8 RPM Debugging
2 8.1 Trace32 scripts
3 8.1.1 Save RAM dump – rpm_dump.cmm

4 If the RPM crashes and there is no expert available, use the following script to capture the state of
5 the session for later analysis:
6
7 do rpm_dump.cmm \\location\to\put\logs
8 8.1.2 Load RAM dump – rpm_load_dump.cmm

9 If rpm_dump.cmm was used to capture the state of an RPM session, it can be tedious to manually
10 restore the many dumps. Use the following script to accelerate this process:
11
12 do rpm_load_dump.cmm \\location\of\logs
13 8.1.3 Restore a crash – rpm_restore_core.cmm

14 If the RPM crashes, it is likely that it dumped its core and then moved on to some other crash
15 management code. To restore the RPM to a point that is as close as possible to the point of the
16 crash, use the following script to load the core dump:
17
18 do rpm_restore_core.cmm
19 NOTE: This script requires that memory dumps and symbols are loaded before it can be used.
20 8.1.4 Parse log – rpm_parse_faults.cmm

21 An RPM crash may be due to a software fault. If so, the core dump may include useful
22 information about the fault that occurred. Use the following script to analyze this information:
23
24 do rpm_parse_faults.cmm
25 NOTE: This script requires that memory dumps and symbols are loaded before it can be used.

RPM Debugging
1 8.1.5 Examine the preempted process – rpm_m3_unstack.cmm

2 A dead RPM may indicate that an executing process was preempted by a software fault handler or
3 interrupt. To examine the interrupted process, navigate to the top of the fault handler and run the
4 following script:
5
6 do rpm_m3_unstack.cmms
7
8 Since the core dump generally occurs at the top of the fault handler, running this script
9 immediately after rpm_restore_core.cmm will usually place you at the faulting instruction.
10 8.2 Getting the RPM log

11 The RPM has a log that is very useful for determining what has occurred on the RPM. This is the
12 primary source of debugging reset and hang problems and can also be useful for looking at
13 performance issues.
14 8.2.1 Using T32

15 While attached to the RPM in the Break state, run the following commands in T32:
16
17 do rpm_proc\core\power\ulog\scripts\ULogDump.cmm <path to your directory>

18 do rpm_proc\core\power\npa\scripts\NPADump.cmm <path to your directory>
19
20 This places the RPM external log and the NPA log, which only contains dump information, into
21 the log directory. The RPM external log requires use of a parsing tool to interpret. To run the
22 ROM external log, run the following command from the log directory:
23
24 python rpm_proc\core\power\rpm\debug\scripts\rpm_log_bfam.py -f “RPM

25 External Log.ulog” -n “NPA Log.ulog” > rpm_parsed.txt
26
27 Additional switches are –r, which print raw (hex sclk value) timestamps.

1 9 Software Events
2 Software events are used to replace RPM log events in RPM.AF. Table 9-1 lists how to add the
3 software event entry.
4 9.1 RPM SWEvent range table

5 Table 9-1 reflects the enumeration in core/api/debugtrace/tracer_event_ids.h.
6 Table 9-1 Software event entry

ID range Tech area
0 RESERVED
1 to 63 DDR
64 to 191 BUS
192 to 319 RPM
320 to 383 SLEEP
384 to 511 CLOCK
512 to 639 PMIC
640 to 649 OCMEM
650 to 669 RAILWAY
670 to 1023 RESERVED

Software Events
1 9.2 Adding RPM SWEvents
2 9.2.1 Add new SWEvent to tech area SConscript

3 Add the new SWEvent to the bottom of the list of SWEvents in the SConscript, but before the last
4 event. The format is ['NEW_SWEVENT', 'description of new software event: param1 %d'].
5 An example of adding RPM_MASTER_SET_TRANSITION_COMPLETE to
6 core/power/rpm/build/Sconscript is:
7
8 if 'USES_QDSS_SWE' in env:
9 QDSS_IMG = ['QDSS_EN_IMG']
10 events = [['RPM_BOOT_STARTED=192','rpm boot started'],
11 ['RPM_BOOT_FINISHED','rpm boot finished'],
12 ['RPM_BRINGUP_REQ','rpm_bringup_req: (master %d) (core %d)'],
13 ['RPM_BRINGUP_ACK','rpm_bringup_ack: (master %d) (core %d)'],
14 ['RPM_SHUTDOWN_REQ','rpm_shutdown_req: (master %d) (core %d)'],
15 ['RPM_SHUTDOWN_ACK','rpm_shutdown_ack: (master %d) (core %d)'],
16 ['RPM_TRANSITION_QUEUED','rpm_transition_queued: (master %d) (status
17 %d) (deadline: %d)'],
18 ['RPM_MASTER_SET_TRANSITION','rpm_master_set_transition: (master %d)
19 (fromSet %d) (toSet: %d)'],
20 ['RPM_MASTER_SET_TRANSITION_COMPLETE','rpm_set_transition_complete:
21 (master %d)'],
22 ['RPM_LAST=319','rpm last placeholder'],
23 ]
24 env.AddSWEInfo(QDSS_IMG, events)
25
26 9.2.2 Add SWEVENT calls for new SConscript

27 Include swevent.h and make calls of the form SWEVENT(<enum>, params...).
28 For example:
29
30 #include "swevent.h"
31 ...
32 SWEVENT(RPM_MASTER_SET_TRANSITION_COMPLETE, master_id);

Software Events
1 9.2.3 Add SWEVENT RAM post-parsing

2 1. Add parsing details to core/power/rpm/debug/scripts/<tech area>_parser.py.
3 2. ID is a hex value which matches the swevent ID.
4 RPM_MASTER_SET_TRANSITION_COMPLETE = 200 = 0xc8.
5 3. The class should return a string describing the SWEvent.
6 4. Data is parseable with various functions, described in core/power/rpm/debug/scripts/
7 target_data.py.
8 An example of adding a parsing class for RPM_MASTER_SET_TRANSITION_COMPLETE is:
9
10 class RPMTransitionComplete:
11 __metaclass__ = Parser
12 id = 0xC8
13 def parse(self, data):
14 return 'rpm_master_set_transition_complete (master: %s)' %
15 get_master_name(data[0])
16

1 10 RPM Master User Guide
2 10.1 Active mode usage

3 Assuming CXO = (clock, 0), to turn it on right now, submit the following Active mode RPM
4 driver request:
5
6 rpm_sync_request(RPM_ACTIVE_SET, RPM_CLOCK_REQ, 0, cxo_request);

7
8 RPM_CLOCK_REQ is a clk string. cxo_request is the KVP buffer constructed as described in

9 Section 5.4.2.
10 The function call above sends a request in Blocking mode. To asynchronously post a message,
11 e.g., because you have multiple messages to send and only want to wait on the last one, exchange
12 the call for a call to rpm_post_request.
13 rpm_post_request returns a message ID. Message IDs uniquely identify the changes that your
14 post request generated to the RPM. Sometimes the message ID can be 0. This may happen when
15 the request was redundant, e.g., the RPM already has that request, or deferred, i.e., some sets, like
16 the sleep set, are not generally synchronized until idle time.
17 To send asynchronously for just a while, and later “join” with your message, call the API
18 rpm_barrier(<message ID>) with the ID returned by rpm_post_request; this API can be used to
19 subsequently wait for the completion of that message (and all preceding messages).
20 To chain multiple messages and wait for them all to complete, use the following idiom:
21
22 unsigned last_id = 0, id;

23 id = rpm_post_request(...);
24 last_id = id ? id : last_id;
29 rpm_barrier(last_id);
30
31 This sequence invokes three RPM requests and then waits for all three to complete. It is robust to
32 the 0 return cases and guarantees that all of the requests have completed, regardless of set request
33 or redundance.

RPM Master User Guide
1 10.2 Sleep mode usage
2 10.2.1 RPM.AF→RPM.BF RPM sleep interaction differences

3 A very important difference in the RPM protocol between RPM.AF and RPM.BF families that
4 significantly affects the optimal usage of the RPM messaging channel is that the RPM now
5 allows multiple messages in flight at a time. It might be able to do some synchronization of the
6 sleep set in advance. The strategy for doing this is not obvious and may vary by processor, but
7 this could include (and is certainly not limited to):
8  Detecting a use case change and presynchronizing new sleep set resources
9  Speculatively preupdating the sleep set based on sleep set usage patterns or other activity
10 occurring on the processor
11  Doing absolutely nothing different than on RPM.AF when standard sleep set caching already
12 results in 0 RPM traffic for nearly all sleep set needs
13 Further, the biggest, largest, and most salient point in all of these discussions is that the limitation
14 on RPM.AF where we strictly enforced that masters must wait until the entire sleep set has been
15 acknowledged before entering into an SPM-RPM handshake has been lifted. This should allow
16 masters to “blast” sleep sets into the RPM and go directly to sleep, minimizing the amount of
17 energy spent in the idle task doing no useful work, i.e., we are trying to achieve RPM processing
18 of any changes to the sleep set in parallel with other expensive power-collapse work, e.g.,
19 flushing caches, etc. We already achieved many gains in this category by enabling sleep set
20 caching on RPM.AF, but this change should further those advances, continuing to make the
21 latency of the RPM handshake LPR smaller and (perhaps more importantly) less variable.
22 At a high level, the normal flow for master processor sleep with RPM has changed from
23 RPM.AF:
24 1. Send sleep set
25 2. Poll for response
26 3. Send next active set and poll for response
27 4. Wi-Fi/handshake
28 5. Force send next active set and wait for response
29 To the faster and more efficient:
30 1. Send sleep set
31 2. Send next active set
32 3. Disable ack interrupt
33 4. Wi-Fi/handshake
34 5. Enable ack interrupt
35 6. If <last next active set msg_id> is nonzero:
36 a. Set the SMDLite signal SMDL_SIG_RI
37 b. rpm_churn_queue(<last next active set msg_id>)
38 c. Clear the SMDLite signal SMDL_SIG_RI

RPM Master User Guide
1 This covers all four interesting combinations of sleep success and next active set usage:
2 1. If there was no next active set request, the last ID is 0; regardless of whether the WFI was
3 successful, we return immediately.
4  If the WFI was not successful, the RPM continues acknowledging the sleep set requests.
5 These acks are processed concurrently with the reason for wakeup so that when sleep
6 does occur next, we should have already reset the RPM status (and, with luck, the sleep
7 set will already be in sync for the next sleep).
8  If the WFI was successful, the acks for all sleep messages will already have been
9 received; the SMD ISR runs once after wakeup to clear out the SMD FIFO. These acks
10 could potentially be processed from sleep context if you save the last sleep msg_id and
11 call churn_queue with the most recent (sleep OR next_active_set) ID. However, if it
12 blocks in sleep context to do this, it can delay processing on whatever wakeup interrupt
13 was received and pass up possible (or, on the Hexagon™, likely) parallelism in
14 processing the wakeup interrupt/sleep acks at the same time.
15 2. If there was a next active set message and the WFI failed:
16  Setting SIG_RI instructs the RPM to process the next active set requests now, rather than
17 waiting for a processor sleep event. (Normally, NAS requests are not touched by the
18 RPM until the master processor goes to sleep.)
19  rpm_churn_queue runs a polling loop waiting for RPM acknowledgement of all next
20 active set requests.
21 3. If there was a next active set message and the WFI succeeded:
22  Setting SIG_RI has no effect on the RPM (all of the outstanding NAS requests will have
23 been handled at the time of the sleep handshake).
24  rpm_churn_queue clears the SMD FIFO of all the existing next active set messages.


Resource Power Manager (RPM - BF) : User Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Resource Power Manager (RPM - BF) : User Guide

Uploaded by

Copyright:

Available Formats

Resource Power Manager (RPM.

Submit technical questions at:

Confidential and Proprietary – Qualcomm Technologies, Inc.

Qualcomm Technologies, Inc.

© 2012-2014 Qualcomm Technologies, Inc.

2 RPM Overview .................................................................................................. 8

3 RPM Build Instructions ................................................................................. 14

4 RPM Scheduling ............................................................................................ 15

80-NA157-15 E 2 Confidential and Proprietary – Qualcomm Technologies, Inc.

5 RPM Messaging ............................................................................................. 24

6 RPM Railway .................................................................................................. 28

7 RPM RBCPR ................................................................................................... 31

8 RPM Debugging ............................................................................................. 38

80-NA157-15 E 3 Confidential and Proprietary – Qualcomm Technologies, Inc.

9 Software Events ............................................................................................. 40

10 RPM Master User Guide .............................................................................. 43

80-NA157-15 E 4 Confidential and Proprietary – Qualcomm Technologies, Inc.

80-NA157-15 E 5 Confidential and Proprietary – Qualcomm Technologies, Inc.

Revision Date Description

80-NA157-15 E 6 Confidential and Proprietary – Qualcomm Technologies, Inc.

15 Table 1-1 Reference documents and standards

17 1.5 Technical assistance

80-NA157-15 E 7 Confidential and Proprietary – Qualcomm Technologies, Inc.

2 2.1 Hardware overview

5 Figure 2-1 RPM example block diagram

6 2.1.1 RPM processor

80-NA157-15 E 8 Confidential and Proprietary – Qualcomm Technologies, Inc.

13 2.1.3 Boot ROM

20 2.1.4 Code RAM

25 2.1.5 Data/log RAM

80-NA157-15 E 9 Confidential and Proprietary – Qualcomm Technologies, Inc.

1 2.1.6 Message RAM

4 Table 2-1 Example RPM messaging masters

Messaging masters  APSS (Krait)  APSS (A5)  APSS

5 2.1.7 Interrupt controller

80-NA157-15 E 10 Confidential and Proprietary – Qualcomm Technologies, Inc.

1 2.2 RPM software overview

Master 1 Master 2 Master 3 Master N

CLK DDR PMIC BUS MPM

KERNAL (DALSYS Native)

Master 1 Master 1 Master N Master N

4 Figure 2-2 RPM software topology

80-NA157-15 E 11 Confidential and Proprietary – Qualcomm Technologies, Inc.

1 2.2.2 RPM handler

17 2.2.3.2 Clock driver

22 2.2.3.3 Bus arbitration driver

32 2.2.3.4 PMIC driver

80-NA157-15 E 12 Confidential and Proprietary – Qualcomm Technologies, Inc.

1 2.2.3.5 WDOG driver

14 2.2.3.6 MPM driver

80-NA157-15 E 13 Confidential and Proprietary – Qualcomm Technologies, Inc.

80-NA157-15 E 14 Confidential and Proprietary – Qualcomm Technologies, Inc.

7 const char *get_name() const;

9  Get task priority:

11 uint8_t get_priority() const;

13  Set the deadline by which the execution should complete:

15 void set_deadline(uint64_t deadline);

17  Get the deadline by which the execution should complete:

19 bool get_deadline(uint64_t& deadline) const;

21  Get the estimate of how long this task takes to execute:

23 virtual uint64_t get_length() const = 0;

27 uint64_t get_start() const;

31 void set_start(uint64_t start_time);