What is latency budget in dynamic sleep?

In dynamic sleep scheme, sleep solver chooses the best low power modes from a pool of enabled low power modes to enter under a few system constraints. These constraints are:
(1) Sleep duration.
(2) Latency budget

The sleep duration is how long the subsystem can stay in the sleep state. The latency budget is how fast the subsystem needs to come out of sleep state to handle a system event. Basically, it is the interrupt latency the system can tolerate. This puts constraint on the total warmup time of the chosen low power modes. For instance, if the latency budget is 0x1, i.e. 1 sleep clock tick ~ 30us, this generally will disable XO shutdown or VDD min because either of these modes requires warmup time much longer than 30us. In other words, if system goes into XO shutdown, it will not be able to recover fast enough to satisfy the 30us latency requirement.

The latency budget is obtained by querying the sleep_latency_node, which is a NPA node.

/* Get the latency budget from the latency node. The latency node will
* return the minimum latency budget being requested by all clients.
* This lets us know how quickly we need to respond to an interrupt when
* it occurs. */
CORE_VERIFY( NPA_QUERY_SUCCESS == npa_query( gSleepLatencyNode,
NPA_QUERY_CURRENT_STATE,
&qres ) );

Software modules can register to the latency node and request for latency budget. This information is shown in the NPA dump, and logged in sleep info ulog. Here is an example of NPA dump that shows HKADC has a latency requirement of 1.

: npa_resource (name: "/core/cpu/latency") (handle: 0x90103260) (units: sclk) (resource max: 4294967295) (active max: 4294967295) (active state 1) (active headroom: 2) (request state: 1)
: npa_client (name: GPS_CPU_LATENCY_CLIENT) (handle: 0x9018B7F4) (resource: 0x90103260) (type: NPA_CLIENT_REQUIRED 0x40) (request: 0)
: npa_client (name: GSM_LATENCY) (handle: 0x90172DE4) (resource: 0x90103260) (type: NPA_CLIENT_REQUIRED 0x40) (request: 0)
: npa_client (name: HKADC) (handle: 0x9013FF24) (resource: 0x90103260) (type: NPA_CLIENT_REQUIRED 0x40) (request: 1)
: end npa_resource (handle: 0x90103260)
: npa_resource (name: "/core/cpu/wakeup") (handle: 0x901032AC) (units: sclk) (resource max: 4294967295) (active max: 4294967295) (active state 0) (active headroom: 0) (request state: 0)
: end npa_resource (handle: 0x901032AC)

As a result, the latency budget logged in solver constraints of sleep info ulog is 0x1.

0xF9AB62A3: Solver constraints (hard duration: 0x0000003C) (soft duration: 0xFFFFFFFF) (latency budget: 0x00000001)

Since latency budget affect low power operation,

I2C Power collapse issue in android build

Problem: The modem side processor keeps spinning for the spinlock acquired by the apps side processor for an I2C transaction when the apps side processor is power collapsed.



Solution:

As a solution to this, wakelocks can be used. "Wakelock" is a mechanism which can prevent the system from going into a low-power state.



