2019-06-04 11:11:33 +03:00
// SPDX-License-Identifier: GPL-2.0-only
2016-05-05 13:50:33 +03:00
/*
* Generic OPP OF helpers
*
* Copyright ( C ) 2009 - 2010 Texas Instruments Incorporated .
* Nishanth Menon
* Romit Dasgupta
* Kevin Hilman
*/
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
# include <linux/cpu.h>
# include <linux/errno.h>
# include <linux/device.h>
2017-10-12 13:32:23 +03:00
# include <linux/of_device.h>
2016-11-18 13:17:46 +03:00
# include <linux/pm_domain.h>
2016-12-01 13:58:19 +03:00
# include <linux/slab.h>
2016-05-05 13:50:33 +03:00
# include <linux/export.h>
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
# include <linux/energy_model.h>
2016-05-05 13:50:33 +03:00
# include "opp.h"
2018-06-14 09:34:43 +03:00
/*
* Returns opp descriptor node for a device node , caller must
* do of_node_put ( ) .
*/
static struct device_node * _opp_of_get_opp_desc_node ( struct device_node * np ,
int index )
{
/* "operating-points-v2" can be an array for power domain providers */
return of_parse_phandle ( np , " operating-points-v2 " , index ) ;
}
/* Returns opp descriptor node for a device, caller must do of_node_put() */
struct device_node * dev_pm_opp_of_get_opp_desc_node ( struct device * dev )
{
return _opp_of_get_opp_desc_node ( dev - > of_node , 0 ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_get_opp_desc_node ) ;
2018-09-07 06:31:54 +03:00
struct opp_table * _managed_opp ( struct device * dev , int index )
2016-05-05 13:50:33 +03:00
{
2017-01-23 07:41:45 +03:00
struct opp_table * opp_table , * managed_table = NULL ;
2018-09-07 06:31:54 +03:00
struct device_node * np ;
2017-01-23 07:41:45 +03:00
2018-09-07 06:31:54 +03:00
np = _opp_of_get_opp_desc_node ( dev - > of_node , index ) ;
if ( ! np )
return NULL ;
2016-05-05 13:50:33 +03:00
2017-01-23 07:41:49 +03:00
list_for_each_entry ( opp_table , & opp_tables , node ) {
2016-05-05 13:50:33 +03:00
if ( opp_table - > np = = np ) {
/*
* Multiple devices can point to the same OPP table and
* so will have same node - pointer , np .
*
* But the OPPs will be considered as shared only if the
* OPP table contains a " opp-shared " property .
*/
2017-01-23 07:41:45 +03:00
if ( opp_table - > shared_opp = = OPP_TABLE_ACCESS_SHARED ) {
_get_opp_table_kref ( opp_table ) ;
managed_table = opp_table ;
}
2016-06-16 16:33:11 +03:00
2017-01-23 07:41:45 +03:00
break ;
2016-05-05 13:50:33 +03:00
}
}
2018-09-07 06:31:54 +03:00
of_node_put ( np ) ;
2017-01-23 07:41:45 +03:00
return managed_table ;
2016-05-05 13:50:33 +03:00
}
2018-06-07 12:20:43 +03:00
/* The caller must call dev_pm_opp_put() after the OPP is used */
static struct dev_pm_opp * _find_opp_of_np ( struct opp_table * opp_table ,
struct device_node * opp_np )
{
struct dev_pm_opp * opp ;
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
if ( opp - > np = = opp_np ) {
dev_pm_opp_get ( opp ) ;
mutex_unlock ( & opp_table - > lock ) ;
return opp ;
}
}
mutex_unlock ( & opp_table - > lock ) ;
return NULL ;
}
static struct device_node * of_parse_required_opp ( struct device_node * np ,
int index )
{
2021-08-12 14:27:20 +03:00
return of_parse_phandle ( np , " required-opps " , index ) ;
2018-06-07 12:20:43 +03:00
}
/* The caller must call dev_pm_opp_put_opp_table() after the table is used */
static struct opp_table * _find_table_of_opp_np ( struct device_node * opp_np )
{
struct opp_table * opp_table ;
2018-11-22 08:34:00 +03:00
struct device_node * opp_table_np ;
2018-06-07 12:20:43 +03:00
2018-11-22 08:34:00 +03:00
opp_table_np = of_get_parent ( opp_np ) ;
if ( ! opp_table_np )
goto err ;
/* It is safe to put the node now as all we need now is its address */
of_node_put ( opp_table_np ) ;
2020-10-27 14:23:21 +03:00
mutex_lock ( & opp_table_lock ) ;
2018-06-07 12:20:43 +03:00
list_for_each_entry ( opp_table , & opp_tables , node ) {
2018-11-22 08:34:00 +03:00
if ( opp_table_np = = opp_table - > np ) {
2018-06-07 12:20:43 +03:00
_get_opp_table_kref ( opp_table ) ;
2020-10-27 14:23:21 +03:00
mutex_unlock ( & opp_table_lock ) ;
2018-06-07 12:20:43 +03:00
return opp_table ;
}
}
2020-10-27 14:23:21 +03:00
mutex_unlock ( & opp_table_lock ) ;
2018-06-07 12:20:43 +03:00
2018-11-22 08:34:00 +03:00
err :
2018-06-07 12:20:43 +03:00
return ERR_PTR ( - ENODEV ) ;
}
/* Free resources previously acquired by _opp_table_alloc_required_tables() */
static void _opp_table_free_required_tables ( struct opp_table * opp_table )
{
struct opp_table * * required_opp_tables = opp_table - > required_opp_tables ;
int i ;
if ( ! required_opp_tables )
return ;
for ( i = 0 ; i < opp_table - > required_opp_count ; i + + ) {
if ( IS_ERR_OR_NULL ( required_opp_tables [ i ] ) )
2019-11-25 11:27:58 +03:00
continue ;
2018-06-07 12:20:43 +03:00
dev_pm_opp_put_opp_table ( required_opp_tables [ i ] ) ;
}
kfree ( required_opp_tables ) ;
opp_table - > required_opp_count = 0 ;
opp_table - > required_opp_tables = NULL ;
2019-11-25 11:27:58 +03:00
list_del ( & opp_table - > lazy ) ;
2018-06-07 12:20:43 +03:00
}
/*
* Populate all devices and opp tables which are part of " required-opps " list .
* Checking only the first OPP node should be enough .
*/
static void _opp_table_alloc_required_tables ( struct opp_table * opp_table ,
struct device * dev ,
struct device_node * opp_np )
{
struct opp_table * * required_opp_tables ;
struct device_node * required_np , * np ;
2019-11-25 11:27:58 +03:00
bool lazy = false ;
2019-05-08 13:13:36 +03:00
int count , i ;
2018-06-07 12:20:43 +03:00
/* Traversing the first OPP node is all we need */
np = of_get_next_available_child ( opp_np , NULL ) ;
if ( ! np ) {
2020-12-08 20:42:27 +03:00
dev_warn ( dev , " Empty OPP table \n " ) ;
2018-06-07 12:20:43 +03:00
return ;
}
count = of_count_phandle_with_args ( np , " required-opps " , NULL ) ;
2021-09-30 13:09:08 +03:00
if ( count < = 0 )
2018-06-07 12:20:43 +03:00
goto put_np ;
required_opp_tables = kcalloc ( count , sizeof ( * required_opp_tables ) ,
GFP_KERNEL ) ;
2019-05-08 13:13:36 +03:00
if ( ! required_opp_tables )
2018-06-07 12:20:43 +03:00
goto put_np ;
opp_table - > required_opp_tables = required_opp_tables ;
opp_table - > required_opp_count = count ;
for ( i = 0 ; i < count ; i + + ) {
required_np = of_parse_required_opp ( np , i ) ;
if ( ! required_np )
goto free_required_tables ;
required_opp_tables [ i ] = _find_table_of_opp_np ( required_np ) ;
of_node_put ( required_np ) ;
2021-06-16 08:33:35 +03:00
if ( IS_ERR ( required_opp_tables [ i ] ) )
2019-11-25 11:27:58 +03:00
lazy = true ;
2018-06-07 12:20:43 +03:00
}
2019-11-25 11:27:58 +03:00
/* Let's do the linking later on */
if ( lazy )
list_add ( & opp_table - > lazy , & lazy_opp_tables ) ;
2018-06-07 12:20:43 +03:00
goto put_np ;
free_required_tables :
_opp_table_free_required_tables ( opp_table ) ;
put_np :
of_node_put ( np ) ;
}
2018-09-05 13:47:14 +03:00
void _of_init_opp_table ( struct opp_table * opp_table , struct device * dev ,
int index )
2016-05-05 13:50:33 +03:00
{
2018-06-14 09:34:43 +03:00
struct device_node * np , * opp_np ;
u32 val ;
2016-05-05 13:50:33 +03:00
/*
* Only required for backward compatibility with v1 bindings , but isn ' t
* harmful for other cases . And so we do it unconditionally .
*/
np = of_node_get ( dev - > of_node ) ;
2018-06-14 09:34:43 +03:00
if ( ! np )
return ;
if ( ! of_property_read_u32 ( np , " clock-latency " , & val ) )
opp_table - > clock_latency_ns_max = val ;
of_property_read_u32 ( np , " voltage-tolerance " ,
& opp_table - > voltage_tolerance_v1 ) ;
2018-06-13 13:30:11 +03:00
if ( of_find_property ( np , " #power-domain-cells " , NULL ) )
opp_table - > is_genpd = true ;
2018-06-14 09:34:43 +03:00
/* Get OPP table node */
opp_np = _opp_of_get_opp_desc_node ( np , index ) ;
of_node_put ( np ) ;
if ( ! opp_np )
return ;
if ( of_property_read_bool ( opp_np , " opp-shared " ) )
opp_table - > shared_opp = OPP_TABLE_ACCESS_SHARED ;
else
opp_table - > shared_opp = OPP_TABLE_ACCESS_EXCLUSIVE ;
opp_table - > np = opp_np ;
2018-06-07 12:20:43 +03:00
_opp_table_alloc_required_tables ( opp_table , dev , opp_np ) ;
2018-06-14 09:34:43 +03:00
of_node_put ( opp_np ) ;
2016-05-05 13:50:33 +03:00
}
2018-06-07 12:20:43 +03:00
void _of_clear_opp_table ( struct opp_table * opp_table )
{
_opp_table_free_required_tables ( opp_table ) ;
}
2018-06-07 12:20:43 +03:00
/*
* Release all resources previously acquired with a call to
* _of_opp_alloc_required_opps ( ) .
*/
void _of_opp_free_required_opps ( struct opp_table * opp_table ,
struct dev_pm_opp * opp )
{
struct dev_pm_opp * * required_opps = opp - > required_opps ;
int i ;
if ( ! required_opps )
return ;
for ( i = 0 ; i < opp_table - > required_opp_count ; i + + ) {
if ( ! required_opps [ i ] )
2019-11-25 11:27:58 +03:00
continue ;
2018-06-07 12:20:43 +03:00
/* Put the reference back */
dev_pm_opp_put ( required_opps [ i ] ) ;
}
opp - > required_opps = NULL ;
2019-11-25 11:27:58 +03:00
kfree ( required_opps ) ;
2018-06-07 12:20:43 +03:00
}
/* Populate all required OPPs which are part of "required-opps" list */
static int _of_opp_alloc_required_opps ( struct opp_table * opp_table ,
struct dev_pm_opp * opp )
{
struct dev_pm_opp * * required_opps ;
struct opp_table * required_table ;
struct device_node * np ;
int i , ret , count = opp_table - > required_opp_count ;
if ( ! count )
return 0 ;
required_opps = kcalloc ( count , sizeof ( * required_opps ) , GFP_KERNEL ) ;
if ( ! required_opps )
return - ENOMEM ;
opp - > required_opps = required_opps ;
for ( i = 0 ; i < count ; i + + ) {
required_table = opp_table - > required_opp_tables [ i ] ;
2019-11-25 11:27:58 +03:00
/* Required table not added yet, we will link later */
if ( IS_ERR_OR_NULL ( required_table ) )
continue ;
2018-06-07 12:20:43 +03:00
np = of_parse_required_opp ( opp - > np , i ) ;
if ( unlikely ( ! np ) ) {
ret = - ENODEV ;
goto free_required_opps ;
}
required_opps [ i ] = _find_opp_of_np ( required_table , np ) ;
of_node_put ( np ) ;
if ( ! required_opps [ i ] ) {
pr_err ( " %s: Unable to find required OPP node: %pOF (%d) \n " ,
__func__ , opp - > np , i ) ;
ret = - ENODEV ;
goto free_required_opps ;
}
}
return 0 ;
free_required_opps :
_of_opp_free_required_opps ( opp_table , opp ) ;
return ret ;
}
2019-11-25 11:27:58 +03:00
/* Link required OPPs for an individual OPP */
static int lazy_link_required_opps ( struct opp_table * opp_table ,
struct opp_table * new_table , int index )
{
struct device_node * required_np ;
struct dev_pm_opp * opp ;
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
required_np = of_parse_required_opp ( opp - > np , index ) ;
if ( unlikely ( ! required_np ) )
return - ENODEV ;
opp - > required_opps [ index ] = _find_opp_of_np ( new_table , required_np ) ;
of_node_put ( required_np ) ;
if ( ! opp - > required_opps [ index ] ) {
pr_err ( " %s: Unable to find required OPP node: %pOF (%d) \n " ,
__func__ , opp - > np , index ) ;
return - ENODEV ;
}
}
return 0 ;
}
/* Link required OPPs for all OPPs of the newly added OPP table */
static void lazy_link_required_opp_table ( struct opp_table * new_table )
{
struct opp_table * opp_table , * temp , * * required_opp_tables ;
struct device_node * required_np , * opp_np , * required_table_np ;
struct dev_pm_opp * opp ;
int i , ret ;
mutex_lock ( & opp_table_lock ) ;
list_for_each_entry_safe ( opp_table , temp , & lazy_opp_tables , lazy ) {
bool lazy = false ;
/* opp_np can't be invalid here */
opp_np = of_get_next_available_child ( opp_table - > np , NULL ) ;
for ( i = 0 ; i < opp_table - > required_opp_count ; i + + ) {
required_opp_tables = opp_table - > required_opp_tables ;
/* Required opp-table is already parsed */
if ( ! IS_ERR ( required_opp_tables [ i ] ) )
continue ;
/* required_np can't be invalid here */
required_np = of_parse_required_opp ( opp_np , i ) ;
required_table_np = of_get_parent ( required_np ) ;
of_node_put ( required_table_np ) ;
of_node_put ( required_np ) ;
/*
* Newly added table isn ' t the required opp - table for
* opp_table .
*/
if ( required_table_np ! = new_table - > np ) {
lazy = true ;
continue ;
}
required_opp_tables [ i ] = new_table ;
_get_opp_table_kref ( new_table ) ;
/* Link OPPs now */
ret = lazy_link_required_opps ( opp_table , new_table , i ) ;
if ( ret ) {
/* The OPPs will be marked unusable */
lazy = false ;
break ;
}
}
of_node_put ( opp_np ) ;
/* All required opp-tables found, remove from lazy list */
if ( ! lazy ) {
2021-05-18 07:49:10 +03:00
list_del_init ( & opp_table - > lazy ) ;
2019-11-25 11:27:58 +03:00
list_for_each_entry ( opp , & opp_table - > opp_list , node )
_required_opps_available ( opp , opp_table - > required_opp_count ) ;
}
}
mutex_unlock ( & opp_table_lock ) ;
}
2020-05-27 22:24:18 +03:00
static int _bandwidth_supported ( struct device * dev , struct opp_table * opp_table )
{
struct device_node * np , * opp_np ;
struct property * prop ;
if ( ! opp_table ) {
np = of_node_get ( dev - > of_node ) ;
if ( ! np )
return - ENODEV ;
opp_np = _opp_of_get_opp_desc_node ( np , 0 ) ;
of_node_put ( np ) ;
} else {
opp_np = of_node_get ( opp_table - > np ) ;
}
/* Lets not fail in case we are parsing opp-v1 bindings */
if ( ! opp_np )
return 0 ;
/* Checking only first OPP is sufficient */
np = of_get_next_available_child ( opp_np , NULL ) ;
if ( ! np ) {
dev_err ( dev , " OPP table empty \n " ) ;
return - EINVAL ;
}
of_node_put ( opp_np ) ;
prop = of_find_property ( np , " opp-peak-kBps " , NULL ) ;
of_node_put ( np ) ;
if ( ! prop | | ! prop - > length )
return 0 ;
return 1 ;
}
2020-05-12 15:53:21 +03:00
int dev_pm_opp_of_find_icc_paths ( struct device * dev ,
struct opp_table * opp_table )
{
struct device_node * np ;
2020-05-27 22:24:18 +03:00
int ret , i , count , num_paths ;
2020-05-12 15:53:21 +03:00
struct icc_path * * paths ;
2020-05-27 22:24:18 +03:00
ret = _bandwidth_supported ( dev , opp_table ) ;
2020-12-08 20:42:27 +03:00
if ( ret = = - EINVAL )
return 0 ; /* Empty OPP table is a valid corner-case, let's not fail */
else if ( ret < = 0 )
2020-05-27 22:24:18 +03:00
return ret ;
ret = 0 ;
2020-05-12 15:53:21 +03:00
np = of_node_get ( dev - > of_node ) ;
if ( ! np )
return 0 ;
count = of_count_phandle_with_args ( np , " interconnects " ,
" #interconnect-cells " ) ;
of_node_put ( np ) ;
if ( count < 0 )
return 0 ;
/* two phandles when #interconnect-cells = <1> */
if ( count % 2 ) {
dev_err ( dev , " %s: Invalid interconnects values \n " , __func__ ) ;
return - EINVAL ;
}
num_paths = count / 2 ;
paths = kcalloc ( num_paths , sizeof ( * paths ) , GFP_KERNEL ) ;
if ( ! paths )
return - ENOMEM ;
for ( i = 0 ; i < num_paths ; i + + ) {
paths [ i ] = of_icc_get_by_index ( dev , i ) ;
if ( IS_ERR ( paths [ i ] ) ) {
ret = PTR_ERR ( paths [ i ] ) ;
if ( ret ! = - EPROBE_DEFER ) {
dev_err ( dev , " %s: Unable to get path%d: %d \n " ,
__func__ , i , ret ) ;
}
goto err ;
}
}
if ( opp_table ) {
opp_table - > paths = paths ;
opp_table - > path_count = num_paths ;
return 0 ;
}
err :
while ( i - - )
icc_put ( paths [ i ] ) ;
kfree ( paths ) ;
return ret ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_find_icc_paths ) ;
2016-05-05 13:50:33 +03:00
static bool _opp_is_supported ( struct device * dev , struct opp_table * opp_table ,
struct device_node * np )
{
2020-08-26 14:02:27 +03:00
unsigned int levels = opp_table - > supported_hw_count ;
int count , versions , ret , i , j ;
u32 val ;
2016-05-05 13:50:33 +03:00
2016-09-23 23:07:47 +03:00
if ( ! opp_table - > supported_hw ) {
/*
* In the case that no supported_hw has been set by the
* platform but there is an opp - supported - hw value set for
* an OPP then the OPP should not be enabled as there is
* no way to see if the hardware supports it .
*/
if ( of_find_property ( np , " opp-supported-hw " , NULL ) )
return false ;
else
return true ;
}
2016-05-05 13:50:33 +03:00
2020-08-26 14:02:27 +03:00
count = of_property_count_u32_elems ( np , " opp-supported-hw " ) ;
if ( count < = 0 | | count % levels ) {
dev_err ( dev , " %s: Invalid opp-supported-hw property (%d) \n " ,
__func__ , count ) ;
return false ;
}
versions = count / levels ;
/* All levels in at least one of the versions should match */
for ( i = 0 ; i < versions ; i + + ) {
bool supported = true ;
for ( j = 0 ; j < levels ; j + + ) {
ret = of_property_read_u32_index ( np , " opp-supported-hw " ,
i * levels + j , & val ) ;
if ( ret ) {
dev_warn ( dev , " %s: failed to read opp-supported-hw property at index %d: %d \n " ,
__func__ , i * levels + j , ret ) ;
return false ;
}
/* Check if the level is supported */
if ( ! ( val & opp_table - > supported_hw [ j ] ) ) {
supported = false ;
break ;
}
2016-05-05 13:50:33 +03:00
}
2020-08-26 14:02:27 +03:00
if ( supported )
return true ;
2016-05-05 13:50:33 +03:00
}
2020-08-26 14:02:27 +03:00
return false ;
2016-05-05 13:50:33 +03:00
}
static int opp_parse_supplies ( struct dev_pm_opp * opp , struct device * dev ,
struct opp_table * opp_table )
{
2016-12-01 13:58:19 +03:00
u32 * microvolt , * microamp = NULL ;
2018-12-11 14:09:36 +03:00
int supplies = opp_table - > regulator_count , vcount , icount , ret , i , j ;
2016-05-05 13:50:33 +03:00
struct property * prop = NULL ;
char name [ NAME_MAX ] ;
/* Search for "opp-microvolt-<name>" */
if ( opp_table - > prop_name ) {
snprintf ( name , sizeof ( name ) , " opp-microvolt-%s " ,
opp_table - > prop_name ) ;
prop = of_find_property ( opp - > np , name , NULL ) ;
}
if ( ! prop ) {
/* Search for "opp-microvolt" */
sprintf ( name , " opp-microvolt " ) ;
prop = of_find_property ( opp - > np , name , NULL ) ;
/* Missing property isn't a problem, but an invalid entry is */
2017-05-23 07:02:12 +03:00
if ( ! prop ) {
2018-12-11 14:09:36 +03:00
if ( unlikely ( supplies = = - 1 ) ) {
/* Initialize regulator_count */
opp_table - > regulator_count = 0 ;
return 0 ;
}
if ( ! supplies )
2017-05-23 07:02:12 +03:00
return 0 ;
dev_err ( dev , " %s: opp-microvolt missing although OPP managing regulators \n " ,
__func__ ) ;
return - EINVAL ;
}
2016-05-05 13:50:33 +03:00
}
2018-12-11 14:09:36 +03:00
if ( unlikely ( supplies = = - 1 ) ) {
/* Initialize regulator_count */
supplies = opp_table - > regulator_count = 1 ;
} else if ( unlikely ( ! supplies ) ) {
dev_err ( dev , " %s: opp-microvolt wasn't expected \n " , __func__ ) ;
return - EINVAL ;
}
2016-12-01 13:58:19 +03:00
vcount = of_property_count_u32_elems ( opp - > np , name ) ;
if ( vcount < 0 ) {
2016-05-05 13:50:33 +03:00
dev_err ( dev , " %s: Invalid %s property (%d) \n " ,
2016-12-01 13:58:19 +03:00
__func__ , name , vcount ) ;
return vcount ;
2016-05-05 13:50:33 +03:00
}
2016-12-01 13:58:19 +03:00
/* There can be one or three elements per supply */
if ( vcount ! = supplies & & vcount ! = supplies * 3 ) {
dev_err ( dev , " %s: Invalid number of elements in %s property (%d) with supplies (%d) \n " ,
__func__ , name , vcount , supplies ) ;
2016-05-05 13:50:33 +03:00
return - EINVAL ;
}
2016-12-01 13:58:19 +03:00
microvolt = kmalloc_array ( vcount , sizeof ( * microvolt ) , GFP_KERNEL ) ;
if ( ! microvolt )
return - ENOMEM ;
ret = of_property_read_u32_array ( opp - > np , name , microvolt , vcount ) ;
2016-05-05 13:50:33 +03:00
if ( ret ) {
dev_err ( dev , " %s: error parsing %s: %d \n " , __func__ , name , ret ) ;
2016-12-01 13:58:19 +03:00
ret = - EINVAL ;
goto free_microvolt ;
2016-05-05 13:50:33 +03:00
}
/* Search for "opp-microamp-<name>" */
prop = NULL ;
if ( opp_table - > prop_name ) {
snprintf ( name , sizeof ( name ) , " opp-microamp-%s " ,
opp_table - > prop_name ) ;
prop = of_find_property ( opp - > np , name , NULL ) ;
}
if ( ! prop ) {
/* Search for "opp-microamp" */
sprintf ( name , " opp-microamp " ) ;
prop = of_find_property ( opp - > np , name , NULL ) ;
}
2016-12-01 13:58:19 +03:00
if ( prop ) {
icount = of_property_count_u32_elems ( opp - > np , name ) ;
if ( icount < 0 ) {
dev_err ( dev , " %s: Invalid %s property (%d) \n " , __func__ ,
name , icount ) ;
ret = icount ;
goto free_microvolt ;
}
2016-05-05 13:50:33 +03:00
2016-12-01 13:58:19 +03:00
if ( icount ! = supplies ) {
dev_err ( dev , " %s: Invalid number of elements in %s property (%d) with supplies (%d) \n " ,
__func__ , name , icount , supplies ) ;
ret = - EINVAL ;
goto free_microvolt ;
}
microamp = kmalloc_array ( icount , sizeof ( * microamp ) , GFP_KERNEL ) ;
if ( ! microamp ) {
ret = - EINVAL ;
goto free_microvolt ;
}
ret = of_property_read_u32_array ( opp - > np , name , microamp ,
icount ) ;
if ( ret ) {
dev_err ( dev , " %s: error parsing %s: %d \n " , __func__ ,
name , ret ) ;
ret = - EINVAL ;
goto free_microamp ;
}
}
for ( i = 0 , j = 0 ; i < supplies ; i + + ) {
opp - > supplies [ i ] . u_volt = microvolt [ j + + ] ;
if ( vcount = = supplies ) {
opp - > supplies [ i ] . u_volt_min = opp - > supplies [ i ] . u_volt ;
opp - > supplies [ i ] . u_volt_max = opp - > supplies [ i ] . u_volt ;
} else {
opp - > supplies [ i ] . u_volt_min = microvolt [ j + + ] ;
opp - > supplies [ i ] . u_volt_max = microvolt [ j + + ] ;
}
if ( microamp )
opp - > supplies [ i ] . u_amp = microamp [ i ] ;
}
free_microamp :
kfree ( microamp ) ;
free_microvolt :
kfree ( microvolt ) ;
return ret ;
2016-05-05 13:50:33 +03:00
}
/**
* dev_pm_opp_of_remove_table ( ) - Free OPP table entries created from static DT
* entries
* @ dev : device pointer used to lookup OPP table .
*
* Free OPPs created using static entries present in DT .
*/
void dev_pm_opp_of_remove_table ( struct device * dev )
{
2020-08-20 10:48:23 +03:00
dev_pm_opp_remove_table ( dev ) ;
2016-05-05 13:50:33 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_remove_table ) ;
2020-05-12 15:53:22 +03:00
static int _read_bw ( struct dev_pm_opp * new_opp , struct opp_table * table ,
struct device_node * np , bool peak )
2020-05-12 15:53:21 +03:00
{
const char * name = peak ? " opp-peak-kBps " : " opp-avg-kBps " ;
struct property * prop ;
int i , count , ret ;
u32 * bw ;
prop = of_find_property ( np , name , NULL ) ;
if ( ! prop )
return - ENODEV ;
count = prop - > length / sizeof ( u32 ) ;
2020-05-12 15:53:22 +03:00
if ( table - > path_count ! = count ) {
pr_err ( " %s: Mismatch between %s and paths (%d %d) \n " ,
__func__ , name , count , table - > path_count ) ;
return - EINVAL ;
}
2020-05-12 15:53:21 +03:00
bw = kmalloc_array ( count , sizeof ( * bw ) , GFP_KERNEL ) ;
if ( ! bw )
return - ENOMEM ;
ret = of_property_read_u32_array ( np , name , bw , count ) ;
if ( ret ) {
pr_err ( " %s: Error parsing %s: %d \n " , __func__ , name , ret ) ;
goto out ;
}
for ( i = 0 ; i < count ; i + + ) {
if ( peak )
new_opp - > bandwidth [ i ] . peak = kBps_to_icc ( bw [ i ] ) ;
else
new_opp - > bandwidth [ i ] . avg = kBps_to_icc ( bw [ i ] ) ;
}
out :
kfree ( bw ) ;
return ret ;
}
2020-05-12 15:53:22 +03:00
static int _read_opp_key ( struct dev_pm_opp * new_opp , struct opp_table * table ,
struct device_node * np , bool * rate_not_available )
2020-05-12 15:53:19 +03:00
{
2020-05-12 15:53:21 +03:00
bool found = false ;
2020-05-12 15:53:19 +03:00
u64 rate ;
int ret ;
ret = of_property_read_u64 ( np , " opp-hz " , & rate ) ;
if ( ! ret ) {
/*
* Rate is defined as an unsigned long in clk API , and so
* casting explicitly to its type . Must be fixed once rate is 64
* bit guaranteed in clk API .
*/
new_opp - > rate = ( unsigned long ) rate ;
2020-05-12 15:53:21 +03:00
found = true ;
2020-05-12 15:53:19 +03:00
}
* rate_not_available = ! ! ret ;
2020-05-12 15:53:21 +03:00
/*
* Bandwidth consists of peak and average ( optional ) values :
* opp - peak - kBps = < path1_value path2_value > ;
* opp - avg - kBps = < path1_value path2_value > ;
*/
2020-05-12 15:53:22 +03:00
ret = _read_bw ( new_opp , table , np , true ) ;
2020-05-12 15:53:21 +03:00
if ( ! ret ) {
found = true ;
2020-05-12 15:53:22 +03:00
ret = _read_bw ( new_opp , table , np , false ) ;
2020-05-12 15:53:21 +03:00
}
/* The properties were found but we failed to parse them */
if ( ret & & ret ! = - ENODEV )
return ret ;
if ( ! of_property_read_u32 ( np , " opp-level " , & new_opp - > level ) )
found = true ;
if ( found )
return 0 ;
2020-05-12 15:53:19 +03:00
return ret ;
}
2016-05-05 13:50:33 +03:00
/**
* _opp_add_static_v2 ( ) - Allocate static OPPs ( As per ' v2 ' DT bindings )
2017-01-02 12:11:01 +03:00
* @ opp_table : OPP table
2016-05-05 13:50:33 +03:00
* @ dev : device for which we do this operation
* @ np : device node
*
* This function adds an opp definition to the opp table and returns status . The
* opp can be controlled using dev_pm_opp_enable / disable functions and may be
* removed by dev_pm_opp_remove .
*
* Return :
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
* Valid OPP pointer :
* On success
* NULL :
2016-05-05 13:50:33 +03:00
* Duplicate OPPs ( both freq and volt are same ) and opp - > available
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
* OR if the OPP is not supported by hardware .
* ERR_PTR ( - EEXIST ) :
* Freq are same and volt are different OR
2016-05-05 13:50:33 +03:00
* Duplicate OPPs ( both freq and volt are same ) and ! opp - > available
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
* ERR_PTR ( - ENOMEM ) :
* Memory allocation failure
* ERR_PTR ( - EINVAL ) :
* Failed parsing the OPP node
2016-05-05 13:50:33 +03:00
*/
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
static struct dev_pm_opp * _opp_add_static_v2 ( struct opp_table * opp_table ,
struct device * dev , struct device_node * np )
2016-05-05 13:50:33 +03:00
{
struct dev_pm_opp * new_opp ;
u32 val ;
int ret ;
2018-04-06 12:05:45 +03:00
bool rate_not_available = false ;
2016-05-05 13:50:33 +03:00
2017-01-02 12:11:01 +03:00
new_opp = _opp_allocate ( opp_table ) ;
if ( ! new_opp )
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
return ERR_PTR ( - ENOMEM ) ;
2016-05-05 13:50:33 +03:00
2020-05-12 15:53:22 +03:00
ret = _read_opp_key ( new_opp , opp_table , np , & rate_not_available ) ;
2021-06-16 08:33:35 +03:00
if ( ret < 0 ) {
2020-05-12 15:53:19 +03:00
dev_err ( dev , " %s: opp key field not found \n " , __func__ ) ;
goto free_opp ;
2016-05-05 13:50:33 +03:00
}
/* Check if the OPP supports hardware's hierarchy of versions or not */
if ( ! _opp_is_supported ( dev , opp_table , np ) ) {
2021-01-18 03:55:15 +03:00
dev_dbg ( dev , " OPP not supported by hardware: %lu \n " ,
new_opp - > rate ) ;
2016-05-05 13:50:33 +03:00
goto free_opp ;
}
new_opp - > turbo = of_property_read_bool ( np , " turbo-mode " ) ;
new_opp - > np = np ;
new_opp - > dynamic = false ;
new_opp - > available = true ;
2018-06-07 12:20:43 +03:00
ret = _of_opp_alloc_required_opps ( opp_table , new_opp ) ;
if ( ret )
goto free_opp ;
2016-05-05 13:50:33 +03:00
if ( ! of_property_read_u32 ( np , " clock-latency-ns " , & val ) )
new_opp - > clock_latency_ns = val ;
ret = opp_parse_supplies ( new_opp , dev , opp_table ) ;
if ( ret )
2018-06-07 12:20:43 +03:00
goto free_required_opps ;
2016-05-05 13:50:33 +03:00
2018-06-14 07:33:26 +03:00
if ( opp_table - > is_genpd )
new_opp - > pstate = pm_genpd_opp_to_performance_state ( dev , new_opp ) ;
2016-05-05 13:50:33 +03:00
2018-04-06 12:05:45 +03:00
ret = _opp_add ( dev , new_opp , opp_table , rate_not_available ) ;
2017-01-02 12:10:55 +03:00
if ( ret ) {
/* Don't return error for duplicate OPPs */
if ( ret = = - EBUSY )
ret = 0 ;
2018-06-07 12:20:43 +03:00
goto free_required_opps ;
2017-01-02 12:10:55 +03:00
}
2016-05-05 13:50:33 +03:00
/* OPP to select on device suspend */
if ( of_property_read_bool ( np , " opp-suspend " ) ) {
if ( opp_table - > suspend_opp ) {
2019-07-09 11:00:13 +03:00
/* Pick the OPP with higher rate as suspend OPP */
if ( new_opp - > rate > opp_table - > suspend_opp - > rate ) {
opp_table - > suspend_opp - > suspend = false ;
new_opp - > suspend = true ;
opp_table - > suspend_opp = new_opp ;
}
2016-05-05 13:50:33 +03:00
} else {
new_opp - > suspend = true ;
opp_table - > suspend_opp = new_opp ;
}
}
if ( new_opp - > clock_latency_ns > opp_table - > clock_latency_ns_max )
opp_table - > clock_latency_ns_max = new_opp - > clock_latency_ns ;
2021-01-18 03:55:24 +03:00
pr_debug ( " %s: turbo:%d rate:%lu uv:%lu uvmin:%lu uvmax:%lu latency:%lu level:%u \n " ,
2016-12-01 13:58:17 +03:00
__func__ , new_opp - > turbo , new_opp - > rate ,
2016-12-01 13:58:19 +03:00
new_opp - > supplies [ 0 ] . u_volt , new_opp - > supplies [ 0 ] . u_volt_min ,
2021-01-18 03:55:24 +03:00
new_opp - > supplies [ 0 ] . u_volt_max , new_opp - > clock_latency_ns ,
new_opp - > level ) ;
2016-05-05 13:50:33 +03:00
/*
* Notify the changes in the availability of the operable
* frequency / voltage list .
*/
2017-01-23 07:41:49 +03:00
blocking_notifier_call_chain ( & opp_table - > head , OPP_EVENT_ADD , new_opp ) ;
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
return new_opp ;
2016-05-05 13:50:33 +03:00
2018-06-07 12:20:43 +03:00
free_required_opps :
_of_opp_free_required_opps ( opp_table , new_opp ) ;
2016-05-05 13:50:33 +03:00
free_opp :
2017-01-02 12:11:01 +03:00
_opp_free ( new_opp ) ;
2021-10-08 10:46:52 +03:00
return ret ? ERR_PTR ( ret ) : NULL ;
2016-05-05 13:50:33 +03:00
}
/* Initializes OPP tables based on new bindings */
2018-09-12 08:51:17 +03:00
static int _of_add_opp_table_v2 ( struct device * dev , struct opp_table * opp_table )
2016-05-05 13:50:33 +03:00
{
struct device_node * np ;
2020-09-11 12:26:18 +03:00
int ret , count = 0 ;
2016-11-18 13:17:46 +03:00
struct dev_pm_opp * opp ;
2016-05-05 13:50:33 +03:00
2018-09-07 06:31:54 +03:00
/* OPP table is already initialized for the device */
2019-11-11 14:05:03 +03:00
mutex_lock ( & opp_table - > lock ) ;
2018-09-07 06:31:54 +03:00
if ( opp_table - > parsed_static_opps ) {
2019-11-11 14:05:03 +03:00
opp_table - > parsed_static_opps + + ;
mutex_unlock ( & opp_table - > lock ) ;
2018-09-07 06:31:54 +03:00
return 0 ;
}
2019-11-11 14:05:03 +03:00
opp_table - > parsed_static_opps = 1 ;
mutex_unlock ( & opp_table - > lock ) ;
2019-10-18 11:41:58 +03:00
2016-05-05 13:50:33 +03:00
/* We have opp-table node now, iterate over it and add OPPs */
2018-09-12 08:51:17 +03:00
for_each_available_child_of_node ( opp_table - > np , np ) {
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
opp = _opp_add_static_v2 ( opp_table , dev , np ) ;
if ( IS_ERR ( opp ) ) {
ret = PTR_ERR ( opp ) ;
2016-05-05 13:50:33 +03:00
dev_err ( dev , " %s: Failed to add OPP, %d \n " , __func__ ,
ret ) ;
2017-10-04 09:05:03 +03:00
of_node_put ( np ) ;
2019-11-11 14:05:03 +03:00
goto remove_static_opp ;
PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added
Currently the _of_add_opp_table_v2 call loops through the OPP nodes in
the operating-points-v2 table in the device tree and calls
_opp_add_static_v2 for each to add them to the table. It counts each
iteration through this loop as an added OPP, however there are cases
where _opp_add_static_v2() returns 0 but no new OPP is added to the
list.
This can happen while adding duplicate OPP or if the OPP isn't supported
by hardware.
Because of this the count variable will contain the number of OPP nodes
in the table in device tree but not necessarily the ones that are
actually added.
As this count value is what is checked to determine if there are any
valid OPPs, if a platform has an operating-points-v2 table with all OPP
nodes containing opp-supported-hw values that are not currently
supported, then _of_add_opp_table_v2 will fail to abort as it should due
to an empty table.
Additionally, since commit 3ba98324e81a ("PM / OPP: Get
performance state using genpd helper"), the same count variable is
compared against the number of OPPs containing performance states and
requires that either all or none have pstates set, however in the case
of any opp table that has any entries that do not get added by
_opp_add_static_v2 due to incompatible opp-supported-hw fields, these
numbers will not match and _of_add_opp_table_v2 will incorrectly fail.
We need to clearly identify all the three cases (success, failure,
unsupported/duplicate OPPs) and then increment count only on success
case. Change return type of _opp_add_static_v2() to return the pointer
to the newly added OPP instead of an integer. This routine now returns a
valid pointer if the OPP is really added, NULL for unsupported or
duplicate OPPs, and error value cased as a pointer on errors.
Ideally the fixes tag in this commit should point back to the commit
that introduced OPP v2 initially, as that's where we started incorrectly
accounting for duplicate OPPs:
commit 274659029c9d ("PM / OPP: Add support to parse "operating-points-v2" bindings")
But it wasn't a real problem until recently as the count was only used
to check if any OPPs are added or not. And so this commit points to a
rather recent commit where we added more code that depends on the value
of "count".
Fixes: 3ba98324e81a ("PM / OPP: Get performance state using genpd helper")
Reported-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Tested-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-10-03 13:43:15 +03:00
} else if ( opp ) {
count + + ;
2016-05-05 13:50:33 +03:00
}
}
2021-07-26 11:30:56 +03:00
/* There should be one or more OPPs defined */
if ( ! count ) {
dev_err ( dev , " %s: no supported OPPs " , __func__ ) ;
2019-11-18 12:11:07 +03:00
ret = - ENOENT ;
2019-11-11 14:05:03 +03:00
goto remove_static_opp ;
2019-11-18 12:11:07 +03:00
}
2016-05-05 13:50:33 +03:00
2020-09-11 12:26:18 +03:00
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
/* Any non-zero performance state would enable the feature */
if ( opp - > pstate ) {
opp_table - > genpd_performance_state = true ;
break ;
}
2016-11-18 13:17:46 +03:00
}
2019-11-25 11:27:58 +03:00
lazy_link_required_opp_table ( opp_table ) ;
2018-09-12 10:05:19 +03:00
return 0 ;
2019-11-18 12:11:07 +03:00
2019-11-11 14:05:03 +03:00
remove_static_opp :
_opp_remove_all_static ( opp_table ) ;
2019-11-18 12:11:07 +03:00
return ret ;
2016-05-05 13:50:33 +03:00
}
/* Initializes OPP tables based on old-deprecated bindings */
2018-09-12 08:51:17 +03:00
static int _of_add_opp_table_v1 ( struct device * dev , struct opp_table * opp_table )
2016-05-05 13:50:33 +03:00
{
const struct property * prop ;
const __be32 * val ;
2017-01-02 12:11:01 +03:00
int nr , ret = 0 ;
2016-05-05 13:50:33 +03:00
2020-09-01 12:37:09 +03:00
mutex_lock ( & opp_table - > lock ) ;
if ( opp_table - > parsed_static_opps ) {
opp_table - > parsed_static_opps + + ;
mutex_unlock ( & opp_table - > lock ) ;
return 0 ;
}
opp_table - > parsed_static_opps = 1 ;
mutex_unlock ( & opp_table - > lock ) ;
2016-05-05 13:50:33 +03:00
prop = of_find_property ( dev - > of_node , " operating-points " , NULL ) ;
2020-09-01 12:37:09 +03:00
if ( ! prop ) {
ret = - ENODEV ;
goto remove_static_opp ;
}
if ( ! prop - > value ) {
ret = - ENODATA ;
goto remove_static_opp ;
}
2016-05-05 13:50:33 +03:00
/*
* Each OPP is a set of tuples consisting of frequency and
* voltage like < freq - kHz vol - uV > .
*/
nr = prop - > length / sizeof ( u32 ) ;
if ( nr % 2 ) {
dev_err ( dev , " %s: Invalid OPP table \n " , __func__ ) ;
2020-09-01 12:37:09 +03:00
ret = - EINVAL ;
goto remove_static_opp ;
2016-05-05 13:50:33 +03:00
}
val = prop - > value ;
while ( nr ) {
unsigned long freq = be32_to_cpup ( val + + ) * 1000 ;
unsigned long volt = be32_to_cpup ( val + + ) ;
2017-01-02 12:11:01 +03:00
ret = _opp_add_v1 ( opp_table , dev , freq , volt , false ) ;
2017-01-02 12:10:58 +03:00
if ( ret ) {
dev_err ( dev , " %s: Failed to add OPP %ld (%d) \n " ,
__func__ , freq , ret ) ;
2020-09-01 12:37:09 +03:00
goto remove_static_opp ;
2017-01-02 12:10:58 +03:00
}
2016-05-05 13:50:33 +03:00
nr - = 2 ;
}
2020-10-14 07:26:28 +03:00
return 0 ;
2020-09-01 12:37:09 +03:00
remove_static_opp :
_opp_remove_all_static ( opp_table ) ;
2017-01-02 12:11:01 +03:00
return ret ;
2016-05-05 13:50:33 +03:00
}
2021-01-28 09:35:22 +03:00
static int _of_add_table_indexed ( struct device * dev , int index , bool getclk )
2016-05-05 13:50:33 +03:00
{
2018-09-12 08:51:17 +03:00
struct opp_table * opp_table ;
2021-01-27 10:15:56 +03:00
int ret , count ;
2016-05-05 13:50:33 +03:00
2021-01-27 10:15:56 +03:00
if ( index ) {
/*
* If only one phandle is present , then the same OPP table
* applies for all index requests .
*/
count = of_count_phandle_with_args ( dev - > of_node ,
" operating-points-v2 " , NULL ) ;
if ( count = = 1 )
index = 0 ;
}
2021-01-28 09:35:22 +03:00
opp_table = _add_opp_table_indexed ( dev , index , getclk ) ;
opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
The OPP core manages various resources, e.g. clocks or interconnect paths.
These resources are looked up when the OPP table is allocated once
dev_pm_opp_get_opp_table() is called the first time (either directly
or indirectly through one of the many helper functions).
At this point, the resources may not be available yet, i.e. looking them
up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table()
is currently unable to propagate this error code since it only returns
the allocated OPP table or NULL.
This means that all consumers of the OPP core are required to make sure
that all necessary resources are available. Usually this happens by
requesting them, checking the result and releasing them immediately after.
For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to
several drivers now just to make sure the interconnect providers are
ready before the OPP table is allocated. If this call is missing,
the OPP core will only warn about this and then attempt to continue
without interconnect. This will eventually fail horribly, e.g.:
cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517
... later ...
of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0)
cpu cpu0: _opp_add_static_v2: opp key field not found
cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
This example happens when trying to use interconnects for a CPU OPP
table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls
dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table
early. To fix the problem with the current approach we would need to add
yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL).
But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects...
This commit attempts to make this more robust by allowing
dev_pm_opp_get_opp_table() to return an error pointer. Fixing all
the usages is trivial because the function is usually used indirectly
through another helper (e.g. dev_pm_opp_set_supported_hw() above).
These other helpers already return an error pointer.
The example above then works correctly because set_supported_hw() will
return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that
error. It should also be possible to remove the remaining usages of
"dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well.
Note that this commit currently only handles -EPROBE_DEFER for the
clock/interconnects within _allocate_opp_table(). Other errors are just
ignored as before. Eventually those should be propagated as well.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
[ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for
EPROBE_DEFER in domain.c, fix NULL return value and reorder
code a bit in core.c, and update exynos-asv.c ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-07-27 12:30:46 +03:00
if ( IS_ERR ( opp_table ) )
return PTR_ERR ( opp_table ) ;
2018-09-12 08:51:17 +03:00
2016-05-05 13:50:33 +03:00
/*
2018-09-12 08:51:17 +03:00
* OPPs have two version of bindings now . Also try the old ( v1 )
* bindings for backward compatibility with older dtbs .
2016-05-05 13:50:33 +03:00
*/
2018-09-12 08:51:17 +03:00
if ( opp_table - > np )
ret = _of_add_opp_table_v2 ( dev , opp_table ) ;
else
ret = _of_add_opp_table_v1 ( dev , opp_table ) ;
2016-05-05 13:50:33 +03:00
2018-09-12 08:51:17 +03:00
if ( ret )
dev_pm_opp_put_opp_table ( opp_table ) ;
2016-05-05 13:50:33 +03:00
return ret ;
}
2021-03-14 19:33:57 +03:00
static void devm_pm_opp_of_table_release ( void * data )
{
dev_pm_opp_of_remove_table ( data ) ;
}
2021-09-20 20:22:46 +03:00
static int _devm_of_add_table_indexed ( struct device * dev , int index , bool getclk )
{
int ret ;
ret = _of_add_table_indexed ( dev , index , getclk ) ;
if ( ret )
return ret ;
return devm_add_action_or_reset ( dev , devm_pm_opp_of_table_release , dev ) ;
}
2021-03-14 19:33:57 +03:00
/**
* devm_pm_opp_of_add_table ( ) - Initialize opp table from device tree
* @ dev : device pointer used to lookup OPP table .
*
* Register the initial OPP table with the OPP library for given device .
*
* The opp_table structure will be freed after the device is destroyed .
*
* Return :
* 0 On success OR
* Duplicate OPPs ( both freq and volt are same ) and opp - > available
* - EEXIST Freq are same and volt are different OR
* Duplicate OPPs ( both freq and volt are same ) and ! opp - > available
* - ENOMEM Memory allocation failure
* - ENODEV when ' operating - points ' property is not found or is invalid data
* in device node .
* - ENODATA when empty ' operating - points ' property is found
* - EINVAL when invalid entries are found in opp - v2 table
*/
int devm_pm_opp_of_add_table ( struct device * dev )
{
2021-09-20 20:22:46 +03:00
return _devm_of_add_table_indexed ( dev , 0 , true ) ;
2021-03-14 19:33:57 +03:00
}
EXPORT_SYMBOL_GPL ( devm_pm_opp_of_add_table ) ;
2017-04-26 08:15:46 +03:00
/**
2021-01-27 10:15:56 +03:00
* dev_pm_opp_of_add_table ( ) - Initialize opp table from device tree
2017-04-26 08:15:46 +03:00
* @ dev : device pointer used to lookup OPP table .
*
2021-01-27 10:15:56 +03:00
* Register the initial OPP table with the OPP library for given device .
2017-04-26 08:15:46 +03:00
*
* Return :
* 0 On success OR
* Duplicate OPPs ( both freq and volt are same ) and opp - > available
* - EEXIST Freq are same and volt are different OR
* Duplicate OPPs ( both freq and volt are same ) and ! opp - > available
* - ENOMEM Memory allocation failure
* - ENODEV when ' operating - points ' property is not found or is invalid data
* in device node .
* - ENODATA when empty ' operating - points ' property is found
* - EINVAL when invalid entries are found in opp - v2 table
*/
2021-01-27 10:15:56 +03:00
int dev_pm_opp_of_add_table ( struct device * dev )
2017-04-26 08:15:46 +03:00
{
2021-01-28 09:35:22 +03:00
return _of_add_table_indexed ( dev , 0 , true ) ;
2021-01-27 10:15:56 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_add_table ) ;
2017-04-26 08:15:46 +03:00
2021-01-27 10:15:56 +03:00
/**
* dev_pm_opp_of_add_table_indexed ( ) - Initialize indexed opp table from device tree
* @ dev : device pointer used to lookup OPP table .
* @ index : Index number .
*
* Register the initial OPP table with the OPP library for given device only
* using the " operating-points-v2 " property .
*
* Return : Refer to dev_pm_opp_of_add_table ( ) for return values .
*/
int dev_pm_opp_of_add_table_indexed ( struct device * dev , int index )
{
2021-01-28 09:35:22 +03:00
return _of_add_table_indexed ( dev , index , true ) ;
2017-04-26 08:15:46 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_add_table_indexed ) ;
2021-09-20 20:22:46 +03:00
/**
* devm_pm_opp_of_add_table_indexed ( ) - Initialize indexed opp table from device tree
* @ dev : device pointer used to lookup OPP table .
* @ index : Index number .
*
* This is a resource - managed variant of dev_pm_opp_of_add_table_indexed ( ) .
*/
int devm_pm_opp_of_add_table_indexed ( struct device * dev , int index )
{
return _devm_of_add_table_indexed ( dev , index , true ) ;
}
EXPORT_SYMBOL_GPL ( devm_pm_opp_of_add_table_indexed ) ;
2021-01-27 11:53:45 +03:00
/**
* dev_pm_opp_of_add_table_noclk ( ) - Initialize indexed opp table from device
* tree without getting clk for device .
* @ dev : device pointer used to lookup OPP table .
* @ index : Index number .
*
* Register the initial OPP table with the OPP library for given device only
* using the " operating-points-v2 " property . Do not try to get the clk for the
* device .
*
* Return : Refer to dev_pm_opp_of_add_table ( ) for return values .
*/
int dev_pm_opp_of_add_table_noclk ( struct device * dev , int index )
{
return _of_add_table_indexed ( dev , index , false ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_add_table_noclk ) ;
2021-09-20 20:22:46 +03:00
/**
* devm_pm_opp_of_add_table_noclk ( ) - Initialize indexed opp table from device
* tree without getting clk for device .
* @ dev : device pointer used to lookup OPP table .
* @ index : Index number .
*
* This is a resource - managed variant of dev_pm_opp_of_add_table_noclk ( ) .
*/
int devm_pm_opp_of_add_table_noclk ( struct device * dev , int index )
{
return _devm_of_add_table_indexed ( dev , index , false ) ;
}
EXPORT_SYMBOL_GPL ( devm_pm_opp_of_add_table_noclk ) ;
2016-05-05 13:50:33 +03:00
/* CPU device specific helpers */
/**
* dev_pm_opp_of_cpumask_remove_table ( ) - Removes OPP table for @ cpumask
* @ cpumask : cpumask for which OPP table needs to be removed
*
* This removes the OPP tables for CPUs present in the @ cpumask .
* This should be used only to remove static entries created from DT .
*/
void dev_pm_opp_of_cpumask_remove_table ( const struct cpumask * cpumask )
{
2018-09-13 10:44:36 +03:00
_dev_pm_opp_cpumask_remove_table ( cpumask , - 1 ) ;
2016-05-05 13:50:33 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_cpumask_remove_table ) ;
/**
* dev_pm_opp_of_cpumask_add_table ( ) - Adds OPP table for @ cpumask
* @ cpumask : cpumask for which OPP table needs to be added .
*
* This adds the OPP tables for CPUs present in the @ cpumask .
*/
int dev_pm_opp_of_cpumask_add_table ( const struct cpumask * cpumask )
{
struct device * cpu_dev ;
2018-10-03 12:42:06 +03:00
int cpu , ret ;
2016-05-05 13:50:33 +03:00
2018-10-03 12:42:06 +03:00
if ( WARN_ON ( cpumask_empty ( cpumask ) ) )
return - ENODEV ;
2016-05-05 13:50:33 +03:00
for_each_cpu ( cpu , cpumask ) {
cpu_dev = get_cpu_device ( cpu ) ;
if ( ! cpu_dev ) {
pr_err ( " %s: failed to get cpu%d device \n " , __func__ ,
cpu ) ;
2018-10-03 12:42:06 +03:00
ret = - ENODEV ;
goto remove_table ;
2016-05-05 13:50:33 +03:00
}
ret = dev_pm_opp_of_add_table ( cpu_dev ) ;
if ( ret ) {
2017-07-12 06:51:49 +03:00
/*
* OPP may get registered dynamically , don ' t print error
* message here .
*/
pr_debug ( " %s: couldn't find opp table for cpu:%d, %d \n " ,
__func__ , cpu , ret ) ;
2016-05-05 13:50:33 +03:00
2018-10-03 12:42:06 +03:00
goto remove_table ;
2016-05-05 13:50:33 +03:00
}
}
2018-10-03 12:42:06 +03:00
return 0 ;
remove_table :
/* Free all other OPPs */
_dev_pm_opp_cpumask_remove_table ( cpumask , cpu ) ;
2016-05-05 13:50:33 +03:00
return ret ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_cpumask_add_table ) ;
/*
* Works only for OPP v2 bindings .
*
* Returns - ENOENT if operating - points - v2 bindings aren ' t supported .
*/
/**
* dev_pm_opp_of_get_sharing_cpus ( ) - Get cpumask of CPUs sharing OPPs with
* @ cpu_dev using operating - points - v2
* bindings .
*
* @ cpu_dev : CPU device for which we do this operation
* @ cpumask : cpumask to update with information of sharing CPUs
*
* This updates the @ cpumask with CPUs that are sharing OPPs with @ cpu_dev .
*
* Returns - ENOENT if operating - points - v2 isn ' t present for @ cpu_dev .
*/
int dev_pm_opp_of_get_sharing_cpus ( struct device * cpu_dev ,
struct cpumask * cpumask )
{
2017-07-27 13:01:17 +03:00
struct device_node * np , * tmp_np , * cpu_np ;
2016-05-05 13:50:33 +03:00
int cpu , ret = 0 ;
/* Get OPP descriptor node */
2017-02-03 20:29:26 +03:00
np = dev_pm_opp_of_get_opp_desc_node ( cpu_dev ) ;
2016-05-05 13:50:33 +03:00
if ( ! np ) {
2016-10-20 10:12:49 +03:00
dev_dbg ( cpu_dev , " %s: Couldn't find opp node. \n " , __func__ ) ;
2016-05-05 13:50:33 +03:00
return - ENOENT ;
}
cpumask_set_cpu ( cpu_dev - > id , cpumask ) ;
/* OPPs are shared ? */
if ( ! of_property_read_bool ( np , " opp-shared " ) )
goto put_cpu_node ;
for_each_possible_cpu ( cpu ) {
if ( cpu = = cpu_dev - > id )
continue ;
2017-10-12 13:32:23 +03:00
cpu_np = of_cpu_device_node_get ( cpu ) ;
2017-07-27 13:01:17 +03:00
if ( ! cpu_np ) {
dev_err ( cpu_dev , " %s: failed to get cpu%d node \n " ,
2016-05-05 13:50:33 +03:00
__func__ , cpu ) ;
2017-07-27 13:01:17 +03:00
ret = - ENOENT ;
2016-05-05 13:50:33 +03:00
goto put_cpu_node ;
}
/* Get OPP descriptor node */
2017-04-26 08:15:46 +03:00
tmp_np = _opp_of_get_opp_desc_node ( cpu_np , 0 ) ;
2017-10-12 13:32:23 +03:00
of_node_put ( cpu_np ) ;
2016-05-05 13:50:33 +03:00
if ( ! tmp_np ) {
2017-07-27 13:01:17 +03:00
pr_err ( " %pOF: Couldn't find opp node \n " , cpu_np ) ;
2016-05-05 13:50:33 +03:00
ret = - ENOENT ;
goto put_cpu_node ;
}
/* CPUs are sharing opp node */
if ( np = = tmp_np )
cpumask_set_cpu ( cpu , cpumask ) ;
of_node_put ( tmp_np ) ;
}
put_cpu_node :
of_node_put ( np ) ;
return ret ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_get_sharing_cpus ) ;
2017-11-29 12:48:36 +03:00
/**
2018-06-27 13:59:50 +03:00
* of_get_required_opp_performance_state ( ) - Search for required OPP and return its performance state .
2017-11-29 12:48:36 +03:00
* @ np : Node that contains the " required-opps " property .
2018-06-27 13:59:50 +03:00
* @ index : Index of the phandle to parse .
2017-11-29 12:48:36 +03:00
*
2018-06-27 13:59:50 +03:00
* Returns the performance state of the OPP pointed out by the " required-opps "
* property at @ index in @ np .
2017-11-29 12:48:36 +03:00
*
2018-12-14 12:50:56 +03:00
* Return : Zero or positive performance state on success , otherwise negative
* value on errors .
2017-11-29 12:48:36 +03:00
*/
2018-12-14 12:50:56 +03:00
int of_get_required_opp_performance_state ( struct device_node * np , int index )
2017-11-29 12:48:36 +03:00
{
2018-06-27 13:59:50 +03:00
struct dev_pm_opp * opp ;
2017-11-29 12:48:36 +03:00
struct device_node * required_np ;
struct opp_table * opp_table ;
2018-12-14 12:50:56 +03:00
int pstate = - EINVAL ;
2017-11-29 12:48:36 +03:00
2018-06-27 13:59:50 +03:00
required_np = of_parse_required_opp ( np , index ) ;
if ( ! required_np )
2021-08-12 14:27:20 +03:00
return - ENODEV ;
2017-11-29 12:48:36 +03:00
2018-06-27 13:59:50 +03:00
opp_table = _find_table_of_opp_np ( required_np ) ;
if ( IS_ERR ( opp_table ) ) {
pr_err ( " %s: Failed to find required OPP table %pOF: %ld \n " ,
__func__ , np , PTR_ERR ( opp_table ) ) ;
goto put_required_np ;
2017-11-29 12:48:36 +03:00
}
2018-06-27 13:59:50 +03:00
opp = _find_opp_of_np ( opp_table , required_np ) ;
if ( opp ) {
pstate = opp - > pstate ;
dev_pm_opp_put ( opp ) ;
2017-11-29 12:48:36 +03:00
}
2018-06-27 13:59:50 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-11-29 12:48:36 +03:00
2018-06-27 13:59:50 +03:00
put_required_np :
2017-11-29 12:48:36 +03:00
of_node_put ( required_np ) ;
2018-06-27 13:59:50 +03:00
return pstate ;
2017-11-29 12:48:36 +03:00
}
2018-06-27 13:59:50 +03:00
EXPORT_SYMBOL_GPL ( of_get_required_opp_performance_state ) ;
2018-01-12 07:33:45 +03:00
/**
* dev_pm_opp_get_of_node ( ) - Gets the DT node corresponding to an opp
* @ opp : opp for which DT node has to be returned for
*
* Return : DT node corresponding to the opp , else 0 on success .
*
* The caller needs to put the node with of_node_put ( ) after using it .
*/
struct device_node * dev_pm_opp_get_of_node ( struct dev_pm_opp * opp )
{
if ( IS_ERR_OR_NULL ( opp ) ) {
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
return NULL ;
}
return of_node_get ( opp - > np ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_of_node ) ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
/*
* Callback function provided to the Energy Model framework upon registration .
2020-05-27 12:58:54 +03:00
* This computes the power estimated by @ dev at @ kHz if it is the frequency
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
* of an existing OPP , or at the frequency of the first OPP above @ kHz otherwise
* ( see dev_pm_opp_find_freq_ceil ( ) ) . This function updates @ kHz to the ceiled
* frequency and @ mW to the associated power . The power is estimated as
2020-05-27 12:58:54 +03:00
* P = C * V ^ 2 * f with C being the device ' s capacitance and V and f
* respectively the voltage and frequency of the OPP .
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
*
2020-05-27 12:58:54 +03:00
* Returns - EINVAL if the power calculation failed because of missing
* parameters , 0 otherwise .
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
*/
2020-05-27 12:58:54 +03:00
static int __maybe_unused _get_power ( unsigned long * mW , unsigned long * kHz ,
struct device * dev )
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
{
struct dev_pm_opp * opp ;
struct device_node * np ;
unsigned long mV , Hz ;
u32 cap ;
u64 tmp ;
int ret ;
2020-05-27 12:58:54 +03:00
np = of_node_get ( dev - > of_node ) ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
if ( ! np )
return - EINVAL ;
ret = of_property_read_u32 ( np , " dynamic-power-coefficient " , & cap ) ;
of_node_put ( np ) ;
if ( ret )
return - EINVAL ;
Hz = * kHz * 1000 ;
2020-05-27 12:58:54 +03:00
opp = dev_pm_opp_find_freq_ceil ( dev , & Hz ) ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
if ( IS_ERR ( opp ) )
return - EINVAL ;
mV = dev_pm_opp_get_voltage ( opp ) / 1000 ;
dev_pm_opp_put ( opp ) ;
if ( ! mV )
return - EINVAL ;
tmp = ( u64 ) cap * mV * mV * ( Hz / 1000000 ) ;
do_div ( tmp , 1000000000 ) ;
* mW = ( unsigned long ) tmp ;
* kHz = Hz / 1000 ;
return 0 ;
}
/**
* dev_pm_opp_of_register_em ( ) - Attempt to register an Energy Model
2020-05-27 12:58:54 +03:00
* @ dev : Device for which an Energy Model has to be registered
* @ cpus : CPUs for which an Energy Model has to be registered . For
* other type of devices it should be set to NULL .
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
*
* This checks whether the " dynamic-power-coefficient " devicetree property has
* been specified , and tries to register an Energy Model with it if it has .
2020-05-27 12:58:54 +03:00
* Having this property means the voltages are known for OPPs and the EM
* might be calculated .
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
*/
2020-05-27 12:58:54 +03:00
int dev_pm_opp_of_register_em ( struct device * dev , struct cpumask * cpus )
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
{
2020-05-27 12:58:54 +03:00
struct em_data_callback em_cb = EM_DATA_CB ( _get_power ) ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
struct device_node * np ;
2020-05-27 12:58:54 +03:00
int ret , nr_opp ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
u32 cap ;
2020-05-27 12:58:54 +03:00
if ( IS_ERR_OR_NULL ( dev ) ) {
ret = - EINVAL ;
goto failed ;
}
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
2020-05-27 12:58:54 +03:00
nr_opp = dev_pm_opp_get_opp_count ( dev ) ;
if ( nr_opp < = 0 ) {
ret = - EINVAL ;
goto failed ;
}
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
2020-05-27 12:58:54 +03:00
np = of_node_get ( dev - > of_node ) ;
if ( ! np ) {
ret = - EINVAL ;
goto failed ;
}
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
/*
* Register an EM only if the ' dynamic - power - coefficient ' property is
* set in devicetree . It is assumed the voltage values are known if that
* property is set since it is useless otherwise . If voltages are not
* known , just let the EM registration fail with an error to alert the
* user about the inconsistent configuration .
*/
ret = of_property_read_u32 ( np , " dynamic-power-coefficient " , & cap ) ;
of_node_put ( np ) ;
2020-05-27 12:58:54 +03:00
if ( ret | | ! cap ) {
dev_dbg ( dev , " Couldn't find proper 'dynamic-power-coefficient' in DT \n " ) ;
ret = - EINVAL ;
goto failed ;
}
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
2020-11-05 15:50:01 +03:00
ret = em_dev_register_perf_domain ( dev , nr_opp , & em_cb , cpus , true ) ;
2020-05-27 12:58:54 +03:00
if ( ret )
goto failed ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
2020-05-27 12:58:54 +03:00
return 0 ;
failed :
dev_dbg ( dev , " Couldn't register Energy Model %d \n " , ret ) ;
return ret ;
PM / OPP: Introduce a power estimation helper
The Energy Model (EM) framework provides an API to let drivers register
the active power of CPUs. The drivers are expected to provide a callback
method which estimates the power consumed by a CPU at each available
performance levels. How exactly this should be implemented, however,
depends on the platform.
On some systems, PM_OPP knows the voltage and frequency at which CPUs
can run. When coupled with the CPU 'capacitance' (as provided by the
'dynamic-power-coefficient' devicetree binding), it is possible to
estimate the dynamic power consumption of a CPU as P = C * V^2 * f, with
C its capacitance and V and f respectively the voltage and frequency of
the OPP. The Intelligent Power Allocator (IPA) thermal governor already
implements that estimation method, in the thermal framework.
However, this power estimation method can be applied to any platform
where all the parameters are known (C, V and f), and not only those
suffering thermal issues. As such, the code implementing this feature
can be re-used to also populate the EM framework now used by EAS.
As a first step, introduce in PM_OPP a helper function which CPUFreq
drivers can use to register into the EM framework. This duplicates the
power estimation done in IPA until it can be migrated to using the EM
framework. This will be done later, once the EM framework has support
for at least all platforms currently supported by IPA.
Signed-off-by: Quentin Perret <quentin.perret@arm.com>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-02-04 14:09:48 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_of_register_em ) ;