OMAP: PM: implement devices wakeup latency constraints APIs
Subsystems (5)
cover OMAP: PM: implement devices wakeup latency constraints APIs
Implement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to set and release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
The power domains get the next power state programmed directly in the registers via pwrdm_wakeuplat_update_pwrst.
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Jean Pihet (2):
OMAP PM: create a PM layer plugin for the devices wakeup latency
constraints
OMAP: PM: implement devices wakeup latency constraints APIs
arch/arm/mach-omap2/omap_hwmod.c | 62 +++++- arch/arm/mach-omap2/powerdomain.c | 197 ++++++++++++++ arch/arm/mach-omap2/powerdomain.h | 39 +++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 60 ++++ arch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/include/plat/omap_device.h | 2 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + arch/arm/plat-omap/omap-pm-constraints.c | 358 +++++++++++++++++++++++++ arch/arm/plat-omap/omap_device.c | 28 ++ 10 files changed, 754 insertions(+), 2 deletions(-) create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
Signature · 1 line
1.7.2.3
PATCH 1/2 OMAP PM: create a PM layer plugin for the devices wakeup latency constraints
Created arch/arm/plat-omap/omap-pm-constraints.c file from arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option OMAP_PM_CONSTRAINTS.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
---
Based on khilman's pm-core branch
arch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/omap-pm-constraints.c | 363 ++++++++++++++++++++++++++++++ 3 files changed, 371 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/omap-pm-constraints.c
arch/arm/plat-omap/Kconfig +7 -0
@@ -215,6 +215,13 @@ config OMAP_PM_NONE config OMAP_PM_NOOP bool "No-op/debug PM layer" +config OMAP_PM_CONSTRAINTS + depends on PM + bool "OMAP PM layer implementation, devices wakeup latency constraints" + help + Select this option to enable the PM layer plugin for + the devices wakeup latency constraints support + endchoice endmenu
arch/arm/plat-omap/Makefile +1 -0
@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o +obj-$(CONFIG_OMAP_PM_CONSTRAINTS) += omap-pm-constraints.o
arch/arm/plat-omap/omap-pm-constraints.c new file +363 -0
363 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 1/2 OMAP PM: create a PM layer plugin for the devices wakeup latency constraints
Quoted 24 lines · Jean Pihet
Created
arch/arm/plat-omap/omap-pm-constraints.cfile fromarch/arm/plat-omap/omap-pm-noop.cand the associatedKconfigoptionOMAP_PM_CONSTRAINTS.Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/Cc Vishwanath BS <[email protected]>Signed-off-by Jean Pihet <[email protected]>---
Based on khilman's pm-core brancharch/arm/plat-omap/Kconfig | 7 + arch/arm/plat-omap/Makefile | 1 + arch/arm/plat-omap/omap-pm-constraints.c | 363 ++++++++++++++++++++++++++++++ 3 files changed, 371 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-omap/omap-pm-constraints.carch/arm/plat-omap/Kconfig +0
-0
arch/arm/plat-omap/Kconfig config OMAP_PM_NONE · line 220
Quoted 6 lines
arch/arm/plat-omap/Kconfig +3
-0@@ -215,6 +215,13 @@ config OMAP_PM_NONE config OMAP_PM_NOOP bool "No-op/debug PM layer" +config OMAP_PM_CONSTRAINTS + depends on PM + bool "OMAP PM layer implementation, devices wakeup latency constraints"
Minor: The 'OMAP PM layer implmentatin' is redundant here as it's a sub-choice of the OMAP PM layer menu. How abou just "per-device constraint
Kevin
Quoted 385 lines
arch/arm/plat-omap/Kconfig +4
-0+ help + Select this option to enable the PM layer plugin for + the devices wakeup latency constraints support + endchoice endmenuarch/arm/plat-omap/Makefile +1
-0@@ -32,3 +32,4 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_OMAP_MBOX_FWK) += mailbox.o obj-$(CONFIG_OMAP_PM_NOOP) += omap-pm-noop.o +obj-$(CONFIG_OMAP_PM_CONSTRAINTS) += omap-pm-constraints.oarch/arm/plat-omap/omap-pm-constraints.c new file +363
-0@@ -0,0 +1,363 @@ +/* +* omap-pm.c - OMAP power management interface +* +* This code implements the OMAP power management interface to +* drivers, CPUIdle, CPUFreq, and DSP Bridge. +* +* Copyright (C) 2008-2009 Texas Instruments, Inc. +* Copyright (C) 2008-2009 Nokia Corporation +* Paul Walmsley +* +* Interface developed by (in alphabetical order): +* Karthik Dasu, Tony Lindgren, Jean Pihet, Rajendra Nayak, Sakari Poussa, +* Veeramanikandan Raju, Anand Sawant, Igor Stoppa, Paul Walmsley, +* Richard Woodruff +*/ + +#undef DEBUG + +#include <linux/init.h> +#include <linux/cpufreq.h> +#include <linux/device.h> +#include <linux/platform_device.h> + +/* Interface documentation is in mach/omap-pm.h */ +#include <plat/omap-pm.h> +#include <plat/omap_device.h> + +static bool off_mode_enabled; +static u32 dummy_context_loss_counter; + +/* +* Device-driver-originated constraints (via board-*.c files) +*/ + +int omap_pm_set_max_mpu_wakeup_lat (struct device *dev,long t) +{ +if (!dev || t <-1 ) { +WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + }; + +if (t ==-1 ) +pr_debug ("OMAP PM: remove max MPU wakeup latency constraint: " +"dev %s\n" ,dev_name (dev)); +else +pr_debug ("OMAP PM: add max MPU wakeup latency constraint: " +"dev %s, t = %ld usec\n" ,dev_name (dev), t); + +/* +* For current Linux, this needs to map the MPU to a +* powerdomain, then go through the list of current max lat +* constraints on the MPU and find the smallest. If +* the latency constraint has changed, the code should +* recompute the state to enter for the next powerdomain +* state. +* +* TI CDP code can call constraint_set here. +*/ + +return 0 ; +} + +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +{ +if (!dev || (agent_id !=OCP_INITIATOR_AGENT && + agent_id !=OCP_TARGET_AGENT )) { +WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + }; + +if (r ==0 ) +pr_debug ("OMAP PM: remove min bus tput constraint: " +"dev %s for agent_id %d\n" ,dev_name (dev), agent_id); +else +pr_debug ("OMAP PM: add min bus tput constraint: " +"dev %s for agent_id %d: rate %ld KiB\n" , +dev_name (dev), agent_id, r); + +/* +* This code should model the interconnect and compute the +* required clock frequency, convert that to a VDD2 OPP ID, then +* set the VDD2 OPP appropriately. +* +* TI CDP code can call constraint_set here on the VDD2 OPP. +*/ + +return 0 ; +} + +int omap_pm_set_max_dev_wakeup_lat (struct device *req_dev,struct device *dev, +long t) +{ +if (!req_dev || !dev || t <-1 ) { +WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + }; + +if (t ==-1 ) +pr_debug ("OMAP PM: remove max device latency constraint: " +"dev %s\n" ,dev_name (dev)); +else +pr_debug ("OMAP PM: add max device latency constraint: " +"dev %s, t = %ld usec\n" ,dev_name (dev), t); + +/* +* For current Linux, this needs to map the device to a +* powerdomain, then go through the list of current max lat +* constraints on that powerdomain and find the smallest. If +* the latency constraint has changed, the code should +* recompute the state to enter for the next powerdomain +* state. Conceivably, this code should also determine +* whether to actually disable the device clocks or not, +* depending on how long it takes to re-enable the clocks. +* +* TI CDP code can call constraint_set here. +*/ + +return 0 ; +} + +int omap_pm_set_max_sdma_lat (struct device *dev,long t) +{ +if (!dev || t <-1 ) { +WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + }; + +if (t ==-1 ) +pr_debug ("OMAP PM: remove max DMA latency constraint: " +"dev %s\n" ,dev_name (dev)); +else +pr_debug ("OMAP PM: add max DMA latency constraint: " +"dev %s, t = %ld usec\n" ,dev_name (dev), t); + +/* +* For current Linux PM QOS params, this code should scan the +* list of maximum CPU and DMA latencies and select the +* smallest, then set cpu_dma_latency pm_qos_param +* accordingly. +* +* For future Linux PM QOS params, with separate CPU and DMA +* latency params, this code should just set the dma_latency param. +* +* TI CDP code can call constraint_set here. +*/ + +return 0 ; +} + +int omap_pm_set_min_clk_rate (struct device *dev,struct clk *c,long r) +{ +if (!dev || !c || r <0 ) { +WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + } + +if (r ==0 ) +pr_debug ("OMAP PM: remove min clk rate constraint: " +"dev %s\n" ,dev_name (dev)); +else +pr_debug ("OMAP PM: add min clk rate constraint: " +"dev %s, rate = %ld Hz\n" ,dev_name (dev), r); + +/* +* Code in a real implementation should keep track of these +* constraints on the clock, and determine the highest minimum +* clock rate. It should iterate over each OPP and determine +* whether the OPP will result in a clock rate that would +* satisfy this constraint (and any other PM constraint in effect +* at that time). Once it finds the lowest-voltage OPP that +* meets those conditions, it should switch to it, or return +* an error if the code is not capable of doing so. +*/ + +return 0 ; +} + +/* +* DSP Bridge-specific constraints +*/ + +const struct omap_opp *omap_pm_dsp_get_opp_table (void ) +{ +pr_debug ("OMAP PM: DSP request for OPP table\n" ); + +/* +* Return DSP frequency table here: The final item in the +* array should have .rate = .opp_id = 0. +*/ + +return NULL ; +} + +void omap_pm_dsp_set_min_opp (u8 opp_id) +{ +if (opp_id ==0 ) { +WARN_ON (1 ); +return ; + } + +pr_debug ("OMAP PM: DSP requests minimum VDD1 OPP to be %d\n" , opp_id); + +/* +* +* For l-o dev tree, our VDD1 clk is keyed on OPP ID, so we +* can just test to see which is higher, the CPU's desired OPP +* ID or the DSP's desired OPP ID, and use whichever is +* highest. +* +* In CDP12.14+, the VDD1 OPP custom clock that controls the DSP +* rate is keyed on MPU speed, not the OPP ID. So we need to +* map the OPP ID to the MPU speed for use with clk_set_rate() +* if it is higher than the current OPP clock rate. +* +*/ +} + + +u8 omap_pm_dsp_get_opp (void ) +{ +pr_debug ("OMAP PM: DSP requests current DSP OPP ID\n" ); + +/* +* For l-o dev tree, call clk_get_rate() on VDD1 OPP clock +* +* CDP12.14+: +* Call clk_get_rate() on the OPP custom clock, map that to an +* OPP ID using the tables defined in board-*.c/chip-*.c files. +*/ + +return 0 ; +} + +/* +* CPUFreq-originated constraint +* +* In the future, this should be handled by custom OPP clocktype +* functions. +*/ + +struct cpufreq_frequency_table **omap_pm_cpu_get_freq_table (void ) +{ +pr_debug ("OMAP PM: CPUFreq request for frequency table\n" ); + +/* +* Return CPUFreq frequency table here: loop over +* all VDD1 clkrates, pull out the mpu_ck frequencies, build +* table +*/ + +return NULL ; +} + +void omap_pm_cpu_set_freq (unsigned long f) +{ +if (f ==0 ) { +WARN_ON (1 ); +return ; + } + +pr_debug ("OMAP PM: CPUFreq requests CPU frequency to be set to %lu\n" , + f); + +/* +* For l-o dev tree, determine whether MPU freq or DSP OPP id +* freq is higher. Find the OPP ID corresponding to the +* higher frequency. Call clk_round_rate() and clk_set_rate() +* on the OPP custom clock. +* +* CDP should just be able to set the VDD1 OPP clock rate here. +*/ +} + +unsigned long omap_pm_cpu_get_freq (void ) +{ +pr_debug ("OMAP PM: CPUFreq requests current CPU frequency\n" ); + +/* +* Call clk_get_rate() on the mpu_ck. +*/ + +return 0 ; +} + +/** +* omap_pm_enable_off_mode - notify OMAP PM that off-mode is enabled +* +* Intended for use only by OMAP PM core code to notify this layer +* that off mode has been enabled. +*/ +void omap_pm_enable_off_mode (void ) +{ + off_mode_enabled = true; +} + +/** +* omap_pm_disable_off_mode - notify OMAP PM that off-mode is disabled +* +* Intended for use only by OMAP PM core code to notify this layer +* that off mode has been disabled. +*/ +void omap_pm_disable_off_mode (void ) +{ + off_mode_enabled = false; +} + +/* +* Device context loss tracking +*/ + +#ifdef CONFIG_ARCH_OMAP2PLUS + +u32 omap_pm_get_dev_context_loss_count (struct device *dev) +{ +struct platform_device *pdev =to_platform_device (dev); +u32 count; + +if (WARN_ON (!dev)) +return 0 ; + +if (dev->parent == &omap_device_parent) { + count =omap_device_get_context_loss_count (pdev); + }else { +WARN_ONCE (off_mode_enabled,"omap_pm: using dummy context " +"loss counter; device %s should be converted to " +"omap_device" ,dev_name (dev)); +if (off_mode_enabled) + dummy_context_loss_counter++; + count = dummy_context_loss_counter; + } + +pr_debug ("OMAP PM: context loss count for dev %s = %d\n" , +dev_name (dev), count); + +return count; +} + +#else + +u32 omap_pm_get_dev_context_loss_count (struct device *dev) +{ +return dummy_context_loss_counter; +} + +#endif + +/* Should be called before clk framework init */ +int __init omap_pm_if_early_init (void ) +{ +return 0 ; +} + +/* Must be called after clock framework is initialized */ +int __init omap_pm_if_init (void ) +{ +return 0 ; +} + +void omap_pm_if_exit (void ) +{ +/* Deallocate CPUFreq frequency table here */ +} +
PATCH 2/2 OMAP: PM: implement devices wakeup latency constraints APIs
In reply to Jean PihetImplement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by creating similar APIs at the omap_device and omap_hwmod levels. The omap_hwmod level call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to set and release the constraints.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
The power domains get the next power state programmed directly in the registers via pwrdm_wakeuplat_update_pwrst.
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to omap_device, omap_hwmod and PM QOS frameworks.
---
Based on khilman's pm-core branch
arch/arm/mach-omap2/omap_hwmod.c | 62 ++++++++- arch/arm/mach-omap2/powerdomain.c | 197 +++++++++++++++++++++++++ arch/arm/mach-omap2/powerdomain.h | 39 +++++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 60 ++++++++ arch/arm/plat-omap/include/plat/omap_device.h | 2 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + arch/arm/plat-omap/omap-pm-constraints.c | 121 +++++++-------- arch/arm/plat-omap/omap_device.c | 28 ++++ 8 files changed, 446 insertions(+), 65 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +61 -1
@@ -142,6 +142,7 @@#include "powerdomain.h" #include <plat/clock.h> #include <plat/omap_hwmod.h> +#include <plat/omap_device.h> #include <plat/prcm.h> #include "cm2xxx_3xxx.h"
@@ -2267,10 +2268,69 @@ ohsps_unlock: }/** +* omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up constraint +* @oh: the device of @oh to set a constraint on. +* @req_oh: the device of @req_oh is the requester of the constraint. +* @t: wakeup latency constraint (us). -1 removes the existing constraint. +* +* Query the powerdomain of @oh to set/release the wake-up constraint. +* @oh is used to determine which power domain to set a constraint on. +* @req_oh is used to record the requester for later update or removal +* of a constraint. +* +* Returns -EINVAL if @oh or @req_oh have no power domain, or the return +* code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint) +* of the powerdomain assocated with @oh. +*/ +int omap_hwmod_set_max_dev_wakeup_lat (struct omap_hwmod *req_oh, +struct omap_hwmod *oh,long t) +{ +struct device *req_dev; +struct platform_device *req_pdev; +struct powerdomain *pwrdm; + + pwrdm =omap_hwmod_get_pwrdm (oh); + +/* Catch devices with undefined powerdomains */ +if (!PTR_ERR (pwrdm)) { +pr_err ("omap_hwmod: Error: could not find parent " +"powerdomain for %s\n" , oh->name); +return -EINVAL ; + } + + req_pdev = &(req_oh->od->pdev); +if (!PTR_ERR (req_pdev)) { +pr_err ("omap_hwmod: Error: pdev not found for oh %s\n" , + oh->name); +return -EINVAL ; + } + + req_dev = &(req_pdev->dev); +if (!PTR_ERR (req_dev)) { +pr_err ("omap_hwmod: Error: device not found for oh %s\n" , + oh->name); +return -EINVAL ; + } + +/* Call set/release_constraint for the given pwrdm */ +if (t ==-1 ) { +pr_debug ("omap_hwmod: remove max device latency constraint: " +"oh %s, pwrdm %s, req by oh %s\n" , + oh->name, pwrdm->name, req_oh->name); + }else { +pr_debug ("omap_hwmod: add max device latency constraint: " +"oh %s, t = %ld usec, pwrdm %s, req by oh %s\n" , + oh->name, t, pwrdm->name, req_oh->name); + } + +return pwrdm_wakeuplat_set_constraint (pwrdm, req_dev, t); +} + +/** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss +* Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh
arch/arm/mach-omap2/powerdomain.c +197 -0
221 lines not on this page · raw message
arch/arm/mach-omap2/powerdomain.h +38 -1
@@ -19,7 +19,10 @@#include <linux/types.h> #include <linux/list.h> - +#include <linux/plist.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/pm_qos_params.h> #include <linux/atomic.h> #include <plat/cpu.h>
@@ -46,6 +49,15 @@#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON)) +/* Powerdomain functional power states */ +#define PWRDM_FUNC_PWRST_OFF 0x0 +#define PWRDM_FUNC_PWRST_OSWR 0x1 +#define PWRDM_FUNC_PWRST_CSWR 0x2 +#define PWRDM_FUNC_PWRST_ON 0x3 + +#define PWRDM_MAX_FUNC_PWRSTS 4 + +#define UNSUP_STATE -1/* Powerdomain flags */ #define PWRDM_HAS_HDWR_SAR (1 << 0)/* hardware save-and-restore support */
@@ -96,6 +108,12 @@ struct powerdomain;* @state_counter: * @timer: * @state_timer: +* @wakeup_lat: wakeup latencies for possible powerdomain power states +* Note about the wakeup latencies ordering: the values must be sorted +* in decremental order +* @wakeuplat_lock: spinlock for plist +* @wakeuplat_dev_list: plist_head linking all devices placing constraint +* @wakeuplat_mutex: mutex to protect per powerdomain list ops * * @prcm_partition possible values are defined in mach-omap2/prcm44xx.h. */
@@ -121,6 +139,22 @@ struct powerdomain {s64 timer;s64 state_timer[PWRDM_MAX_PWRSTS ];#endif +const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS ]; +spinlock_t wakeuplat_lock; +struct plist_head wakeuplat_dev_list; +struct mutex wakeuplat_mutex; +}; + +/* +* Linked list for the power domains wakeup latencies constraints +* The PM QOS handle is only used to control the MPU and CORE power +* domains states; to be removed when a generic solution is in place. +*/ +struct wakeuplat_dev_list { +struct device *dev; +unsigned long constraint_us; +struct plist_node node; +struct pm_qos_request_list pm_qos_request; };/**
@@ -210,6 +244,9 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);int pwrdm_pre_transition (void );int pwrdm_post_transition (void );int pwrdm_set_lowpwrstchange (struct powerdomain *pwrdm); + +int pwrdm_wakeuplat_set_constraint (struct powerdomain *pwrdm, +struct device *req_dev,long t);u32 pwrdm_get_context_loss_count (struct powerdomain *pwrdm);extern void omap2xxx_powerdomains_init (void );
arch/arm/mach-omap2/powerdomains3xxx_data.c +60 -0
120 lines not on this page · raw message
arch/arm/plat-omap/include/plat/omap_device.h +2 -0
@@ -107,6 +107,8 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);int omap_device_align_pm_lat (struct platform_device *pdev,u32 new_wakeup_lat_limit);struct powerdomain *omap_device_get_pwrdm (struct omap_device *od); +int omap_device_set_max_dev_wakeup_lat (struct platform_device *req_pdev, +struct platform_device *pdev,long t);u32 omap_device_get_context_loss_count (struct platform_device *pdev);/* Other */
arch/arm/plat-omap/include/plat/omap_hwmod.h +2 -0
@@ -595,6 +595,8 @@ int omap_hwmod_for_each_by_class(const char *classname, void *user);int omap_hwmod_set_postsetup_state (struct omap_hwmod *oh,u8 state); +int omap_hwmod_set_max_dev_wakeup_lat (struct omap_hwmod *req_oh, +struct omap_hwmod *oh,long t);u32 omap_hwmod_get_context_loss_count (struct omap_hwmod *oh);/*
arch/arm/plat-omap/omap-pm-constraints.c +58 -63
162 lines not on this page · raw message
arch/arm/plat-omap/omap_device.c +28 -0
@@ -296,6 +296,34 @@ static void _add_optional_clock_clkdev(struct omap_device *od,/* Public functions for use by core code */ /** +* omap_device_set_max_dev_wakeup_lat - set/release a device constraint +* @od: struct omap_device * +* @req_od: struct omap_device * +* +* Using the primary hwmod, set/release a device constraint for the pdev +* device, requested by the req_pdev device. +* +* If any hwmods exist for the omap_device assoiated with @pdev and @req_pdev, +* set/release the constraint for the corresponding hwmods, otherwise return +* -EINVAL. +*/ +int omap_device_set_max_dev_wakeup_lat (struct platform_device *req_pdev, +struct platform_device *pdev,long t) +{ +struct omap_device *od, *req_od; +u32 ret = -EINVAL ; + + od =_find_by_pdev (pdev); + req_od =_find_by_pdev (req_pdev); + +if ((od->hwmods_cnt) && (req_od->hwmods_cnt)) + ret =omap_hwmod_set_max_dev_wakeup_lat (req_od->hwmods[0 ], + od->hwmods[0 ], t); + +return ret; +} + +/** * omap_device_get_context_loss_count - get lost context count * @od: struct omap_device * *
Signature · 1 line
1.7.2.3
PATCH 2/2 OMAP: PM: implement devices wakeup latency constraints APIs
Quoted 15 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating similar APIs at theomap_deviceandomap_hwmodlevels. Theomap_hwmodlevel call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to set and release the constraints.NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
The power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.
Quoted 7 lines
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.
I haven't got to a detailed review of this code yet, but did do some experiements and have some general comments on the code/design to get started.
Also, I had a problem doing a real dumb test until I figured out the problem with the init sequence. I tried setting a constraint in the device init code for UART (mach-omap2/serial.c:omap_serial_init_port()), and then I realized that that runs before mach-omap2/pm34xx.c:pwrdms_setup() which also calls omap_set_pwrdm_state() for each powerdomain to initialize.
Also, for debug purposes, it might be useful to have a per-device sysfs interface to setting this wakeup latency constraint. Something like
/sys/devices/platform/omap/.../power/wakeup_latency
I'm not sure exactly what to set the requesting device to though.
As far as implementation goes, you've so far implemented only wakeup latencies, but not througput. When you implement throughput you will have to duplicate large parts of this code and data structures for throughput, and if ever add some other constraint (frequency, voltage) it would need to be duplicated again.
Maybe now is the time to consider an interface to add a generic per-device constraint, with a type (latency, throughput, etc.), or "class" as it's called in PM QoS. For now the type/class does not need to be exposed externally, but will make implementing new constraint types much easer.
Some other comments below...
Quoted 157 lines
Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>---
Based on khilman's pm-core brancharch/arm/mach-omap2/omap_hwmod.c | 62 ++++++++- arch/arm/mach-omap2/powerdomain.c | 197 +++++++++++++++++++++++++ arch/arm/mach-omap2/powerdomain.h | 39 +++++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 60 ++++++++ arch/arm/plat-omap/include/plat/omap_device.h | 2 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 + arch/arm/plat-omap/omap-pm-constraints.c | 121 +++++++-------- arch/arm/plat-omap/omap_device.c | 28 ++++ 8 files changed, 446 insertions(+), 65 deletions(-)arch/arm/mach-omap2/omap_hwmod.c +61
-1@@ -142,6 +142,7 @@#include "powerdomain.h" #include <plat/clock.h> #include <plat/omap_hwmod.h> +#include <plat/omap_device.h> #include <plat/prcm.h> #include "cm2xxx_3xxx.h" @@ -2267,10 +2268,69 @@ ohsps_unlock: }/** +* omap_hwmod_set_max_dev_wakeup_lat - set a device wake-up constraint +* @oh: the device of @oh to set a constraint on. +* @req_oh: the device of @req_oh is the requester of the constraint. +* @t: wakeup latency constraint (us). -1 removes the existing constraint. +* +* Query the powerdomain of @oh to set/release the wake-up constraint. +* @oh is used to determine which power domain to set a constraint on. +* @req_oh is used to record the requester for later update or removal +* of a constraint. +* +* Returns -EINVAL if @oh or @req_oh have no power domain, or the return +* code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint) +* of the powerdomain assocated with @oh. +*/ +int omap_hwmod_set_max_dev_wakeup_lat (struct omap_hwmod *req_oh, +struct omap_hwmod *oh,long t) +{ +struct device *req_dev; +struct platform_device *req_pdev; +struct powerdomain *pwrdm; + + pwrdm =omap_hwmod_get_pwrdm (oh); + +/* Catch devices with undefined powerdomains */ +if (!PTR_ERR (pwrdm)) { +pr_err ("omap_hwmod: Error: could not find parent " +"powerdomain for %s\n" , oh->name); +return -EINVAL ; + } + + req_pdev = &(req_oh->od->pdev); +if (!PTR_ERR (req_pdev)) { +pr_err ("omap_hwmod: Error: pdev not found for oh %s\n" , + oh->name); +return -EINVAL ; + } + + req_dev = &(req_pdev->dev); +if (!PTR_ERR (req_dev)) { +pr_err ("omap_hwmod: Error: device not found for oh %s\n" , + oh->name); +return -EINVAL ; + } + +/* Call set/release_constraint for the given pwrdm */ +if (t ==-1 ) { +pr_debug ("omap_hwmod: remove max device latency constraint: " +"oh %s, pwrdm %s, req by oh %s\n" , + oh->name, pwrdm->name, req_oh->name); + }else { +pr_debug ("omap_hwmod: add max device latency constraint: " +"oh %s, t = %ld usec, pwrdm %s, req by oh %s\n" , + oh->name, t, pwrdm->name, req_oh->name); + } + +return pwrdm_wakeuplat_set_constraint (pwrdm, req_dev, t); +} + +/** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss +* Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh arch/arm/mach-omap2/powerdomain.c +37
-0@@ -19,6 +19,8 @@#include <linux/list.h> #include <linux/errno.h> #include <linux/string.h> +#include <linux/slab.h> +#include "cm2xxx_3xxx.h" #include "prcm44xx.h" #include "cm44xx.h" @@ -103,6 +105,13 @@ static int _pwrdm_register(struct powerdomain *pwrdm) pwrdm->state =pwrdm_read_pwrst (pwrdm); pwrdm->state_counter[pwrdm->state] =1 ; +/* Initialize priority ordered list for wakeup latency constraint */ +spin_lock_init (&pwrdm->wakeuplat_lock); +plist_head_init (&pwrdm->wakeuplat_dev_list, &pwrdm->wakeuplat_lock); + +/* res_mutex protects res_list add and del ops */ +mutex_init (&pwrdm->wakeuplat_mutex); +pr_debug ("powerdomain: registered %s\n" , pwrdm->name);return 0 ;@@ -176,6 +185,74 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused)return 0 ; } +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* +* Finds the minimum allowed wake-up latency value from all entries +* in the list and the power domain power state needing the constraint. +* Programs a new target state if it is different from current power state. +* +* Only OMAP3xxx is supported for now +* +* Returns 0 upon success. +*/ +static int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm) +{ +struct plist_node *node; +int ret =0 , new_state; +long min_latency =-1 ; + +/* Find the strongest constraint from the plist */ +if (!plist_head_empty (&pwrdm->wakeuplat_dev_list)) { + node =plist_first (&pwrdm->wakeuplat_dev_list); + min_latency = node->prio; + } + +/* Find power state with wakeup latency < minimum constraint. */ +for (new_state =0x0 ; new_state <PWRDM_MAX_PWRSTS ; new_state++) { +if (min_latency ==-1 || + pwrdm->wakeup_lat[new_state] <= min_latency)
arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 225
Quoted 10 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+break ; + } + +switch (new_state) { +case PWRDM_FUNC_PWRST_OFF : + new_state =PWRDM_POWER_OFF ; +break ; +case PWRDM_FUNC_PWRST_OSWR : +if (cpu_is_omap34xx ()) +pwrdm_set_logic_retst (pwrdm,PWRDM_POWER_OFF );
cpu_is_* checks here aren't right.
You should use SoC specific function pointers as are done for many of the other powerdomain calls after Rajendra's splitup series.
Quoted 30 lines
arch/arm/mach-omap2/powerdomain.c +30
-0+ new_state =PWRDM_POWER_RET ; +break ; +case PWRDM_FUNC_PWRST_CSWR : +if (cpu_is_omap34xx ()) +pwrdm_set_logic_retst (pwrdm,PWRDM_POWER_RET ); + new_state =PWRDM_POWER_RET ; +break ; +case PWRDM_FUNC_PWRST_ON : + new_state =PWRDM_POWER_ON ; +break ; +default : +pr_warn ("powerdomain: requested latency constraint not " +"supported %s set to ON state\n" , pwrdm->name); + new_state =PWRDM_POWER_ON ; +break ; + } + +if (pwrdm_read_pwrst (pwrdm) != new_state) { +if (cpu_is_omap34xx ()) + ret =omap_set_pwrdm_state (pwrdm, new_state); + } + +pr_debug ("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " +"min_latency=%ld, set_state=%d\n" , pwrdm->name, +pwrdm_read_pwrst (pwrdm),pwrdm_read_prev_pwrst (pwrdm), +pwrdm_read_next_pwrst (pwrdm), min_latency, new_state); + +return ret; +} +
[...]
Quoted 122 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +54
-0@@ -52,6 +52,12 @@ static struct powerdomain iva2_pwrdm = { [2] = PWRSTS_OFF_ON, [3] = PWRDM_POWER_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 350, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +74,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { .pwrsts_mem_on = { [0] = PWRSTS_OFF_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 95, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 45, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };/* @@ -98,6 +110,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1 ] =PWRSTS_OFF_RET_ON ,/* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 60, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain core_3xxx_es3_1_pwrdm = {@@ -121,6 +139,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1 ] =PWRSTS_OFF_RET_ON ,/* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 60, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain dss_pwrdm = {@@ -136,6 +160,12 @@ static struct powerdomain dss_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 70, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 20, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };/* @@ -157,6 +187,12 @@ static struct powerdomain sgx_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1000, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain cam_pwrdm = {@@ -172,6 +208,12 @@ static struct powerdomain cam_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 850, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain per_pwrdm = {@@ -187,6 +229,12 @@ static struct powerdomain per_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 200, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 110, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain emu_pwrdm = {@@ -201,6 +249,12 @@ static struct powerdomain neon_pwrdm = { .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430), .pwrsts = PWRSTS_OFF_RET_ON, .pwrsts_logic_ret = PWRDM_POWER_RET, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 200, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };static struct powerdomain usbhost_pwrdm = {
arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain usbhost_pwrdm = { · line 286
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -223,6 +277,12 @@ static struct powerdomain usbhost_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 800, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 150, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };
A summary about where the latency numbers for each powerdomain come from would be useful.
[...]
Quoted 22 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -87,64 +60,86 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)return 0 ; } +/* +* omap_pm_set_max_dev_wakeup_lat - set/release devices wake-up latency +* constraints +*/ int omap_pm_set_max_dev_wakeup_lat (struct device *req_dev,struct device *dev,long t) { +struct platform_device *pdev, *req_pdev; +int ret =0 ; +if (!req_dev || !dev || t <-1 ) {WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__);return -EINVAL ; + } + +/* Look for the platform devices */ + pdev =to_platform_device (dev); + req_pdev =to_platform_device (req_dev);
arch/arm/mach-omap2/powerdomains3xxx_data.c int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) · line 90
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +10
-0+ +/* Try to catch non platform devices. */ +if ((pdev->name ==NULL ) || (req_pdev->name ==NULL )) { +pr_err ("OMAP-PM set_wakeup_lat: Error: platform devices " +"not valid\n" ); +return -EINVAL ; + }else { +/* Call the omap_device API */ + ret =omap_device_set_max_dev_wakeup_lat (req_pdev, pdev, t); + }
I don't think a NULL name check is the right sanity check here. WHat you really need to know is whether the target device is an omap_device. The requesting device can be anything (I think.)
Here's a simpler check:
if (pdev->dev->parent == &omap_device_parent) ret = omap_device_set_max_dev_wakeup_lat(req_pdev, pdev, t); else ...
arch/arm/mach-omap2/powerdomains3xxx_data.c int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) · line 92
Quoted 2 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +2
-0+return ret; +}
Kevin
PATCH 2/2 OMAP: PM: implement devices wakeup latency constraints APIs
Quoted 29 lines · Kevin Hilman
Quoted 15 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating similar APIs at theomap_deviceandomap_hwmodlevels. Theomap_hwmodlevel call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to set and release the constraints.NOTE: only works for devices which have been converted to use ? ? ? omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
The power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.Quoted 7 lines
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.I haven't got to a detailed review of this code yet, but did do some experiements and have some general comments on the code/design to get started.
Quoted 6 lines
Also, I had a problem doing a real dumb test until I figured out the problem with the init sequence. ?I tried setting a constraint in the device init code for UART (mach-omap2/serial.c:omap_serial_init_port()), and then I realized that that runs before mach-omap2/pm34xx.c:pwrdms_setup() which also calls
omap_set_pwrdm_state()for each powerdomain to initialize.
Do we need to change the behavior at init?
Quoted 4 lines
Also, for debug purposes, it might be useful to have a per-device sysfs interface to setting this wakeup latency constraint. ?Something like
?
/sys/devices/platform/omap/.../power/wakeup_latency
I do not see this as a debug interface but rather an API to the user space. If that is the case there are some issues to deal with, cf. below.
Quoted 1 line
I'm not sure exactly what to set the requesting device to though.
And also, how to track the requesters? PM QOS is using a /dev node that must be kept open as long as the constraints remains valid.
Quoted 11 lines
As far as implementation goes, you've so far implemented only wakeup latencies, but not througput. ?When you implement throughput you will have to duplicate large parts of this code and data structures for throughput, and if ever add some other constraint (frequency, voltage) it would need to be duplicated again.
Maybe now is the time to consider an interface to add a generic per-device constraint, with a type (latency, throughput, etc.), or "class" as it's called in PM QoS. ?For now the type/class does not need to be exposed externally, but will make implementing new constraint types much easer.
Ok that makes sense.
In the current patch the constraints plist is stored inside the powerdomain structure. This does not apply to throughput, frequency and voltage constraints.
Should the list constraint be managed in the OMAP PM layer instead of in the power domain code? If so where to store the constraints?
Quoted 172 lines
Some other comments below...
Quoted 157 lines
Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>---
Based on khilman's pm-core branch?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ? ? ? ?| ? 62 ++++++++- ?arch/arm/mach-omap2/powerdomain.c ? ? ? ? ? ? | ?197 +++++++++++++++++++++++++ ?arch/arm/mach-omap2/powerdomain.h ? ? ? ? ? ? | ? 39 +++++- ?arch/arm/mach-omap2/powerdomains3xxx_data.c ? | ? 60 ++++++++ ?arch/arm/plat-omap/include/plat/omap_device.h | ? ?2 + ?arch/arm/plat-omap/include/plat/omap_hwmod.h ?| ? ?2 + ?arch/arm/plat-omap/omap-pm-constraints.c ? ? ?| ?121 +++++++-------- ?arch/arm/plat-omap/omap_device.c ? ? ? ? ? ? ?| ? 28 ++++?8 files changed, 446 insertions(+), 65 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -142,6 +142,7 @@?#include "
powerdomain.h"
?#include <plat/clock.h>
?#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
?#include <plat/prcm.h>?#include "
cm2xxx_3xxx.h"arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -2267,10 +2268,69 @@ ohsps_unlock: ?}?/**
+ *omap_hwmod_set_max_dev_wakeup_lat- set a device wake-up constraint
+ * @oh: the device of @oh to set a constraint on.
+ * @req_oh: the device of @req_oh is the requester of the constraint.
+ * @t: wakeup latency constraint (us). -1 removes the existing constraint.
+ *
+ * Query the powerdomain of @oh to set/release the wake-up constraint.
+ * @oh is used to determine which power domain to set a constraint on.
+ * @req_oh is used to record the requester for later update or removal
+ * of a constraint.
+ *
+ * Returns-EINVALif @oh or @req_oh have no power domain, or the return
+ * code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */arch/arm/mach-omap2/omap_hwmod.c +45
-0+int omap_hwmod_set_max_dev_wakeup_lat (struct omap_hwmod *req_oh, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct omap_hwmod *oh, long t) +{ + ? ? struct device *req_dev; + ? ? struct platform_device *req_pdev; + ? ? struct powerdomain *pwrdm; + + ? ? pwrdm = omap_hwmod_get_pwrdm(oh); + + ? ? /* Catch devices with undefined powerdomains */ + ? ? if (!PTR_ERR(pwrdm)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: could not find parent " + ? ? ? ? ? ? ? ? ? ? "powerdomain for %s\n", oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? req_pdev = &(req_oh->od->pdev); + ? ? if (!PTR_ERR(req_pdev)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: pdev not found for oh %s\n", + ? ? ? ? ? ? ? ? ? ?oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? req_dev = &(req_pdev->dev); + ? ? if (!PTR_ERR(req_dev)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: device not found for oh %s\n", + ? ? ? ? ? ? ? ? ? ?oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* Call set/release_constraint for the given pwrdm */ + ? ? if (t == -1) { + ? ? ? ? ? ? pr_debug("omap_hwmod: remove max device latency constraint: " + ? ? ? ? ? ? ? ? ? ? ?"oh %s, pwrdm %s, req by oh %s\n", + ? ? ? ? ? ? ? ? ? ? ?oh->name, pwrdm->name, req_oh->name); + ? ? } else { + ? ? ? ? ? ? pr_debug("omap_hwmod: add max device latency constraint: " + ? ? ? ? ? ? ? ? ? ? ?"oh %s, t = %ld usec, pwrdm %s, req by oh %s\n", + ? ? ? ? ? ? ? ? ? ? ?oh->name, t, pwrdm->name, req_oh->name); + ? ? } + + ? ? return pwrdm_wakeuplat_set_constraint(pwrdm, req_dev, t); +} + +/** ? *
omap_hwmod_get_context_loss_count- get lost context count ? * @oh: structomap_hwmod*
? *
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
? * count for this device.
? *
? * Returns the context loss count of the powerdomain assocated with @oharch/arm/mach-omap2/powerdomain.c +0
-0@@ -19,6 +19,8 @@?#include <
linux/list.h>
?#include <linux/errno.h>
?#include <linux/string.h>arch/arm/mach-omap2/powerdomain.c +2
-0+#include <linux/slab.h> +?#include "
cm2xxx_3xxx.h"
?#include "prcm44xx.h"
?#include "cm44xx.h"arch/arm/mach-omap2/powerdomain.c +35
-0@@ -103,6 +105,13 @@ static int _pwrdm_register(struct powerdomain *pwrdm) ? ? ? pwrdm->state = pwrdm_read_pwrst(pwrdm); ? ? ? pwrdm->state_counter[pwrdm->state] = 1; + ? ? /* Initialize priority ordered list for wakeup latency constraint */ + ? ? spin_lock_init(&pwrdm->wakeuplat_lock); + ? ? plist_head_init(&pwrdm->wakeuplat_dev_list, &pwrdm->wakeuplat_lock); + + ? ? /* res_mutex protects res_list add and del ops */ + ? ? mutex_init(&pwrdm->wakeuplat_mutex); + ? ? ? pr_debug("powerdomain: registered %s\n", pwrdm->name); ? ? ? return 0;@@ -176,6 +185,74 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) ? ? ? return 0; ?} +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* +* Finds the minimum allowed wake-up latency value from all entries +* in the list and the power domain power state needing the constraint. +* Programs a new target state if it is different from current power state. +* +* Only OMAP3xxx is supported for now +* +* Returns 0 upon success. +*/ +static int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm) +{ + ? ? struct plist_node *node; + ? ? int ret = 0, new_state; + ? ? long min_latency = -1; + + ? ? /* Find the strongest constraint from the plist */ + ? ? if (!plist_head_empty(&pwrdm->wakeuplat_dev_list)) { + ? ? ? ? ? ? node = plist_first(&pwrdm->wakeuplat_dev_list); + ? ? ? ? ? ? min_latency = node->prio; + ? ? } + + ? ? /* Find power state with wakeup latency < minimum constraint. */ + ? ? for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++) { + ? ? ? ? ? ? if (min_latency == -1 || + ? ? ? ? ? ? ? ? pwrdm->wakeup_lat[new_state] <= min_latency)arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 225
Quoted 10 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+ ? ? ? ? ? ? ? ? ? ? break; + ? ? } + + ? ? switch (new_state) { + ? ? case PWRDM_FUNC_PWRST_OFF: + ? ? ? ? ? ? new_state = PWRDM_POWER_OFF; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_OSWR: + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF);cpu_is_* checks here aren't right.
Quoted 2 lines
You should use SoC specific function pointers as are done for many of the other powerdomain calls after Rajendra's splitup series.
The cpu_is_* tests are not related to the SoC specific function pointers but rather to the comment in the function description 'Only OMAP3xxx is supported for now'.
In fact the function that are conditionally called (pwrdm_set_logic_retst and omap_set_pwrdm_state) are correctly using the SoC specific pointers.
Is this test needed? If so is it the correct way to do it?
Quoted 154 lines
Quoted 31 lines
arch/arm/mach-omap2/powerdomain.c +30
-0+ ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_CSWR: + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_ON: + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? default: + ? ? ? ? ? ? pr_warn("powerdomain: requested latency constraint not " + ? ? ? ? ? ? ? ? ? ? "supported %s set to ON state\n", pwrdm->name); + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? } + + ? ? if (pwrdm_read_pwrst(pwrdm) != new_state) { + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? ret = omap_set_pwrdm_state(pwrdm, new_state); + ? ? } + + ? ? pr_debug("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " + ? ? ? ? ? ? ?"min_latency=%ld, set_state=%d\n", pwrdm->name, + ? ? ? ? ? ? ?pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), + ? ? ? ? ? ? ?pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + ? ? return ret; +} +[...]
Quoted 120 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -52,6 +52,12 @@ static struct powerdomain iva2_pwrdm = { ? ? ? ? ? ? ? [2] = PWRSTS_OFF_ON, ? ? ? ? ? ? ? [3] = PWRDM_POWER_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1100, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 350, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?}; ?static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +74,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= { ? ? ? ? ? ? ? [0] = PWRSTS_OFF_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 95, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 45, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -98,6 +110,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
core_3xxx_es3_1_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -121,6 +139,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
dss_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -136,6 +160,12 @@ static struct powerdomain dss_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 70,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 20,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -157,6 +187,12 @@ static struct powerdomain sgx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1000,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
cam_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -172,6 +208,12 @@ static struct powerdomain cam_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 850,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
per_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -187,6 +229,12 @@ static struct powerdomain per_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 110,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
emu_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -201,6 +249,12 @@ static struct powerdomain neon_pwrdm = { ? ? ? .omap_chip ? ? ? ?= OMAP_CHIP_INIT(CHIP_IS_OMAP3430), ? ? ? .pwrsts ? ? ? ? ? = PWRSTS_OFF_RET_ON, ? ? ? .pwrsts_logic_ret = PWRDM_POWER_RET, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};
Quoted 15 lines
Quoted 4 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0?static struct powerdomain usbhost_pwrdm = {@@ -223,6 +277,12 @@ static struct powerdomain usbhost_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */Quoted 8 lines
? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 800,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 150,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};A summary about where the latency numbers for each powerdomain come from would be useful.
Ok
Quoted 40 lines
[...]
Quoted 22 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -87,64 +60,86 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) ? ? ? return 0; ?} +/* +* omap_pm_set_max_dev_wakeup_lat - set/release devices wake-up latency +* constraints +*/ ?int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?long t) ?{ + ? ? struct platform_device *pdev, *req_pdev; + ? ? int ret = 0; + ? ? ? if (!req_dev || !dev || t < -1) { ? ? ? ? ? ? ? WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__); ? ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* Look for the platform devices */ + ? ? pdev = to_platform_device(dev); + ? ? req_pdev = to_platform_device(req_dev);arch/arm/mach-omap2/powerdomains3xxx_data.c int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) · line 90
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +10
-0+ + ? ? /* Try to catch non platform devices. */ + ? ? if ((pdev->name == NULL) || (req_pdev->name == NULL)) { + ? ? ? ? ? ? pr_err("OMAP-PM set_wakeup_lat: Error: platform devices " + ? ? ? ? ? ? ? ? ? ?"not valid\n"); + ? ? ? ? ? ? return -EINVAL; + ? ? } else { + ? ? ? ? ? ? /* Call the omap_device API */ + ? ? ? ? ? ? ret = omap_device_set_max_dev_wakeup_lat(req_pdev, pdev, t); + ? ? }I don't think a NULL name check is the right sanity check here. ?WHat you really need to know is whether the target device is an
omap_device. The requesting device can be anything (I think.)
Quoted 6 lines
Here's a simpler check:
? ? ? ?if (
pdev->dev->parent==&omap_device_parent)
? ? ? ? ? ? ? ?ret =omap_device_set_max_dev_wakeup_lat(req_pdev, pdev, t); ? ? ? ?else
? ? ? ? ? ? ? ?...
Ok I will use this test. Note: the dev parameter is already checked for NULL above.
Also I think the requester parameter needs to keep the device* type across all layers. In any case only this type is used by the low level code (in powerdomain.c). This allows for any device (i.e. that does not necessarily have an associated omap_device) to request constraints.
What do you think?
Quoted 7 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) · line 92
Quoted 4 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +2
-0+ ? ? return ret; +}Kevin
Thanks for reviewing the code.
Jean
PATCH 2/2 OMAP: PM: implement devices wakeup latency constraints APIs
Quoted 30 lines · Jean Pihet
Quoted 29 lines · Kevin Hilman
Quoted 15 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating similar APIs at theomap_deviceandomap_hwmodlevels. Theomap_hwmodlevel call is the layer with access to the powerdomain core, so it is the place where the powerdomain is queried to set and release the constraints.NOTE: only works for devices which have been converted to use ? ? ? omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
The power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.Quoted 7 lines
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.I haven't got to a detailed review of this code yet, but did do some experiements and have some general comments on the code/design to get started.
Quoted 9 lines
Quoted 6 lines
Also, I had a problem doing a real dumb test until I figured out the problem with the init sequence. ?I tried setting a constraint in the device init code for UART (mach-omap2/serial.c:omap_serial_init_port()), and then I realized that that runs before mach-omap2/pm34xx.c:pwrdms_setup() which also calls
omap_set_pwrdm_state()for each powerdomain to initialize.Do we need to change the behavior at init?
I think so.
At a minimum, it should be documented somewhere that the constraints API cannot be used before pwrdms_setup(). But since that happens much later in the boot process than device init code, that might be too strict.
Quoted 6 lines
Quoted 4 lines
Also, for debug purposes, it might be useful to have a per-device sysfs interface to setting this wakeup latency constraint. ?Something like
?
/sys/devices/platform/omap/.../power/wakeup_latencyI do not see this as a debug interface but rather an API to the user space. If that is the case there are some issues to deal with, cf. below.
By debug, I was thinking under '#ifdef CONFIG_PM_DEBUG'. Even if you did this as a separate patch that we did not try to get upstream, it would be extremely valuable for testing this framework.
Quoted 3 lines
Quoted 1 line
I'm not sure exactly what to set the requesting device to though.
And also, how to track the requesters? PM QOS is using a /dev node that must be kept open as long as the constraints remains valid.
A dummy device could be created for all sysfs requesters since you would want subsequent writes to override previous ones.
Quoted 11 lines
Quoted 11 lines
As far as implementation goes, you've so far implemented only wakeup latencies, but not througput. ?When you implement throughput you will have to duplicate large parts of this code and data structures for throughput, and if ever add some other constraint (frequency, voltage) it would need to be duplicated again.
Maybe now is the time to consider an interface to add a generic per-device constraint, with a type (latency, throughput, etc.), or "class" as it's called in PM QoS. ?For now the type/class does not need to be exposed externally, but will make implementing new constraint types much easer.
Quoted 6 lines
Ok that makes sense.
In the current patch the constraints plist is stored inside the powerdomain structure. This does not apply to throughput, frequency and voltage constraints.
Should the list constraint be managed in the OMAP PM layer instead of in the power domain code? If so where to store the constraints?
I was thinking at the omap_device layer, where there would be a constraint plist managed for each class of constraint.
Quoted 174 lines
Quoted 172 lines
Some other comments below...
Quoted 157 lines
Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>---
Based on khilman's pm-core branch?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ? ? ? ?| ? 62 ++++++++- ?arch/arm/mach-omap2/powerdomain.c ? ? ? ? ? ? | ?197 +++++++++++++++++++++++++ ?arch/arm/mach-omap2/powerdomain.h ? ? ? ? ? ? | ? 39 +++++- ?arch/arm/mach-omap2/powerdomains3xxx_data.c ? | ? 60 ++++++++ ?arch/arm/plat-omap/include/plat/omap_device.h | ? ?2 + ?arch/arm/plat-omap/include/plat/omap_hwmod.h ?| ? ?2 + ?arch/arm/plat-omap/omap-pm-constraints.c ? ? ?| ?121 +++++++-------- ?arch/arm/plat-omap/omap_device.c ? ? ? ? ? ? ?| ? 28 ++++?8 files changed, 446 insertions(+), 65 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -142,6 +142,7 @@?#include "
powerdomain.h"
?#include <plat/clock.h>
?#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
?#include <plat/prcm.h>?#include "
cm2xxx_3xxx.h"arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -2267,10 +2268,69 @@ ohsps_unlock: ?}?/**
+ *omap_hwmod_set_max_dev_wakeup_lat- set a device wake-up constraint
+ * @oh: the device of @oh to set a constraint on.
+ * @req_oh: the device of @req_oh is the requester of the constraint.
+ * @t: wakeup latency constraint (us). -1 removes the existing constraint.
+ *
+ * Query the powerdomain of @oh to set/release the wake-up constraint.
+ * @oh is used to determine which power domain to set a constraint on.
+ * @req_oh is used to record the requester for later update or removal
+ * of a constraint.
+ *
+ * Returns-EINVALif @oh or @req_oh have no power domain, or the return
+ * code from the pwrdm function (pwrdm_wakeuplat_set/release_constraint)
+ * of the powerdomain assocated with @oh.
+ */arch/arm/mach-omap2/omap_hwmod.c +45
-0+int omap_hwmod_set_max_dev_wakeup_lat (struct omap_hwmod *req_oh, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct omap_hwmod *oh, long t) +{ + ? ? struct device *req_dev; + ? ? struct platform_device *req_pdev; + ? ? struct powerdomain *pwrdm; + + ? ? pwrdm = omap_hwmod_get_pwrdm(oh); + + ? ? /* Catch devices with undefined powerdomains */ + ? ? if (!PTR_ERR(pwrdm)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: could not find parent " + ? ? ? ? ? ? ? ? ? ? "powerdomain for %s\n", oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? req_pdev = &(req_oh->od->pdev); + ? ? if (!PTR_ERR(req_pdev)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: pdev not found for oh %s\n", + ? ? ? ? ? ? ? ? ? ?oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? req_dev = &(req_pdev->dev); + ? ? if (!PTR_ERR(req_dev)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: device not found for oh %s\n", + ? ? ? ? ? ? ? ? ? ?oh->name); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* Call set/release_constraint for the given pwrdm */ + ? ? if (t == -1) { + ? ? ? ? ? ? pr_debug("omap_hwmod: remove max device latency constraint: " + ? ? ? ? ? ? ? ? ? ? ?"oh %s, pwrdm %s, req by oh %s\n", + ? ? ? ? ? ? ? ? ? ? ?oh->name, pwrdm->name, req_oh->name); + ? ? } else { + ? ? ? ? ? ? pr_debug("omap_hwmod: add max device latency constraint: " + ? ? ? ? ? ? ? ? ? ? ?"oh %s, t = %ld usec, pwrdm %s, req by oh %s\n", + ? ? ? ? ? ? ? ? ? ? ?oh->name, t, pwrdm->name, req_oh->name); + ? ? } + + ? ? return pwrdm_wakeuplat_set_constraint(pwrdm, req_dev, t); +} + +/** ? *
omap_hwmod_get_context_loss_count- get lost context count ? * @oh: structomap_hwmod*
? *
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
? * count for this device.
? *
? * Returns the context loss count of the powerdomain assocated with @oharch/arm/mach-omap2/powerdomain.c +0
-0@@ -19,6 +19,8 @@?#include <
linux/list.h>
?#include <linux/errno.h>
?#include <linux/string.h>arch/arm/mach-omap2/powerdomain.c +2
-0+#include <linux/slab.h> +?#include "
cm2xxx_3xxx.h"
?#include "prcm44xx.h"
?#include "cm44xx.h"arch/arm/mach-omap2/powerdomain.c +35
-0@@ -103,6 +105,13 @@ static int _pwrdm_register(struct powerdomain *pwrdm) ? ? ? pwrdm->state = pwrdm_read_pwrst(pwrdm); ? ? ? pwrdm->state_counter[pwrdm->state] = 1; + ? ? /* Initialize priority ordered list for wakeup latency constraint */ + ? ? spin_lock_init(&pwrdm->wakeuplat_lock); + ? ? plist_head_init(&pwrdm->wakeuplat_dev_list, &pwrdm->wakeuplat_lock); + + ? ? /* res_mutex protects res_list add and del ops */ + ? ? mutex_init(&pwrdm->wakeuplat_mutex); + ? ? ? pr_debug("powerdomain: registered %s\n", pwrdm->name); ? ? ? return 0;@@ -176,6 +185,74 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) ? ? ? return 0; ?} +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* +* Finds the minimum allowed wake-up latency value from all entries +* in the list and the power domain power state needing the constraint. +* Programs a new target state if it is different from current power state. +* +* Only OMAP3xxx is supported for now +* +* Returns 0 upon success. +*/ +static int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm) +{ + ? ? struct plist_node *node; + ? ? int ret = 0, new_state; + ? ? long min_latency = -1; + + ? ? /* Find the strongest constraint from the plist */ + ? ? if (!plist_head_empty(&pwrdm->wakeuplat_dev_list)) { + ? ? ? ? ? ? node = plist_first(&pwrdm->wakeuplat_dev_list); + ? ? ? ? ? ? min_latency = node->prio; + ? ? } + + ? ? /* Find power state with wakeup latency < minimum constraint. */ + ? ? for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++) { + ? ? ? ? ? ? if (min_latency == -1 || + ? ? ? ? ? ? ? ? pwrdm->wakeup_lat[new_state] <= min_latency)arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 225
Quoted 10 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+ ? ? ? ? ? ? ? ? ? ? break; + ? ? } + + ? ? switch (new_state) { + ? ? case PWRDM_FUNC_PWRST_OFF: + ? ? ? ? ? ? new_state = PWRDM_POWER_OFF; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_OSWR: + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF);cpu_is_* checks here aren't right.
Quoted 2 lines
You should use SoC specific function pointers as are done for many of the other powerdomain calls after Rajendra's splitup series.
Quoted 8 lines
The cpu_is_* tests are not related to the SoC specific function pointers but rather to the comment in the function description 'Only OMAP3xxx is supported for now'.
In fact the function that are conditionally called (pwrdm_set_logic_retstandomap_set_pwrdm_state) are correctly using the SoC specific pointers.Is this test needed? If so is it the correct way to do it?
Right, I think you can just drop the cpu_is_* checks here since as you pointed out, the called functions already handle SoC specifics.
Quoted 220 lines
Quoted 154 lines
Quoted 31 lines
arch/arm/mach-omap2/powerdomain.c +30
-0+ ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_CSWR: + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_ON: + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? default: + ? ? ? ? ? ? pr_warn("powerdomain: requested latency constraint not " + ? ? ? ? ? ? ? ? ? ? "supported %s set to ON state\n", pwrdm->name); + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? } + + ? ? if (pwrdm_read_pwrst(pwrdm) != new_state) { + ? ? ? ? ? ? if (cpu_is_omap34xx()) + ? ? ? ? ? ? ? ? ? ? ret = omap_set_pwrdm_state(pwrdm, new_state); + ? ? } + + ? ? pr_debug("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " + ? ? ? ? ? ? ?"min_latency=%ld, set_state=%d\n", pwrdm->name, + ? ? ? ? ? ? ?pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), + ? ? ? ? ? ? ?pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + ? ? return ret; +} +[...]
Quoted 120 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -52,6 +52,12 @@ static struct powerdomain iva2_pwrdm = { ? ? ? ? ? ? ? [2] = PWRSTS_OFF_ON, ? ? ? ? ? ? ? [3] = PWRDM_POWER_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1100, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 350, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?}; ?static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +74,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= { ? ? ? ? ? ? ? [0] = PWRSTS_OFF_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 95, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 45, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -98,6 +110,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
core_3xxx_es3_1_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -121,6 +139,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
dss_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -136,6 +160,12 @@ static struct powerdomain dss_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 70,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 20,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -157,6 +187,12 @@ static struct powerdomain sgx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1000,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
cam_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -172,6 +208,12 @@ static struct powerdomain cam_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 850,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
per_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -187,6 +229,12 @@ static struct powerdomain per_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 110,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
emu_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -201,6 +249,12 @@ static struct powerdomain neon_pwrdm = { ? ? ? .omap_chip ? ? ? ?= OMAP_CHIP_INIT(CHIP_IS_OMAP3430), ? ? ? .pwrsts ? ? ? ? ? = PWRSTS_OFF_RET_ON, ? ? ? .pwrsts_logic_ret = PWRDM_POWER_RET, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};Quoted 15 lines
Quoted 4 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0?static struct powerdomain usbhost_pwrdm = {@@ -223,6 +277,12 @@ static struct powerdomain usbhost_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */Quoted 8 lines
? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 800,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 150,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};A summary about where the latency numbers for each powerdomain come from would be useful.
Ok
Quoted 40 lines
[...]
Quoted 22 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -87,64 +60,86 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) ? ? ? return 0; ?} +/* +* omap_pm_set_max_dev_wakeup_lat - set/release devices wake-up latency +* constraints +*/ ?int omap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?long t) ?{ + ? ? struct platform_device *pdev, *req_pdev; + ? ? int ret = 0; + ? ? ? if (!req_dev || !dev || t < -1) { ? ? ? ? ? ? ? WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__); ? ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* Look for the platform devices */ + ? ? pdev = to_platform_device(dev); + ? ? req_pdev = to_platform_device(req_dev);arch/arm/mach-omap2/powerdomains3xxx_data.c int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) · line 90
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +10
-0+ + ? ? /* Try to catch non platform devices. */ + ? ? if ((pdev->name == NULL) || (req_pdev->name == NULL)) { + ? ? ? ? ? ? pr_err("OMAP-PM set_wakeup_lat: Error: platform devices " + ? ? ? ? ? ? ? ? ? ?"not valid\n"); + ? ? ? ? ? ? return -EINVAL; + ? ? } else { + ? ? ? ? ? ? /* Call the omap_device API */ + ? ? ? ? ? ? ret = omap_device_set_max_dev_wakeup_lat(req_pdev, pdev, t); + ? ? }I don't think a NULL name check is the right sanity check here. ?WHat you really need to know is whether the target device is an
omap_device. The requesting device can be anything (I think.)Quoted 6 lines
Here's a simpler check:
? ? ? ?if (
pdev->dev->parent==&omap_device_parent)
? ? ? ? ? ? ? ?ret =omap_device_set_max_dev_wakeup_lat(req_pdev, pdev, t); ? ? ? ?else
? ? ? ? ? ? ? ?...Ok I will use this test. Note: the dev parameter is already checked for NULL above.
Quoted 6 lines
Also I think the requester parameter needs to keep the device* type across all layers. In any case only this type is used by the low level code (in
powerdomain.c). This allows for any device (i.e. that does not necessarily have an associatedomap_device) to request constraints.
What do you think?
I agree that the only the target device needs to be an omap_device, the requester can be any device.
Kevin
PATCH 2/2 OMAP: PM: implement devices constraints APIs
In reply to Jean PihetImplement OMAP PM layer omap_pm_set_max_dev_wakeup_lat API by creating a unified API which calls omap_device_set_dev_constraint for all classes of constraints (devices wake-up latency, devices throughput...).
The implementation of the constraints framework is at the omap_device
level: management and storage of the constraints, dispatching of the constraints to the appropriate low level layers.
NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
For the devices wake-up latency constraints, the power domains get the next power state programmed directly in the registers via pwrdm_wakeuplat_update_pwrst.
Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to omap_device, omap_hwmod and PM QOS frameworks.
--- arch/arm/mach-omap2/omap_hwmod.c | 29 ++++- arch/arm/mach-omap2/powerdomain.c | 99 +++++++++++++ arch/arm/mach-omap2/powerdomain.h | 24 +++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 63 +++++++++ arch/arm/plat-omap/include/plat/omap-pm.h | 6 +- arch/arm/plat-omap/include/plat/omap_device.h | 14 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/omap-pm-constraints.c | 161 ++++++++++------------ arch/arm/plat-omap/omap-pm-noop.c | 2 +- arch/arm/plat-omap/omap_device.c | 187 +++++++++++++++++++++++++ 10 files changed, 493 insertions(+), 93 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +28 -1
@@ -142,6 +142,7 @@#include "powerdomain.h" #include <plat/clock.h> #include <plat/omap_hwmod.h> +#include <plat/omap_device.h> #include <plat/prcm.h> #include "cm2xxx_3xxx.h"
@@ -2277,11 +2278,37 @@ ohsps_unlock:return ret; } +/* +* omap_hwmod_update_power_state - Update the power domain power state of +* @oh +* +* @oh: struct omap_hwmod* to which the requesting device belongs to. +* @min_latency: the allowed wake-up latency for the power domain of @oh. +* +* Finds the power domain next power state that fulfills the constraint. +* Applies the constraint to the power domain by calling +* pwrdm_wakeuplat_update_pwrst. +* +* Returns 0 upon success. +*/ +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency) +{ +struct powerdomain *pwrdm =omap_hwmod_get_pwrdm (oh); + +if (!PTR_ERR (pwrdm)) { +pr_err ("omap_hwmod: Error: could not find parent " +"powerdomain for %s\n" , oh->name); +return -EINVAL ; + } + +return pwrdm_wakeuplat_update_pwrst (pwrdm, min_latency); +} +/** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss +* Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh
arch/arm/mach-omap2/powerdomain.c +99 -0
111 lines not on this page · raw message
arch/arm/mach-omap2/powerdomain.h +22 -2
@@ -19,7 +19,10 @@#include <linux/types.h> #include <linux/list.h> - +#include <linux/plist.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/pm_qos_params.h> #include <linux/atomic.h> #include <plat/cpu.h>
@@ -46,6 +49,15 @@#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON)) +/* Powerdomain functional power states */ +#define PWRDM_FUNC_PWRST_OFF 0x0 +#define PWRDM_FUNC_PWRST_OSWR 0x1 +#define PWRDM_FUNC_PWRST_CSWR 0x2 +#define PWRDM_FUNC_PWRST_ON 0x3 + +#define PWRDM_MAX_FUNC_PWRSTS 4 + +#define UNSUP_STATE -1/* Powerdomain flags */ #define PWRDM_HAS_HDWR_SAR (1 << 0)/* hardware save-and-restore support */
@@ -96,7 +108,11 @@ struct powerdomain;* @state_counter: * @timer: * @state_timer: -* +* @wakeup_lat: wakeup latencies for possible powerdomain power states +* Note about the wakeup latencies ordering: the values must be sorted +* in decremental order +* @pm_qos_request: PM QOS handle, only used to control the MPU and CORE power +* domains states; to be removed when a generic solution is in place. * @prcm_partition possible values are defined in mach-omap2/prcm44xx.h. */ struct powerdomain {
@@ -121,6 +137,8 @@ struct powerdomain {s64 timer;s64 state_timer[PWRDM_MAX_PWRSTS ];#endif +const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS ]; +struct pm_qos_request_list pm_qos_request; };/**
@@ -210,6 +228,8 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);int pwrdm_pre_transition (void );int pwrdm_post_transition (void );int pwrdm_set_lowpwrstchange (struct powerdomain *pwrdm); + +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency);u32 pwrdm_get_context_loss_count (struct powerdomain *pwrdm);extern void omap2xxx_powerdomains_init (void );
arch/arm/mach-omap2/powerdomains3xxx_data.c +63 -0
129 lines not on this page · raw message
arch/arm/plat-omap/include/plat/omap-pm.h +5 -1
@@ -70,6 +70,10 @@ void omap_pm_if_exit(void);* Device-driver-originated constraints (via board-*.c files, platform_data) */ +enum omap_pm_constraint_class { +OMAP_PM_CONSTRAINT_WKUP_LAT , +OMAP_PM_CONSTRAINT_THROUGHPUT +};/** * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
@@ -137,7 +141,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);* Returns -EINVAL for an invalid argument, -ERANGE if the constraint * is not satisfiable, or 0 upon success. */ -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r); +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r);/**
arch/arm/plat-omap/include/plat/omap_device.h +14 -0
@@ -32,9 +32,11 @@#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H#include <linux/kernel.h> +#include <linux/plist.h> #include <linux/platform_device.h> #include <plat/omap_hwmod.h> +#include <plat/omap-pm.h> extern struct device omap_device_parent;
@@ -73,6 +75,15 @@ struct omap_device {s8 pm_lat_level;u8 hwmods_cnt;u8 _state; + +}; + +/* Linked list for the devices constraints entries */ +struct omap_device_constraints_entry { +struct device *req_dev; +void *target; +unsigned long constraint_value; +struct plist_node node; };/* Device driver interface (call via platform_data fn ptrs) */
@@ -107,6 +118,9 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);int omap_device_align_pm_lat (struct platform_device *pdev,u32 new_wakeup_lat_limit);struct powerdomain *omap_device_get_pwrdm (struct omap_device *od); +int omap_device_set_dev_constraint (enum omap_pm_constraint_class class, +struct device *req_dev, +struct device *dev,long t);u32 omap_device_get_context_loss_count (struct platform_device *pdev);/* Other */
arch/arm/plat-omap/include/plat/omap_hwmod.h +1 -0
@@ -597,6 +597,7 @@ int omap_hwmod_for_each_by_class(const char *classname, void *user);int omap_hwmod_set_postsetup_state (struct omap_hwmod *oh,u8 state); +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency);u32 omap_hwmod_get_context_loss_count (struct omap_hwmod *oh);/*
arch/arm/plat-omap/omap-pm-constraints.c +73 -88
197 lines not on this page · raw message
arch/arm/plat-omap/omap-pm-noop.c +1 -1
@@ -61,7 +61,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)return 0 ; } -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r) {if (!dev || (agent_id !=OCP_INITIATOR_AGENT && agent_id !=OCP_TARGET_AGENT )) {
arch/arm/plat-omap/omap_device.c +187 -0
203 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 2/2 OMAP: PM: implement devices constraints APIs
Hi,
This patch is sent as en early review request, the testing is still on-going. I will post the updated series (with a new revision number) as soon as possible.
I have some inlined comments, questions and concerns about it. Can you please check?
Quoted 186 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating a unified API which callsomap_device_set_dev_constraintfor all classes of constraints (devices wake-up latency, devices throughput...).
The implementation of the constraints framework is at theomap_device
level: management and storage of the constraints, dispatching of the constraints to the appropriate low level layers.NOTE: only works for devices which have been converted to use ? ? ?omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
For the devices wake-up latency constraints, the power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>---
?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ? ? ? ?| ? 29 ++++- ?arch/arm/mach-omap2/powerdomain.c ? ? ? ? ? ? | ? 99 +++++++++++++ ?arch/arm/mach-omap2/powerdomain.h ? ? ? ? ? ? | ? 24 +++- ?arch/arm/mach-omap2/powerdomains3xxx_data.c ? | ? 63 +++++++++ ?arch/arm/plat-omap/include/plat/omap-pm.h ? ? | ? ?6 +- ?arch/arm/plat-omap/include/plat/omap_device.h | ? 14 ++ ?arch/arm/plat-omap/include/plat/omap_hwmod.h ?| ? ?1 + ?arch/arm/plat-omap/omap-pm-constraints.c ? ? ?| ?161 ++++++++++------------ ?arch/arm/plat-omap/omap-pm-noop.c ? ? ? ? ? ? | ? ?2 +- ?arch/arm/plat-omap/omap_device.c ? ? ? ? ? ? ?| ?187 +++++++++++++++++++++++++?10 files changed, 493 insertions(+), 93 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -142,6 +142,7 @@?#include "
powerdomain.h"
?#include <plat/clock.h>
?#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
?#include <plat/prcm.h>?#include "
cm2xxx_3xxx.h"arch/arm/mach-omap2/omap_hwmod.c +26
-0@@ -2277,11 +2278,37 @@ ohsps_unlock: ? ? ? ?return ret; ?} +/* +* omap_hwmod_update_power_state - Update the power domain power state of +* @oh +* +* @oh: struct omap_hwmod* to which the requesting device belongs to. +* @min_latency: the allowed wake-up latency for the power domain of @oh. +* +* Finds the power domain next power state that fulfills the constraint. +* Applies the constraint to the power domain by calling +* pwrdm_wakeuplat_update_pwrst. +* +* Returns 0 upon success. +*/ +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency) +{ + ? ? ? struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh); + + ? ? ? if (!PTR_ERR(pwrdm)) { + ? ? ? ? ? ? ? pr_err("omap_hwmod: Error: could not find parent " + ? ? ? ? ? ? ? ? ? ? ? "powerdomain for %s\n", oh->name); + ? ? ? ? ? ? ? return -EINVAL; + ? ? ? } + + ? ? ? return pwrdm_wakeuplat_update_pwrst(pwrdm, min_latency); +} +?/**
?*omap_hwmod_get_context_loss_count- get lost context count ?* @oh: structomap_hwmod*
?*
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
?* count for this device.
?*
?* Returns the context loss count of the powerdomain assocated with @oharch/arm/mach-omap2/powerdomain.c +0
-0@@ -19,6 +19,7 @@?#include <
linux/list.h>
?#include <linux/errno.h>
?#include <linux/string.h>
+
?#include "cm2xxx_3xxx.h"
?#include "prcm44xx.h"
?#include "cm44xx.h"arch/arm/mach-omap2/powerdomain.c +78
-0@@ -176,6 +177,104 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) ? ? ? ?return 0; ?} +/* +* Test if the current powerdomain is MPU or CORE +* +* This function is only used by pwrdm_wakeuplat_update_pwrst +* which applies the MPU and CORE power domains constraints using PM QOS. +* +* This will disappear when all power domains will be controlled directly +* from the wake-up latency constraints framework +*/ +static inline int is_pwrdm_mpu_or_core (struct powerdomain *pwrdm) +{ + ? ? ? if ((strncmp(pwrdm->name, "mpu_pwrdm", 9) == 0) || + ? ? ? ? ? (strncmp(pwrdm->name, "core_pwrdm", 10) == 0)) + ? ? ? ? ? ? ? return 1; + ? ? ? else + ? ? ? ? ? ? ? return 0; +} + +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* @min_latency: the allowed wake-up latency for the given power domain. +* +* Finds the power domain next power state that fulfills the constraint. +* Programs a new target state if it is different from current power state. +* +* Returns 0 upon success. +*/ +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency) +{ + ? ? ? int ret = 0, new_state = 0; + + ? ? ? if (!pwrdm) { + ? ? ? ? ? ? ? WARN(1, "powerdomain: %s: invalid parameter(s)", __func__); + ? ? ? ? ? ? ? return -EINVAL; + ? ? ? } + + ? ? ? /* + ? ? ? ?* Apply constraints to MPU and CORE via the PM QOS API. + ? ? ? ?* Every power domain struct has a pm_qos_request_list field + ? ? ? ?*/ + ? ? ? if (is_pwrdm_mpu_or_core(pwrdm)) { + ? ? ? ? ? ? ? if (pm_qos_request_active(&(pwrdm->pm_qos_request))) + ? ? ? ? ? ? ? ? ? ? ? pm_qos_remove_request(&(pwrdm->pm_qos_request)); + + ? ? ? ? ? ? ? if (min_latency >= 0) + ? ? ? ? ? ? ? ? ? ? ? pm_qos_add_request(&(pwrdm->pm_qos_request), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_QOS_CPU_DMA_LATENCY, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?min_latency); + ? ? ? ? ? ? ? return 0; + ? ? ? } + + ? ? ? /* + ? ? ? ?* Apply constraints to pwrdm other than MPU and CORE by programming + ? ? ? ?* the pwrdm next power state. + ? ? ? ?*/ + + ? ? ? /* Find power state with wakeup latency < minimum constraint */ + ? ? ? for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++) { + ? ? ? ? ? ? ? if (min_latency == -1 || + ? ? ? ? ? ? ? ? ? pwrdm->wakeup_lat[new_state] <= min_latency) + ? ? ? ? ? ? ? ? ? ? ? break; + ? ? ? } + + ? ? ? switch (new_state) { + ? ? ? case PWRDM_FUNC_PWRST_OFF: + ? ? ? ? ? ? ? new_state = PWRDM_POWER_OFF; + ? ? ? ? ? ? ? break; + ? ? ? case PWRDM_FUNC_PWRST_OSWR: + ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF); + ? ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? ? break; + ? ? ? case PWRDM_FUNC_PWRST_CSWR: + ? ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + ? ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? ? break; + ? ? ? case PWRDM_FUNC_PWRST_ON: + ? ? ? ? ? ? ? new_state = PWRDM_POWER_ON;
arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 267
Quoted 10 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+ ? ? ? ? ? ? ? break; + ? ? ? default: + ? ? ? ? ? ? ? pr_warn("powerdomain: requested latency constraint not " + ? ? ? ? ? ? ? ? ? ? ? "supported %s set to ON state\n", pwrdm->name); + ? ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? ? break; + ? ? ? } + + ? ? ? if (pwrdm_read_pwrst(pwrdm) != new_state) { + ? ? ? ? ? ? ? ret = omap_set_pwrdm_state(pwrdm, new_state);
The function pwrdms_setup (called from omap3_pm_init for every pwrdm) runs late in the boot process and so it overwrites the registers values programmed by omap_set_pwrdm_state with the default values. Could the default values get written earlier in the boot process (e.g. at hwmod init) before the devices can put constraints on the power domains?
Quoted 401 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+ ? ? ? } + + ? ? ? pr_debug("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " + ? ? ? ? ? ? ? ?"min_latency=%ld, set_state=%d\n", pwrdm->name, + ? ? ? ? ? ? ? ?pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), + ? ? ? ? ? ? ? ?pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + ? ? ? return ret; +} +?/* Public functions */
?/**
arch/arm/mach-omap2/powerdomain.h +0
-0@@ -19,7 +19,10 @@?#include <
linux/types.h>
?#include <linux/list.h>arch/arm/mach-omap2/powerdomain.h +4
-1- +#include <linux/plist.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/pm_qos_params.h> ?#include <
linux/atomic.h>?#include <
plat/cpu.h>arch/arm/mach-omap2/powerdomain.h +9
-0@@ -46,6 +49,15 @@ ?#define PWRSTS_OFF_RET_ON ? ? ?(PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON)) +/* Powerdomain functional power states */ +#define PWRDM_FUNC_PWRST_OFF ? 0x0 +#define PWRDM_FUNC_PWRST_OSWR ?0x1 +#define PWRDM_FUNC_PWRST_CSWR ?0x2 +#define PWRDM_FUNC_PWRST_ON ? ?0x3 + +#define PWRDM_MAX_FUNC_PWRSTS ?4 + +#define UNSUP_STATE ? ? ? ? ? ?-1?/* Powerdomain flags */
?#definePWRDM_HAS_HDWR_SAR? ? (1 << 0) /* hardware save-and-restore support */arch/arm/mach-omap2/powerdomain.h +0
-0@@ -96,7 +108,11 @@ struct powerdomain;?* @state_counter:
?* @timer:
?* @state_timer:
- *
+ * @wakeup_lat: wakeup latencies for possible powerdomain power states
+ * Note about the wakeup latencies ordering: the values must be sorted
+ * ?in decremental order
+ * @pm_qos_request: PM QOS handle, only used to control the MPU and CORE power
+ * ?domains states; to be removed when a generic solution is in place. ?* @prcm_partition possible values are defined inmach-omap2/prcm44xx.h. ?*/
?struct powerdomain {arch/arm/mach-omap2/powerdomain.h +0
-0@@ -121,6 +137,8 @@ struct powerdomain { ? ? ? ?s64 timer; ? ? ? ?s64 state_timer[PWRDM_MAX_PWRSTS];?#endif
+ ? ? ? const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS];
+ ? ? ? structpm_qos_request_listpm_qos_request; ?};?/**
arch/arm/mach-omap2/powerdomain.h +2
-0@@ -210,6 +228,8 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm); ?int pwrdm_pre_transition(void); ?int pwrdm_post_transition(void); ?int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm); + +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency); ?u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm); ?extern void omap2xxx_powerdomains_init(void);arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -31,6 +31,9 @@?/*
?* Powerdomains
+ *
+ * Thewakeup_latvalues are derived from measurements on
+ * the actual target.
?*/?static struct powerdomain
iva2_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +12
-0@@ -52,6 +55,12 @@ static struct powerdomain iva2_pwrdm = { ? ? ? ? ? ? ? ?[2] = PWRSTS_OFF_ON, ? ? ? ? ? ? ? ?[3] = PWRDM_POWER_ON, ? ? ? ?}, + ? ? ? .wakeup_lat = { + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1100, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 350, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? ? }, ?}; ?static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +77,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= { ? ? ? ? ? ? ? ?[0] = PWRSTS_OFF_ON, ? ? ? ?}, + ? ? ? .wakeup_lat = { + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 95, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 45, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? ? }, ?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -98,6 +113,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {? ? ? ? ? ? ? ?[0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? ?[1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
core_3xxx_es3_1_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -121,6 +142,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {? ? ? ? ? ? ? ?[0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? ?[1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
dss_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -136,6 +163,12 @@ static struct powerdomain dss_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= {? ? ? ? ? ? ? ?[0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 70,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 20,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -157,6 +190,12 @@ static struct powerdomain sgx_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= {? ? ? ? ? ? ? ?[0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1000,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
cam_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -172,6 +211,12 @@ static struct powerdomain cam_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= {? ? ? ? ? ? ? ?[0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 850,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
per_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -187,6 +232,12 @@ static struct powerdomain per_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= {? ? ? ? ? ? ? ?[0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 110,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
emu_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -201,6 +252,12 @@ static struct powerdomain neon_pwrdm = { ? ? ? ?.omap_chip ? ? ? ?= OMAP_CHIP_INIT(CHIP_IS_OMAP3430), ? ? ? ?.pwrsts ? ? ? ? ? = PWRSTS_OFF_RET_ON, ? ? ? ?.pwrsts_logic_ret = PWRDM_POWER_RET, + ? ? ? .wakeup_lat = { + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35, + ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? ? }, ?}; ?static struct powerdomain usbhost_pwrdm = {@@ -223,6 +280,12 @@ static struct powerdomain usbhost_pwrdm = { ? ? ? ?.pwrsts_mem_on ? ?= {? ? ? ? ? ? ? ?[0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? ?},
+ ? ? ? .wakeup_lat = {
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 800,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 150,
+ ? ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? ? },
?};?static struct powerdomain
dpll1_pwrdm= {arch/arm/plat-omap/include/plat/omap-pm.h +0
-0@@ -70,6 +70,10 @@ void omap_pm_if_exit(void); ?* Device-driver-originated constraints (via board-*.c files, platform_data)?*/
arch/arm/plat-omap/include/plat/omap-pm.h +4
-0+enum omap_pm_constraint_class { + ? ? ? OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? OMAP_PM_CONSTRAINT_THROUGHPUT +};?/**
?*omap_pm_set_max_mpu_wakeup_lat- set the maximum MPU wakeup latencyarch/arm/plat-omap/include/plat/omap-pm.h +0
-0@@ -137,7 +141,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);?* Returns
-EINVALfor an invalid argument,-ERANGEif the constraint ?* is not satisfiable, or 0 upon success.
?*/arch/arm/plat-omap/include/plat/omap-pm.h +1
-1-int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r); +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r);?/**
arch/arm/plat-omap/include/plat/omap_device.h +0
-0@@ -32,9 +32,11 @@?#define
__ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H?#include <
linux/kernel.h>
+#include <linux/plist.h>
?#include <linux/platform_device.h>?#include <
plat/omap_hwmod.h>
+#include <plat/omap-pm.h>?extern struct device
omap_device_parent;arch/arm/plat-omap/include/plat/omap_device.h +9
-0@@ -73,6 +75,15 @@ struct omap_device { ? ? ? ?s8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pm_lat_level; ? ? ? ?u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?hwmods_cnt; ? ? ? ?u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_state; + +}; + +/* Linked list for the devices constraints entries */ +struct omap_device_constraints_entry { + ? ? ? struct device ? ? ? ? ? ? ? ? ? *req_dev; + ? ? ? void ? ? ? ? ? ? ? ? ? ? ? ? ? ?*target; + ? ? ? unsigned long ? ? ? ? ? ? ? ? ? constraint_value; + ? ? ? struct plist_node ? ? ? ? ? ? ? node; ?};?/* Device driver interface (call via
platform_datafn ptrs) */arch/arm/plat-omap/include/plat/omap_device.h +3
-0@@ -107,6 +118,9 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od); ?int omap_device_align_pm_lat(struct platform_device *pdev, ? ? ? ? ? ? ? ? ? ? ? ? ? ? u32 new_wakeup_lat_limit); ?struct powerdomain *omap_device_get_pwrdm(struct omap_device *od); +int omap_device_set_dev_constraint (enum omap_pm_constraint_class class, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *dev, long t); ?u32 omap_device_get_context_loss_count(struct platform_device *pdev);?/* Other */
arch/arm/plat-omap/include/plat/omap_hwmod.h +1
-0@@ -597,6 +597,7 @@ int omap_hwmod_for_each_by_class(const char *classname, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? void *user); ?int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state); +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency); ?u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);?/*
arch/arm/plat-omap/omap-pm-constraints.c +0
-0@@ -24,6 +24,7 @@?/* Interface documentation is in
mach/omap-pm.h*/ ?#include <plat/omap-pm.h>
?#include <plat/omap_device.h>
+#include <plat/common.h>?static bool
off_mode_enabled;
?static u32dummy_context_loss_counter;arch/arm/plat-omap/omap-pm-constraints.c +0
-0@@ -32,35 +33,46 @@ static u32 dummy_context_loss_counter; ?* Device-driver-originated constraints (via board-*.c files)?*/
arch/arm/plat-omap/omap-pm-constraints.c +6
-1-int omap_pm_set_max_mpu_wakeup_lat (struct device *dev,long t) +/* +* Generic function to omap_device layer for the constraints API. +*/ +static int omap_pm_set_dev_constraint (enum omap_pm_constraint_class class, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct device *req_dev, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct device *dev, long t)?{
- ? ? ? if (!dev || t < -1) {
+ ? ? ? int ret = 0;
+
+ ? ? ? if (!req_dev || !dev || t < -1) {
? ? ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)",__func__); ? ? ? ? ? ? ? ?return-EINVAL;
- ? ? ? };arch/arm/plat-omap/omap-pm-constraints.c +20
-18- - ? ? ? if (t == -1) - ? ? ? ? ? ? ? pr_debug("OMAP PM: remove max MPU wakeup latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? ? else - ? ? ? ? ? ? ? pr_debug("OMAP PM: add max MPU wakeup latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); + ? ? ? } - ? ? ? /* - ? ? ? ?* For current Linux, this needs to map the MPU to a - ? ? ? ?* powerdomain, then go through the list of current max lat - ? ? ? ?* constraints on the MPU and find the smallest. ?If - ? ? ? ?* the latency constraint has changed, the code should - ? ? ? ?* recompute the state to enter for the next powerdomain - ? ? ? ?* state. - ? ? ? ?* - ? ? ? ?* TI CDP code can call constraint_set here. - ? ? ? ?*/ + ? ? ? /* Try to catch non omap_device for dev */ + ? ? ? if (dev->parent == &omap_device_parent) { + ? ? ? ? ? ? ? if (t == -1) + ? ? ? ? ? ? ? ? ? ? ? pr_debug("OMAP PM: remove constraint of class %d " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"from req_dev %s on dev %s\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?class, dev_name(req_dev), dev_name(dev)); + ? ? ? ? ? ? ? else + ? ? ? ? ? ? ? ? ? ? ? pr_debug("OMAP PM: add constraint of class %d " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"from req_dev %s on dev %s, t = %ld\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?class, dev_name(req_dev), dev_name(dev), t); + + ? ? ? ? ? ? ? /* Call the omap_device API */ + ? ? ? ? ? ? ? ret = omap_device_set_dev_constraint(class, req_dev, dev, t); + ? ? ? } else { + ? ? ? ? ? ? ? pr_err("OMAP-PM set_wakeup_lat: Error: platform device " + ? ? ? ? ? ? ? ? ? ? ?"not valid\n"); + ? ? ? ? ? ? ? return -EINVAL; + ? ? ? } - ? ? ? return 0; + ? ? ? return ret;?}
arch/arm/plat-omap/omap-pm-constraints.c +4
-1-int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +/* +* omap_pm_set_min_bus_tput - set/release bus throughput constraints +*/ +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r)?{
? ? ? ?if (!dev || (agent_id!=OCP_INITIATOR_AGENT&& ? ? ? ? ? ?agent_id !=OCP_TARGET_AGENT)) {arch/arm/plat-omap/omap-pm-constraints.c +0
-8@@ -68,83 +80,56 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) ? ? ? ? ? ? ? ?return -EINVAL; ? ? ? ?}; - ? ? ? if (r == 0) - ? ? ? ? ? ? ? pr_debug("OMAP PM: remove min bus tput constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s for agent_id %d\n", dev_name(dev), agent_id); - ? ? ? else - ? ? ? ? ? ? ? pr_debug("OMAP PM: add min bus tput constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s for agent_id %d: rate %ld KiB\n", - ? ? ? ? ? ? ? ? ? ? ? ?dev_name(dev), agent_id, r); -? ? ? ?/*
- ? ? ? ?* This code should model the interconnect and compute the
- ? ? ? ?* required clock frequency, convert that to a VDD2 OPP ID, then
- ? ? ? ?* set the VDD2 OPP appropriately.
- ? ? ? ?*
- ? ? ? ?* TI CDP code can callconstraint_sethere on the VDD2 OPP.
+ ? ? ? ?* This code calls the genericomap_deviceAPI function
+ ? ? ? ?*omap_pm_set_dev_constraintwith the class
+ ? ? ? ?*OMAP_PM_CONSTRAINT_THROUGHPUT.omap_pm_set_dev_constraint
+ ? ? ? ?* should manage the constraints lists and call the appropriate
Quoted 8 lines
+ ? ? ? ?* low level code that models the interconnect, computes the required
+ ? ? ? ?* clock frequency, converts that to a VDD2 OPP ID and sets the
+ ? ? ? ?* VDD2 OPP appropriately.
? ? ? ? */
-
- ? ? ? return 0;
+ ? ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_THROUGHPUT,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev, dev, r);
The tput constraint API is not clear to me. What is the agent_id field for? Can this be replaced by a requester device ptr?
Quoted 111 lines
?}
+/*
+ *omap_pm_set_max_dev_wakeup_lat- set/release devices wake-up latency
+ * constraints
+ */
?intomap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? long t)
?{
- ? ? ? if (!req_dev || !dev || t < -1) {
- ? ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- ? ? ? ? ? ? ? return-EINVAL;
- ? ? ? };arch/arm/plat-omap/omap-pm-constraints.c +2
-22- - ? ? ? if (t == -1) - ? ? ? ? ? ? ? pr_debug("OMAP PM: remove max device latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? ? else - ? ? ? ? ? ? ? pr_debug("OMAP PM: add max device latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); - - ? ? ? /* - ? ? ? ?* For current Linux, this needs to map the device to a - ? ? ? ?* powerdomain, then go through the list of current max lat - ? ? ? ?* constraints on that powerdomain and find the smallest. ?If - ? ? ? ?* the latency constraint has changed, the code should - ? ? ? ?* recompute the state to enter for the next powerdomain - ? ? ? ?* state. ?Conceivably, this code should also determine - ? ? ? ?* whether to actually disable the device clocks or not, - ? ? ? ?* depending on how long it takes to re-enable the clocks. - ? ? ? ?* - ? ? ? ?* TI CDP code can call constraint_set here. - ? ? ? ?*/ - - ? ? ? return 0; + ? ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, dev, t);?}
arch/arm/plat-omap/omap-pm-constraints.c +8
-1-int omap_pm_set_max_sdma_lat (struct device *dev,long t) +/* +* omap_pm_set_max_mpu_wakeup_lat - set/release MPU wake-up latency +* constraints +* +* Maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the MPU device as constraints target. +*/ +int omap_pm_set_max_mpu_wakeup_lat (struct device *req_dev,long t)?{
- ? ? ? if (!dev || t < -1) {
- ? ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- ? ? ? ? ? ? ? return-EINVAL;
- ? ? ? };arch/arm/plat-omap/omap-pm-constraints.c +16
-20- - ? ? ? if (t == -1) - ? ? ? ? ? ? ? pr_debug("OMAP PM: remove max DMA latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? ? else - ? ? ? ? ? ? ? pr_debug("OMAP PM: add max DMA latency constraint: " - ? ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); - - ? ? ? /* - ? ? ? ?* For current Linux PM QOS params, this code should scan the - ? ? ? ?* list of maximum CPU and DMA latencies and select the - ? ? ? ?* smallest, then set cpu_dma_latency pm_qos_param - ? ? ? ?* accordingly. - ? ? ? ?* - ? ? ? ?* For future Linux PM QOS params, with separate CPU and DMA - ? ? ? ?* latency params, this code should just set the dma_latency param. - ? ? ? ?* - ? ? ? ?* TI CDP code can call constraint_set here. - ? ? ? ?*/ + ? ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, omap2_get_mpuss_device(), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t); +} - ? ? ? return 0; +/* +* omap_pm_set_max_sdma_lat - set/release SDMA start latency +* constraints +* +* Currently maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the L3 device as constraints target. +*/ +int omap_pm_set_max_sdma_lat (struct device *req_dev,long t) +{ + ? ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, omap2_get_l3_device(), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t);?}
?int
omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r)arch/arm/plat-omap/omap-pm-noop.c +1
-1@@ -61,7 +61,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t) ? ? ? ?return 0; ?} -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r) ?{? ? ? ?if (!dev || (
agent_id!=OCP_INITIATOR_AGENT&& ? ? ? ? ? ?agent_id !=OCP_TARGET_AGENT)) {arch/arm/plat-omap/omap_device.c +0
-0
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 300
Quoted 9 lines
arch/arm/plat-omap/omap_device.c +6
-0@@ -292,10 +292,189 @@ static void _add_optional_clock_clkdev(struct omap_device *od, ? ? ? ?} ?} +/* plist that stores the devices wake-up latency constraints */ +static struct plist_head omap_device_wkup_lat_constraints_list; +/* Spinlock that protects the constraints lists */ +static spinlock_t omap_device_constraints_lock; +/* Mutex that protects the constraints lists ops */ +static struct mutex omap_device_constraints_mutex;
Is that OK to do so to define the internal variables?
Quoted 70 lines
arch/arm/plat-omap/omap_device.c +70
-0+ +/* + * omap_device_store_constraint: add/update/remove a constraint from a plist + * + * @constraints_list: plist to use + * @req_dev: constraint requester, used to track the requests + * @target: target which the constraint applies to (e.g. power domain ID or + * ?ptr for wake-up latency constraints) + * @value: constraint value. The plist is sorted by the value. -1 remove the + * ?constraint from the list + * + * Returns the strongest constraint value for the given target, 0 in the + * case there is no constraint on the given target or a negative value in + * case of error. + * The caller must check the validity of the parameters. + */ +static long omap_device_store_constraint(struct plist_head *constraints_list, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev, void *target, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?long value) +{ + ? ? ? struct omap_device_constraints_entry *user; + ? ? ? int found = 0, ret = 0; + + ? ? ? mutex_lock(&omap_device_constraints_mutex); + + ? ? ? /* Check if the constraint requester is already in the list */ + ? ? ? plist_for_each_entry(user, constraints_list, node) { + ? ? ? ? ? ? ? if (user->req_dev == req_dev) { + ? ? ? ? ? ? ? ? ? ? ? found = 1; + ? ? ? ? ? ? ? ? ? ? ? break; + ? ? ? ? ? ? ? } + ? ? ? } + + ? ? ? if (value >= 0) { + ? ? ? ? ? ? ? /* Add new entry to the list or update existing request */ + ? ? ? ? ? ? ? if (found && + ? ? ? ? ? ? ? ? ? user->constraint_value == value && + ? ? ? ? ? ? ? ? ? user->target == target) { + ? ? ? ? ? ? ? ? ? ? ? goto exit_ok; + ? ? ? ? ? ? ? } else if (!found) { + ? ? ? ? ? ? ? ? ? ? ? user = kzalloc( + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct omap_device_constraints_entry), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL); + ? ? ? ? ? ? ? ? ? ? ? if (!user) { + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? pr_err("%s: FATAL ERROR: kzalloc failed\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__); + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM; + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? goto exit_error; + ? ? ? ? ? ? ? ? ? ? ? } + ? ? ? ? ? ? ? ? ? ? ? user->req_dev = req_dev; + ? ? ? ? ? ? ? } else { + ? ? ? ? ? ? ? ? ? ? ? plist_del(&user->node, constraints_list); + ? ? ? ? ? ? ? } + + ? ? ? ? ? ? ? plist_node_init(&user->node, value); + ? ? ? ? ? ? ? plist_add(&user->node, constraints_list); + ? ? ? ? ? ? ? user->node.prio = user->constraint_value = value; + ? ? ? ? ? ? ? user->target = target; + ? ? ? } else { + ? ? ? ? ? ? ? /* Remove the constraint from the list */ + ? ? ? ? ? ? ? if (!found) { + ? ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error: no prior constraint to release\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__); + ? ? ? ? ? ? ? ? ? ? ? ret = -EINVAL; + ? ? ? ? ? ? ? ? ? ? ? goto exit_error; + ? ? ? ? ? ? ? } + + ? ? ? ? ? ? ? plist_del(&user->node, constraints_list); + ? ? ? ? ? ? ? kfree(user); + ? ? ? }
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 380
Quoted 10 lines
arch/arm/plat-omap/omap_device.c +10
-0+ +exit_ok: + ? ? ? /* Find the strongest constraint for the given target */ + ? ? ? ret = 0; + ? ? ? plist_for_each_entry(user, constraints_list, node) { + ? ? ? ? ? ? ? if (user->target == target) { + ? ? ? ? ? ? ? ? ? ? ? ret = user->constraint_value; + ? ? ? ? ? ? ? ? ? ? ? break; + ? ? ? ? ? ? ? } + ? ? ? }
This is supposed to return the higher priority from the plist, and so the lowest constraint_value.
Although it is OK for wake-up latency it could not fit all constraints type (e.g. throughput requires the highest value).
I will correct this.
Quoted 105 lines
arch/arm/plat-omap/omap_device.c +6
-0+ +exit_error: + ? ? ? mutex_unlock(&omap_device_constraints_mutex); + + ? ? ? return ret; +}?/* Public functions for use by core code */
?/**
+ *omap_device_set_max_dev_wakeup_lat- set/release a device constraint
+ * @class: constraint class
+ * @dev: device to apply the constraint to. Must have an associatedomap_device
+ * @req_dev: constraint requester, used for tracking the constraints
+ *
+ * Using the primary hwmod, set/release a device constraint for the dev
+ * device, requested by thereq_devdevice. Depending of the constraint class
+ * this code calls the appropriate low level code, e.g. power domain for
+ * the wake-up latency constraints.
+ *
+ * If any hwmods exist for theomap_deviceassoiated with @dev and @req_dev,
+ * set/release the constraint for the corresponding hwmods, otherwise return
+ *-EINVAL.
+ */arch/arm/plat-omap/omap_device.c +73
-0+int omap_device_set_dev_constraint(enum omap_pm_constraint_class class, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *dev, long t) +{ + ? ? ? struct omap_device *od; + ? ? ? struct omap_hwmod *oh; + ? ? ? struct platform_device *pdev; + ? ? ? struct powerdomain *pwrdm = NULL; + ? ? ? u32 ret = -EINVAL; + + ? ? ? /* Look for the platform device for dev */ + ? ? ? pdev = to_platform_device(dev); + + ? ? ? /* Try to catch non platform devices. */ + ? ? ? if (pdev->name == NULL) { + ? ? ? ? ? ? ? pr_err("%s: Error: platform device for device %s not valid\n", + ? ? ? ? ? ? ? ? ? ? ?__func__, dev_name(dev)); + ? ? ? ? ? ? ? return -EINVAL; + ? ? ? } + + ? ? ? /* Find the associated omap_device for dev */ + ? ? ? od = _find_by_pdev(pdev); + ? ? ? if (!(od->hwmods_cnt)) { + ? ? ? ? ? ? ? pr_err("%s: Error: No hwmod for device %s\n", + ? ? ? ? ? ? ? ? ? ? ?__func__, dev_name(dev)); + ? ? ? ? ? ? ? return -EINVAL; + ? ? ? } + + ? ? ? /* Find the associated omap_hwmod for dev */ + ? ? ? oh = od->hwmods[0]; + + ? ? ? switch (class) { + ? ? ? case OMAP_PM_CONSTRAINT_WKUP_LAT: + ? ? ? ? ? ? ? /* Find the pwrdm associated to dev */ + ? ? ? ? ? ? ? pwrdm = omap_device_get_pwrdm(od); + ? ? ? ? ? ? ? if (!pwrdm) { + ? ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error: No pwrdm for device %s\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__, dev_name(dev)); + ? ? ? ? ? ? ? ? ? ? ? ret = -EINVAL; + ? ? ? ? ? ? ? ? ? ? ? break; + ? ? ? ? ? ? ? } + + ? ? ? ? ? ? ? /* + ? ? ? ? ? ? ? ?* Store the constraint in the appropriate list and find the + ? ? ? ? ? ? ? ?* strongest constraint for the given pwrdm + ? ? ? ? ? ? ? ?*/ + ? ? ? ? ? ? ? ret = omap_device_store_constraint( + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &omap_device_wkup_lat_constraints_list, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, (void *) pwrdm, t); + + ? ? ? ? ? ? ? /* Apply the constraint to the corresponding pwrdm */ + ? ? ? ? ? ? ? if (ret >= 0) { + ? ? ? ? ? ? ? ? ? ? ? ret = omap_hwmod_update_power_state(oh, ret); + ? ? ? ? ? ? ? } else { + ? ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error storing the constraint for device " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"%s\n", __func__, dev_name(dev)); + ? ? ? ? ? ? ? } + + ? ? ? ? ? ? ? break; + ? ? ? case OMAP_PM_CONSTRAINT_THROUGHPUT: + ? ? ? ? ? ? ? WARN(1, "OMAP PM: %s: Bus throughput constraint class \ + ? ? ? ? ? ? ? ? ? ?not implemented\n", __func__); + ? ? ? ? ? ? ? ret = -EINVAL; + ? ? ? ? ? ? ? break; + ? ? ? default: + ? ? ? ? ? ? ? WARN(1, "OMAP PM: %s: invalid constraint class %d", + ? ? ? ? ? ? ? ? ? ?__func__, class); + ? ? ? } + + ? ? ? return ret; +} + +/**?*
omap_device_get_context_loss_count- get lost context count ?* @od: structomap_device*
?*arch/arm/plat-omap/omap_device.c +1
-0@@ -824,6 +1003,14 @@ struct device omap_device_parent = { ?static int __init omap_device_init(void) ?{ + ? ? ? /* Initialize priority ordered list for wakeup latency constraint */
arch/arm/plat-omap/omap_device.c struct device omap_device_parent = { · line 1016
Quoted 10 lines
arch/arm/plat-omap/omap_device.c +7
-0+ ? ? ? spin_lock_init(&omap_device_constraints_lock); + ? ? ? plist_head_init(&omap_device_wkup_lat_constraints_list, + ? ? ? ? ? ? ? ? ? ? ? &omap_device_constraints_lock); + + ? ? ? /* res_mutex protects res_list add and del ops */ + ? ? ? mutex_init(&omap_device_constraints_mutex); + ? ? ? ?return device_register(&omap_device_parent); ?} ?core_initcall(omap_device_init);
Is it OK to initialize the list, lock and mutex here? This code runs very early in the boot sequence (right after hwmod init). Same remark about pwrdms_setup that overwrites the registers values.
Quoted 4 lines
--
1.7.2.3
Thanks for looking,
Jean
PATCH 2/2 OMAP: PM: implement devices constraints APIs
Jean Pihet <[email protected]> writes:
[...]
Quoted 9 lines
Quoted 2 lines
+ ? ? ? if (
pwrdm_read_pwrst(pwrdm)!=new_state) {
+ ? ? ? ? ? ? ? ret =omap_set_pwrdm_state(pwrdm, new_state);The function
pwrdms_setup(called fromomap3_pm_initfor every pwrdm) runs late in the boot process and so it overwrites the registers values programmed byomap_set_pwrdm_statewith the default values. Could the default values get written earlier in the boot process (e.g. at hwmod init) before the devices can put constraints on the power domains?
Yes, default vaules for each power domain's next state should probably be written earlier in the boot. Probably when the powerdomain is initialized, or at least when this constraints framework is initialized.
Then, the initial states set in omap3_pm_init() can just be removed.
Kevin
Paul Walmsley
maintainerPATCH 2/2 OMAP: PM: implement devices constraints APIs
In reply to Jean PihetHello Jean
Thanks for working on this stuff. Some comments based on a quick look...
Quoted 28 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating a unified API which callsomap_device_set_dev_constraintfor all classes of constraints (devices wake-up latency, devices throughput...).
The implementation of the constraints framework is at theomap_device
level: management and storage of the constraints, dispatching of the constraints to the appropriate low level layers.NOTE: only works for devices which have been converted to use
omap_device/omap_hwmod.Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
For the devices wake-up latency constraints, the power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>
Quoted 12 lines
--- arch/arm/mach-omap2/omap_hwmod.c | 29 ++++- arch/arm/mach-omap2/powerdomain.c | 99 +++++++++++++ arch/arm/mach-omap2/powerdomain.h | 24 +++- arch/arm/mach-omap2/powerdomains3xxx_data.c | 63 +++++++++ arch/arm/plat-omap/include/plat/omap-pm.h | 6 +- arch/arm/plat-omap/include/plat/omap_device.h | 14 ++ arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 + arch/arm/plat-omap/omap-pm-constraints.c | 161 ++++++++++------------ arch/arm/plat-omap/omap-pm-noop.c | 2 +- arch/arm/plat-omap/omap_device.c | 187 +++++++++++++++++++++++++ 10 files changed, 493 insertions(+), 93 deletions(-)
Please split this patch up into several patches:
- the powerdomain.h/powerdomain.c changes
- the powerdomains*_data.c changes
- any changes you want to make to the omap-pm.h interface, and if those require changes to the omap-pm-*.c files, change those here too
- omap_hwmod changes (if needed, which I don't think they are)
- omap_device changes
- omap-pm-constraints changes
Quoted 31 lines
arch/arm/mach-omap2/omap_hwmod.c +16
-0@@ -142,6 +142,7 @@#include "powerdomain.h" #include <plat/clock.h> #include <plat/omap_hwmod.h> +#include <plat/omap_device.h> #include <plat/prcm.h> #include "cm2xxx_3xxx.h" @@ -2277,11 +2278,37 @@ ohsps_unlock:return ret; } +/* +* omap_hwmod_update_power_state - Update the power domain power state of +* @oh +* +* @oh: struct omap_hwmod* to which the requesting device belongs to. +* @min_latency: the allowed wake-up latency for the power domain of @oh. +* +* Finds the power domain next power state that fulfills the constraint. +* Applies the constraint to the power domain by calling +* pwrdm_wakeuplat_update_pwrst. +* +* Returns 0 upon success. +*/ +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency) +{
arch/arm/mach-omap2/omap_hwmod.c ohsps_unlock: · line 2305
Quoted 10 lines
arch/arm/mach-omap2/omap_hwmod.c +10
-0+struct powerdomain *pwrdm =omap_hwmod_get_pwrdm (oh); + +if (!PTR_ERR (pwrdm)) { +pr_err ("omap_hwmod: Error: could not find parent " +"powerdomain for %s\n" , oh->name); +return -EINVAL ; + } + +return pwrdm_wakeuplat_update_pwrst (pwrdm, min_latency); +}
I don't think this function is needed. Might as well just take care of it in your omap_device code.
Quoted 33 lines
arch/arm/mach-omap2/omap_hwmod.c +2
-1+/** * omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss +* Query the powerdomain of @oh to get the context loss * count for this device. * * Returns the context loss count of the powerdomain assocated with @oh arch/arm/mach-omap2/powerdomain.c +8
-0@@ -19,6 +19,7 @@#include <linux/list.h> #include <linux/errno.h> #include <linux/string.h> +#include "cm2xxx_3xxx.h" #include "prcm44xx.h" #include "cm44xx.h" @@ -176,6 +177,104 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused)return 0 ; } +/* +* Test if the current powerdomain is MPU or CORE +* +* This function is only used by pwrdm_wakeuplat_update_pwrst +* which applies the MPU and CORE power domains constraints using PM QOS. +* +* This will disappear when all power domains will be controlled directly
arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 196
Quoted 10 lines
arch/arm/mach-omap2/powerdomain.c +10
-0+* from the wake-up latency constraints framework +*/ +static inline int is_pwrdm_mpu_or_core (struct powerdomain *pwrdm) +{ +if ((strncmp (pwrdm->name,"mpu_pwrdm" ,9 ) ==0 ) || + (strncmp (pwrdm->name,"core_pwrdm" ,10 ) ==0 )) +return 1 ; +else +return 0 ; +}
Please add some kind of powerdomain flag instead, set in some OMAP3 powerdomain-specific init code, rather than strncmp().
Quoted 101 lines
arch/arm/mach-omap2/powerdomain.c +81
-0+ +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* @min_latency: the allowed wake-up latency for the given power domain. +* +* Finds the power domain next power state that fulfills the constraint. +* Programs a new target state if it is different from current power state. +* +* Returns 0 upon success. +*/ +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency) +{ +int ret =0 , new_state =0 ; + +if (!pwrdm) { +WARN (1 ,"powerdomain: %s: invalid parameter(s)" , __func__); +return -EINVAL ; + } + +/* +* Apply constraints to MPU and CORE via the PM QOS API. +* Every power domain struct has a pm_qos_request_list field +*/ +if (is_pwrdm_mpu_or_core (pwrdm)) { +if (pm_qos_request_active (&(pwrdm->pm_qos_request))) +pm_qos_remove_request (&(pwrdm->pm_qos_request)); + +if (min_latency >=0 ) +pm_qos_add_request (&(pwrdm->pm_qos_request), +PM_QOS_CPU_DMA_LATENCY , + min_latency); +return 0 ; + } + +/* +* Apply constraints to pwrdm other than MPU and CORE by programming +* the pwrdm next power state. +*/ + +/* Find power state with wakeup latency < minimum constraint */ +for (new_state =0x0 ; new_state <PWRDM_MAX_PWRSTS ; new_state++) { +if (min_latency ==-1 || + pwrdm->wakeup_lat[new_state] <= min_latency) +break ; + } + +switch (new_state) { +case PWRDM_FUNC_PWRST_OFF : + new_state =PWRDM_POWER_OFF ; +break ; +case PWRDM_FUNC_PWRST_OSWR : +pwrdm_set_logic_retst (pwrdm,PWRDM_POWER_OFF ); + new_state =PWRDM_POWER_RET ; +break ; +case PWRDM_FUNC_PWRST_CSWR : +pwrdm_set_logic_retst (pwrdm,PWRDM_POWER_RET ); + new_state =PWRDM_POWER_RET ; +break ; +case PWRDM_FUNC_PWRST_ON : + new_state =PWRDM_POWER_ON ; +break ; +default : +pr_warn ("powerdomain: requested latency constraint not " +"supported %s set to ON state\n" , pwrdm->name); + new_state =PWRDM_POWER_ON ; +break ; + } + +if (pwrdm_read_pwrst (pwrdm) != new_state) { + ret =omap_set_pwrdm_state (pwrdm, new_state); + } + +pr_debug ("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " +"min_latency=%ld, set_state=%d\n" , pwrdm->name, +pwrdm_read_pwrst (pwrdm),pwrdm_read_prev_pwrst (pwrdm), +pwrdm_read_next_pwrst (pwrdm), min_latency, new_state); + +return ret; +} +/* Public functions */ /** arch/arm/mach-omap2/powerdomain.h +4
-1@@ -19,7 +19,10 @@#include <linux/types.h> #include <linux/list.h> - +#include <linux/plist.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/pm_qos_params.h> #include <linux/atomic.h> #include <plat/cpu.h>
arch/arm/mach-omap2/powerdomain.h line 55
Quoted 7 lines
arch/arm/mach-omap2/powerdomain.h +4
-0@@ -46,6 +49,15 @@#define PWRSTS_OFF_RET_ON (PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON)) +/* Powerdomain functional power states */ +#define PWRDM_FUNC_PWRST_OFF 0x0 +#define PWRDM_FUNC_PWRST_OSWR 0x1 +#define PWRDM_FUNC_PWRST_CSWR 0x2
You'll also want an _INACTIVE state here, per:
http://www.mail-archive.com/linux-omap at vger.kernel.org/msg43783.html
Quoted 9 lines
arch/arm/mach-omap2/powerdomain.h +5
-0+#define PWRDM_FUNC_PWRST_ON 0x3 + +#define PWRDM_MAX_FUNC_PWRSTS 4 + +#define UNSUP_STATE -1/* Powerdomain flags */ #define PWRDM_HAS_HDWR_SAR (1 << 0)/* hardware save-and-restore support */
arch/arm/mach-omap2/powerdomain.h struct powerdomain; · line 113
Quoted 7 lines
arch/arm/mach-omap2/powerdomain.h +3
-1@@ -96,7 +108,11 @@ struct powerdomain;* @state_counter: * @timer: * @state_timer: -* +* @wakeup_lat: wakeup latencies for possible powerdomain power states +* Note about the wakeup latencies ordering: the values must be sorted +* in decremental order
Would be good to specify the unit of time here.
Quoted 28 lines
arch/arm/mach-omap2/powerdomain.h +6
-0+* @pm_qos_request: PM QOS handle, only used to control the MPU and CORE power +* domains states; to be removed when a generic solution is in place. * @prcm_partition possible values are defined in mach-omap2/prcm44xx.h. */ struct powerdomain {@@ -121,6 +137,8 @@ struct powerdomain {s64 timer;s64 state_timer[PWRDM_MAX_PWRSTS ];#endif +const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS ]; +struct pm_qos_request_list pm_qos_request; };/** @@ -210,6 +228,8 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm);int pwrdm_pre_transition (void );int pwrdm_post_transition (void );int pwrdm_set_lowpwrstchange (struct powerdomain *pwrdm); + +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency);u32 pwrdm_get_context_loss_count (struct powerdomain *pwrdm);extern void omap2xxx_powerdomains_init (void );arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0
arch/arm/mach-omap2/powerdomains3xxx_data.c line 36
Quoted 6 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +3
-0@@ -31,6 +31,9 @@/* * Powerdomains +* +* The wakeup_lat values are derived from measurements on +* the actual target.
Which type of OMAP3 chip were these measured on? OMAP34xx/35xx, OMAP36xx/37xx, AM3505/17 ?
Also it would be good to know the sys_clk rate and the VDD1/2 OPPs that you took these measurements at. Do you have a sense of how much these measurements vary based on those three factors? Presumably, 12MHz/125MHz/83MHz would be the worst case, for the standard OPPs anyway.
In general, if you could elaborate further how you measured these, that would be good. Some of these measurements seem to be too low (described below).
I'm not sure if a strictly static table is the right approach for these measurements. It might be good to start with a static table that represents the lowest possible latencies, measured with DPLL autoidle disabled, and then to add or remove amounts from those numbers dynamically based on the state of other devices. For example, in terms of CORE, the AUTOEXTCLKMODE settings and the amount of time it takes the external HF oscillator to restart will have a major impact on the CORE OFF->ON measurements, potentially several milliseconds. Similarly, if DPLL1, 2, or 3 have to relock, that could take quite a bit of time, potentially several hundred microseconds.
Quoted 4 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0*/ static struct powerdomain iva2_pwrdm = {
arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain iva2_pwrdm = { · line 64
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -52,6 +55,12 @@ static struct powerdomain iva2_pwrdm = { [2] = PWRSTS_OFF_ON, [3] = PWRDM_POWER_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 350, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };
Was this measured with DPLL2 autoidle enabled or disabled?
arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain mpu_3xxx_pwrdm = { · line 86
Quoted 13 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +77,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { .pwrsts_mem_on = { [0] = PWRSTS_OFF_ON, }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 95, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 45, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };
Was this measured with DPLL1 autoidle enabled or disabled?
That OFF->ON time looks really low to me...
Quoted 16 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0/* @@ -98,6 +113,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1 ] =PWRSTS_OFF_RET_ON ,/* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 60, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain core_3xxx_es3_1_pwrdm = {
arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain core_3xxx_es3_1_pwrdm = { · line 151
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -121,6 +142,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = { [0] = PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ [1] = PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 100, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 60, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };
The figures for the CORE powerdomain look implausibly low. Do these figures represent the amount of time required to transition from the low power state to the point at which Linux is running again? Or do they represent something else?
Quoted 95 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +36
-0static struct powerdomain dss_pwrdm = {@@ -136,6 +163,12 @@ static struct powerdomain dss_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 70, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 20, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };/* @@ -157,6 +190,12 @@ static struct powerdomain sgx_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 1000, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain cam_pwrdm = {@@ -172,6 +211,12 @@ static struct powerdomain cam_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 850, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain per_pwrdm = {@@ -187,6 +232,12 @@ static struct powerdomain per_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 200, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 110, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain emu_pwrdm = {@@ -201,6 +252,12 @@ static struct powerdomain neon_pwrdm = { .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430), .pwrsts = PWRSTS_OFF_RET_ON, .pwrsts_logic_ret = PWRDM_POWER_RET, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 200, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 35, + [PWRDM_FUNC_PWRST_ON] = 0, + }, };static struct powerdomain usbhost_pwrdm = {@@ -223,6 +280,12 @@ static struct powerdomain usbhost_pwrdm = { .pwrsts_mem_on = { [0 ] =PWRDM_POWER_ON ,/* MEMONSTATE */ }, + .wakeup_lat = { + [PWRDM_FUNC_PWRST_OFF] = 800, + [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + [PWRDM_FUNC_PWRST_CSWR] = 150, + [PWRDM_FUNC_PWRST_ON] = 0, + }, }; static struct powerdomain dpll1_pwrdm = {arch/arm/plat-omap/include/plat/omap-pm.h +4
-0@@ -70,6 +70,10 @@ void omap_pm_if_exit(void);* Device-driver-originated constraints (via board-*.c files, platform_data) */ +enum omap_pm_constraint_class { +OMAP_PM_CONSTRAINT_WKUP_LAT , +OMAP_PM_CONSTRAINT_THROUGHPUT +};/** * omap_pm_set_max_mpu_wakeup_lat - set the maximum MPU wakeup latency
arch/arm/plat-omap/include/plat/omap-pm.h int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t); · line 144
Quoted 5 lines
arch/arm/plat-omap/include/plat/omap-pm.h +1
-1@@ -137,7 +141,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);* Returns -EINVAL for an invalid argument, -ERANGE if the constraint * is not satisfiable, or 0 upon success. */ -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r); +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r);
The documentation for this function states:
To remove the interconnect throughput restriction for this device, call with r = 0.
So an unsigned long seems reasonable here?
Quoted 35 lines
arch/arm/plat-omap/include/plat/omap-pm.h +0
-0/** arch/arm/plat-omap/include/plat/omap_device.h +11
-0@@ -32,9 +32,11 @@#define __ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H#include <linux/kernel.h> +#include <linux/plist.h> #include <linux/platform_device.h> #include <plat/omap_hwmod.h> +#include <plat/omap-pm.h> extern struct device omap_device_parent;@@ -73,6 +75,15 @@ struct omap_device {s8 pm_lat_level;u8 hwmods_cnt;u8 _state; + +}; + +/* Linked list for the devices constraints entries */ +struct omap_device_constraints_entry { +struct device *req_dev; +void *target; +unsigned long constraint_value; +struct plist_node node; };/* Device driver interface (call via platform_data fn ptrs) */
arch/arm/plat-omap/include/plat/omap_device.h void __iomem *omap_device_get_rt_va(struct omap_device *od); · line 123
Quoted 6 lines
arch/arm/plat-omap/include/plat/omap_device.h +3
-0@@ -107,6 +118,9 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od);int omap_device_align_pm_lat (struct platform_device *pdev,u32 new_wakeup_lat_limit);struct powerdomain *omap_device_get_pwrdm (struct omap_device *od); +int omap_device_set_dev_constraint (enum omap_pm_constraint_class class, +struct device *req_dev, +struct device *dev,long t);
This should be two separate functions, one for max wakeup latency and the other for minimum bandwidth... discussed further below.
Quoted 28 lines
arch/arm/plat-omap/include/plat/omap_device.h +0
-0u32 omap_device_get_context_loss_count (struct platform_device *pdev);/* Other */ arch/arm/plat-omap/include/plat/omap_hwmod.h +1
-0@@ -597,6 +597,7 @@ int omap_hwmod_for_each_by_class(const char *classname, void *user);int omap_hwmod_set_postsetup_state (struct omap_hwmod *oh,u8 state); +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency);u32 omap_hwmod_get_context_loss_count (struct omap_hwmod *oh);/* arch/arm/plat-omap/omap-pm-constraints.c +1
-0@@ -24,6 +24,7 @@/* Interface documentation is in mach/omap-pm.h */ #include <plat/omap-pm.h> #include <plat/omap_device.h> +#include <plat/common.h> static bool off_mode_enabled;static u32 dummy_context_loss_counter;
arch/arm/plat-omap/omap-pm-constraints.c static u32 dummy_context_loss_counter; · line 41
Quoted 10 lines
arch/arm/plat-omap/omap-pm-constraints.c +6
-1@@ -32,35 +33,46 @@ static u32 dummy_context_loss_counter;* Device-driver-originated constraints (via board-*.c files) */ -int omap_pm_set_max_mpu_wakeup_lat (struct device *dev,long t) +/* +* Generic function to omap_device layer for the constraints API. +*/ +static int omap_pm_set_dev_constraint (enum omap_pm_constraint_class class, +struct device *req_dev, +struct device *dev,long t)
For static functions, I'd suggest dropping the "omap_pm" prefix from the names of these functions, so they begin with an underscore.
Quoted 232 lines
arch/arm/plat-omap/omap-pm-constraints.c +66
-87{ -if (!dev || t <-1 ) { +int ret =0 ; + +if (!req_dev || !dev || t <-1 ) {WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__);return -EINVAL ; - }; - -if (t ==-1 ) -pr_debug ("OMAP PM: remove max MPU wakeup latency constraint: " -"dev %s\n" ,dev_name (dev)); -else -pr_debug ("OMAP PM: add max MPU wakeup latency constraint: " -"dev %s, t = %ld usec\n" ,dev_name (dev), t); + } -/* -* For current Linux, this needs to map the MPU to a -* powerdomain, then go through the list of current max lat -* constraints on the MPU and find the smallest. If -* the latency constraint has changed, the code should -* recompute the state to enter for the next powerdomain -* state. -* -* TI CDP code can call constraint_set here. -*/ +/* Try to catch non omap_device for dev */ +if (dev->parent == &omap_device_parent) { +if (t ==-1 ) +pr_debug ("OMAP PM: remove constraint of class %d " +"from req_dev %s on dev %s\n" , + class,dev_name (req_dev),dev_name (dev)); +else +pr_debug ("OMAP PM: add constraint of class %d " +"from req_dev %s on dev %s, t = %ld\n" , + class,dev_name (req_dev),dev_name (dev), t); + +/* Call the omap_device API */ + ret =omap_device_set_dev_constraint (class, req_dev, dev, t); + }else { +pr_err ("OMAP-PM set_wakeup_lat: Error: platform device " +"not valid\n" ); +return -EINVAL ; + } -return 0 ; +return ret; } -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +/* +* omap_pm_set_min_bus_tput - set/release bus throughput constraints +*/ +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r) {if (!dev || (agent_id !=OCP_INITIATOR_AGENT && agent_id !=OCP_TARGET_AGENT )) {@@ -68,83 +80,56 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r)return -EINVAL ; }; -if (r ==0 ) -pr_debug ("OMAP PM: remove min bus tput constraint: " -"dev %s for agent_id %d\n" ,dev_name (dev), agent_id); -else -pr_debug ("OMAP PM: add min bus tput constraint: " -"dev %s for agent_id %d: rate %ld KiB\n" , -dev_name (dev), agent_id, r); -/* -* This code should model the interconnect and compute the -* required clock frequency, convert that to a VDD2 OPP ID, then -* set the VDD2 OPP appropriately. -* -* TI CDP code can call constraint_set here on the VDD2 OPP. +* This code calls the generic omap_device API function +* omap_pm_set_dev_constraint with the class +* OMAP_PM_CONSTRAINT_THROUGHPUT. omap_pm_set_dev_constraint +* should manage the constraints lists and call the appropriate +* low level code that models the interconnect, computes the required +* clock frequency, converts that to a VDD2 OPP ID and sets the +* VDD2 OPP appropriately. */ - -return 0 ; +return omap_pm_set_dev_constraint (OMAP_PM_CONSTRAINT_THROUGHPUT , + dev, dev, r); } +/* +* omap_pm_set_max_dev_wakeup_lat - set/release devices wake-up latency +* constraints +*/ int omap_pm_set_max_dev_wakeup_lat (struct device *req_dev,struct device *dev,long t) { -if (!req_dev || !dev || t <-1 ) { -WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); -return -EINVAL ; - }; - -if (t ==-1 ) -pr_debug ("OMAP PM: remove max device latency constraint: " -"dev %s\n" ,dev_name (dev)); -else -pr_debug ("OMAP PM: add max device latency constraint: " -"dev %s, t = %ld usec\n" ,dev_name (dev), t); - -/* -* For current Linux, this needs to map the device to a -* powerdomain, then go through the list of current max lat -* constraints on that powerdomain and find the smallest. If -* the latency constraint has changed, the code should -* recompute the state to enter for the next powerdomain -* state. Conceivably, this code should also determine -* whether to actually disable the device clocks or not, -* depending on how long it takes to re-enable the clocks. -* -* TI CDP code can call constraint_set here. -*/ - -return 0 ; +return omap_pm_set_dev_constraint (OMAP_PM_CONSTRAINT_WKUP_LAT , + req_dev, dev, t); } -int omap_pm_set_max_sdma_lat (struct device *dev,long t) +/* +* omap_pm_set_max_mpu_wakeup_lat - set/release MPU wake-up latency +* constraints +* +* Maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the MPU device as constraints target. +*/ +int omap_pm_set_max_mpu_wakeup_lat (struct device *req_dev,long t) { -if (!dev || t <-1 ) { -WARN (1 ,"OMAP PM: %s: invalid parameter(s)" , __func__); -return -EINVAL ; - }; - -if (t ==-1 ) -pr_debug ("OMAP PM: remove max DMA latency constraint: " -"dev %s\n" ,dev_name (dev)); -else -pr_debug ("OMAP PM: add max DMA latency constraint: " -"dev %s, t = %ld usec\n" ,dev_name (dev), t); - -/* -* For current Linux PM QOS params, this code should scan the -* list of maximum CPU and DMA latencies and select the -* smallest, then set cpu_dma_latency pm_qos_param -* accordingly. -* -* For future Linux PM QOS params, with separate CPU and DMA -* latency params, this code should just set the dma_latency param. -* -* TI CDP code can call constraint_set here. -*/ +return omap_pm_set_dev_constraint (OMAP_PM_CONSTRAINT_WKUP_LAT , + req_dev,omap2_get_mpuss_device (), + t); +} -return 0 ; +/* +* omap_pm_set_max_sdma_lat - set/release SDMA start latency +* constraints +* +* Currently maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the L3 device as constraints target. +*/ +int omap_pm_set_max_sdma_lat (struct device *req_dev,long t) +{ +return omap_pm_set_dev_constraint (OMAP_PM_CONSTRAINT_WKUP_LAT , + req_dev,omap2_get_l3_device (), + t); }int omap_pm_set_min_clk_rate (struct device *dev,struct clk *c,long r)arch/arm/plat-omap/omap-pm-noop.c +1
-1@@ -61,7 +61,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t)return 0 ; } -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r) {if (!dev || (agent_id !=OCP_INITIATOR_AGENT && agent_id !=OCP_TARGET_AGENT )) {arch/arm/plat-omap/omap_device.c +30
-0@@ -292,10 +292,189 @@ static void _add_optional_clock_clkdev(struct omap_device *od, } } +/* plist that stores the devices wake-up latency constraints */ +static struct plist_head omap_device_wkup_lat_constraints_list; +/* Spinlock that protects the constraints lists */ +static spinlock_t omap_device_constraints_lock; +/* Mutex that protects the constraints lists ops */ +static struct mutex omap_device_constraints_mutex; + +/* +* omap_device_store_constraint: add/update/remove a constraint from a plist +* +* @constraints_list: plist to use +* @req_dev: constraint requester, used to track the requests +* @target: target which the constraint applies to (e.g. power domain ID or +* ptr for wake-up latency constraints) +* @value: constraint value. The plist is sorted by the value. -1 remove the +* constraint from the list +* +* Returns the strongest constraint value for the given target, 0 in the +* case there is no constraint on the given target or a negative value in +* case of error. +* The caller must check the validity of the parameters. +*/ +static long omap_device_store_constraint (struct plist_head *constraints_list, +struct device *req_dev,void *target, +long value) +{ +struct omap_device_constraints_entry *user; +int found =0 , ret =0 ; + +mutex_lock (&omap_device_constraints_mutex);
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 334
Quoted 10 lines
arch/arm/plat-omap/omap_device.c +10
-0+ +/* Check if the constraint requester is already in the list */ +plist_for_each_entry (user, constraints_list, node) { +if (user->req_dev == req_dev) { + found =1 ; +break ; + } + } + +if (value >=0 ) {
This should really be split into two functions, _add_constraint() and _remove_constraint(). You may wish to review Documentation/CodingStyle Chapter 6.
Quoted 63 lines
arch/arm/plat-omap/omap_device.c +59
-0+/* Add new entry to the list or update existing request */ +if (found && + user->constraint_value == value && + user->target == target) { + goto exit_ok; + }else if (!found) { + user =kzalloc ( +sizeof (struct omap_device_constraints_entry ), +GFP_KERNEL ); +if (!user) { +pr_err ("%s: FATAL ERROR: kzalloc failed\n" , + __func__); + ret = -ENOMEM ; + goto exit_error; + } + user->req_dev = req_dev; + }else { +plist_del (&user->node, constraints_list); + } + +plist_node_init (&user->node, value); +plist_add (&user->node, constraints_list); + user->node.prio = user->constraint_value = value; + user->target = target; + }else { +/* Remove the constraint from the list */ +if (!found) { +pr_err ("%s: Error: no prior constraint to release\n" , + __func__); + ret = -EINVAL ; + goto exit_error; + } + +plist_del (&user->node, constraints_list); +kfree (user); + } + +exit_ok: +/* Find the strongest constraint for the given target */ + ret =0 ; +plist_for_each_entry (user, constraints_list, node) { +if (user->target == target) { + ret = user->constraint_value; +break ; + } + } + +exit_error: +mutex_unlock (&omap_device_constraints_mutex); + +return ret; +}/* Public functions for use by core code */ /** +* omap_device_set_max_dev_wakeup_lat - set/release a device constraint +* @class: constraint class +* @dev: device to apply the constraint to. Must have an associated omap_device +* @req_dev: constraint requester, used for tracking the constraints +* +* Using the primary hwmod, set/release a device constraint for the dev +* device, requested by the req_dev device. Depending of the constraint class
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 407
Quoted 10 lines
arch/arm/plat-omap/omap_device.c +10
-0+* this code calls the appropriate low level code, e.g. power domain for +* the wake-up latency constraints. +* +* If any hwmods exist for the omap_device assoiated with @dev and @req_dev, +* set/release the constraint for the corresponding hwmods, otherwise return +* -EINVAL. +*/ +int omap_device_set_dev_constraint (enum omap_pm_constraint_class class, +struct device *req_dev, +struct device *dev,long t)
The name of this function doesn't match what's in the kerneldoc comment.
Quoted 14 lines
arch/arm/plat-omap/omap_device.c +14
-0+{ +struct omap_device *od; +struct omap_hwmod *oh; +struct platform_device *pdev; +struct powerdomain *pwrdm =NULL ; +u32 ret = -EINVAL ; + +/* Look for the platform device for dev */ + pdev =to_platform_device (dev); + +/* Try to catch non platform devices. */ +if (pdev->name ==NULL ) { +pr_err ("%s: Error: platform device for device %s not valid\n" , + __func__,dev_name (dev));
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 431
Quoted 10 lines
arch/arm/plat-omap/omap_device.c +10
-0+return -EINVAL ; + } + +/* Find the associated omap_device for dev */ + od =_find_by_pdev (pdev); +if (!(od->hwmods_cnt)) { +pr_err ("%s: Error: No hwmod for device %s\n" , + __func__,dev_name (dev)); +return -EINVAL ; + }
Please also pr_err() and bail out if there is more than one hwmod in the omap_device.
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 437
Quoted 6 lines
arch/arm/plat-omap/omap_device.c +6
-0+ +/* Find the associated omap_hwmod for dev */ + oh = od->hwmods[0 ]; + +switch (class) { +case OMAP_PM_CONSTRAINT_WKUP_LAT :
Please create two different functions, omap_device_set_max_dev_wakeup_lat() and omap_device_set_min_bus_tput(). Documentation/CodingStyle chapter 6.
Quoted 66 lines
arch/arm/plat-omap/omap_device.c +48
-0+/* Find the pwrdm associated to dev */ + pwrdm =omap_device_get_pwrdm (od); +if (!pwrdm) { +pr_err ("%s: Error: No pwrdm for device %s\n" , + __func__,dev_name (dev)); + ret = -EINVAL ; +break ; + } + +/* +* Store the constraint in the appropriate list and find the +* strongest constraint for the given pwrdm +*/ + ret =omap_device_store_constraint ( + &omap_device_wkup_lat_constraints_list, + req_dev, (void *) pwrdm, t); + +/* Apply the constraint to the corresponding pwrdm */ +if (ret >=0 ) { + ret =omap_hwmod_update_power_state (oh, ret); + }else { +pr_err ("%s: Error storing the constraint for device " +"%s\n" , __func__,dev_name (dev)); + } + +break ; +case OMAP_PM_CONSTRAINT_THROUGHPUT : +WARN (1 ,"OMAP PM: %s: Bus throughput constraint class \ +not implemented\n" , __func__); + ret = -EINVAL ; +break ; +default : +WARN (1 ,"OMAP PM: %s: invalid constraint class %d" , + __func__, class); + } + +return ret; +} + +/** * omap_device_get_context_loss_count - get lost context count * @od: struct omap_device * * @@ -824,6 +1003,14 @@ struct device omap_device_parent = {static int __init omap_device_init (void ) { +/* Initialize priority ordered list for wakeup latency constraint */ +spin_lock_init (&omap_device_constraints_lock); +plist_head_init (&omap_device_wkup_lat_constraints_list, + &omap_device_constraints_lock); + +/* res_mutex protects res_list add and del ops */ +mutex_init (&omap_device_constraints_mutex); +return device_register (&omap_device_parent); }core_initcall (omap_device_init);Signature · 6 lines
1.7.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
- Paul
PATCH 2/2 OMAP: PM: implement devices constraints APIs
Hi Paul,
Quoted 49 lines · Paul Walmsley
Hello Jean
Thanks for working on this stuff. ?Some comments based on a quick look...
Quoted 39 lines · Jean Pihet
Implement OMAP PM layer
omap_pm_set_max_dev_wakeup_latAPI by creating a unified API which callsomap_device_set_dev_constraintfor all classes of constraints (devices wake-up latency, devices throughput...).
The implementation of the constraints framework is at theomap_device
level: management and storage of the constraints, dispatching of the constraints to the appropriate low level layers.NOTE: only works for devices which have been converted to use ? ? ? omap_device/omap_hwmod.
Longer term, we could possibly remove this API from the OMAP PM layer, and instead directly use the device level API.
For the devices wake-up latency constraints, the power domains get the next power state programmed directly in the registers via
pwrdm_wakeuplat_update_pwrst.Note about PM QOS: the MPU and CORE power domains get the next power state via cpuidle, which get the strongest wake-up latency constraint by querying PM QOS. The usage of PM QOS is temporary, until a generic solution is in place.
Based on Vibhore's original patch, adapted to
omap_device,omap_hwmodand PM QOS frameworks.Signed-off-by Jean Pihet <[email protected]>Cc Vibhore Vardhan <[email protected]>---
?arch/arm/mach-omap2/omap_hwmod.c ? ? ? ? ? ? ?| ? 29 ++++- ?arch/arm/mach-omap2/powerdomain.c ? ? ? ? ? ? | ? 99 +++++++++++++ ?arch/arm/mach-omap2/powerdomain.h ? ? ? ? ? ? | ? 24 +++- ?arch/arm/mach-omap2/powerdomains3xxx_data.c ? | ? 63 +++++++++ ?arch/arm/plat-omap/include/plat/omap-pm.h ? ? | ? ?6 +- ?arch/arm/plat-omap/include/plat/omap_device.h | ? 14 ++ ?arch/arm/plat-omap/include/plat/omap_hwmod.h ?| ? ?1 + ?arch/arm/plat-omap/omap-pm-constraints.c ? ? ?| ?161 ++++++++++------------ ?arch/arm/plat-omap/omap-pm-noop.c ? ? ? ? ? ? | ? ?2 +- ?arch/arm/plat-omap/omap_device.c ? ? ? ? ? ? ?| ?187 +++++++++++++++++++++++++Quoted 1 line
?10 files changed, 493 insertions(+), 93 deletions(-)
Please split this patch up into several patches:
Quoted 7 lines
- the
powerdomain.h/powerdomain.cchanges
- the powerdomains*_data.c changes
- any changes you want to make to theomap-pm.hinterface, and if those ?require changes to the omap-pm-*.c files, change those here too
-omap_hwmodchanges (if needed, which I don't think they are)
-omap_devicechanges
- omap-pm-constraints changes
Ok that will make the patch easier to read (and digest).
Quoted 37 lines
Quoted 37 lines
arch/arm/mach-omap2/omap_hwmod.c +0
-0@@ -142,6 +142,7 @@?#include "
powerdomain.h"
?#include <plat/clock.h>
?#include <plat/omap_hwmod.h>
+#include <plat/omap_device.h>
?#include <plat/prcm.h>?#include "
cm2xxx_3xxx.h"arch/arm/mach-omap2/omap_hwmod.c +20
-0@@ -2277,11 +2278,37 @@ ohsps_unlock: ? ? ? return ret; ?} +/* +* omap_hwmod_update_power_state - Update the power domain power state of +* @oh +* +* @oh: struct omap_hwmod* to which the requesting device belongs to. +* @min_latency: the allowed wake-up latency for the power domain of @oh. +* +* Finds the power domain next power state that fulfills the constraint. +* Applies the constraint to the power domain by calling +* pwrdm_wakeuplat_update_pwrst. +* +* Returns 0 upon success. +*/ +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency) +{ + ? ? struct powerdomain *pwrdm = omap_hwmod_get_pwrdm(oh); + + ? ? if (!PTR_ERR(pwrdm)) { + ? ? ? ? ? ? pr_err("omap_hwmod: Error: could not find parent " + ? ? ? ? ? ? ? ? ? ? "powerdomain for %s\n", oh->name);
Quoted 8 lines
arch/arm/mach-omap2/omap_hwmod.c ohsps_unlock: · line 2305
Quoted 5 lines
arch/arm/mach-omap2/omap_hwmod.c +5
-0+ ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? return pwrdm_wakeuplat_update_pwrst(pwrdm, min_latency); +}I don't think this function is needed. ?Might as well just take care of it in your
omap_devicecode.
I did not have it originally but arch/arm/mach-omap2/powerdomain.h is not included in arch/arm/plat-omap/include/plat/omap_device.c, so I think I have to pass the call through the hwmod layer. Please let me know if that is allowed. I do not see any pwrdm code in omap_device.c (excepted omap_device_get_pwrdm(od)).
Quoted 39 lines
Quoted 39 lines
arch/arm/mach-omap2/omap_hwmod.c +1
-0+?/**
? *omap_hwmod_get_context_loss_count- get lost context count ? * @oh: structomap_hwmod*
? *
- * Query the powerdomain of of @oh to get the context loss
+ * Query the powerdomain of @oh to get the context loss
? * count for this device.
? *
? * Returns the context loss count of the powerdomain assocated with @oharch/arm/mach-omap2/powerdomain.c +0
-0@@ -19,6 +19,7 @@?#include <
linux/list.h>
?#include <linux/errno.h>
?#include <linux/string.h>
+
?#include "cm2xxx_3xxx.h"
?#include "prcm44xx.h"
?#include "cm44xx.h"arch/arm/mach-omap2/powerdomain.c +12
-0@@ -176,6 +177,104 @@ static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) ? ? ? return 0; ?} +/* +* Test if the current powerdomain is MPU or CORE +* +* This function is only used by pwrdm_wakeuplat_update_pwrst +* which applies the MPU and CORE power domains constraints using PM QOS. +* +* This will disappear when all power domains will be controlled directly +* from the wake-up latency constraints framework +*/ +static inline int is_pwrdm_mpu_or_core (struct powerdomain *pwrdm) +{ + ? ? if ((strncmp(pwrdm->name, "mpu_pwrdm", 9) == 0) ||
Quoted 8 lines
arch/arm/mach-omap2/powerdomain.c static int _pwrdm_post_transition_cb(struct powerdomain *pwrdm, void *unused) · line 196
Quoted 5 lines
arch/arm/mach-omap2/powerdomain.c +5
-0+ ? ? ? ? (strncmp(pwrdm->name, "core_pwrdm", 10) == 0)) + ? ? ? ? ? ? return 1; + ? ? else + ? ? ? ? ? ? return 0; +}Please add some kind of powerdomain flag instead, set in some OMAP3 powerdomain-specific init code, rather than
strncmp().
Ok I am looking at it. Note that this code is scheduled for removal, in favor of a generic solution that uses pwrdm code only (i.e. not PM QOS).
Quoted 105 lines
Quoted 105 lines
arch/arm/mach-omap2/powerdomain.c +81
-0+ +/** +* pwrdm_wakeuplat_update_pwrst - Update power domain power state if needed +* @pwrdm: struct powerdomain * to which requesting device belongs to. +* @min_latency: the allowed wake-up latency for the given power domain. +* +* Finds the power domain next power state that fulfills the constraint. +* Programs a new target state if it is different from current power state. +* +* Returns 0 upon success. +*/ +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency) +{ + ? ? int ret = 0, new_state = 0; + + ? ? if (!pwrdm) { + ? ? ? ? ? ? WARN(1, "powerdomain: %s: invalid parameter(s)", __func__); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* + ? ? ?* Apply constraints to MPU and CORE via the PM QOS API. + ? ? ?* Every power domain struct has a pm_qos_request_list field + ? ? ?*/ + ? ? if (is_pwrdm_mpu_or_core(pwrdm)) { + ? ? ? ? ? ? if (pm_qos_request_active(&(pwrdm->pm_qos_request))) + ? ? ? ? ? ? ? ? ? ? pm_qos_remove_request(&(pwrdm->pm_qos_request)); + + ? ? ? ? ? ? if (min_latency >= 0) + ? ? ? ? ? ? ? ? ? ? pm_qos_add_request(&(pwrdm->pm_qos_request), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?PM_QOS_CPU_DMA_LATENCY, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?min_latency); + ? ? ? ? ? ? return 0; + ? ? } + + ? ? /* + ? ? ?* Apply constraints to pwrdm other than MPU and CORE by programming + ? ? ?* the pwrdm next power state. + ? ? ?*/ + + ? ? /* Find power state with wakeup latency < minimum constraint */ + ? ? for (new_state = 0x0; new_state < PWRDM_MAX_PWRSTS; new_state++) { + ? ? ? ? ? ? if (min_latency == -1 || + ? ? ? ? ? ? ? ? pwrdm->wakeup_lat[new_state] <= min_latency) + ? ? ? ? ? ? ? ? ? ? break; + ? ? } + + ? ? switch (new_state) { + ? ? case PWRDM_FUNC_PWRST_OFF: + ? ? ? ? ? ? new_state = PWRDM_POWER_OFF; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_OSWR: + ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_OFF); + ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_CSWR: + ? ? ? ? ? ? pwrdm_set_logic_retst(pwrdm, PWRDM_POWER_RET); + ? ? ? ? ? ? new_state = PWRDM_POWER_RET; + ? ? ? ? ? ? break; + ? ? case PWRDM_FUNC_PWRST_ON: + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? default: + ? ? ? ? ? ? pr_warn("powerdomain: requested latency constraint not " + ? ? ? ? ? ? ? ? ? ? "supported %s set to ON state\n", pwrdm->name); + ? ? ? ? ? ? new_state = PWRDM_POWER_ON; + ? ? ? ? ? ? break; + ? ? } + + ? ? if (pwrdm_read_pwrst(pwrdm) != new_state) { + ? ? ? ? ? ? ret = omap_set_pwrdm_state(pwrdm, new_state); + ? ? } + + ? ? pr_debug("powerdomain: %s pwrst: curr=%d, prev=%d next=%d " + ? ? ? ? ? ? ?"min_latency=%ld, set_state=%d\n", pwrdm->name, + ? ? ? ? ? ? ?pwrdm_read_pwrst(pwrdm), pwrdm_read_prev_pwrst(pwrdm), + ? ? ? ? ? ? ?pwrdm_read_next_pwrst(pwrdm), min_latency, new_state); + + ? ? return ret; +} +?/* Public functions */
?/**
arch/arm/mach-omap2/powerdomain.h +0
-0@@ -19,7 +19,10 @@?#include <
linux/types.h>
?#include <linux/list.h>arch/arm/mach-omap2/powerdomain.h +4
-1- +#include <linux/plist.h> +#include <linux/mutex.h> +#include <linux/spinlock.h> +#include <linux/pm_qos_params.h> ?#include <
linux/atomic.h>?#include <
plat/cpu.h>arch/arm/mach-omap2/powerdomain.h +0
-0@@ -46,6 +49,15 @@ ?#define PWRSTS_OFF_RET_ON ? ?(PWRSTS_OFF_RET | (1 << PWRDM_POWER_ON))
Quoted 8 lines
arch/arm/mach-omap2/powerdomain.h
Quoted 4 lines
arch/arm/mach-omap2/powerdomain.h +4
-0+/* Powerdomain functional power states */ +#define PWRDM_FUNC_PWRST_OFF 0x0 +#define PWRDM_FUNC_PWRST_OSWR ? ? ? ?0x1 +#define PWRDM_FUNC_PWRST_CSWR ? ? ? ?0x2You'll also want an
_INACTIVEstate here, per:? http://www.mail-archive.com/linux-omap at vger.kernel.org/msg43783.html
Is this state implemented? I do not see any code using it in the current pm-core branch. If so can this be done later. See also the remarks below about the latency figures.
Quoted 7 lines
Quoted 7 lines
arch/arm/mach-omap2/powerdomain.h +5
-0+#define PWRDM_FUNC_PWRST_ON ?0x3 + +#define PWRDM_MAX_FUNC_PWRSTS ? ? ? ?4 + +#define UNSUP_STATE ? ? ? ? ?-1
Quoted 12 lines
Quoted 10 lines
?/* Powerdomain flags */
?#definePWRDM_HAS_HDWR_SAR? (1 << 0) /* hardware save-and-restore support */arch/arm/mach-omap2/powerdomain.h +0
-0@@ -96,7 +108,11 @@ struct powerdomain;? * @state_counter:
? * @timer:
? * @state_timer:
- *
+ * @wakeup_lat: wakeup latencies for possible powerdomain power states
+ * Note about the wakeup latencies ordering: the values must be sorted
+ * ?in decremental orderWould be good to specify the unit of time here.
Ok will do.
Quoted 30 lines
Quoted 30 lines
+ * @pm_qos_request: PM QOS handle, only used to control the MPU and CORE power
+ * ?domains states; to be removed when a generic solution is in place. ? * @prcm_partition possible values are defined inmach-omap2/prcm44xx.h. ? */
?struct powerdomain {arch/arm/mach-omap2/powerdomain.h +0
-0@@ -121,6 +137,8 @@ struct powerdomain { ? ? ? s64 timer; ? ? ? s64 state_timer[PWRDM_MAX_PWRSTS];?#endif
+ ? ? const u32 wakeup_lat[PWRDM_MAX_FUNC_PWRSTS];
+ ? ? structpm_qos_request_listpm_qos_request; ?};?/**
arch/arm/mach-omap2/powerdomain.h +2
-0@@ -210,6 +228,8 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm); ?int pwrdm_pre_transition(void); ?int pwrdm_post_transition(void); ?int pwrdm_set_lowpwrstchange(struct powerdomain *pwrdm); + +int pwrdm_wakeuplat_update_pwrst (struct powerdomain *pwrdm,long min_latency); ?u32 pwrdm_get_context_loss_count(struct powerdomain *pwrdm); ?extern void omap2xxx_powerdomains_init(void);arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -31,6 +31,9 @@
Quoted 8 lines
Quoted 5 lines
?/*
? * Powerdomains
+ *
+ * Thewakeup_latvalues are derived from measurements on
+ * the actual target.Which type of OMAP3 chip were these measured on? ?OMAP34xx/35xx, OMAP36xx/37xx, AM3505/17 ?
Well although the comment says actual measurements have been made (which is true!), the figures are not correct for the moment. Once the framework is in place some more accurate measurements will be performed.
The OMAP tracepoints implementation, the wiki information [1] and the PMIC OFF support wiki [2] will definitely help. Also there are measurements activities going-on at TI.
[1] http://omappedia.org/wiki/Power_Management_Device_Latencies_Measurement
[2] http://omappedia.org/wiki/TWL4030_power_scripts
Quoted 9 lines
Also it would be good to know the
sys_clkrate and the VDD1/2 OPPs that you took these measurements at. ?Do you have a sense of how much these measurements vary based on those three factors? ?Presumably, 12MHz/125MHz/83MHz would be the worst case, for the standard OPPs anyway.In general, if you could elaborate further how you measured these, that would be good. ?Some of these measurements seem to be too low (described below).
That will be part of the measurements task.
Quoted 11 lines
I'm not sure if a strictly static table is the right approach for these measurements. ?It might be good to start with a static table that represents the lowest possible latencies, measured with DPLL autoidle disabled, and then to add or remove amounts from those numbers dynamically based on the state of other devices. ?For example, in terms of CORE, the AUTOEXTCLKMODE settings and the amount of time it takes the external HF oscillator to restart will have a major impact on the CORE
OFF->ONmeasurements, potentially several milliseconds. ?Similarly, if DPLL1, 2, or 3 have to relock, that could take quite a bit of time, potentially several hundred microseconds.
The idea is to use the dynamic measurements mechanism implemented in hwmod. Also I am still not sure on how to account for all the power domains
combination: should the latencies values be added together?
Quoted 171 lines
Quoted 5 lines
? */
?static struct powerdomain
iva2_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain iva2_pwrdm = { · line 64
Quoted 10 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -52,6 +55,12 @@ static struct powerdomain iva2_pwrdm = { ? ? ? ? ? ? ? [2] = PWRSTS_OFF_ON, ? ? ? ? ? ? ? [3] = PWRDM_POWER_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1100, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 350, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};Was this measured with DPLL2 autoidle enabled or disabled?
arch/arm/mach-omap2/powerdomains3xxx_data.c static struct powerdomain mpu_3xxx_pwrdm = { · line 86
Quoted 13 lines
arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0?static struct powerdomain mpu_3xxx_pwrdm = {@@ -68,6 +77,12 @@ static struct powerdomain mpu_3xxx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= { ? ? ? ? ? ? ? [0] = PWRSTS_OFF_ON, ? ? ? }, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 95, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 45, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?};Was this measured with DPLL1 autoidle enabled or disabled?
That
OFF->ONtime looks really low to me...Quoted 18 lines
?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -98,6 +113,12 @@ static struct powerdomain core_3xxx_pre_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
core_3xxx_es3_1_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -121,6 +142,12 @@ static struct powerdomain core_3xxx_es3_1_pwrdm = {? ? ? ? ? ? ? [0] =
PWRSTS_OFF_RET_ON, /* MEM1ONSTATE */ ? ? ? ? ? ? ? [1] =PWRSTS_OFF_RET_ON, /* MEM2ONSTATE */Quoted 8 lines
? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 100,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 60,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};The figures for the CORE powerdomain look implausibly low. ?Do these figures represent the amount of time required to transition from the low power state to the point at which Linux is running again? ?Or do they represent something else?
Quoted 98 lines
?static struct powerdomain
dss_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -136,6 +163,12 @@ static struct powerdomain dss_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 70,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 20,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?/*
arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -157,6 +190,12 @@ static struct powerdomain sgx_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 1000,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
cam_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -172,6 +211,12 @@ static struct powerdomain cam_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 850,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
per_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +0
-0@@ -187,6 +232,12 @@ static struct powerdomain per_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 110,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
emu_pwrdm= {arch/arm/mach-omap2/powerdomains3xxx_data.c +6
-0@@ -201,6 +252,12 @@ static struct powerdomain neon_pwrdm = { ? ? ? .omap_chip ? ? ? ?= OMAP_CHIP_INIT(CHIP_IS_OMAP3430), ? ? ? .pwrsts ? ? ? ? ? = PWRSTS_OFF_RET_ON, ? ? ? .pwrsts_logic_ret = PWRDM_POWER_RET, + ? ? .wakeup_lat = { + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 200, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] = UNSUP_STATE, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 35, + ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0, + ? ? }, ?}; ?static struct powerdomain usbhost_pwrdm = {@@ -223,6 +280,12 @@ static struct powerdomain usbhost_pwrdm = { ? ? ? .pwrsts_mem_on ? ?= {? ? ? ? ? ? ? [0] =
PWRDM_POWER_ON, ?/* MEMONSTATE */ ? ? ? },
+ ? ? .wakeup_lat = {
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OFF] = 800,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_OSWR] =UNSUP_STATE,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_CSWR] = 150,
+ ? ? ? ? ? ? [PWRDM_FUNC_PWRST_ON] = 0,
+ ? ? },
?};?static struct powerdomain
dpll1_pwrdm= {arch/arm/plat-omap/include/plat/omap-pm.h +0
-0@@ -70,6 +70,10 @@ void omap_pm_if_exit(void); ? * Device-driver-originated constraints (via board-*.c files, platform_data)? */
arch/arm/plat-omap/include/plat/omap-pm.h +4
-0+enum omap_pm_constraint_class { + ? ? OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? OMAP_PM_CONSTRAINT_THROUGHPUT +};?/**
? *omap_pm_set_max_mpu_wakeup_lat- set the maximum MPU wakeup latencyarch/arm/plat-omap/include/plat/omap-pm.h +0
-0@@ -137,7 +141,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t);? * Returns
-EINVALfor an invalid argument,-ERANGEif the constraint ? * is not satisfiable, or 0 upon success.
? */arch/arm/plat-omap/include/plat/omap-pm.h int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t); · line 144
Quoted 2 lines
arch/arm/plat-omap/include/plat/omap-pm.h +1
-1-int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r); +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r);The documentation for this function states:
Quoted 3 lines
?To remove the interconnect throughput restriction for this device, call with r = 0.
So an unsigned long seems reasonable here?
Hmm good catch! I changed the parameter to be inline with the constraints API (value=-1 means removal of the constraint). Can the tput API be changed (and the doc acordingly)?
BTW what is the agent_id? A requester ID or ptr is needed in order to keep track of the constraints.
Quoted 34 lines
Quoted 34 lines
?/**
arch/arm/plat-omap/include/plat/omap_device.h +0
-0@@ -32,9 +32,11 @@?#define
__ARCH_ARM_PLAT_OMAP_INCLUDE_MACH_OMAP_DEVICE_H?#include <
linux/kernel.h>
+#include <linux/plist.h>
?#include <linux/platform_device.h>?#include <
plat/omap_hwmod.h>
+#include <plat/omap-pm.h>?extern struct device
omap_device_parent;arch/arm/plat-omap/include/plat/omap_device.h +9
-0@@ -73,6 +75,15 @@ struct omap_device { ? ? ? s8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pm_lat_level; ? ? ? u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?hwmods_cnt; ? ? ? u8 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?_state; + +}; + +/* Linked list for the devices constraints entries */ +struct omap_device_constraints_entry { + ? ? struct device ? ? ? ? ? ? ? ? ? *req_dev; + ? ? void ? ? ? ? ? ? ? ? ? ? ? ? ? ?*target; + ? ? unsigned long ? ? ? ? ? ? ? ? ? constraint_value; + ? ? struct plist_node ? ? ? ? ? ? ? node; ?};
Quoted 11 lines
arch/arm/plat-omap/include/plat/omap_device.h void __iomem *omap_device_get_rt_va(struct omap_device *od); · line 123
Quoted 8 lines
?/* Device driver interface (call via
platform_datafn ptrs) */arch/arm/plat-omap/include/plat/omap_device.h +3
-0@@ -107,6 +118,9 @@ void __iomem *omap_device_get_rt_va(struct omap_device *od); ?int omap_device_align_pm_lat(struct platform_device *pdev, ? ? ? ? ? ? ? ? ? ? ? ? ? ?u32 new_wakeup_lat_limit); ?struct powerdomain *omap_device_get_pwrdm(struct omap_device *od); +int omap_device_set_dev_constraint (enum omap_pm_constraint_class class, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *dev, long t);This should be two separate functions, one for max wakeup latency and the other for minimum bandwidth... discussed further below.
Why? The idea is to keep the code compact and not duplicated. Cf. the function omap_device_store_constraint which is meant to manage all constraint lists.
Quoted 32 lines
Quoted 32 lines
arch/arm/plat-omap/include/plat/omap_device.h +0
-0?u32 omap_device_get_context_loss_count(struct platform_device *pdev);?/* Other */
arch/arm/plat-omap/include/plat/omap_hwmod.h +1
-0@@ -597,6 +597,7 @@ int omap_hwmod_for_each_by_class(const char *classname, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?void *user); ?int omap_hwmod_set_postsetup_state(struct omap_hwmod *oh, u8 state); +int omap_hwmod_update_power_state (struct omap_hwmod *oh,long min_latency); ?u32 omap_hwmod_get_context_loss_count(struct omap_hwmod *oh);?/*
arch/arm/plat-omap/omap-pm-constraints.c +0
-0@@ -24,6 +24,7 @@?/* Interface documentation is in
mach/omap-pm.h*/ ?#include <plat/omap-pm.h>
?#include <plat/omap_device.h>
+#include <plat/common.h>?static bool
off_mode_enabled;
?static u32dummy_context_loss_counter;arch/arm/plat-omap/omap-pm-constraints.c +0
-0@@ -32,35 +33,46 @@ static u32 dummy_context_loss_counter; ? * Device-driver-originated constraints (via board-*.c files)? */
Quoted 10 lines
arch/arm/plat-omap/omap-pm-constraints.c static u32 dummy_context_loss_counter;
Quoted 7 lines
arch/arm/plat-omap/omap-pm-constraints.c +6
-1-int omap_pm_set_max_mpu_wakeup_lat (struct device *dev,long t) +/* +* Generic function to omap_device layer for the constraints API. +*/ +static int omap_pm_set_dev_constraint (enum omap_pm_constraint_class class, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct device *req_dev, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? struct device *dev, long t)For static functions, I'd suggest dropping the "
omap_pm" prefix from the names of these functions, so they begin with an underscore.
Ok will do.
Quoted 239 lines
Quoted 239 lines
?{
- ? ? if (!dev || t < -1) {
+ ? ? int ret = 0;
+
+ ? ? if (!req_dev || !dev || t < -1) {
? ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__); ? ? ? ? ? ? ? return-EINVAL;
- ? ? };arch/arm/plat-omap/omap-pm-constraints.c +20
-18- - ? ? if (t == -1) - ? ? ? ? ? ? pr_debug("OMAP PM: remove max MPU wakeup latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? else - ? ? ? ? ? ? pr_debug("OMAP PM: add max MPU wakeup latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); + ? ? } - ? ? /* - ? ? ?* For current Linux, this needs to map the MPU to a - ? ? ?* powerdomain, then go through the list of current max lat - ? ? ?* constraints on the MPU and find the smallest. ?If - ? ? ?* the latency constraint has changed, the code should - ? ? ?* recompute the state to enter for the next powerdomain - ? ? ?* state. - ? ? ?* - ? ? ?* TI CDP code can call constraint_set here. - ? ? ?*/ + ? ? /* Try to catch non omap_device for dev */ + ? ? if (dev->parent == &omap_device_parent) { + ? ? ? ? ? ? if (t == -1) + ? ? ? ? ? ? ? ? ? ? pr_debug("OMAP PM: remove constraint of class %d " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"from req_dev %s on dev %s\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?class, dev_name(req_dev), dev_name(dev)); + ? ? ? ? ? ? else + ? ? ? ? ? ? ? ? ? ? pr_debug("OMAP PM: add constraint of class %d " + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?"from req_dev %s on dev %s, t = %ld\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?class, dev_name(req_dev), dev_name(dev), t); + + ? ? ? ? ? ? /* Call the omap_device API */ + ? ? ? ? ? ? ret = omap_device_set_dev_constraint(class, req_dev, dev, t); + ? ? } else { + ? ? ? ? ? ? pr_err("OMAP-PM set_wakeup_lat: Error: platform device " + ? ? ? ? ? ? ? ? ? ?"not valid\n"); + ? ? ? ? ? ? return -EINVAL; + ? ? } - ? ? return 0; + ? ? return ret;?}
arch/arm/plat-omap/omap-pm-constraints.c +4
-1-int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +/* +* omap_pm_set_min_bus_tput - set/release bus throughput constraints +*/ +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r)?{
? ? ? if (!dev || (agent_id!=OCP_INITIATOR_AGENT&& ? ? ? ? ?agent_id!=OCP_TARGET_AGENT)) {arch/arm/plat-omap/omap-pm-constraints.c +0
-8@@ -68,83 +80,56 @@ int omap_pm_set_min_bus_tput(struct device *dev, u8 agent_id, unsigned long r) ? ? ? ? ? ? ? return -EINVAL; ? ? ? }; - ? ? if (r == 0) - ? ? ? ? ? ? pr_debug("OMAP PM: remove min bus tput constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s for agent_id %d\n", dev_name(dev), agent_id); - ? ? else - ? ? ? ? ? ? pr_debug("OMAP PM: add min bus tput constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s for agent_id %d: rate %ld KiB\n", - ? ? ? ? ? ? ? ? ? ? ?dev_name(dev), agent_id, r); -? ? ? /*
- ? ? ?* This code should model the interconnect and compute the
- ? ? ?* required clock frequency, convert that to a VDD2 OPP ID, then
- ? ? ?* set the VDD2 OPP appropriately.
- ? ? ?*
- ? ? ?* TI CDP code can callconstraint_sethere on the VDD2 OPP.
+ ? ? ?* This code calls the genericomap_deviceAPI function
+ ? ? ?*omap_pm_set_dev_constraintwith the class
+ ? ? ?*OMAP_PM_CONSTRAINT_THROUGHPUT.omap_pm_set_dev_constraint
+ ? ? ?* should manage the constraints lists and call the appropriate
+ ? ? ?* low level code that models the interconnect, computes the required
+ ? ? ?* clock frequency, converts that to a VDD2 OPP ID and sets the
+ ? ? ?* VDD2 OPP appropriately.
? ? ? ?*/
-
- ? ? return 0;
+ ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_THROUGHPUT,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? dev, dev, r);
?}+/*
+ *omap_pm_set_max_dev_wakeup_lat- set/release devices wake-up latency
+ * constraints
+ */
?intomap_pm_set_max_dev_wakeup_lat(struct device *req_dev, struct device *dev, ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?long t)
?{
- ? ? if (!req_dev || !dev || t < -1) {
- ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- ? ? ? ? ? ? return-EINVAL;
- ? ? };arch/arm/plat-omap/omap-pm-constraints.c +2
-22- - ? ? if (t == -1) - ? ? ? ? ? ? pr_debug("OMAP PM: remove max device latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? else - ? ? ? ? ? ? pr_debug("OMAP PM: add max device latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); - - ? ? /* - ? ? ?* For current Linux, this needs to map the device to a - ? ? ?* powerdomain, then go through the list of current max lat - ? ? ?* constraints on that powerdomain and find the smallest. ?If - ? ? ?* the latency constraint has changed, the code should - ? ? ?* recompute the state to enter for the next powerdomain - ? ? ?* state. ?Conceivably, this code should also determine - ? ? ?* whether to actually disable the device clocks or not, - ? ? ?* depending on how long it takes to re-enable the clocks. - ? ? ?* - ? ? ?* TI CDP code can call constraint_set here. - ? ? ?*/ - - ? ? return 0; + ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, dev, t);?}
arch/arm/plat-omap/omap-pm-constraints.c +8
-1-int omap_pm_set_max_sdma_lat (struct device *dev,long t) +/* +* omap_pm_set_max_mpu_wakeup_lat - set/release MPU wake-up latency +* constraints +* +* Maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the MPU device as constraints target. +*/ +int omap_pm_set_max_mpu_wakeup_lat (struct device *req_dev,long t)?{
- ? ? if (!dev || t < -1) {
- ? ? ? ? ? ?WARN(1, "OMAP PM: %s: invalid parameter(s)", __func__);
- ? ? ? ? ? ? return-EINVAL;
- ? ? };arch/arm/plat-omap/omap-pm-constraints.c +16
-20- - ? ? if (t == -1) - ? ? ? ? ? ? pr_debug("OMAP PM: remove max DMA latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s\n", dev_name(dev)); - ? ? else - ? ? ? ? ? ? pr_debug("OMAP PM: add max DMA latency constraint: " - ? ? ? ? ? ? ? ? ? ? ?"dev %s, t = %ld usec\n", dev_name(dev), t); - - ? ? /* - ? ? ?* For current Linux PM QOS params, this code should scan the - ? ? ?* list of maximum CPU and DMA latencies and select the - ? ? ?* smallest, then set cpu_dma_latency pm_qos_param - ? ? ?* accordingly. - ? ? ?* - ? ? ?* For future Linux PM QOS params, with separate CPU and DMA - ? ? ?* latency params, this code should just set the dma_latency param. - ? ? ?* - ? ? ?* TI CDP code can call constraint_set here. - ? ? ?*/ + ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, omap2_get_mpuss_device(), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t); +} - ? ? return 0; +/* +* omap_pm_set_max_sdma_lat - set/release SDMA start latency +* constraints +* +* Currently maps to omap_pm_set_dev_constraint with OMAP_PM_CONSTRAINT_WKUP_LAT +* as constraint class and the L3 device as constraints target. +*/ +int omap_pm_set_max_sdma_lat (struct device *req_dev,long t) +{ + ? ? return omap_pm_set_dev_constraint(OMAP_PM_CONSTRAINT_WKUP_LAT, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, omap2_get_l3_device(), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? t);?}
?int
omap_pm_set_min_clk_rate(struct device *dev, struct clk *c, long r)arch/arm/plat-omap/omap-pm-noop.c +1
-1@@ -61,7 +61,7 @@ int omap_pm_set_max_mpu_wakeup_lat(struct device *dev, long t) ? ? ? return 0; ?} -int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,unsigned long r) +int omap_pm_set_min_bus_tput (struct device *dev,u8 agent_id,long r) ?{? ? ? if (!dev || (
agent_id!=OCP_INITIATOR_AGENT&& ? ? ? ? ?agent_id!=OCP_TARGET_AGENT)) {arch/arm/plat-omap/omap_device.c +36
-0@@ -292,10 +292,189 @@ static void _add_optional_clock_clkdev(struct omap_device *od, ? ? ? } ?} +/* plist that stores the devices wake-up latency constraints */ +static struct plist_head omap_device_wkup_lat_constraints_list; +/* Spinlock that protects the constraints lists */ +static spinlock_t omap_device_constraints_lock; +/* Mutex that protects the constraints lists ops */ +static struct mutex omap_device_constraints_mutex; + +/* +* omap_device_store_constraint: add/update/remove a constraint from a plist +* +* @constraints_list: plist to use +* @req_dev: constraint requester, used to track the requests +* @target: target which the constraint applies to (e.g. power domain ID or +* ?ptr for wake-up latency constraints) +* @value: constraint value. The plist is sorted by the value. -1 remove the +* ?constraint from the list +* +* Returns the strongest constraint value for the given target, 0 in the +* case there is no constraint on the given target or a negative value in +* case of error. +* The caller must check the validity of the parameters. +*/ +static long omap_device_store_constraint (struct plist_head *constraints_list, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *req_dev, void *target, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?long value) +{ + ? ? struct omap_device_constraints_entry *user; + ? ? int found = 0, ret = 0; + + ? ? mutex_lock(&omap_device_constraints_mutex); + + ? ? /* Check if the constraint requester is already in the list */ + ? ? plist_for_each_entry(user, constraints_list, node) { + ? ? ? ? ? ? if (user->req_dev == req_dev) { + ? ? ? ? ? ? ? ? ? ? found = 1; + ? ? ? ? ? ? ? ? ? ? break;
Quoted 8 lines
arch/arm/plat-omap/omap_device.c static void _add_optional_clock_clkdev(struct omap_device *od, · line 334
Quoted 4 lines
arch/arm/plat-omap/omap_device.c +4
-0+ ? ? ? ? ? ? } + ? ? } + + ? ? if (value >= 0) {This should really be split into two functions,
_add_constraint()and_remove_constraint(). ?You may wish to reviewDocumentation/CodingStyleChapter 6.
Cf. the remark above about it.
Yes the 80-characters rule is a real PITA. I am not using my monochrome (amber) monitor anymore those days ;p
Quoted 68 lines
Quoted 68 lines
arch/arm/plat-omap/omap_device.c +52
-0+ ? ? ? ? ? ? /* Add new entry to the list or update existing request */ + ? ? ? ? ? ? if (found && + ? ? ? ? ? ? ? ? user->constraint_value == value && + ? ? ? ? ? ? ? ? user->target == target) { + ? ? ? ? ? ? ? ? ? ? goto exit_ok; + ? ? ? ? ? ? } else if (!found) { + ? ? ? ? ? ? ? ? ? ? user = kzalloc( + ? ? ? ? ? ? ? ? ? ? ? ? ? ? sizeof(struct omap_device_constraints_entry), + ? ? ? ? ? ? ? ? ? ? ? ? ? ? GFP_KERNEL); + ? ? ? ? ? ? ? ? ? ? if (!user) { + ? ? ? ? ? ? ? ? ? ? ? ? ? ? pr_err("%s: FATAL ERROR: kzalloc failed\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__); + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ret = -ENOMEM; + ? ? ? ? ? ? ? ? ? ? ? ? ? ? goto exit_error; + ? ? ? ? ? ? ? ? ? ? } + ? ? ? ? ? ? ? ? ? ? user->req_dev = req_dev; + ? ? ? ? ? ? } else { + ? ? ? ? ? ? ? ? ? ? plist_del(&user->node, constraints_list); + ? ? ? ? ? ? } + + ? ? ? ? ? ? plist_node_init(&user->node, value); + ? ? ? ? ? ? plist_add(&user->node, constraints_list); + ? ? ? ? ? ? user->node.prio = user->constraint_value = value; + ? ? ? ? ? ? user->target = target; + ? ? } else { + ? ? ? ? ? ? /* Remove the constraint from the list */ + ? ? ? ? ? ? if (!found) { + ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error: no prior constraint to release\n", + ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__); + ? ? ? ? ? ? ? ? ? ? ret = -EINVAL; + ? ? ? ? ? ? ? ? ? ? goto exit_error; + ? ? ? ? ? ? } + + ? ? ? ? ? ? plist_del(&user->node, constraints_list); + ? ? ? ? ? ? kfree(user); + ? ? } + +exit_ok: + ? ? /* Find the strongest constraint for the given target */ + ? ? ret = 0; + ? ? plist_for_each_entry(user, constraints_list, node) { + ? ? ? ? ? ? if (user->target == target) { + ? ? ? ? ? ? ? ? ? ? ret = user->constraint_value; + ? ? ? ? ? ? ? ? ? ? break; + ? ? ? ? ? ? } + ? ? } + +exit_error: + ? ? mutex_unlock(&omap_device_constraints_mutex); + + ? ? return ret; +}?/* Public functions for use by core code */
?/**
+ *omap_device_set_max_dev_wakeup_lat- set/release a device constraint
+ * @class: constraint class
+ * @dev: device to apply the constraint to. Must have an associatedomap_device
+ * @req_dev: constraint requester, used for tracking the constraints
+ *
+ * Using the primary hwmod, set/release a device constraint for the dev
+ * device, requested by thereq_devdevice. Depending of the constraint class
+ * this code calls the appropriate low level code, e.g. power domain for
+ * the wake-up latency constraints.
+ *
+ * If any hwmods exist for theomap_deviceassoiated with @dev and @req_dev,
Quoted 8 lines
Quoted 6 lines
+ * set/release the constraint for the corresponding hwmods, otherwise return
+ *-EINVAL.
+ */
+int omap_device_set_dev_constraint(enumomap_pm_constraint_classclass,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device*req_dev,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device *dev, long t)The name of this function doesn't match what's in the kerneldoc comment.
OK will update.
Quoted 20 lines
Quoted 20 lines
arch/arm/plat-omap/omap_device.c +19
-0+{ + ? ? struct omap_device *od; + ? ? struct omap_hwmod *oh; + ? ? struct platform_device *pdev; + ? ? struct powerdomain *pwrdm = NULL; + ? ? u32 ret = -EINVAL; + + ? ? /* Look for the platform device for dev */ + ? ? pdev = to_platform_device(dev); + + ? ? /* Try to catch non platform devices. */ + ? ? if (pdev->name == NULL) { + ? ? ? ? ? ? pr_err("%s: Error: platform device for device %s not valid\n", + ? ? ? ? ? ? ? ? ? ?__func__, dev_name(dev)); + ? ? ? ? ? ? return -EINVAL; + ? ? } + + ? ? /* Find the associated omap_device for dev */ + ? ? od = _find_by_pdev(pdev);
Quoted 8 lines
Quoted 5 lines
+ ? ? if (!(od->hwmods_cnt)) {
+ ? ? ? ? ? ? pr_err("%s: Error: No hwmod for device %s\n",
+ ? ? ? ? ? ? ? ? ? ?__func__,dev_name(dev));
+ ? ? ? ? ? ? return-EINVAL;
+ ? ? }Please also
pr_err()and bail out if there is more than one hwmod in theomap_device.
Ok. IIUC nothing should be done in case of more than one hwmod per od? Is that a realistic situation?
Quoted 11 lines
arch/arm/plat-omap/omap_device.c
Quoted 7 lines
arch/arm/plat-omap/omap_device.c +6
-0+ + ? ? /* Find the associated omap_hwmod for dev */ + ? ? oh = od->hwmods[0]; + + ? ? switch (class) { + ? ? case OMAP_PM_CONSTRAINT_WKUP_LAT:Please create two different functions,
omap_device_set_max_dev_wakeup_lat()andomap_device_set_min_bus_tput(). ?Documentation/CodingStyle chapter 6.
It has been agreed (in weekly calls) to have two functions at the OMAP PM level but only one function with a class parameter at the omap_device level. This allows easier maintenance and clean-up later. Kevin, is that corrcet?
Quoted 62 lines
Quoted 62 lines
+ ? ? ? ? ? ? /* Find the pwrdm associated to dev */
+ ? ? ? ? ? ? pwrdm =omap_device_get_pwrdm(od);
+ ? ? ? ? ? ? if (!pwrdm) {
+ ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error: No pwrdm for device %s\n",
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ?__func__,dev_name(dev));
+ ? ? ? ? ? ? ? ? ? ? ret =-EINVAL;
+ ? ? ? ? ? ? ? ? ? ? break;
+ ? ? ? ? ? ? }arch/arm/plat-omap/omap_device.c +32
-0+ + ? ? ? ? ? ? /* + ? ? ? ? ? ? ?* Store the constraint in the appropriate list and find the + ? ? ? ? ? ? ?* strongest constraint for the given pwrdm + ? ? ? ? ? ? ?*/ + ? ? ? ? ? ? ret = omap_device_store_constraint( + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &omap_device_wkup_lat_constraints_list, + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? req_dev, (void *) pwrdm, t); + + ? ? ? ? ? ? /* Apply the constraint to the corresponding pwrdm */ + ? ? ? ? ? ? if (ret >= 0) { + ? ? ? ? ? ? ? ? ? ? ret = omap_hwmod_update_power_state(oh, ret); + ? ? ? ? ? ? } else { + ? ? ? ? ? ? ? ? ? ? pr_err("%s: Error storing the constraint for device " + ? ? ? ? ? ? ? ? ? ? ? ? ? ?"%s\n", __func__, dev_name(dev)); + ? ? ? ? ? ? } + + ? ? ? ? ? ? break; + ? ? case OMAP_PM_CONSTRAINT_THROUGHPUT: + ? ? ? ? ? ? WARN(1, "OMAP PM: %s: Bus throughput constraint class \ +? ? ? ? ? ? ? ? ?not implemented\n" , __func__); + ? ? ? ? ? ? ret = -EINVAL; + ? ? ? ? ? ? break; + ? ? default: + ? ? ? ? ? ? WARN(1, "OMAP PM: %s: invalid constraint class %d", + ? ? ? ? ? ? ? ? ?__func__, class); + ? ? } + + ? ? return ret; +} + +/** ? *
omap_device_get_context_loss_count- get lost context count ? * @od: structomap_device*
? *arch/arm/plat-omap/omap_device.c +8
-1@@ -824,6 +1003,14 @@ struct device omap_device_parent = { ?static int __init omap_device_init(void) ?{ + ? ? /* Initialize priority ordered list for wakeup latency constraint */ + ? ? spin_lock_init(&omap_device_constraints_lock); + ? ? plist_head_init(&omap_device_wkup_lat_constraints_list, + ? ? ? ? ? ? ? ? ? ? &omap_device_constraints_lock); + + ? ? /* res_mutex protects res_list add and del ops */ + ? ? mutex_init(&omap_device_constraints_mutex); + ? ? ? return device_register(&omap_device_parent); ?} ?core_initcall(omap_device_init); --1.7.2.3
Quoted 9 lines
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html- Paul
Thanks!
Jean
PATCH 2/2 OMAP: PM: implement devices constraints APIs
Jean Pihet <[email protected]> writes:
[...]
Quoted 9 lines
Quoted 4 lines
Please create two different functions,
omap_device_set_max_dev_wakeup_lat()andomap_device_set_min_bus_tput(). ?Documentation/CodingStyle chapter 6.It has been agreed (in weekly calls) to have two functions at the OMAP PM level but only one function with a class parameter at the
omap_devicelevel. This allows easier maintenance and clean-up later. Kevin, is that corrcet?
Yes, that is my preference (but Paul is the maintainer of these layers, so he has the final say.) What I would like to see is a more generic API at the omap_device level which can easily be extended to handle new constraints (by adding a new 'class'), without having to grow the API each time.
That being said, you can still create the two functions that Paul mentioned above and just have the generic function call those based on class.
The only question then is which interface the drivers will eventually use. I much prefer keeping the driver interface to a simple set of add & remove constraint functions where the type is determined by class:
Today we have:
- max wakeup latency
- min bus througput
but eventually we may also want
- min frequency
- max frequency (thermal)
- etc.
Kevin