2019-06-04 11:11:33 +03:00
// SPDX-License-Identifier: GPL-2.0-only
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/*
* Generic OPP Interface
*
* Copyright ( C ) 2009 - 2010 Texas Instruments Incorporated .
* Nishanth Menon
* Romit Dasgupta
* Kevin Hilman
*/
2015-10-17 07:15:18 +03:00
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2016-02-09 08:00:38 +03:00
# include <linux/clk.h>
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
# include <linux/errno.h>
# include <linux/err.h>
# include <linux/slab.h>
2012-01-22 20:23:42 +04:00
# include <linux/device.h>
2012-10-23 03:27:44 +04:00
# include <linux/export.h>
2017-10-11 10:24:14 +03:00
# include <linux/pm_domain.h>
2016-02-09 08:00:33 +03:00
# include <linux/regulator/consumer.h>
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2015-09-04 11:17:26 +03:00
# include "opp.h"
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/*
2016-02-16 11:47:53 +03:00
* The root of the list of all opp - tables . All opp_table structures branch off
* from here , with each opp_table containing the list of opps it supports in
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* various states of availability .
*/
2016-05-05 13:50:33 +03:00
LIST_HEAD ( opp_tables ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/* Lock to allow exclusive modification to the device and opp lists */
2016-02-16 11:47:53 +03:00
DEFINE_MUTEX ( opp_table_lock ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2016-02-16 11:47:53 +03:00
static struct opp_device * _find_opp_dev ( const struct device * dev ,
struct opp_table * opp_table )
2015-07-29 13:53:04 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_device * opp_dev ;
2015-07-29 13:53:04 +03:00
2016-02-16 11:47:53 +03:00
list_for_each_entry ( opp_dev , & opp_table - > dev_list , node )
if ( opp_dev - > dev = = dev )
return opp_dev ;
2015-07-29 13:53:04 +03:00
return NULL ;
}
2017-02-06 17:29:55 +03:00
static struct opp_table * _find_opp_table_unlocked ( struct device * dev )
2017-01-23 07:41:48 +03:00
{
struct opp_table * opp_table ;
2018-08-03 04:35:21 +03:00
bool found ;
2017-01-23 07:41:48 +03:00
list_for_each_entry ( opp_table , & opp_tables , node ) {
2018-08-03 04:35:21 +03:00
mutex_lock ( & opp_table - > lock ) ;
found = ! ! _find_opp_dev ( dev , opp_table ) ;
mutex_unlock ( & opp_table - > lock ) ;
if ( found ) {
2017-01-23 07:41:48 +03:00
_get_opp_table_kref ( opp_table ) ;
return opp_table ;
}
}
return ERR_PTR ( - ENODEV ) ;
}
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2016-02-16 11:47:53 +03:00
* _find_opp_table ( ) - find opp_table struct using device pointer
* @ dev : device pointer used to lookup OPP table
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2017-01-23 07:41:49 +03:00
* Search OPP table for one containing matching device .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2016-02-16 11:47:53 +03:00
* Return : pointer to ' struct opp_table ' if found , otherwise - ENODEV or
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* - EINVAL based on type of error .
*
2017-01-23 07:41:48 +03:00
* The callers must call dev_pm_opp_put_opp_table ( ) after the table is used .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2016-02-16 11:47:53 +03:00
struct opp_table * _find_opp_table ( struct device * dev )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2015-08-12 13:29:39 +03:00
if ( IS_ERR_OR_NULL ( dev ) ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
return ERR_PTR ( - EINVAL ) ;
}
2017-01-23 07:41:48 +03:00
mutex_lock ( & opp_table_lock ) ;
opp_table = _find_opp_table_unlocked ( dev ) ;
mutex_unlock ( & opp_table_lock ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-23 07:41:48 +03:00
return opp_table ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
/**
2015-09-10 20:09:29 +03:00
* dev_pm_opp_get_voltage ( ) - Gets the voltage corresponding to an opp
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ opp : opp for which voltage has to be returned for
*
2014-12-24 20:22:57 +03:00
* Return : voltage in micro volt corresponding to the opp , else
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* return 0
*
2016-12-01 13:58:19 +03:00
* This is useful only for devices with single power supply .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:51 +04:00
unsigned long dev_pm_opp_get_voltage ( struct dev_pm_opp * opp )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2017-01-23 07:41:49 +03:00
if ( IS_ERR_OR_NULL ( opp ) ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
2017-01-23 07:41:49 +03:00
return 0 ;
}
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-23 07:41:49 +03:00
return opp - > supplies [ 0 ] . u_volt ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_voltage ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_get_freq ( ) - Gets the frequency corresponding to an available opp
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ opp : opp for which frequency has to be returned for
*
2014-12-24 20:22:57 +03:00
* Return : frequency in hertz corresponding to the opp , else
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* return 0
*/
2013-09-20 01:03:51 +04:00
unsigned long dev_pm_opp_get_freq ( struct dev_pm_opp * opp )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2020-07-20 11:55:26 +03:00
if ( IS_ERR_OR_NULL ( opp ) ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
2017-01-23 07:41:49 +03:00
return 0 ;
}
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-23 07:41:49 +03:00
return opp - > rate ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_freq ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2019-01-10 07:02:02 +03:00
/**
* dev_pm_opp_get_level ( ) - Gets the level corresponding to an available opp
* @ opp : opp for which level value has to be returned for
*
* Return : level read from device tree corresponding to the opp , else
* return 0.
*/
unsigned int dev_pm_opp_get_level ( struct dev_pm_opp * opp )
{
if ( IS_ERR_OR_NULL ( opp ) | | ! opp - > available ) {
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
return 0 ;
}
return opp - > level ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_level ) ;
2015-07-09 18:43:35 +03:00
/**
* dev_pm_opp_is_turbo ( ) - Returns if opp is turbo OPP or not
* @ opp : opp for which turbo mode is being verified
*
* Turbo OPPs are not for normal use , and can be enabled ( under certain
* conditions ) for short duration of times to finish high throughput work
* quickly . Running on them for longer times may overheat the chip .
*
* Return : true if opp is turbo opp , else false .
*/
bool dev_pm_opp_is_turbo ( struct dev_pm_opp * opp )
{
2017-01-23 07:41:49 +03:00
if ( IS_ERR_OR_NULL ( opp ) | | ! opp - > available ) {
2015-07-09 18:43:35 +03:00
pr_err ( " %s: Invalid parameters \n " , __func__ ) ;
return false ;
}
2017-01-23 07:41:49 +03:00
return opp - > turbo ;
2015-07-09 18:43:35 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_is_turbo ) ;
2015-07-29 13:53:03 +03:00
/**
* dev_pm_opp_get_max_clock_latency ( ) - Get max clock latency in nanoseconds
* @ dev : device for which we do this operation
*
* Return : This function returns the max clock latency in nanoseconds .
*/
unsigned long dev_pm_opp_get_max_clock_latency ( struct device * dev )
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2015-07-29 13:53:03 +03:00
unsigned long clock_latency_ns ;
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) )
2017-01-23 07:41:48 +03:00
return 0 ;
clock_latency_ns = opp_table - > clock_latency_ns_max ;
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-07-29 13:53:03 +03:00
return clock_latency_ns ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_max_clock_latency ) ;
2016-02-09 08:00:35 +03:00
/**
* dev_pm_opp_get_max_volt_latency ( ) - Get max voltage latency in nanoseconds
* @ dev : device for which we do this operation
*
* Return : This function returns the max voltage latency in nanoseconds .
*/
unsigned long dev_pm_opp_get_max_volt_latency ( struct device * dev )
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2016-02-09 08:00:35 +03:00
struct dev_pm_opp * opp ;
2017-05-23 07:02:11 +03:00
struct regulator * reg ;
2016-02-09 08:00:35 +03:00
unsigned long latency_ns = 0 ;
2016-12-01 13:58:19 +03:00
int ret , i , count ;
struct {
unsigned long min ;
unsigned long max ;
} * uV ;
2017-01-23 07:41:51 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) )
return 0 ;
2016-12-01 13:58:19 +03:00
/* Regulator may not be required for the device */
2018-12-11 14:02:47 +03:00
if ( ! opp_table - > regulators )
2017-01-23 07:41:51 +03:00
goto put_opp_table ;
2016-12-01 13:58:19 +03:00
2018-12-11 14:02:47 +03:00
count = opp_table - > regulator_count ;
2016-12-01 13:58:19 +03:00
uV = kmalloc_array ( count , sizeof ( * uV ) , GFP_KERNEL ) ;
if ( ! uV )
2017-05-23 07:02:11 +03:00
goto put_opp_table ;
2016-02-09 08:00:35 +03:00
2017-01-23 07:41:49 +03:00
mutex_lock ( & opp_table - > lock ) ;
2016-12-01 13:58:19 +03:00
for ( i = 0 ; i < count ; i + + ) {
uV [ i ] . min = ~ 0 ;
uV [ i ] . max = 0 ;
2016-02-09 08:00:35 +03:00
2017-01-23 07:41:49 +03:00
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
2016-12-01 13:58:19 +03:00
if ( ! opp - > available )
continue ;
if ( opp - > supplies [ i ] . u_volt_min < uV [ i ] . min )
uV [ i ] . min = opp - > supplies [ i ] . u_volt_min ;
if ( opp - > supplies [ i ] . u_volt_max > uV [ i ] . max )
uV [ i ] . max = opp - > supplies [ i ] . u_volt_max ;
}
2016-02-09 08:00:35 +03:00
}
2017-01-23 07:41:49 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2016-02-09 08:00:35 +03:00
/*
2016-02-16 11:47:53 +03:00
* The caller needs to ensure that opp_table ( and hence the regulator )
2016-02-09 08:00:35 +03:00
* isn ' t freed , while we are executing this routine .
*/
2017-02-20 21:57:57 +03:00
for ( i = 0 ; i < count ; i + + ) {
2017-05-23 07:02:11 +03:00
reg = opp_table - > regulators [ i ] ;
2016-12-01 13:58:19 +03:00
ret = regulator_set_voltage_time ( reg , uV [ i ] . min , uV [ i ] . max ) ;
if ( ret > 0 )
latency_ns + = ret * 1000 ;
}
kfree ( uV ) ;
2017-01-23 07:41:51 +03:00
put_opp_table :
dev_pm_opp_put_opp_table ( opp_table ) ;
2016-02-09 08:00:35 +03:00
return latency_ns ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_max_volt_latency ) ;
2016-02-09 08:00:36 +03:00
/**
* dev_pm_opp_get_max_transition_latency ( ) - Get max transition latency in
* nanoseconds
* @ dev : device for which we do this operation
*
* Return : This function returns the max transition latency , in nanoseconds , to
* switch from one OPP to other .
*/
unsigned long dev_pm_opp_get_max_transition_latency ( struct device * dev )
{
return dev_pm_opp_get_max_volt_latency ( dev ) +
dev_pm_opp_get_max_clock_latency ( dev ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_max_transition_latency ) ;
2015-09-08 19:41:01 +03:00
/**
2017-01-02 12:11:02 +03:00
* dev_pm_opp_get_suspend_opp_freq ( ) - Get frequency of suspend opp in Hz
2015-09-08 19:41:01 +03:00
* @ dev : device for which we do this operation
*
2017-01-02 12:11:02 +03:00
* Return : This function returns the frequency of the OPP marked as suspend_opp
* if one is available , else returns 0 ;
2015-09-08 19:41:01 +03:00
*/
2017-01-02 12:11:02 +03:00
unsigned long dev_pm_opp_get_suspend_opp_freq ( struct device * dev )
2015-09-08 19:41:01 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2017-01-02 12:11:02 +03:00
unsigned long freq = 0 ;
2015-09-08 19:41:01 +03:00
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
2017-01-23 07:41:48 +03:00
if ( IS_ERR ( opp_table ) )
return 0 ;
2017-01-02 12:11:02 +03:00
2017-01-23 07:41:48 +03:00
if ( opp_table - > suspend_opp & & opp_table - > suspend_opp - > available )
freq = dev_pm_opp_get_freq ( opp_table - > suspend_opp ) ;
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-09-08 19:41:01 +03:00
2017-01-02 12:11:02 +03:00
return freq ;
2015-09-08 19:41:01 +03:00
}
2017-01-02 12:11:02 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_suspend_opp_freq ) ;
2015-09-08 19:41:01 +03:00
2018-04-06 12:05:45 +03:00
int _get_opp_count ( struct opp_table * opp_table )
{
struct dev_pm_opp * opp ;
int count = 0 ;
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
if ( opp - > available )
count + + ;
}
mutex_unlock ( & opp_table - > lock ) ;
return count ;
}
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2016-02-16 11:47:53 +03:00
* dev_pm_opp_get_opp_count ( ) - Get number of opps available in the opp table
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
*
2014-12-24 20:22:57 +03:00
* Return : This function returns the number of available opps if there are any ,
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* else returns 0 if none or the corresponding error value .
*/
2013-09-20 01:03:50 +04:00
int dev_pm_opp_get_opp_count ( struct device * dev )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2018-04-06 12:05:45 +03:00
int count ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
count = PTR_ERR ( opp_table ) ;
2017-09-29 20:39:49 +03:00
dev_dbg ( dev , " %s: OPP table not found (%d) \n " ,
2014-12-17 02:09:38 +03:00
__func__ , count ) ;
2018-10-03 12:52:03 +03:00
return count ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2018-04-06 12:05:45 +03:00
count = _get_opp_count ( opp_table ) ;
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
return count ;
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_opp_count ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_find_freq_exact ( ) - search for an exact frequency
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : frequency to search for
2011-02-26 01:46:18 +03:00
* @ available : true / false - match for available opp
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2016-02-16 11:47:53 +03:00
* Return : Searches for exact match in the opp table and returns pointer to the
2014-12-24 20:22:57 +03:00
* matching opp if found , else returns ERR_PTR in case of error and should
* be handled using IS_ERR . Error return values can be :
2012-10-25 00:00:12 +04:00
* EINVAL : for bad pointer
* ERANGE : no match found for search
* ENODEV : if device not found in list of registered devices
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
* Note : available is a modifier for the search . if available = true , then the
* match is for exact matching frequency and is available in the stored OPP
* table . if false , the match is for exact frequency which is not available .
*
* This provides a mechanism to enable an opp which is not available currently
* or the opposite as well .
*
2017-01-23 07:41:47 +03:00
* The callers are required to call dev_pm_opp_put ( ) for the returned OPP after
* use .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:51 +04:00
struct dev_pm_opp * dev_pm_opp_find_freq_exact ( struct device * dev ,
unsigned long freq ,
bool available )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2013-09-20 01:03:51 +04:00
struct dev_pm_opp * temp_opp , * opp = ERR_PTR ( - ERANGE ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
int r = PTR_ERR ( opp_table ) ;
dev_err ( dev , " %s: OPP table not found (%d) \n " , __func__ , r ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
return ERR_PTR ( r ) ;
}
2017-01-23 07:41:49 +03:00
mutex_lock ( & opp_table - > lock ) ;
2017-01-23 07:41:48 +03:00
2017-01-23 07:41:49 +03:00
list_for_each_entry ( temp_opp , & opp_table - > opp_list , node ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( temp_opp - > available = = available & &
temp_opp - > rate = = freq ) {
opp = temp_opp ;
2017-01-23 07:41:47 +03:00
/* Increment the reference count of OPP */
dev_pm_opp_get ( opp ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
break ;
}
}
2017-01-23 07:41:49 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-23 07:41:47 +03:00
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
return opp ;
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_find_freq_exact ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2019-07-25 13:41:29 +03:00
/**
* dev_pm_opp_find_level_exact ( ) - search for an exact level
* @ dev : device for which we do this operation
* @ level : level to search for
*
* Return : Searches for exact match in the opp table and returns pointer to the
* matching opp if found , else returns ERR_PTR in case of error and should
* be handled using IS_ERR . Error return values can be :
* EINVAL : for bad pointer
* ERANGE : no match found for search
* ENODEV : if device not found in list of registered devices
*
* The callers are required to call dev_pm_opp_put ( ) for the returned OPP after
* use .
*/
struct dev_pm_opp * dev_pm_opp_find_level_exact ( struct device * dev ,
unsigned int level )
{
struct opp_table * opp_table ;
struct dev_pm_opp * temp_opp , * opp = ERR_PTR ( - ERANGE ) ;
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
int r = PTR_ERR ( opp_table ) ;
dev_err ( dev , " %s: OPP table not found (%d) \n " , __func__ , r ) ;
return ERR_PTR ( r ) ;
}
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry ( temp_opp , & opp_table - > opp_list , node ) {
if ( temp_opp - > level = = level ) {
opp = temp_opp ;
/* Increment the reference count of OPP */
dev_pm_opp_get ( opp ) ;
break ;
}
}
mutex_unlock ( & opp_table - > lock ) ;
dev_pm_opp_put_opp_table ( opp_table ) ;
return opp ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_find_level_exact ) ;
2016-07-25 09:11:16 +03:00
static noinline struct dev_pm_opp * _find_freq_ceil ( struct opp_table * opp_table ,
unsigned long * freq )
{
struct dev_pm_opp * temp_opp , * opp = ERR_PTR ( - ERANGE ) ;
2017-01-23 07:41:49 +03:00
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry ( temp_opp , & opp_table - > opp_list , node ) {
2016-07-25 09:11:16 +03:00
if ( temp_opp - > available & & temp_opp - > rate > = * freq ) {
opp = temp_opp ;
* freq = opp - > rate ;
2017-01-23 07:41:47 +03:00
/* Increment the reference count of OPP */
dev_pm_opp_get ( opp ) ;
2016-07-25 09:11:16 +03:00
break ;
}
}
2017-01-23 07:41:49 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2016-07-25 09:11:16 +03:00
return opp ;
}
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_find_freq_ceil ( ) - Search for an rounded ceil freq
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : Start frequency
*
* Search for the matching ceil * available * OPP from a starting freq
* for a device .
*
2014-12-24 20:22:57 +03:00
* Return : matching * opp and refreshes * freq accordingly , else returns
2012-10-25 00:00:12 +04:00
* ERR_PTR in case of error and should be handled using IS_ERR . Error return
* values can be :
* EINVAL : for bad pointer
* ERANGE : no match found for search
* ENODEV : if device not found in list of registered devices
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2017-01-23 07:41:47 +03:00
* The callers are required to call dev_pm_opp_put ( ) for the returned OPP after
* use .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:51 +04:00
struct dev_pm_opp * dev_pm_opp_find_freq_ceil ( struct device * dev ,
unsigned long * freq )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2017-01-23 07:41:47 +03:00
struct dev_pm_opp * opp ;
2014-12-17 02:09:36 +03:00
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( ! dev | | ! freq ) {
dev_err ( dev , " %s: Invalid argument freq=%p \n " , __func__ , freq ) ;
return ERR_PTR ( - EINVAL ) ;
}
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
2017-01-23 07:41:48 +03:00
if ( IS_ERR ( opp_table ) )
2016-02-16 11:47:53 +03:00
return ERR_CAST ( opp_table ) ;
2017-01-23 07:41:48 +03:00
2017-01-23 07:41:47 +03:00
opp = _find_freq_ceil ( opp_table , freq ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-23 07:41:47 +03:00
return opp ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_find_freq_ceil ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_find_freq_floor ( ) - Search for a rounded floor freq
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : Start frequency
*
* Search for the matching floor * available * OPP from a starting freq
* for a device .
*
2014-12-24 20:22:57 +03:00
* Return : matching * opp and refreshes * freq accordingly , else returns
2012-10-25 00:00:12 +04:00
* ERR_PTR in case of error and should be handled using IS_ERR . Error return
* values can be :
* EINVAL : for bad pointer
* ERANGE : no match found for search
* ENODEV : if device not found in list of registered devices
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2017-01-23 07:41:47 +03:00
* The callers are required to call dev_pm_opp_put ( ) for the returned OPP after
* use .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:51 +04:00
struct dev_pm_opp * dev_pm_opp_find_freq_floor ( struct device * dev ,
unsigned long * freq )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2013-09-20 01:03:51 +04:00
struct dev_pm_opp * temp_opp , * opp = ERR_PTR ( - ERANGE ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( ! dev | | ! freq ) {
dev_err ( dev , " %s: Invalid argument freq=%p \n " , __func__ , freq ) ;
return ERR_PTR ( - EINVAL ) ;
}
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
2017-01-23 07:41:48 +03:00
if ( IS_ERR ( opp_table ) )
2016-02-16 11:47:53 +03:00
return ERR_CAST ( opp_table ) ;
2017-01-23 07:41:48 +03:00
2017-01-23 07:41:49 +03:00
mutex_lock ( & opp_table - > lock ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-23 07:41:49 +03:00
list_for_each_entry ( temp_opp , & opp_table - > opp_list , node ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( temp_opp - > available ) {
/* go to the next node, before choosing prev */
if ( temp_opp - > rate > * freq )
break ;
else
opp = temp_opp ;
}
}
2017-01-23 07:41:47 +03:00
/* Increment the reference count of OPP */
if ( ! IS_ERR ( opp ) )
dev_pm_opp_get ( opp ) ;
2017-01-23 07:41:49 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-23 07:41:47 +03:00
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( ! IS_ERR ( opp ) )
* freq = opp - > rate ;
return opp ;
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_find_freq_floor ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2019-03-29 09:46:10 +03:00
/**
* dev_pm_opp_find_freq_ceil_by_volt ( ) - Find OPP with highest frequency for
* target voltage .
* @ dev : Device for which we do this operation .
* @ u_volt : Target voltage .
*
* Search for OPP with highest ( ceil ) frequency and has voltage < = u_volt .
*
* Return : matching * opp , else returns ERR_PTR in case of error which should be
* handled using IS_ERR .
*
* Error return values can be :
* EINVAL : bad parameters
*
* The callers are required to call dev_pm_opp_put ( ) for the returned OPP after
* use .
*/
struct dev_pm_opp * dev_pm_opp_find_freq_ceil_by_volt ( struct device * dev ,
unsigned long u_volt )
{
struct opp_table * opp_table ;
struct dev_pm_opp * temp_opp , * opp = ERR_PTR ( - ERANGE ) ;
if ( ! dev | | ! u_volt ) {
dev_err ( dev , " %s: Invalid argument volt=%lu \n " , __func__ ,
u_volt ) ;
return ERR_PTR ( - EINVAL ) ;
}
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) )
return ERR_CAST ( opp_table ) ;
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry ( temp_opp , & opp_table - > opp_list , node ) {
if ( temp_opp - > available ) {
if ( temp_opp - > supplies [ 0 ] . u_volt > u_volt )
break ;
opp = temp_opp ;
}
}
/* Increment the reference count of OPP */
if ( ! IS_ERR ( opp ) )
dev_pm_opp_get ( opp ) ;
mutex_unlock ( & opp_table - > lock ) ;
dev_pm_opp_put_opp_table ( opp_table ) ;
return opp ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_find_freq_ceil_by_volt ) ;
2016-02-09 08:00:39 +03:00
static int _set_opp_voltage ( struct device * dev , struct regulator * reg ,
2016-12-01 13:58:18 +03:00
struct dev_pm_opp_supply * supply )
2016-02-09 08:00:39 +03:00
{
int ret ;
/* Regulator not available for device */
if ( IS_ERR ( reg ) ) {
dev_dbg ( dev , " %s: regulator not available: %ld \n " , __func__ ,
PTR_ERR ( reg ) ) ;
return 0 ;
}
2016-12-01 13:58:18 +03:00
dev_dbg ( dev , " %s: voltages (mV): %lu %lu %lu \n " , __func__ ,
supply - > u_volt_min , supply - > u_volt , supply - > u_volt_max ) ;
2016-02-09 08:00:39 +03:00
2016-12-01 13:58:18 +03:00
ret = regulator_set_voltage_triplet ( reg , supply - > u_volt_min ,
supply - > u_volt , supply - > u_volt_max ) ;
2016-02-09 08:00:39 +03:00
if ( ret )
dev_err ( dev , " %s: failed to set voltage (%lu %lu %lu mV): %d \n " ,
2016-12-01 13:58:18 +03:00
__func__ , supply - > u_volt_min , supply - > u_volt ,
supply - > u_volt_max , ret ) ;
2016-02-09 08:00:39 +03:00
return ret ;
}
2019-01-31 11:23:25 +03:00
static inline int _generic_set_opp_clk_only ( struct device * dev , struct clk * clk ,
unsigned long freq )
2016-12-01 13:58:20 +03:00
{
int ret ;
ret = clk_set_rate ( clk , freq ) ;
if ( ret ) {
dev_err ( dev , " %s: failed to set clock rate: %d \n " , __func__ ,
ret ) ;
}
return ret ;
}
2019-07-19 18:05:32 +03:00
static int _generic_set_opp_regulator ( struct opp_table * opp_table ,
2017-05-23 07:02:10 +03:00
struct device * dev ,
unsigned long old_freq ,
unsigned long freq ,
struct dev_pm_opp_supply * old_supply ,
struct dev_pm_opp_supply * new_supply )
2016-12-01 13:58:20 +03:00
{
2017-05-23 07:02:10 +03:00
struct regulator * reg = opp_table - > regulators [ 0 ] ;
2016-12-01 13:58:20 +03:00
int ret ;
/* This function only supports single regulator per device */
2017-05-23 07:02:10 +03:00
if ( WARN_ON ( opp_table - > regulator_count > 1 ) ) {
2016-12-01 13:58:20 +03:00
dev_err ( dev , " multiple regulators are not supported \n " ) ;
return - EINVAL ;
}
/* Scaling up? Scale voltage before frequency */
PM / OPP: Update voltage in case freq == old_freq
This commit fixes a rare but possible case when the clk rate is updated
without update of the regulator voltage.
At boot up, CPUfreq checks if the system is running at the right freq. This
is a sanity check in case a bootloader set clk rate that is outside of freq
table present with cpufreq core. In such cases system can be unstable so
better to change it to a freq that is preset in freq-table.
The CPUfreq takes next freq that is >= policy->cur and this is our
target_freq that needs to be set now.
dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
old_freq (a current rate). If these are equal it returns early. If not,
it searches for OPP (old_opp) that fits best to old_freq (not listed in
the table) and updates old_freq (!).
Here, we can end up with old_freq = old_opp.rate = target_freq, which
is not handled in _generic_set_opp_regulator(). It's supposed to update
voltage only when freq > old_freq || freq > old_freq.
if (freq > old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
[...]
if (freq < old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
if (ret)
It results in, no voltage update while clk rate is updated.
Example:
freq-table = {
1000MHz 1.15V
666MHZ 1.10V
333MHz 1.05V
}
boot-up-freq = 800MHz # not listed in freq-table
freq = target_freq = 1GHz
old_freq = 800Mhz
old_opp = _find_freq_ceil(opp_table, &old_freq); #(old_freq is modified!)
old_freq = 1GHz
Fixes: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()")
Cc: 4.6+ <stable@vger.kernel.org> # v4.6+
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-06-14 16:56:08 +03:00
if ( freq > = old_freq ) {
2016-12-01 13:58:20 +03:00
ret = _set_opp_voltage ( dev , reg , new_supply ) ;
if ( ret )
goto restore_voltage ;
}
/* Change frequency */
2019-01-31 11:23:25 +03:00
ret = _generic_set_opp_clk_only ( dev , opp_table - > clk , freq ) ;
2016-12-01 13:58:20 +03:00
if ( ret )
goto restore_voltage ;
/* Scaling down? Scale voltage after frequency */
if ( freq < old_freq ) {
ret = _set_opp_voltage ( dev , reg , new_supply ) ;
if ( ret )
goto restore_freq ;
}
2019-07-19 18:05:32 +03:00
/*
* Enable the regulator after setting its voltages , otherwise it breaks
* some boot - enabled regulators .
*/
2020-08-13 06:08:37 +03:00
if ( unlikely ( ! opp_table - > enabled ) ) {
2019-07-19 18:05:32 +03:00
ret = regulator_enable ( reg ) ;
if ( ret < 0 )
dev_warn ( dev , " Failed to enable regulator: %d " , ret ) ;
}
2016-12-01 13:58:20 +03:00
return 0 ;
restore_freq :
2019-01-31 11:23:25 +03:00
if ( _generic_set_opp_clk_only ( dev , opp_table - > clk , old_freq ) )
2016-12-01 13:58:20 +03:00
dev_err ( dev , " %s: failed to restore old-freq (%lu Hz) \n " ,
__func__ , old_freq ) ;
restore_voltage :
/* This shouldn't harm even if the voltages weren't updated earlier */
2017-05-23 07:02:10 +03:00
if ( old_supply )
2016-12-01 13:58:20 +03:00
_set_opp_voltage ( dev , reg , old_supply ) ;
return ret ;
}
2020-05-27 07:03:44 +03:00
static int _set_opp_bw ( const struct opp_table * opp_table ,
struct dev_pm_opp * opp , struct device * dev , bool remove )
{
u32 avg , peak ;
int i , ret ;
if ( ! opp_table - > paths )
return 0 ;
for ( i = 0 ; i < opp_table - > path_count ; i + + ) {
if ( remove ) {
avg = 0 ;
peak = 0 ;
} else {
avg = opp - > bandwidth [ i ] . avg ;
peak = opp - > bandwidth [ i ] . peak ;
}
ret = icc_set_bw ( opp_table - > paths [ i ] , avg , peak ) ;
if ( ret ) {
dev_err ( dev , " Failed to %s bandwidth[%d]: %d \n " ,
remove ? " remove " : " set " , i , ret ) ;
return ret ;
}
}
return 0 ;
}
2018-06-12 12:17:03 +03:00
static int _set_opp_custom ( const struct opp_table * opp_table ,
struct device * dev , unsigned long old_freq ,
unsigned long freq ,
struct dev_pm_opp_supply * old_supply ,
struct dev_pm_opp_supply * new_supply )
{
struct dev_pm_set_opp_data * data ;
int size ;
data = opp_table - > set_opp_data ;
data - > regulators = opp_table - > regulators ;
data - > regulator_count = opp_table - > regulator_count ;
data - > clk = opp_table - > clk ;
data - > dev = dev ;
data - > old_opp . rate = old_freq ;
size = sizeof ( * old_supply ) * opp_table - > regulator_count ;
2019-06-23 20:50:53 +03:00
if ( ! old_supply )
2018-06-12 12:17:03 +03:00
memset ( data - > old_opp . supplies , 0 , size ) ;
else
memcpy ( data - > old_opp . supplies , old_supply , size ) ;
data - > new_opp . rate = freq ;
memcpy ( data - > new_opp . supplies , new_supply , size ) ;
return opp_table - > set_opp ( data ) ;
}
2020-07-30 11:01:44 +03:00
static int _set_required_opp ( struct device * dev , struct device * pd_dev ,
struct dev_pm_opp * opp , int i )
{
unsigned int pstate = likely ( opp ) ? opp - > required_opps [ i ] - > pstate : 0 ;
int ret ;
if ( ! pd_dev )
return 0 ;
ret = dev_pm_genpd_set_performance_state ( pd_dev , pstate ) ;
if ( ret ) {
dev_err ( dev , " Failed to set performance rate of %s: %d (%d) \n " ,
dev_name ( pd_dev ) , pstate , ret ) ;
}
return ret ;
}
2018-06-14 07:33:26 +03:00
/* This is only called for PM domain for now */
static int _set_required_opps ( struct device * dev ,
struct opp_table * opp_table ,
struct dev_pm_opp * opp )
{
struct opp_table * * required_opp_tables = opp_table - > required_opp_tables ;
struct device * * genpd_virt_devs = opp_table - > genpd_virt_devs ;
int i , ret = 0 ;
if ( ! required_opp_tables )
return 0 ;
/* Single genpd case */
2020-07-30 11:01:44 +03:00
if ( ! genpd_virt_devs )
return _set_required_opp ( dev , dev , opp , 0 ) ;
2018-06-14 07:33:26 +03:00
/* Multiple genpd case */
/*
* Acquire genpd_virt_dev_lock to make sure we don ' t use a genpd_dev
* after it is freed from another thread .
*/
mutex_lock ( & opp_table - > genpd_virt_dev_lock ) ;
for ( i = 0 ; i < opp_table - > required_opp_count ; i + + ) {
2020-07-30 11:01:44 +03:00
ret = _set_required_opp ( dev , genpd_virt_devs [ i ] , opp , i ) ;
if ( ret )
2018-06-14 07:33:26 +03:00
break ;
}
mutex_unlock ( & opp_table - > genpd_virt_dev_lock ) ;
return ret ;
}
2020-06-06 00:33:30 +03:00
/**
* dev_pm_opp_set_bw ( ) - sets bandwidth levels corresponding to an opp
* @ dev : device for which we do this operation
* @ opp : opp based on which the bandwidth levels are to be configured
*
* This configures the bandwidth to the levels specified by the OPP . However
* if the OPP specified is NULL the bandwidth levels are cleared out .
*
* Return : 0 on success or a negative error value .
*/
int dev_pm_opp_set_bw ( struct device * dev , struct dev_pm_opp * opp )
{
struct opp_table * opp_table ;
int ret ;
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
dev_err ( dev , " %s: device opp table doesn't exist \n " , __func__ ) ;
return PTR_ERR ( opp_table ) ;
}
if ( opp )
ret = _set_opp_bw ( opp_table , opp , dev , false ) ;
else
ret = _set_opp_bw ( opp_table , NULL , dev , true ) ;
dev_pm_opp_put_opp_table ( opp_table ) ;
return ret ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_bw ) ;
2020-08-13 07:18:04 +03:00
static int _opp_set_rate_zero ( struct device * dev , struct opp_table * opp_table )
{
int ret ;
if ( ! opp_table - > enabled )
return 0 ;
/*
* Some drivers need to support cases where some platforms may
* have OPP table for the device , while others don ' t and
* opp_set_rate ( ) just needs to behave like clk_set_rate ( ) .
*/
if ( ! _get_opp_count ( opp_table ) )
return 0 ;
ret = _set_opp_bw ( opp_table , NULL , dev , true ) ;
if ( ret )
return ret ;
if ( opp_table - > regulators )
regulator_disable ( opp_table - > regulators [ 0 ] ) ;
ret = _set_required_opps ( dev , opp_table , NULL ) ;
opp_table - > enabled = false ;
return ret ;
}
2016-02-09 08:00:39 +03:00
/**
* dev_pm_opp_set_rate ( ) - Configure new OPP based on frequency
* @ dev : device for which we do this operation
* @ target_freq : frequency to achieve
*
opp: Don't overwrite rounded clk rate
The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.
On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.
The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().
The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[ Viresh: Massaged changelog, added comment and use temp_opp variable
instead ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-03-20 12:49:08 +03:00
* This configures the power - supplies to the levels specified by the OPP
* corresponding to the target_freq , and programs the clock to a value < =
* target_freq , as rounded by clk_round_rate ( ) . Device wanting to run at fmax
* provided by the opp , should have already rounded to the target OPP ' s
* frequency .
2016-02-09 08:00:39 +03:00
*/
int dev_pm_opp_set_rate ( struct device * dev , unsigned long target_freq )
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
opp: Don't overwrite rounded clk rate
The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.
On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.
The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().
The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[ Viresh: Massaged changelog, added comment and use temp_opp variable
instead ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-03-20 12:49:08 +03:00
unsigned long freq , old_freq , temp_freq ;
2016-02-09 08:00:39 +03:00
struct dev_pm_opp * old_opp , * opp ;
struct clk * clk ;
2020-05-27 07:03:44 +03:00
int ret ;
2016-02-09 08:00:39 +03:00
2017-01-23 07:41:49 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
dev_err ( dev , " %s: device opp doesn't exist \n " , __func__ ) ;
return PTR_ERR ( opp_table ) ;
}
2019-03-20 12:49:09 +03:00
if ( unlikely ( ! target_freq ) ) {
2020-08-13 07:18:04 +03:00
ret = _opp_set_rate_zero ( dev , opp_table ) ;
2019-03-20 12:49:09 +03:00
goto put_opp_table ;
}
2017-01-23 07:41:49 +03:00
clk = opp_table - > clk ;
if ( IS_ERR ( clk ) ) {
dev_err ( dev , " %s: No clock available for the device \n " ,
__func__ ) ;
ret = PTR_ERR ( clk ) ;
goto put_opp_table ;
}
2016-02-09 08:00:39 +03:00
freq = clk_round_rate ( clk , target_freq ) ;
if ( ( long ) freq < = 0 )
freq = target_freq ;
old_freq = clk_get_rate ( clk ) ;
/* Return early if nothing to do */
2020-08-13 06:08:37 +03:00
if ( opp_table - > enabled & & old_freq = = freq ) {
dev_dbg ( dev , " %s: old/new frequencies (%lu Hz) are same, nothing to do \n " ,
__func__ , freq ) ;
ret = 0 ;
goto put_opp_table ;
2016-02-09 08:00:39 +03:00
}
2020-04-08 16:46:27 +03:00
/*
* For IO devices which require an OPP on some platforms / SoCs
* while just needing to scale the clock on some others
* we look for empty OPP tables with just a clock handle and
* scale only the clk . This makes dev_pm_opp_set_rate ( )
* equivalent to a clk_set_rate ( )
*/
if ( ! _get_opp_count ( opp_table ) ) {
ret = _generic_set_opp_clk_only ( dev , clk , freq ) ;
goto put_opp_table ;
}
opp: Don't overwrite rounded clk rate
The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.
On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.
The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().
The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[ Viresh: Massaged changelog, added comment and use temp_opp variable
instead ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-03-20 12:49:08 +03:00
temp_freq = old_freq ;
old_opp = _find_freq_ceil ( opp_table , & temp_freq ) ;
2016-09-15 18:38:38 +03:00
if ( IS_ERR ( old_opp ) ) {
2016-02-09 08:00:39 +03:00
dev_err ( dev , " %s: failed to find current OPP for freq %lu (%ld) \n " ,
__func__ , old_freq , PTR_ERR ( old_opp ) ) ;
}
opp: Don't overwrite rounded clk rate
The OPP table normally contains 'fmax' values corresponding to the
voltage or performance levels of each OPP, but we don't necessarily want
all the devices to run at fmax all the time. Running at fmax makes sense
for devices like CPU/GPU, which have a finite amount of work to do and
since a specific amount of energy is consumed at an OPP, its better to
run at the highest possible frequency for that voltage value.
On the other hand, we have IO devices which need to run at specific
frequencies only for their proper functioning, instead of maximum
possible frequency.
The OPP core currently roundup to the next possible OPP for a frequency
and select the fmax value. To support the IO devices by the OPP core,
lets do the roundup to fetch the voltage or performance state values,
but not use the OPP frequency value. Rather use the value returned by
clk_round_rate().
The current user, cpufreq, of dev_pm_opp_set_rate() already does the
rounding to the next OPP before calling this routine and it won't
have any side affects because of this change.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
[ Viresh: Massaged changelog, added comment and use temp_opp variable
instead ]
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-03-20 12:49:08 +03:00
temp_freq = freq ;
opp = _find_freq_ceil ( opp_table , & temp_freq ) ;
2016-02-09 08:00:39 +03:00
if ( IS_ERR ( opp ) ) {
ret = PTR_ERR ( opp ) ;
dev_err ( dev , " %s: failed to find OPP for freq %lu (%d) \n " ,
__func__ , freq , ret ) ;
2017-01-23 07:41:49 +03:00
goto put_old_opp ;
2016-02-09 08:00:39 +03:00
}
2016-12-01 13:58:20 +03:00
dev_dbg ( dev , " %s: switching OPP: %lu Hz --> %lu Hz \n " , __func__ ,
old_freq , freq ) ;
2016-12-01 13:58:19 +03:00
2018-06-14 07:33:26 +03:00
/* Scaling up? Configure required OPPs before frequency */
2019-03-12 07:57:18 +03:00
if ( freq > = old_freq ) {
2018-06-14 07:33:26 +03:00
ret = _set_required_opps ( dev , opp_table , opp ) ;
if ( ret )
goto put_opp ;
}
2018-06-12 12:17:03 +03:00
if ( opp_table - > set_opp ) {
ret = _set_opp_custom ( opp_table , dev , old_freq , freq ,
IS_ERR ( old_opp ) ? NULL : old_opp - > supplies ,
opp - > supplies ) ;
} else if ( opp_table - > regulators ) {
2017-05-23 07:02:10 +03:00
ret = _generic_set_opp_regulator ( opp_table , dev , old_freq , freq ,
IS_ERR ( old_opp ) ? NULL : old_opp - > supplies ,
opp - > supplies ) ;
} else {
2018-06-12 12:17:03 +03:00
/* Only frequency scaling */
2019-01-31 11:23:25 +03:00
ret = _generic_set_opp_clk_only ( dev , clk , freq ) ;
2018-06-14 07:33:26 +03:00
}
2017-05-23 07:02:10 +03:00
2018-06-14 07:33:26 +03:00
/* Scaling down? Configure required OPPs after frequency */
if ( ! ret & & freq < old_freq ) {
ret = _set_required_opps ( dev , opp_table , opp ) ;
if ( ret )
dev_err ( dev , " Failed to set required opps: %d \n " , ret ) ;
2016-12-01 13:58:19 +03:00
}
2020-08-13 06:08:37 +03:00
if ( ! ret ) {
2020-05-27 07:03:44 +03:00
ret = _set_opp_bw ( opp_table , opp , dev , false ) ;
2020-08-13 06:08:37 +03:00
if ( ! ret )
opp_table - > enabled = true ;
}
2020-05-12 15:53:23 +03:00
2018-06-14 07:33:26 +03:00
put_opp :
2017-01-23 07:41:47 +03:00
dev_pm_opp_put ( opp ) ;
2017-01-23 07:41:49 +03:00
put_old_opp :
2017-01-23 07:41:47 +03:00
if ( ! IS_ERR ( old_opp ) )
dev_pm_opp_put ( old_opp ) ;
2017-01-23 07:41:49 +03:00
put_opp_table :
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-23 07:41:49 +03:00
return ret ;
2016-02-09 08:00:39 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_rate ) ;
2016-02-16 11:47:53 +03:00
/* OPP-dev Helpers */
static void _remove_opp_dev ( struct opp_device * opp_dev ,
struct opp_table * opp_table )
2015-07-29 13:53:04 +03:00
{
2016-02-16 11:47:53 +03:00
opp_debug_unregister ( opp_dev , opp_table ) ;
list_del ( & opp_dev - > node ) ;
2017-01-23 07:41:49 +03:00
kfree ( opp_dev ) ;
2015-07-29 13:53:04 +03:00
}
2018-09-07 06:31:54 +03:00
static struct opp_device * _add_opp_dev_unlocked ( const struct device * dev ,
struct opp_table * opp_table )
2015-07-29 13:53:04 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_device * opp_dev ;
2015-07-29 13:53:04 +03:00
2016-02-16 11:47:53 +03:00
opp_dev = kzalloc ( sizeof ( * opp_dev ) , GFP_KERNEL ) ;
if ( ! opp_dev )
2015-07-29 13:53:04 +03:00
return NULL ;
2016-02-16 11:47:53 +03:00
/* Initialize opp-dev */
opp_dev - > dev = dev ;
2018-08-03 04:35:21 +03:00
2017-01-23 07:41:49 +03:00
list_add ( & opp_dev - > node , & opp_table - > dev_list ) ;
2015-07-29 13:53:04 +03:00
2016-02-16 11:47:53 +03:00
/* Create debugfs entries for the opp_table */
2019-01-22 18:21:17 +03:00
opp_debug_register ( opp_dev , opp_table ) ;
2018-09-07 06:31:54 +03:00
return opp_dev ;
}
struct opp_device * _add_opp_dev ( const struct device * dev ,
struct opp_table * opp_table )
{
struct opp_device * opp_dev ;
mutex_lock ( & opp_table - > lock ) ;
opp_dev = _add_opp_dev_unlocked ( dev , opp_table ) ;
2018-08-03 04:35:21 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2015-11-11 05:29:01 +03:00
2016-02-16 11:47:53 +03:00
return opp_dev ;
2015-07-29 13:53:04 +03:00
}
2018-09-05 13:47:14 +03:00
static struct opp_table * _allocate_opp_table ( struct device * dev , int index )
2014-12-10 07:15:34 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
struct opp_device * opp_dev ;
2016-02-09 08:00:38 +03:00
int ret ;
2014-12-10 07:15:34 +03:00
/*
2016-02-16 11:47:53 +03:00
* Allocate a new OPP table . In the infrequent case where a new
2014-12-10 07:15:34 +03:00
* device is needed to be added , we pay this penalty .
*/
2016-02-16 11:47:53 +03:00
opp_table = kzalloc ( sizeof ( * opp_table ) , GFP_KERNEL ) ;
if ( ! opp_table )
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
return ERR_PTR ( - ENOMEM ) ;
2014-12-10 07:15:34 +03:00
2018-08-03 04:35:21 +03:00
mutex_init ( & opp_table - > lock ) ;
2018-06-26 13:59:34 +03:00
mutex_init ( & opp_table - > genpd_virt_dev_lock ) ;
2016-02-16 11:47:53 +03:00
INIT_LIST_HEAD ( & opp_table - > dev_list ) ;
2015-07-29 13:53:04 +03:00
2018-12-11 14:09:36 +03:00
/* Mark regulator count uninitialized */
opp_table - > regulator_count = - 1 ;
2016-02-16 11:47:53 +03:00
opp_dev = _add_opp_dev ( dev , opp_table ) ;
if ( ! opp_dev ) {
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
ret = - ENOMEM ;
goto err ;
2015-07-29 13:53:04 +03:00
}
2018-09-05 13:47:14 +03:00
_of_init_opp_table ( opp_table , dev , index ) ;
2016-02-09 08:00:37 +03:00
2016-02-09 08:00:38 +03:00
/* Find clk for the device */
2016-02-16 11:47:53 +03:00
opp_table - > clk = clk_get ( dev , NULL ) ;
if ( IS_ERR ( opp_table - > clk ) ) {
ret = PTR_ERR ( opp_table - > clk ) ;
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 ( ret = = - EPROBE_DEFER )
goto err ;
dev_dbg ( dev , " %s: Couldn't find clock: %d \n " , __func__ , ret ) ;
2016-02-09 08:00:38 +03:00
}
2020-05-12 15:53:21 +03:00
/* Find interconnect path(s) for the device */
ret = dev_pm_opp_of_find_icc_paths ( dev , opp_table ) ;
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 ( ret ) {
if ( ret = = - EPROBE_DEFER )
goto err ;
2020-05-12 15:53:21 +03:00
dev_warn ( dev , " %s: Error finding interconnect paths: %d \n " ,
__func__ , ret ) ;
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
}
2020-05-12 15:53:21 +03:00
2017-01-23 07:41:49 +03:00
BLOCKING_INIT_NOTIFIER_HEAD ( & opp_table - > head ) ;
2016-02-16 11:47:53 +03:00
INIT_LIST_HEAD ( & opp_table - > opp_list ) ;
2017-01-23 07:41:42 +03:00
kref_init ( & opp_table - > kref ) ;
2014-12-10 07:15:34 +03:00
2016-02-16 11:47:53 +03:00
/* Secure the device table modification */
2017-01-23 07:41:49 +03:00
list_add ( & opp_table - > node , & opp_tables ) ;
2016-02-16 11:47:53 +03:00
return opp_table ;
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
err :
kfree ( opp_table ) ;
return ERR_PTR ( ret ) ;
2014-12-10 07:15:34 +03:00
}
2017-01-23 07:41:42 +03:00
void _get_opp_table_kref ( struct opp_table * opp_table )
2017-01-02 12:11:04 +03:00
{
2017-01-23 07:41:42 +03:00
kref_get ( & opp_table - > kref ) ;
}
2018-09-05 13:47:14 +03:00
static struct opp_table * _opp_get_opp_table ( struct device * dev , int index )
2017-01-23 07:41:42 +03:00
{
struct opp_table * opp_table ;
/* Hold our table modification lock here */
mutex_lock ( & opp_table_lock ) ;
2017-01-23 07:41:48 +03:00
opp_table = _find_opp_table_unlocked ( dev ) ;
if ( ! IS_ERR ( opp_table ) )
2017-01-23 07:41:42 +03:00
goto unlock ;
2018-09-07 06:31:54 +03:00
opp_table = _managed_opp ( dev , index ) ;
if ( opp_table ) {
if ( ! _add_opp_dev_unlocked ( dev , opp_table ) ) {
dev_pm_opp_put_opp_table ( opp_table ) ;
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
opp_table = ERR_PTR ( - ENOMEM ) ;
2018-09-07 06:31:54 +03:00
}
goto unlock ;
}
2018-09-05 13:47:14 +03:00
opp_table = _allocate_opp_table ( dev , index ) ;
2017-01-23 07:41:42 +03:00
unlock :
mutex_unlock ( & opp_table_lock ) ;
return opp_table ;
}
2018-09-05 13:47:14 +03:00
struct opp_table * dev_pm_opp_get_opp_table ( struct device * dev )
{
return _opp_get_opp_table ( dev , 0 ) ;
}
2017-01-23 07:41:42 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_get_opp_table ) ;
2018-09-05 13:47:14 +03:00
struct opp_table * dev_pm_opp_get_opp_table_indexed ( struct device * dev ,
int index )
{
return _opp_get_opp_table ( dev , index ) ;
}
2017-01-23 07:41:45 +03:00
static void _opp_table_kref_release ( struct kref * kref )
2017-01-23 07:41:42 +03:00
{
struct opp_table * opp_table = container_of ( kref , struct opp_table , kref ) ;
2018-09-12 10:05:19 +03:00
struct opp_device * opp_dev , * temp ;
2020-05-12 15:53:21 +03:00
int i ;
2017-01-02 12:11:04 +03:00
2018-06-07 12:20:43 +03:00
_of_clear_opp_table ( opp_table ) ;
2017-01-02 12:11:04 +03:00
/* Release clk */
if ( ! IS_ERR ( opp_table - > clk ) )
clk_put ( opp_table - > clk ) ;
2020-05-12 15:53:21 +03:00
if ( opp_table - > paths ) {
for ( i = 0 ; i < opp_table - > path_count ; i + + )
icc_put ( opp_table - > paths [ i ] ) ;
kfree ( opp_table - > paths ) ;
}
2018-09-12 10:05:19 +03:00
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2017-01-02 12:11:04 +03:00
2018-09-12 10:05:19 +03:00
list_for_each_entry_safe ( opp_dev , temp , & opp_table - > dev_list , node ) {
/*
* The OPP table is getting removed , drop the performance state
* constraints .
*/
if ( opp_table - > genpd_performance_state )
dev_pm_genpd_set_performance_state ( ( struct device * ) ( opp_dev - > dev ) , 0 ) ;
2017-01-02 12:11:04 +03:00
2018-09-12 10:05:19 +03:00
_remove_opp_dev ( opp_dev , opp_table ) ;
}
2017-01-02 12:11:04 +03:00
2018-06-26 13:59:34 +03:00
mutex_destroy ( & opp_table - > genpd_virt_dev_lock ) ;
2017-01-23 07:41:41 +03:00
mutex_destroy ( & opp_table - > lock ) ;
2017-01-23 07:41:49 +03:00
list_del ( & opp_table - > node ) ;
kfree ( opp_table ) ;
2017-01-02 12:11:04 +03:00
2017-01-23 07:41:42 +03:00
mutex_unlock ( & opp_table_lock ) ;
}
void dev_pm_opp_put_opp_table ( struct opp_table * opp_table )
{
kref_put_mutex ( & opp_table - > kref , _opp_table_kref_release ,
& opp_table_lock ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_put_opp_table ) ;
2017-01-02 12:11:01 +03:00
void _opp_free ( struct dev_pm_opp * opp )
2017-01-02 12:10:59 +03:00
{
kfree ( opp ) ;
}
2019-01-04 12:44:33 +03:00
static void _opp_kref_release ( struct dev_pm_opp * opp ,
struct opp_table * opp_table )
2014-11-27 06:24:06 +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_REMOVE , opp ) ;
2018-06-07 12:20:43 +03:00
_of_opp_free_required_opps ( opp_table , opp ) ;
2015-11-11 05:29:01 +03:00
opp_debug_remove_one ( opp ) ;
2017-01-23 07:41:49 +03:00
list_del ( & opp - > node ) ;
kfree ( opp ) ;
2019-01-04 12:44:33 +03:00
}
2014-11-27 06:24:06 +03:00
2019-01-04 12:44:33 +03:00
static void _opp_kref_release_unlocked ( struct kref * kref )
{
struct dev_pm_opp * opp = container_of ( kref , struct dev_pm_opp , kref ) ;
struct opp_table * opp_table = opp - > opp_table ;
_opp_kref_release ( opp , opp_table ) ;
}
static void _opp_kref_release_locked ( struct kref * kref )
{
struct dev_pm_opp * opp = container_of ( kref , struct dev_pm_opp , kref ) ;
struct opp_table * opp_table = opp - > opp_table ;
_opp_kref_release ( opp , opp_table ) ;
2017-01-23 07:41:41 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2014-11-27 06:24:06 +03:00
}
2017-11-29 12:48:36 +03:00
void dev_pm_opp_get ( struct dev_pm_opp * opp )
2017-01-23 07:41:47 +03:00
{
kref_get ( & opp - > kref ) ;
}
2017-01-23 07:41:46 +03:00
void dev_pm_opp_put ( struct dev_pm_opp * opp )
{
2019-01-04 12:44:33 +03:00
kref_put_mutex ( & opp - > kref , _opp_kref_release_locked ,
& opp - > opp_table - > lock ) ;
2017-01-23 07:41:46 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_put ) ;
2019-01-04 12:44:33 +03:00
static void dev_pm_opp_put_unlocked ( struct dev_pm_opp * opp )
{
kref_put ( & opp - > kref , _opp_kref_release_unlocked ) ;
}
2014-11-27 06:24:06 +03:00
/**
2016-02-16 11:47:53 +03:00
* dev_pm_opp_remove ( ) - Remove an OPP from OPP table
2014-11-27 06:24:06 +03:00
* @ dev : device for which we do this operation
* @ freq : OPP to remove with matching ' freq '
*
2016-02-16 11:47:53 +03:00
* This function removes an opp from the opp table .
2014-11-27 06:24:06 +03:00
*/
void dev_pm_opp_remove ( struct device * dev , unsigned long freq )
{
struct dev_pm_opp * opp ;
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2014-11-27 06:24:06 +03:00
bool found = false ;
2016-02-16 11:47:53 +03:00
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) )
2017-01-23 07:41:48 +03:00
return ;
2014-11-27 06:24:06 +03:00
2017-01-23 07:41:41 +03:00
mutex_lock ( & opp_table - > lock ) ;
2016-02-16 11:47:53 +03:00
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
2014-11-27 06:24:06 +03:00
if ( opp - > rate = = freq ) {
found = true ;
break ;
}
}
2017-01-23 07:41:41 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2017-01-23 07:41:48 +03:00
if ( found ) {
dev_pm_opp_put ( opp ) ;
2018-08-02 11:53:09 +03:00
/* Drop the reference taken by dev_pm_opp_add() */
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-23 07:41:48 +03:00
} else {
2014-11-27 06:24:06 +03:00
dev_warn ( dev , " %s: Couldn't find OPP with freq: %lu \n " ,
__func__ , freq ) ;
}
2018-08-02 11:53:09 +03:00
/* Drop the reference taken by _find_opp_table() */
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2014-11-27 06:24:06 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_remove ) ;
2019-11-11 14:05:03 +03:00
void _opp_remove_all_static ( struct opp_table * opp_table )
{
struct dev_pm_opp * opp , * tmp ;
mutex_lock ( & opp_table - > lock ) ;
if ( ! opp_table - > parsed_static_opps | | - - opp_table - > parsed_static_opps )
goto unlock ;
list_for_each_entry_safe ( opp , tmp , & opp_table - > opp_list , node ) {
if ( ! opp - > dynamic )
dev_pm_opp_put_unlocked ( opp ) ;
}
unlock :
mutex_unlock ( & opp_table - > lock ) ;
}
2019-01-04 12:44:33 +03:00
/**
* dev_pm_opp_remove_all_dynamic ( ) - Remove all dynamically created OPPs
* @ dev : device for which we do this operation
*
* This function removes all dynamically created OPPs from the opp table .
*/
void dev_pm_opp_remove_all_dynamic ( struct device * dev )
{
struct opp_table * opp_table ;
struct dev_pm_opp * opp , * temp ;
int count = 0 ;
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) )
return ;
mutex_lock ( & opp_table - > lock ) ;
list_for_each_entry_safe ( opp , temp , & opp_table - > opp_list , node ) {
if ( opp - > dynamic ) {
dev_pm_opp_put_unlocked ( opp ) ;
count + + ;
}
}
mutex_unlock ( & opp_table - > lock ) ;
/* Drop the references taken by dev_pm_opp_add() */
while ( count - - )
dev_pm_opp_put_opp_table ( opp_table ) ;
/* Drop the reference taken by _find_opp_table() */
dev_pm_opp_put_opp_table ( opp_table ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_remove_all_dynamic ) ;
2017-01-02 12:11:01 +03:00
struct dev_pm_opp * _opp_allocate ( struct opp_table * table )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2015-07-29 13:53:01 +03:00
struct dev_pm_opp * opp ;
2020-05-12 15:53:21 +03:00
int supply_count , supply_size , icc_size ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2016-12-01 13:58:19 +03:00
/* Allocate space for at least one supply */
2020-05-12 15:53:21 +03:00
supply_count = table - > regulator_count > 0 ? table - > regulator_count : 1 ;
supply_size = sizeof ( * opp - > supplies ) * supply_count ;
icc_size = sizeof ( * opp - > bandwidth ) * table - > path_count ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2016-12-01 13:58:19 +03:00
/* allocate new OPP node and supplies structures */
2020-05-12 15:53:21 +03:00
opp = kzalloc ( sizeof ( * opp ) + supply_size + icc_size , GFP_KERNEL ) ;
2017-01-02 12:11:01 +03:00
if ( ! opp )
2015-07-29 13:53:01 +03:00
return NULL ;
2016-12-01 13:58:19 +03:00
/* Put the supplies at the end of the OPP structure as an empty array */
opp - > supplies = ( struct dev_pm_opp_supply * ) ( opp + 1 ) ;
2020-05-12 15:53:21 +03:00
if ( icc_size )
opp - > bandwidth = ( struct dev_pm_opp_icc_bw * ) ( opp - > supplies + supply_count ) ;
2016-12-01 13:58:19 +03:00
INIT_LIST_HEAD ( & opp - > node ) ;
2015-07-29 13:53:01 +03:00
return opp ;
}
2016-02-09 08:00:34 +03:00
static bool _opp_supported_by_regulators ( struct dev_pm_opp * opp ,
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table )
2016-02-09 08:00:34 +03:00
{
2016-12-01 13:58:19 +03:00
struct regulator * reg ;
int i ;
2018-12-11 14:02:47 +03:00
if ( ! opp_table - > regulators )
return true ;
2016-12-01 13:58:19 +03:00
for ( i = 0 ; i < opp_table - > regulator_count ; i + + ) {
reg = opp_table - > regulators [ i ] ;
if ( ! regulator_is_supported_voltage ( reg ,
opp - > supplies [ i ] . u_volt_min ,
opp - > supplies [ i ] . u_volt_max ) ) {
pr_warn ( " %s: OPP minuV: %lu maxuV: %lu, not supported by regulator \n " ,
__func__ , opp - > supplies [ i ] . u_volt_min ,
opp - > supplies [ i ] . u_volt_max ) ;
return false ;
}
2016-02-09 08:00:34 +03:00
}
return true ;
}
2020-05-12 15:53:19 +03:00
int _opp_compare_key ( struct dev_pm_opp * opp1 , struct dev_pm_opp * opp2 )
{
if ( opp1 - > rate ! = opp2 - > rate )
return opp1 - > rate < opp2 - > rate ? - 1 : 1 ;
2020-05-12 15:53:21 +03:00
if ( opp1 - > bandwidth & & opp2 - > bandwidth & &
opp1 - > bandwidth [ 0 ] . peak ! = opp2 - > bandwidth [ 0 ] . peak )
return opp1 - > bandwidth [ 0 ] . peak < opp2 - > bandwidth [ 0 ] . peak ? - 1 : 1 ;
2020-05-12 15:53:19 +03:00
if ( opp1 - > level ! = opp2 - > level )
return opp1 - > level < opp2 - > level ? - 1 : 1 ;
return 0 ;
}
2018-04-06 12:05:45 +03:00
static int _opp_is_duplicate ( struct device * dev , struct dev_pm_opp * new_opp ,
struct opp_table * opp_table ,
struct list_head * * head )
2015-07-29 13:53:01 +03:00
{
struct dev_pm_opp * opp ;
2020-05-12 15:53:19 +03:00
int opp_cmp ;
2015-07-29 13:53:01 +03:00
/*
* Insert new OPP in order of increasing frequency and discard if
* already present .
*
2016-02-16 11:47:53 +03:00
* Need to use & opp_table - > opp_list in the condition part of the ' for '
2015-07-29 13:53:01 +03:00
* loop , don ' t replace it with head otherwise it will become an infinite
* loop .
*/
2017-01-23 07:41:49 +03:00
list_for_each_entry ( opp , & opp_table - > opp_list , node ) {
2020-05-12 15:53:19 +03:00
opp_cmp = _opp_compare_key ( new_opp , opp ) ;
if ( opp_cmp > 0 ) {
2018-04-06 12:05:45 +03:00
* head = & opp - > node ;
2015-07-29 13:53:01 +03:00
continue ;
}
2020-05-12 15:53:19 +03:00
if ( opp_cmp < 0 )
2018-04-06 12:05:45 +03:00
return 0 ;
2015-07-29 13:53:01 +03:00
/* Duplicate OPPs */
2015-07-29 13:53:04 +03:00
dev_warn ( dev , " %s: duplicate OPPs detected. Existing: freq: %lu, volt: %lu, enabled: %d. New: freq: %lu, volt: %lu, enabled: %d \n " ,
2016-12-01 13:58:19 +03:00
__func__ , opp - > rate , opp - > supplies [ 0 ] . u_volt ,
opp - > available , new_opp - > rate ,
new_opp - > supplies [ 0 ] . u_volt , new_opp - > available ) ;
2015-07-29 13:53:01 +03:00
2016-12-01 13:58:19 +03:00
/* Should we compare voltages for all regulators here ? */
2018-04-06 12:05:45 +03:00
return opp - > available & &
new_opp - > supplies [ 0 ] . u_volt = = opp - > supplies [ 0 ] . u_volt ? - EBUSY : - EEXIST ;
}
return 0 ;
}
/*
* Returns :
* 0 : On success . And appropriate error message for duplicate OPPs .
* - EBUSY : For OPP with same freq / volt and is available . The callers of
* _opp_add ( ) must return 0 if they receive - EBUSY from it . This is to make
* sure we don ' t print error messages unnecessarily if different parts of
* kernel try to initialize the OPP table .
* - EEXIST : For OPP with same freq but different volt or is unavailable . This
* should be considered an error by the callers of _opp_add ( ) .
*/
int _opp_add ( struct device * dev , struct dev_pm_opp * new_opp ,
struct opp_table * opp_table , bool rate_not_available )
{
struct list_head * head ;
int ret ;
mutex_lock ( & opp_table - > lock ) ;
head = & opp_table - > opp_list ;
2017-01-23 07:41:41 +03:00
2018-04-06 12:05:45 +03:00
if ( likely ( ! rate_not_available ) ) {
ret = _opp_is_duplicate ( dev , new_opp , opp_table , & head ) ;
if ( ret ) {
mutex_unlock ( & opp_table - > lock ) ;
return ret ;
}
2015-07-29 13:53:01 +03:00
}
2017-01-23 07:41:49 +03:00
list_add ( & new_opp - > node , head ) ;
2017-01-23 07:41:41 +03:00
mutex_unlock ( & opp_table - > lock ) ;
new_opp - > opp_table = opp_table ;
2017-01-23 07:41:46 +03:00
kref_init ( & new_opp - > kref ) ;
2015-07-29 13:53:01 +03:00
2019-01-22 18:21:17 +03:00
opp_debug_create_one ( new_opp , opp_table ) ;
2015-11-11 05:29:01 +03:00
2016-02-16 11:47:53 +03:00
if ( ! _opp_supported_by_regulators ( new_opp , opp_table ) ) {
2016-02-09 08:00:34 +03:00
new_opp - > available = false ;
dev_warn ( dev , " %s: OPP not supported by regulators (%lu) \n " ,
__func__ , new_opp - > rate ) ;
}
2015-07-29 13:53:01 +03:00
return 0 ;
}
2014-12-24 20:22:57 +03:00
/**
2015-10-15 19:12:44 +03:00
* _opp_add_v1 ( ) - Allocate a OPP based on v1 bindings .
2017-01-02 12:11:01 +03:00
* @ opp_table : OPP table
2014-12-24 20:22:57 +03:00
* @ dev : device for which we do this operation
* @ freq : Frequency in Hz for this OPP
* @ u_volt : Voltage in uVolts for this OPP
* @ dynamic : Dynamically added OPPs .
*
2016-02-16 11:47:53 +03:00
* This function adds an opp definition to the opp table and returns status .
2014-12-24 20:22:57 +03:00
* The opp is made available by default and it can be controlled using
* dev_pm_opp_enable / disable functions and may be removed by dev_pm_opp_remove .
*
2015-09-04 11:17:24 +03:00
* NOTE : " dynamic " parameter impacts OPPs added by the dev_pm_opp_of_add_table
* and freed by dev_pm_opp_of_remove_table .
2014-12-24 20:22:57 +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
*/
2017-01-02 12:11:01 +03:00
int _opp_add_v1 ( struct opp_table * opp_table , struct device * dev ,
unsigned long freq , long u_volt , bool dynamic )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2015-07-29 13:53:01 +03:00
struct dev_pm_opp * new_opp ;
2016-02-09 08:00:37 +03:00
unsigned long tol ;
2014-12-10 07:15:35 +03:00
int ret ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-01-02 12:11:01 +03:00
new_opp = _opp_allocate ( opp_table ) ;
if ( ! new_opp )
return - ENOMEM ;
2015-07-29 13:53:01 +03:00
2014-11-25 13:34:17 +03:00
/* populate the opp table */
new_opp - > rate = freq ;
2016-02-16 11:47:53 +03:00
tol = u_volt * opp_table - > voltage_tolerance_v1 / 100 ;
2016-12-01 13:58:19 +03:00
new_opp - > supplies [ 0 ] . u_volt = u_volt ;
new_opp - > supplies [ 0 ] . u_volt_min = u_volt - tol ;
new_opp - > supplies [ 0 ] . u_volt_max = u_volt + tol ;
2014-11-25 13:34:17 +03:00
new_opp - > available = true ;
2015-07-29 13:53:01 +03:00
new_opp - > dynamic = dynamic ;
2014-11-25 13:34:17 +03:00
2018-04-06 12:05:45 +03:00
ret = _opp_add ( dev , new_opp , opp_table , false ) ;
2017-01-02 12:10:55 +03:00
if ( ret ) {
/* Don't return error for duplicate OPPs */
if ( ret = = - EBUSY )
ret = 0 ;
2014-12-10 07:15:35 +03:00
goto free_opp ;
2017-01-02 12:10:55 +03:00
}
2014-05-22 09:06:26 +04:00
2011-10-01 00:35:12 +04: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: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
return 0 ;
2014-12-10 07:15:35 +03:00
free_opp :
2017-01-02 12:11:01 +03:00
_opp_free ( new_opp ) ;
2014-12-10 07:15:35 +03:00
return ret ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2014-11-25 13:34:18 +03:00
2015-12-09 05:31:46 +03:00
/**
* dev_pm_opp_set_supported_hw ( ) - Set supported platforms
* @ dev : Device for which supported - hw has to be set .
* @ versions : Array of hierarchy of versions to match .
* @ count : Number of elements in the array .
*
* This is required only for the V2 bindings , and it enables a platform to
* specify the hierarchy of versions it supports . OPP layer will then enable
* OPPs , which are available for those versions , based on its ' opp - supported - hw '
* property .
*/
2017-01-23 07:41:43 +03:00
struct opp_table * dev_pm_opp_set_supported_hw ( struct device * dev ,
const u32 * versions , unsigned int count )
2015-12-09 05:31:46 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2015-12-09 05:31:46 +03:00
2017-01-23 07:41:43 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2015-12-09 05:31:46 +03:00
2016-02-16 11:47:53 +03:00
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2015-12-09 05:31:46 +03:00
2018-05-22 14:08:08 +03:00
/* Another CPU that shares the OPP table has set the property ? */
if ( opp_table - > supported_hw )
return opp_table ;
2015-12-09 05:31:46 +03:00
2016-02-16 11:47:53 +03:00
opp_table - > supported_hw = kmemdup ( versions , count * sizeof ( * versions ) ,
2015-12-09 05:31:46 +03:00
GFP_KERNEL ) ;
2016-02-16 11:47:53 +03:00
if ( ! opp_table - > supported_hw ) {
2018-05-22 14:08:08 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
return ERR_PTR ( - ENOMEM ) ;
2015-12-09 05:31:46 +03:00
}
2016-02-16 11:47:53 +03:00
opp_table - > supported_hw_count = count ;
2017-01-23 07:41:43 +03:00
return opp_table ;
2015-12-09 05:31:46 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_supported_hw ) ;
/**
* dev_pm_opp_put_supported_hw ( ) - Releases resources blocked for supported hw
2017-01-23 07:41:43 +03:00
* @ opp_table : OPP table returned by dev_pm_opp_set_supported_hw ( ) .
2015-12-09 05:31:46 +03:00
*
* This is required only for the V2 bindings , and is called for a matching
2016-02-16 11:47:53 +03:00
* dev_pm_opp_set_supported_hw ( ) . Until this is called , the opp_table structure
2015-12-09 05:31:46 +03:00
* will not be freed .
*/
2017-01-23 07:41:43 +03:00
void dev_pm_opp_put_supported_hw ( struct opp_table * opp_table )
2015-12-09 05:31:46 +03:00
{
2016-02-16 11:47:53 +03:00
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2015-12-09 05:31:46 +03:00
2016-02-16 11:47:53 +03:00
kfree ( opp_table - > supported_hw ) ;
opp_table - > supported_hw = NULL ;
opp_table - > supported_hw_count = 0 ;
2015-12-09 05:31:46 +03:00
2017-01-23 07:41:43 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-12-09 05:31:46 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_put_supported_hw ) ;
2015-12-09 05:31:47 +03:00
/**
* dev_pm_opp_set_prop_name ( ) - Set prop - extn name
2016-02-16 11:47:52 +03:00
* @ dev : Device for which the prop - name has to be set .
2015-12-09 05:31:47 +03:00
* @ name : name to postfix to properties .
*
* This is required only for the V2 bindings , and it enables a platform to
* specify the extn to be used for certain property names . The properties to
* which the extension will apply are opp - microvolt and opp - microamp . OPP core
* should postfix the property name with - < name > while looking for them .
*/
2017-01-23 07:41:43 +03:00
struct opp_table * dev_pm_opp_set_prop_name ( struct device * dev , const char * name )
2015-12-09 05:31:47 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2015-12-09 05:31:47 +03:00
2017-01-23 07:41:43 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2015-12-09 05:31:47 +03:00
2016-02-16 11:47:53 +03:00
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2015-12-09 05:31:47 +03:00
2018-05-22 14:08:08 +03:00
/* Another CPU that shares the OPP table has set the property ? */
if ( opp_table - > prop_name )
return opp_table ;
2015-12-09 05:31:47 +03:00
2016-02-16 11:47:53 +03:00
opp_table - > prop_name = kstrdup ( name , GFP_KERNEL ) ;
if ( ! opp_table - > prop_name ) {
2018-05-22 14:08:08 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
return ERR_PTR ( - ENOMEM ) ;
2015-12-09 05:31:47 +03:00
}
2017-01-23 07:41:43 +03:00
return opp_table ;
2015-12-09 05:31:47 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_prop_name ) ;
/**
* dev_pm_opp_put_prop_name ( ) - Releases resources blocked for prop - name
2017-01-23 07:41:43 +03:00
* @ opp_table : OPP table returned by dev_pm_opp_set_prop_name ( ) .
2015-12-09 05:31:47 +03:00
*
* This is required only for the V2 bindings , and is called for a matching
2016-02-16 11:47:53 +03:00
* dev_pm_opp_set_prop_name ( ) . Until this is called , the opp_table structure
2015-12-09 05:31:47 +03:00
* will not be freed .
*/
2017-01-23 07:41:43 +03:00
void dev_pm_opp_put_prop_name ( struct opp_table * opp_table )
2015-12-09 05:31:47 +03:00
{
2016-02-16 11:47:53 +03:00
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2015-12-09 05:31:47 +03:00
2016-02-16 11:47:53 +03:00
kfree ( opp_table - > prop_name ) ;
opp_table - > prop_name = NULL ;
2015-12-09 05:31:47 +03:00
2017-01-23 07:41:43 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-12-09 05:31:47 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_put_prop_name ) ;
2016-12-01 13:58:20 +03:00
static int _allocate_set_opp_data ( struct opp_table * opp_table )
{
struct dev_pm_set_opp_data * data ;
int len , count = opp_table - > regulator_count ;
2018-12-11 14:02:47 +03:00
if ( WARN_ON ( ! opp_table - > regulators ) )
2016-12-01 13:58:20 +03:00
return - EINVAL ;
/* space for set_opp_data */
len = sizeof ( * data ) ;
/* space for old_opp.supplies and new_opp.supplies */
len + = 2 * sizeof ( struct dev_pm_opp_supply ) * count ;
data = kzalloc ( len , GFP_KERNEL ) ;
if ( ! data )
return - ENOMEM ;
data - > old_opp . supplies = ( void * ) ( data + 1 ) ;
data - > new_opp . supplies = data - > old_opp . supplies + count ;
opp_table - > set_opp_data = data ;
return 0 ;
}
static void _free_set_opp_data ( struct opp_table * opp_table )
{
kfree ( opp_table - > set_opp_data ) ;
opp_table - > set_opp_data = NULL ;
}
2016-02-09 08:00:33 +03:00
/**
2016-12-01 13:58:19 +03:00
* dev_pm_opp_set_regulators ( ) - Set regulator names for the device
2016-02-09 08:00:33 +03:00
* @ dev : Device for which regulator name is being set .
2016-12-01 13:58:19 +03:00
* @ names : Array of pointers to the names of the regulator .
* @ count : Number of regulators .
2016-02-09 08:00:33 +03:00
*
* In order to support OPP switching , OPP layer needs to know the name of the
2016-12-01 13:58:19 +03:00
* device ' s regulators , as the core would be required to switch voltages as
* well .
2016-02-09 08:00:33 +03:00
*
* This must be called before any OPPs are initialized for the device .
*/
2016-12-01 13:58:19 +03:00
struct opp_table * dev_pm_opp_set_regulators ( struct device * dev ,
const char * const names [ ] ,
unsigned int count )
2016-02-09 08:00:33 +03:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2016-02-09 08:00:33 +03:00
struct regulator * reg ;
2016-12-01 13:58:19 +03:00
int ret , i ;
2016-02-09 08:00:33 +03:00
2017-01-23 07:41:43 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2016-02-09 08:00:33 +03:00
/* This should be called before OPPs are initialized */
2016-02-16 11:47:53 +03:00
if ( WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ) {
2016-02-09 08:00:33 +03:00
ret = - EBUSY ;
goto err ;
}
2018-05-22 14:08:08 +03:00
/* Another CPU that shares the OPP table has set the regulators ? */
if ( opp_table - > regulators )
return opp_table ;
2016-12-01 13:58:19 +03:00
opp_table - > regulators = kmalloc_array ( count ,
sizeof ( * opp_table - > regulators ) ,
GFP_KERNEL ) ;
if ( ! opp_table - > regulators ) {
ret = - ENOMEM ;
2016-02-09 08:00:33 +03:00
goto err ;
}
2016-12-01 13:58:19 +03:00
for ( i = 0 ; i < count ; i + + ) {
reg = regulator_get_optional ( dev , names [ i ] ) ;
if ( IS_ERR ( reg ) ) {
ret = PTR_ERR ( reg ) ;
if ( ret ! = - EPROBE_DEFER )
dev_err ( dev , " %s: no regulator (%s) found: %d \n " ,
__func__ , names [ i ] , ret ) ;
goto free_regulators ;
}
opp_table - > regulators [ i ] = reg ;
}
opp_table - > regulator_count = count ;
2016-02-09 08:00:33 +03:00
2016-12-01 13:58:20 +03:00
/* Allocate block only once to pass to set_opp() routines */
ret = _allocate_set_opp_data ( opp_table ) ;
if ( ret )
goto free_regulators ;
2016-11-30 13:51:25 +03:00
return opp_table ;
2016-02-09 08:00:33 +03:00
2016-12-01 13:58:19 +03:00
free_regulators :
2019-10-17 13:27:58 +03:00
while ( i ! = 0 )
regulator_put ( opp_table - > regulators [ - - i ] ) ;
2016-12-01 13:58:19 +03:00
kfree ( opp_table - > regulators ) ;
opp_table - > regulators = NULL ;
2018-12-11 14:09:36 +03:00
opp_table - > regulator_count = - 1 ;
2016-02-09 08:00:33 +03:00
err :
2017-01-23 07:41:43 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2016-02-09 08:00:33 +03:00
2016-11-30 13:51:25 +03:00
return ERR_PTR ( ret ) ;
2016-02-09 08:00:33 +03:00
}
2016-12-01 13:58:19 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_regulators ) ;
2016-02-09 08:00:33 +03:00
/**
2016-12-01 13:58:19 +03:00
* dev_pm_opp_put_regulators ( ) - Releases resources blocked for regulator
* @ opp_table : OPP table returned from dev_pm_opp_set_regulators ( ) .
2016-02-09 08:00:33 +03:00
*/
2016-12-01 13:58:19 +03:00
void dev_pm_opp_put_regulators ( struct opp_table * opp_table )
2016-02-09 08:00:33 +03:00
{
2016-12-01 13:58:19 +03:00
int i ;
2018-05-22 14:08:08 +03:00
if ( ! opp_table - > regulators )
goto put_opp_table ;
2016-02-09 08:00:33 +03:00
2016-02-16 11:47:53 +03:00
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
2016-02-09 08:00:33 +03:00
2020-08-13 06:08:37 +03:00
if ( opp_table - > enabled ) {
2019-07-19 18:05:32 +03:00
for ( i = opp_table - > regulator_count - 1 ; i > = 0 ; i - - )
regulator_disable ( opp_table - > regulators [ i ] ) ;
}
2019-10-17 13:27:58 +03:00
for ( i = opp_table - > regulator_count - 1 ; i > = 0 ; i - - )
2016-12-01 13:58:19 +03:00
regulator_put ( opp_table - > regulators [ i ] ) ;
2016-12-01 13:58:20 +03:00
_free_set_opp_data ( opp_table ) ;
2016-12-01 13:58:19 +03:00
kfree ( opp_table - > regulators ) ;
opp_table - > regulators = NULL ;
2018-12-11 14:09:36 +03:00
opp_table - > regulator_count = - 1 ;
2016-02-09 08:00:33 +03:00
2018-05-22 14:08:08 +03:00
put_opp_table :
2017-01-23 07:41:43 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2016-02-09 08:00:33 +03:00
}
2016-12-01 13:58:19 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_put_regulators ) ;
2016-02-09 08:00:33 +03:00
2017-06-21 07:59:13 +03:00
/**
* dev_pm_opp_set_clkname ( ) - Set clk name for the device
* @ dev : Device for which clk name is being set .
* @ name : Clk name .
*
* In order to support OPP switching , OPP layer needs to get pointer to the
* clock for the device . Simple cases work fine without using this routine ( i . e .
* by passing connection - id as NULL ) , but for a device with multiple clocks
* available , the OPP core needs to know the exact name of the clk to use .
*
* This must be called before any OPPs are initialized for the device .
*/
struct opp_table * dev_pm_opp_set_clkname ( struct device * dev , const char * name )
{
struct opp_table * opp_table ;
int ret ;
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2017-06-21 07:59:13 +03:00
/* This should be called before OPPs are initialized */
if ( WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ) {
ret = - EBUSY ;
goto err ;
}
/* Already have default clk set, free it */
if ( ! IS_ERR ( opp_table - > clk ) )
clk_put ( opp_table - > clk ) ;
/* Find clk for the device */
opp_table - > clk = clk_get ( dev , name ) ;
if ( IS_ERR ( opp_table - > clk ) ) {
ret = PTR_ERR ( opp_table - > clk ) ;
if ( ret ! = - EPROBE_DEFER ) {
dev_err ( dev , " %s: Couldn't find clock: %d \n " , __func__ ,
ret ) ;
}
goto err ;
}
return opp_table ;
err :
dev_pm_opp_put_opp_table ( opp_table ) ;
return ERR_PTR ( ret ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_set_clkname ) ;
/**
* dev_pm_opp_put_clkname ( ) - Releases resources blocked for clk .
* @ opp_table : OPP table returned from dev_pm_opp_set_clkname ( ) .
*/
void dev_pm_opp_put_clkname ( struct opp_table * opp_table )
{
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
clk_put ( opp_table - > clk ) ;
opp_table - > clk = ERR_PTR ( - EINVAL ) ;
dev_pm_opp_put_opp_table ( opp_table ) ;
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_put_clkname ) ;
2016-12-01 13:58:21 +03:00
/**
* dev_pm_opp_register_set_opp_helper ( ) - Register custom set OPP helper
* @ dev : Device for which the helper is getting registered .
* @ set_opp : Custom set OPP helper .
*
* This is useful to support complex platforms ( like platforms with multiple
* regulators per device ) , instead of the generic OPP set rate helper .
*
* This must be called before any OPPs are initialized for the device .
*/
2017-01-23 07:41:43 +03:00
struct opp_table * dev_pm_opp_register_set_opp_helper ( struct device * dev ,
2016-12-01 13:58:21 +03:00
int ( * set_opp ) ( struct dev_pm_set_opp_data * data ) )
{
struct opp_table * opp_table ;
if ( ! set_opp )
2017-01-23 07:41:43 +03:00
return ERR_PTR ( - EINVAL ) ;
2016-12-01 13:58:21 +03:00
2017-01-23 07:41:43 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2016-12-01 13:58:21 +03:00
/* This should be called before OPPs are initialized */
if ( WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ) {
2018-05-22 14:08:08 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
return ERR_PTR ( - EBUSY ) ;
2016-12-01 13:58:21 +03:00
}
2018-05-22 14:08:08 +03:00
/* Another CPU that shares the OPP table has set the helper ? */
if ( ! opp_table - > set_opp )
opp_table - > set_opp = set_opp ;
2016-12-01 13:58:21 +03:00
2017-01-23 07:41:43 +03:00
return opp_table ;
2016-12-01 13:58:21 +03:00
}
EXPORT_SYMBOL_GPL ( dev_pm_opp_register_set_opp_helper ) ;
/**
2017-10-05 14:56:21 +03:00
* dev_pm_opp_unregister_set_opp_helper ( ) - Releases resources blocked for
2016-12-01 13:58:21 +03:00
* set_opp helper
2017-01-23 07:41:43 +03:00
* @ opp_table : OPP table returned from dev_pm_opp_register_set_opp_helper ( ) .
2016-12-01 13:58:21 +03:00
*
2017-01-23 07:41:43 +03:00
* Release resources blocked for platform specific set_opp helper .
2016-12-01 13:58:21 +03:00
*/
2017-10-05 14:56:21 +03:00
void dev_pm_opp_unregister_set_opp_helper ( struct opp_table * opp_table )
2016-12-01 13:58:21 +03:00
{
/* Make sure there are no concurrent readers while updating opp_table */
WARN_ON ( ! list_empty ( & opp_table - > opp_list ) ) ;
opp_table - > set_opp = NULL ;
2017-01-23 07:41:43 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2016-12-01 13:58:21 +03:00
}
2017-10-05 14:56:21 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_unregister_set_opp_helper ) ;
2016-12-01 13:58:21 +03:00
2019-05-08 12:49:13 +03:00
static void _opp_detach_genpd ( struct opp_table * opp_table )
{
int index ;
for ( index = 0 ; index < opp_table - > required_opp_count ; index + + ) {
if ( ! opp_table - > genpd_virt_devs [ index ] )
continue ;
dev_pm_domain_detach ( opp_table - > genpd_virt_devs [ index ] , false ) ;
opp_table - > genpd_virt_devs [ index ] = NULL ;
}
2019-05-08 13:13:36 +03:00
kfree ( opp_table - > genpd_virt_devs ) ;
opp_table - > genpd_virt_devs = NULL ;
2019-05-08 12:49:13 +03:00
}
2018-06-26 13:59:34 +03:00
/**
2019-05-08 12:49:13 +03:00
* dev_pm_opp_attach_genpd - Attach genpd ( s ) for the device and save virtual device pointer
* @ dev : Consumer device for which the genpd is getting attached .
* @ names : Null terminated array of pointers containing names of genpd to attach .
2019-07-08 08:54:56 +03:00
* @ virt_devs : Pointer to return the array of virtual devices .
2018-06-26 13:59:34 +03:00
*
* Multiple generic power domains for a device are supported with the help of
* virtual genpd devices , which are created for each consumer device - genpd
* pair . These are the device structures which are attached to the power domain
* and are required by the OPP core to set the performance state of the genpd .
2019-05-08 12:49:13 +03:00
* The same API also works for the case where single genpd is available and so
* we don ' t need to support that separately .
2018-06-26 13:59:34 +03:00
*
* This helper will normally be called by the consumer driver of the device
2019-05-08 12:49:13 +03:00
* " dev " , as only that has details of the genpd names .
2018-06-26 13:59:34 +03:00
*
2019-05-08 12:49:13 +03:00
* This helper needs to be called once with a list of all genpd to attach .
* Otherwise the original device structure will be used instead by the OPP core .
2019-07-17 08:50:17 +03:00
*
* The order of entries in the names array must match the order in which
* " required-opps " are added in DT .
2018-06-26 13:59:34 +03:00
*/
2019-07-08 08:54:56 +03:00
struct opp_table * dev_pm_opp_attach_genpd ( struct device * dev ,
const char * * names , struct device * * * virt_devs )
2018-06-26 13:59:34 +03:00
{
struct opp_table * opp_table ;
2019-05-08 12:49:13 +03:00
struct device * virt_dev ;
2019-07-17 08:50:17 +03:00
int index = 0 , ret = - EINVAL ;
2019-05-08 12:49:13 +03:00
const char * * name = names ;
2018-06-26 13:59:34 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 opp_table ;
2018-06-26 13:59:34 +03:00
2019-05-08 12:49:13 +03:00
/*
* If the genpd ' s OPP table isn ' t already initialized , parsing of the
* required - opps fail for dev . We should retry this after genpd ' s OPP
* table is added .
*/
if ( ! opp_table - > required_opp_count ) {
ret = - EPROBE_DEFER ;
goto put_table ;
}
2018-06-26 13:59:34 +03:00
mutex_lock ( & opp_table - > genpd_virt_dev_lock ) ;
2019-05-08 13:13:36 +03:00
opp_table - > genpd_virt_devs = kcalloc ( opp_table - > required_opp_count ,
sizeof ( * opp_table - > genpd_virt_devs ) ,
GFP_KERNEL ) ;
if ( ! opp_table - > genpd_virt_devs )
goto unlock ;
2018-06-26 13:59:34 +03:00
2019-05-08 12:49:13 +03:00
while ( * name ) {
if ( index > = opp_table - > required_opp_count ) {
dev_err ( dev , " Index can't be greater than required-opp-count - 1, %s (%d : %d) \n " ,
* name , opp_table - > required_opp_count , index ) ;
goto err ;
}
virt_dev = dev_pm_domain_attach_by_name ( dev , * name ) ;
if ( IS_ERR ( virt_dev ) ) {
ret = PTR_ERR ( virt_dev ) ;
dev_err ( dev , " Couldn't attach to pm_domain: %d \n " , ret ) ;
goto err ;
}
opp_table - > genpd_virt_devs [ index ] = virt_dev ;
2019-07-17 08:50:17 +03:00
index + + ;
2019-05-08 12:49:13 +03:00
name + + ;
2018-06-26 13:59:34 +03:00
}
2019-07-08 08:54:56 +03:00
if ( virt_devs )
* virt_devs = opp_table - > genpd_virt_devs ;
2018-06-26 13:59:34 +03:00
mutex_unlock ( & opp_table - > genpd_virt_dev_lock ) ;
return opp_table ;
2019-05-08 12:49:13 +03:00
err :
_opp_detach_genpd ( opp_table ) ;
2019-05-08 13:13:36 +03:00
unlock :
2019-05-08 12:49:13 +03:00
mutex_unlock ( & opp_table - > genpd_virt_dev_lock ) ;
put_table :
dev_pm_opp_put_opp_table ( opp_table ) ;
return ERR_PTR ( ret ) ;
2018-06-26 13:59:34 +03:00
}
2019-05-08 12:49:13 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_attach_genpd ) ;
2018-06-26 13:59:34 +03:00
/**
2019-05-08 12:49:13 +03:00
* dev_pm_opp_detach_genpd ( ) - Detach genpd ( s ) from the device .
* @ opp_table : OPP table returned by dev_pm_opp_attach_genpd ( ) .
2018-06-26 13:59:34 +03:00
*
2019-05-08 12:49:13 +03:00
* This detaches the genpd ( s ) , resets the virtual device pointers , and puts the
* OPP table .
2018-06-26 13:59:34 +03:00
*/
2019-05-08 12:49:13 +03:00
void dev_pm_opp_detach_genpd ( struct opp_table * opp_table )
2018-06-26 13:59:34 +03:00
{
/*
* Acquire genpd_virt_dev_lock to make sure virt_dev isn ' t getting
* used in parallel .
*/
mutex_lock ( & opp_table - > genpd_virt_dev_lock ) ;
2019-05-08 12:49:13 +03:00
_opp_detach_genpd ( opp_table ) ;
2018-06-26 13:59:34 +03:00
mutex_unlock ( & opp_table - > genpd_virt_dev_lock ) ;
2019-05-08 12:49:13 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2018-06-26 13:59:34 +03:00
}
2019-05-08 12:49:13 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_detach_genpd ) ;
2018-06-26 13:59:34 +03:00
2018-11-02 12:06:42 +03:00
/**
* dev_pm_opp_xlate_performance_state ( ) - Find required OPP ' s pstate for src_table .
* @ src_table : OPP table which has dst_table as one of its required OPP table .
* @ dst_table : Required OPP table of the src_table .
* @ pstate : Current performance state of the src_table .
*
* This Returns pstate of the OPP ( present in @ dst_table ) pointed out by the
* " required-opps " property of the OPP ( present in @ src_table ) which has
* performance state set to @ pstate .
*
* Return : Zero or positive performance state on success , otherwise negative
* value on errors .
*/
int dev_pm_opp_xlate_performance_state ( struct opp_table * src_table ,
struct opp_table * dst_table ,
unsigned int pstate )
{
struct dev_pm_opp * opp ;
int dest_pstate = - EINVAL ;
int i ;
if ( ! pstate )
return 0 ;
/*
* Normally the src_table will have the " required_opps " property set to
* point to one of the OPPs in the dst_table , but in some cases the
* genpd and its master have one to one mapping of performance states
* and so none of them have the " required-opps " property set . Return the
* pstate of the src_table as it is in such cases .
*/
if ( ! src_table - > required_opp_count )
return pstate ;
for ( i = 0 ; i < src_table - > required_opp_count ; i + + ) {
if ( src_table - > required_opp_tables [ i ] - > np = = dst_table - > np )
break ;
}
if ( unlikely ( i = = src_table - > required_opp_count ) ) {
pr_err ( " %s: Couldn't find matching OPP table (%p: %p) \n " ,
__func__ , src_table , dst_table ) ;
return - EINVAL ;
}
mutex_lock ( & src_table - > lock ) ;
list_for_each_entry ( opp , & src_table - > opp_list , node ) {
if ( opp - > pstate = = pstate ) {
dest_pstate = opp - > required_opps [ i ] - > pstate ;
goto unlock ;
}
}
pr_err ( " %s: Couldn't find matching OPP (%p: %p) \n " , __func__ , src_table ,
dst_table ) ;
unlock :
mutex_unlock ( & src_table - > lock ) ;
return dest_pstate ;
}
2014-11-25 13:34:18 +03:00
/**
* dev_pm_opp_add ( ) - Add an OPP table from a table definitions
* @ dev : device for which we do this operation
* @ freq : Frequency in Hz for this OPP
* @ u_volt : Voltage in uVolts for this OPP
*
2016-02-16 11:47:53 +03:00
* This function adds an opp definition to the opp table and returns status .
2014-11-25 13:34:18 +03:00
* The opp is made available by default and it can be controlled using
* dev_pm_opp_enable / disable functions .
*
* Return :
2014-12-24 20:22:57 +03:00
* 0 On success OR
2014-11-25 13:34:18 +03:00
* Duplicate OPPs ( both freq and volt are same ) and opp - > available
2014-12-24 20:22:57 +03:00
* - EEXIST Freq are same and volt are different OR
2014-11-25 13:34:18 +03:00
* Duplicate OPPs ( both freq and volt are same ) and ! opp - > available
2014-12-24 20:22:57 +03:00
* - ENOMEM Memory allocation failure
2014-11-25 13:34:18 +03:00
*/
int dev_pm_opp_add ( struct device * dev , unsigned long freq , unsigned long u_volt )
{
2017-01-02 12:11:01 +03:00
struct opp_table * opp_table ;
int ret ;
2017-01-23 07:41:45 +03:00
opp_table = dev_pm_opp_get_opp_table ( dev ) ;
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 ) ;
2017-01-02 12:11:01 +03:00
2018-12-11 14:09:36 +03:00
/* Fix regulator count for dynamic OPPs */
opp_table - > regulator_count = 1 ;
2017-01-02 12:11:01 +03:00
ret = _opp_add_v1 ( opp_table , dev , freq , u_volt , true ) ;
2018-08-02 11:53:09 +03:00
if ( ret )
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-02 12:11:01 +03:00
return ret ;
2014-11-25 13:34:18 +03:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_add ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2014-12-24 20:22:56 +03:00
* _opp_set_availability ( ) - helper to set the availability of an opp
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : OPP frequency to modify availability
* @ availability_req : availability status requested for this opp
*
2017-01-23 07:41:49 +03:00
* Set the availability of an OPP , opp_ { enable , disable } share a common logic
* which is isolated here .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2014-12-24 20:22:57 +03:00
* Return : - EINVAL for bad pointers , - ENOMEM if no memory available for the
2015-09-24 22:28:44 +03:00
* copy operation , returns 0 if no modification was done OR modification was
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* successful .
*/
2014-12-24 20:22:56 +03:00
static int _opp_set_availability ( struct device * dev , unsigned long freq ,
bool availability_req )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2016-02-16 11:47:53 +03:00
struct opp_table * opp_table ;
2017-01-23 07:41:50 +03:00
struct dev_pm_opp * tmp_opp , * opp = ERR_PTR ( - ENODEV ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
int r = 0 ;
2016-02-16 11:47:53 +03:00
/* Find the opp_table */
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
r = PTR_ERR ( opp_table ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
dev_warn ( dev , " %s: Device OPP not found (%d) \n " , __func__ , r ) ;
2017-01-23 07:41:50 +03:00
return r ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2017-01-23 07:41:41 +03:00
mutex_lock ( & opp_table - > lock ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/* Do we have the frequency? */
2016-02-16 11:47:53 +03:00
list_for_each_entry ( tmp_opp , & opp_table - > opp_list , node ) {
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( tmp_opp - > rate = = freq ) {
opp = tmp_opp ;
break ;
}
}
2017-01-23 07:41:41 +03:00
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
if ( IS_ERR ( opp ) ) {
r = PTR_ERR ( opp ) ;
goto unlock ;
}
/* Is update really needed? */
if ( opp - > available = = availability_req )
goto unlock ;
2017-01-23 07:41:50 +03:00
opp - > available = availability_req ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-09-21 20:44:36 +03:00
dev_pm_opp_get ( opp ) ;
mutex_unlock ( & opp_table - > lock ) ;
2011-10-01 00:35:12 +04:00
/* Notify the change of the OPP availability */
if ( availability_req )
2017-01-23 07:41:49 +03:00
blocking_notifier_call_chain ( & opp_table - > head , OPP_EVENT_ENABLE ,
2017-01-23 07:41:50 +03:00
opp ) ;
2011-10-01 00:35:12 +04:00
else
2017-01-23 07:41:49 +03:00
blocking_notifier_call_chain ( & opp_table - > head ,
2017-01-23 07:41:50 +03:00
OPP_EVENT_DISABLE , opp ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2017-09-21 20:44:36 +03:00
dev_pm_opp_put ( opp ) ;
goto put_table ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
unlock :
2017-01-23 07:41:48 +03:00
mutex_unlock ( & opp_table - > lock ) ;
2017-09-21 20:44:36 +03:00
put_table :
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
return r ;
}
2019-10-16 17:57:53 +03:00
/**
* dev_pm_opp_adjust_voltage ( ) - helper to change the voltage of an OPP
* @ dev : device for which we do this operation
* @ freq : OPP frequency to adjust voltage of
* @ u_volt : new OPP target voltage
* @ u_volt_min : new OPP min voltage
* @ u_volt_max : new OPP max voltage
*
* Return : - EINVAL for bad pointers , - ENOMEM if no memory available for the
* copy operation , returns 0 if no modifcation was done OR modification was
* successful .
*/
int dev_pm_opp_adjust_voltage ( struct device * dev , unsigned long freq ,
unsigned long u_volt , unsigned long u_volt_min ,
unsigned long u_volt_max )
{
struct opp_table * opp_table ;
struct dev_pm_opp * tmp_opp , * opp = ERR_PTR ( - ENODEV ) ;
int r = 0 ;
/* Find the opp_table */
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
r = PTR_ERR ( opp_table ) ;
dev_warn ( dev , " %s: Device OPP not found (%d) \n " , __func__ , r ) ;
return r ;
}
mutex_lock ( & opp_table - > lock ) ;
/* Do we have the frequency? */
list_for_each_entry ( tmp_opp , & opp_table - > opp_list , node ) {
if ( tmp_opp - > rate = = freq ) {
opp = tmp_opp ;
break ;
}
}
if ( IS_ERR ( opp ) ) {
r = PTR_ERR ( opp ) ;
goto adjust_unlock ;
}
/* Is update really needed? */
if ( opp - > supplies - > u_volt = = u_volt )
goto adjust_unlock ;
opp - > supplies - > u_volt = u_volt ;
opp - > supplies - > u_volt_min = u_volt_min ;
opp - > supplies - > u_volt_max = u_volt_max ;
dev_pm_opp_get ( opp ) ;
mutex_unlock ( & opp_table - > lock ) ;
/* Notify the voltage change of the OPP */
blocking_notifier_call_chain ( & opp_table - > head , OPP_EVENT_ADJUST_VOLTAGE ,
opp ) ;
dev_pm_opp_put ( opp ) ;
goto adjust_put_table ;
adjust_unlock :
mutex_unlock ( & opp_table - > lock ) ;
adjust_put_table :
dev_pm_opp_put_opp_table ( opp_table ) ;
return r ;
}
2020-06-20 20:03:22 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_adjust_voltage ) ;
2019-10-16 17:57:53 +03:00
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_enable ( ) - Enable a specific OPP
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : OPP frequency to enable
*
* Enables a provided opp . If the operation is valid , this returns 0 , else the
* corresponding error value . It is meant to be used for users an OPP available
2013-09-20 01:03:50 +04:00
* after being temporarily made unavailable with dev_pm_opp_disable .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2014-12-24 20:22:57 +03:00
* Return : - EINVAL for bad pointers , - ENOMEM if no memory available for the
2015-09-24 22:28:44 +03:00
* copy operation , returns 0 if no modification was done OR modification was
2014-12-24 20:22:57 +03:00
* successful .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:50 +04:00
int dev_pm_opp_enable ( struct device * dev , unsigned long freq )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2014-12-24 20:22:56 +03:00
return _opp_set_availability ( dev , freq , true ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_enable ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
/**
2013-09-20 01:03:50 +04:00
* dev_pm_opp_disable ( ) - Disable a specific OPP
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
* @ dev : device for which we do this operation
* @ freq : OPP frequency to disable
*
* Disables a provided opp . If the operation is valid , this returns
* 0 , else the corresponding error value . It is meant to be a temporary
* control by users to make this OPP not available until the circumstances are
2013-09-20 01:03:50 +04:00
* right to make it available again ( with a call to dev_pm_opp_enable ) .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*
2014-12-24 20:22:57 +03:00
* Return : - EINVAL for bad pointers , - ENOMEM if no memory available for the
2015-09-24 22:28:44 +03:00
* copy operation , returns 0 if no modification was done OR modification was
2014-12-24 20:22:57 +03:00
* successful .
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
*/
2013-09-20 01:03:50 +04:00
int dev_pm_opp_disable ( struct device * dev , unsigned long freq )
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
{
2014-12-24 20:22:56 +03:00
return _opp_set_availability ( dev , freq , false ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
}
2013-09-20 01:03:50 +04:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_disable ) ;
PM: Introduce library for device-specific OPPs (v7)
SoCs have a standard set of tuples consisting of frequency and
voltage pairs that the device will support per voltage domain. These
are called Operating Performance Points or OPPs. The actual
definitions of OPP varies over silicon versions. For a specific domain,
we can have a set of {frequency, voltage} pairs. As the kernel boots
and more information is available, a default set of these are activated
based on the precise nature of device. Further on operation, based on
conditions prevailing in the system (such as temperature), some OPP
availability may be temporarily controlled by the SoC frameworks.
To implement an OPP, some sort of power management support is necessary
hence this library depends on CONFIG_PM.
Contributions include:
Sanjeev Premi for the initial concept:
http://patchwork.kernel.org/patch/50998/
Kevin Hilman for converting original design to device-based.
Kevin Hilman and Paul Walmsey for cleaning up many of the function
abstractions, improvements and data structure handling.
Romit Dasgupta for using enums instead of opp pointers.
Thara Gopinath, Eduardo Valentin and Vishwanath BS for fixes and
cleanups.
Linus Walleij for recommending this layer be made generic for usage
in other architectures beyond OMAP and ARM.
Mark Brown, Andrew Morton, Rafael J. Wysocki, Paul E. McKenney for
valuable improvements.
Discussions and comments from:
http://marc.info/?l=linux-omap&m=126033945313269&w=2
http://marc.info/?l=linux-omap&m=125482970102327&w=2
http://marc.info/?t=125809247500002&r=1&w=2
http://marc.info/?l=linux-omap&m=126025973426007&w=2
http://marc.info/?t=128152609200064&r=1&w=2
http://marc.info/?t=128468723000002&r=1&w=2
incorporated.
v1: http://marc.info/?t=128468723000002&r=1&w=2
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2010-10-13 02:13:10 +04:00
2011-10-01 00:35:12 +04:00
/**
2017-01-02 12:11:03 +03:00
* dev_pm_opp_register_notifier ( ) - Register OPP notifier for the device
* @ dev : Device for which notifier needs to be registered
* @ nb : Notifier block to be registered
2014-12-24 20:22:57 +03:00
*
2017-01-02 12:11:03 +03:00
* Return : 0 on success or a negative error value .
*/
int dev_pm_opp_register_notifier ( struct device * dev , struct notifier_block * nb )
{
struct opp_table * opp_table ;
int ret ;
opp_table = _find_opp_table ( dev ) ;
2017-01-23 07:41:48 +03:00
if ( IS_ERR ( opp_table ) )
return PTR_ERR ( opp_table ) ;
2017-01-23 07:41:49 +03:00
ret = blocking_notifier_chain_register ( & opp_table - > head , nb ) ;
2017-01-02 12:11:03 +03:00
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-02 12:11:03 +03:00
return ret ;
}
EXPORT_SYMBOL ( dev_pm_opp_register_notifier ) ;
/**
* dev_pm_opp_unregister_notifier ( ) - Unregister OPP notifier for the device
* @ dev : Device for which notifier needs to be unregistered
* @ nb : Notifier block to be unregistered
2014-12-24 20:22:57 +03:00
*
2017-01-02 12:11:03 +03:00
* Return : 0 on success or a negative error value .
2011-10-01 00:35:12 +04:00
*/
2017-01-02 12:11:03 +03:00
int dev_pm_opp_unregister_notifier ( struct device * dev ,
struct notifier_block * nb )
2011-10-01 00:35:12 +04:00
{
2017-01-02 12:11:03 +03:00
struct opp_table * opp_table ;
int ret ;
2011-10-01 00:35:12 +04:00
2017-01-02 12:11:03 +03:00
opp_table = _find_opp_table ( dev ) ;
2017-01-23 07:41:48 +03:00
if ( IS_ERR ( opp_table ) )
return PTR_ERR ( opp_table ) ;
2017-01-02 12:11:03 +03:00
2017-01-23 07:41:49 +03:00
ret = blocking_notifier_chain_unregister ( & opp_table - > head , nb ) ;
2011-10-01 00:35:12 +04:00
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2017-01-02 12:11:03 +03:00
return ret ;
2011-10-01 00:35:12 +04:00
}
2017-01-02 12:11:03 +03:00
EXPORT_SYMBOL ( dev_pm_opp_unregister_notifier ) ;
2012-09-05 03:09:12 +04:00
2020-08-20 10:48:23 +03:00
/**
* dev_pm_opp_remove_table ( ) - Free all OPPs associated with the device
* @ dev : device pointer used to lookup OPP table .
*
* Free both OPPs created using static entries present in DT and the
* dynamically added entries .
*/
void dev_pm_opp_remove_table ( struct device * dev )
2017-01-02 12:11:00 +03:00
{
struct opp_table * opp_table ;
2016-02-16 11:47:53 +03:00
/* Check for existing table for 'dev' */
opp_table = _find_opp_table ( dev ) ;
if ( IS_ERR ( opp_table ) ) {
int error = PTR_ERR ( opp_table ) ;
2015-07-29 13:52:58 +03:00
if ( error ! = - ENODEV )
2016-02-16 11:47:53 +03:00
WARN ( 1 , " %s: opp_table: %d \n " ,
2015-07-29 13:52:58 +03:00
IS_ERR_OR_NULL ( dev ) ?
" Invalid device " : dev_name ( dev ) ,
error ) ;
2017-01-23 07:41:48 +03:00
return ;
2015-07-29 13:52:58 +03:00
}
2019-11-11 14:05:03 +03:00
_opp_remove_all_static ( opp_table ) ;
2018-09-12 10:05:19 +03:00
/* Drop reference taken by _find_opp_table() */
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-07-29 13:52:58 +03:00
2018-09-12 10:05:19 +03:00
/* Drop reference taken while the OPP table was added */
2017-01-23 07:41:48 +03:00
dev_pm_opp_put_opp_table ( opp_table ) ;
2015-07-29 13:52:58 +03:00
}
2016-05-03 17:05:04 +03:00
EXPORT_SYMBOL_GPL ( dev_pm_opp_remove_table ) ;