To prevent the above mentioned problem, the I2C driver at the apps side grabs a wakelock at the beginning of the I2C transaction (inside the msm_i2c_xfer() and then releases it at the end of the transaction. With this, the power collapse is delayed for the time the wakelock is held by the i2c driver i.e. till the spinlock held by the apps side processor is released, and the released spinlock can, then, be used by the modem side processor.



To setup a wakelock in the kernel space:

#include <linux/wakelock.h>

wake_lock_init(struct wake_lock *lock, int type, const char *name)

where,

name: name of the lock

type: kind of wakelock



The two types are : WAKE_LOCK_SUSPEND : prevents the system from suspending

WAKE_LOCK_IDLE: prevents going into a low_power idle state



Following are the APIs to handle this lock:



void wake_lock(struct wake_lock *lock);

void wake_lock_timeout(struct wake_lock *lock, long timeout);

void wake_unlock(struct wake_lock *lock);



Note: pm_qos() is not intended to influence the suspend power collapse. It influences the idle power collapse. Thus, pm_qos() should not be used in the above mentioned scenario.

Andoird Platform doesn't go to suspend when BT is on

On LE build or Android build, some of BT chip (not one from Qualcomm) prevents system from getting into suspend. Reason for that could be continuous sending data to MSM or QSD over UART or clock enablement and wake lock holding. To work around this without changing BT solution, platform suspend and resume can be implemented within HSUART driver.


static int msm_hs_suspend(struct platform_device *pdev)
{
struct msm_hs_port *msm_uport;
struct uart_port *uport;


msm_uport = &q_uart_port[pdev->id];
uport = msm_uport->uport;


clk_disable(msm_uport->clk);
msm_uport->clk_state = MSM_HS_CLK_OFF;


disable_irq_wake(uport->irq);
wake_unlock(&rx->wake_lock);


return 0;
}


static int msm_hs_resume(struct platform_device *pdev)
{
struct msm_hs_port *msm_uport;
struct uart_port *uport;


msm_uport = &q_uart_port[pdev->id];
uport = msm_uport->uport;


enable_irq_wake(uport->irq);
msm_hs_request_clock_on(uport);


return 0;
}


This can be applied to 2.6.27 kernel and 2.6.29 kernel for LE and Android build.

How to make the device able to sleep when usb cable is connected with PC

Only if usb in suspend status, device can sleep with usb cable connected

In sleep task, it will check votes from usb, if usb does not allow to turn off TXCO, the device can not go to deep sleep.
When the usb cable connect to PC, usb task will not vote for deep sleep unless the usb core go to suspend status.

There are some scenarios that the usb core can get suspend event:
1. The host remove the usb device in device manager.
2. The host disable the driver of the usb device
3. The host go to standby mode
4. The host enable selective suspension and there is no activity on usb bus after the set timeout value.

In AMSS, the usb code can get a interrupt for suspend if the scenario happen.
please see 80-v4609-1 about enable selective suspension in Windows.

About RRC Deep Sleep Optimization timers

Question :- What are RRC Deep sleep optimization timers available in the AMSS code and their use?



Answer :- UE uses Deep Sleep optimization timers RRCTMR_FREQ_SCAN_TIMER and RRCTMR_DEEP_SLEEP_NO_SVC_TIMER, when it enters deep sleep as part of OOS(Out of Service).



Detail:- RRCTMR_FREQ_SCAN_TIMER : If UE is in deep sleep and performed RRC_MAX_FULL_SCANS_IN_DEEP_SLEEP (i.e 3 as per the current code) number of full frequency scans on all supported bands and it didn't find any cell, it starts full scan timer ( For 30sec as per the current code) during which it only performs ACQ-DB scan and full scan only on bands which are not present in the ACQ-DB. This optimization is not followed if ACQ-DB is empty.


RRC_MAX_FULL_SCANS_IN_DEEP_SLEEP (3 as per the current code) :- This counter defines the max number of attempts for which full frequency scan should be done after UE enters deep sleep. Full Scan timer is started after these number of full scan attempts are completed.



RRCTMR_DEEP_SLEEP_NO_SVC_TIMER (10s as per the current code) :- If UE is in deep sleep and available plmn list is empty during service search, then UE starts a timer RRCTMR_DEEP_SLEEP_NO_SVC_TIMER (i.e no_svc_timer, 10sec), so that if RRC receives a RRC_SERVICE_REQ from NAS before this timer expires then return immediately RRC_SERVICE_CNF with no service.

MSM7x30 BL/LCD Power Measurement Procedure

1. In order to measure LCD and BL on Spartanized FFA, need SW and HW tools: UDAS application, Spartan station, SIC3 card or LowRider card, shorting blocks.
2. Follow the video test precedure ans select the folling power grid (as below) from UDAS channel list and do the measurement.
3. On 7x30 LPDDR1 Spartanized FFA: Total BL/LCD = 156mA.
SET1-2D:MEdia_1E_MDDI=25.72mA
SET1-7C:LCD_3d05V=8.93mA
SET2-0C:Media_VDDS_MDDI_LCD=8.35mA
SET2-6D:Media_eDRAM_VDD2E=2.54mA
SET2-4A:KYPD_BL=0mA
SET2-5D:LCD_BL=110.14mA