[PATCH v3 0/3] cpufreq: Introduce TI CPUFreq/OPP Driver

[PATCH v3 0/3] cpufreq: Introduce TI CPUFreq/OPP Driver

[Dave Gerlach]

Hi,
This series is v3 of the series to introduce the ti-cpufreq driver
which parses SoC data and provides opp-supported-hw data to the
OPP core in order to enable the proper OPPs for the silicon in use.
v2 of this series can be found here [1].

Several changes to the dt-binding and ti-cpufreq driver are
present in v3, which are described in detail under scissors line
in patches but mostly focused on moving properties that were added
in cpu node previously to the operating-points node and updating
driver to reflect these changes, along with using a common compatible
for all ti platforms. Also, a new patch was added to expose an internal
OPP core API to allow a common way to get a reference to the OPP table
from a platform driver.

I have just sent the driver and binding here but have held off on the
updated DT nodes, I will send these out once we can agree on the binding
and driver changes but have pushed them if anyone is curious here [2].

Regards,
Dave

[1] http://www.spinics.net/lists/linux-omap/msg131601.html
[2] https://github.com/dgerlach/linux-pm/tree/upstream/v4.9/ti-cpufreq-driver-v3

Dave Gerlach (3):
  PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
  Documentation: dt: add bindings for ti-cpufreq
  cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

 .../devicetree/bindings/cpufreq/ti-cpufreq.txt     | 132 ++++++++++
 drivers/base/power/opp/of.c                        |   8 +-
 drivers/base/power/opp/opp.h                       |   1 -
 drivers/cpufreq/Kconfig.arm                        |  11 +
 drivers/cpufreq/Makefile                           |   1 +
 drivers/cpufreq/ti-cpufreq.c                       | 288 +++++++++++++++++++++
 include/linux/pm_opp.h                             |   6 +
 7 files changed, 442 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
 create mode 100644 drivers/cpufreq/ti-cpufreq.c

-- 
2.9.3

[PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API

[Dave Gerlach]

Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
OPP and cpufreq drivers, to make use of it.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
 drivers/base/power/opp/of.c  | 8 ++++----
 drivers/base/power/opp/opp.h | 1 -
 include/linux/pm_opp.h       | 6 ++++++
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 5552211e6fcd..215f5a538c78 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
 EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
 
 /* Returns opp descriptor node for a device, caller must do of_node_put() */
-struct device_node *_of_get_opp_desc_node(struct device *dev)
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
 {
 	/*
 	 * TODO: Support for multiple OPP tables.
@@ -450,7 +450,7 @@ int dev_pm_opp_of_add_table(struct device *dev)
 	 * OPPs have two version of bindings now. The older one is deprecated,
 	 * try for the new binding first.
 	 */
-	opp_np = _of_get_opp_desc_node(dev);
+	opp_np = dev_pm_opp_of_get_opp_desc_node(dev);
 	if (!opp_np) {
 		/*
 		 * Try old-deprecated bindings for backward compatibility with
@@ -560,7 +560,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
 	int cpu, ret = 0;
 
 	/* Get OPP descriptor node */
-	np = _of_get_opp_desc_node(cpu_dev);
+	np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
 	if (!np) {
 		dev_dbg(cpu_dev, "%s: Couldn't find cpu_dev node.\n", __func__);
 		return -ENOENT;
@@ -585,7 +585,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
 		}
 
 		/* Get OPP descriptor node */
-		tmp_np = _of_get_opp_desc_node(tcpu_dev);
+		tmp_np = dev_pm_opp_of_get_opp_desc_node(tcpu_dev);
 		if (!tmp_np) {
 			dev_err(tcpu_dev, "%s: Couldn't find tcpu_dev node.\n",
 				__func__);
diff --git a/drivers/base/power/opp/opp.h b/drivers/base/power/opp/opp.h
index fabd5ca1a083..96cd30ac6c1d 100644
--- a/drivers/base/power/opp/opp.h
+++ b/drivers/base/power/opp/opp.h
@@ -190,7 +190,6 @@ struct opp_table {
 /* Routines internal to opp core */
 struct opp_table *_find_opp_table(struct device *dev);
 struct opp_device *_add_opp_dev(const struct device *dev, struct opp_table *opp_table);
-struct device_node *_of_get_opp_desc_node(struct device *dev);
 void _dev_pm_opp_remove_table(struct device *dev, bool remove_all);
 struct dev_pm_opp *_allocate_opp(struct device *dev, struct opp_table **opp_table);
 int _opp_add(struct device *dev, struct dev_pm_opp *new_opp, struct opp_table *opp_table);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index bca26157f5b6..9e8c138f55b7 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -208,6 +208,7 @@ void dev_pm_opp_of_remove_table(struct device *dev);
 int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask);
 void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
 int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask);
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
 #else
 static inline int dev_pm_opp_of_add_table(struct device *dev)
 {
@@ -231,6 +232,11 @@ static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct
 {
 	return -ENOTSUPP;
 }
+
+static inline struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
+{
+	return NULL;
+}
 #endif
 
 #endif		/* __LINUX_OPP_H__ */
-- 
2.9.3

Re: [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 5105 bytes --]

Hi Dave,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.9-rc2]
[cannot apply to pm/linux-next next-20161027]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:    https://github.com/0day-ci/linux/commits/Dave-Gerlach/cpufreq-Introduce-TI-CPUFreq-OPP-Driver/20161028-054633
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
        wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/base/power/opp/of.c:184:6: error: redefinition of 'dev_pm_opp_of_remove_table'
    void dev_pm_opp_of_remove_table(struct device *dev)
         ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:218:20: note: previous definition of 'dev_pm_opp_of_remove_table' was here
    static inline void dev_pm_opp_of_remove_table(struct device *dev)
                       ^
>> drivers/base/power/opp/of.c:191:21: error: redefinition of 'dev_pm_opp_of_get_opp_desc_node'
    struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
                        ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:236:35: note: previous definition of 'dev_pm_opp_of_get_opp_desc_node' was here
    static inline struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
                                      ^
   drivers/base/power/opp/of.c:434:5: error: redefinition of 'dev_pm_opp_of_add_table'
    int dev_pm_opp_of_add_table(struct device *dev)
        ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:213:19: note: previous definition of 'dev_pm_opp_of_add_table' was here
    static inline int dev_pm_opp_of_add_table(struct device *dev)
                      ^
   drivers/base/power/opp/of.c:474:6: error: redefinition of 'dev_pm_opp_of_cpumask_remove_table'
    void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask)
         ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:227:20: note: previous definition of 'dev_pm_opp_of_cpumask_remove_table' was here
    static inline void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask)
                       ^
   drivers/base/power/opp/of.c:492:5: error: redefinition of 'dev_pm_opp_of_cpumask_add_table'
    int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask)
        ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:222:19: note: previous definition of 'dev_pm_opp_of_cpumask_add_table' was here
    static inline int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask)
                      ^
   drivers/base/power/opp/of.c:545:5: error: redefinition of 'dev_pm_opp_of_get_sharing_cpus'
    int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
        ^
   In file included from drivers/base/power/opp/opp.h:21:0,
                    from drivers/base/power/opp/of.c:22:
   include/linux/pm_opp.h:231:19: note: previous definition of 'dev_pm_opp_of_get_sharing_cpus' was here
    static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask)
                      ^

vim +/dev_pm_opp_of_get_opp_desc_node +191 drivers/base/power/opp/of.c

   178	 * Locking: The internal opp_table and opp structures are RCU protected.
   179	 * Hence this function indirectly uses RCU updater strategy with mutex locks
   180	 * to keep the integrity of the internal data structures. Callers should ensure
   181	 * that this function is *NOT* called under RCU protection or in contexts where
   182	 * mutex cannot be locked.
   183	 */
 > 184	void dev_pm_opp_of_remove_table(struct device *dev)
   185	{
   186		_dev_pm_opp_remove_table(dev, false);
   187	}
   188	EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
   189	
   190	/* Returns opp descriptor node for a device, caller must do of_node_put() */
 > 191	struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
   192	{
   193		/*
   194		 * TODO: Support for multiple OPP tables.

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 46043 bytes --]

Re: [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API

[Viresh Kumar]

On 27-10-16, 16:41, Dave Gerlach wrote:
> Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
> dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
> OPP and cpufreq drivers, to make use of it.
> 
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
>  drivers/base/power/opp/of.c  | 8 ++++----
>  drivers/base/power/opp/opp.h | 1 -
>  include/linux/pm_opp.h       | 6 ++++++
>  3 files changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
> index 5552211e6fcd..215f5a538c78 100644
> --- a/drivers/base/power/opp/of.c
> +++ b/drivers/base/power/opp/of.c
> @@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
>  EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>  
>  /* Returns opp descriptor node for a device, caller must do of_node_put() */
> -struct device_node *_of_get_opp_desc_node(struct device *dev)
> +struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)

Export as well ?

-- 
viresh

Re: [PATCH v3 1/3] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API

[Dave Gerlach]

On 10/27/2016 11:05 PM, Viresh Kumar wrote:
> On 27-10-16, 16:41, Dave Gerlach wrote:
>> Move _of_get_opp_desc_node into include/linux/pm_opp.h and rename it
>> dev_pm_opp_of_get_opp_desc_node to allow other drivers, such as platform
>> OPP and cpufreq drivers, to make use of it.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
>> ---
>>  drivers/base/power/opp/of.c  | 8 ++++----
>>  drivers/base/power/opp/opp.h | 1 -
>>  include/linux/pm_opp.h       | 6 ++++++
>>  3 files changed, 10 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
>> index 5552211e6fcd..215f5a538c78 100644
>> --- a/drivers/base/power/opp/of.c
>> +++ b/drivers/base/power/opp/of.c
>> @@ -198,7 +198,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
>>  EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
>>
>>  /* Returns opp descriptor node for a device, caller must do of_node_put() */
>> -struct device_node *_of_get_opp_desc_node(struct device *dev)
>> +struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
>
> Export as well ?
>

Whoops, yes will need to do that. I'll give some time for comments on 
any other patches before sending v3.

Thanks,
Dave
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq

[Dave Gerlach]

Add the device tree bindings document for the TI CPUFreq/OPP driver
on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
to provide an opp-supported-hw property for each OPP to define when
it is available. This driver is responsible for reading and parsing
registers to determine which OPPs can be selectively enabled based
on the specific SoC in use by matching against the opp-supported-hw
data.

Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
v2->v3:
- Move ti,syscon-* properties under opp table instead of cpu node, as
  that is a better location for them.
- For the opp table do not use platform specific compatible strings
  but instead a operating-points-v2-ti-cpu

 .../devicetree/bindings/cpufreq/ti-cpufreq.txt     | 132 +++++++++++++++++++++
 1 file changed, 132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
new file mode 100644
index 000000000000..467ad29c75c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -0,0 +1,132 @@
+TI CPUFreq and OPP bindings
+================================
+
+Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
+families support different OPPs depending on the silicon variant in use.
+The ti_cpufreq driver can use revision and an efuse value from the SoC to
+provide the OPP framework with supported hardware information. This is
+used to determine which OPPs from the operating-points-v2 table get enabled
+when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be 'operating-points-v2-ti-cpu' for am335x, am43xx,
+	      and dra7xx/am57xx SoCs
+- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
+		   mask, and efuse register shift to get the relevant bits
+		   that describe OPP availability.
+- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
+
+Optional properties:
+--------------------
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: Two bitfields indicating:
+	1. Which revision of the SoC the OPP is supported by
+	2. Which eFuse bits indicate this OPP is available
+
+	A bitwise AND is performed against these values and if any bit
+	matches, the OPP gets enabled. Not providing the property for an
+	entry indicates that an OPP is always supported.
+
+Example:
+--------
+
+/* From arch/arm/boot/dts/am33xx.dtsi */
+cpus {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	cpu@0 {
+		compatible = "arm,cortex-a8";
+		device_type = "cpu";
+		reg = <0>;
+
+		operating-points-v2 = <&cpu0_opp_table>;
+
+		clocks = <&dpll_mpu_ck>;
+		clock-names = "cpu";
+
+		clock-latency = <300000>; /* From omap-cpufreq driver */
+	};
+};
+
+/*
+ * cpu0 has different OPPs depending on SoC revision and some on revisions
+ * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
+ */
+cpu0_opp_table: opp_table0 {
+	compatible = "operating-points-v2-ti-am3352-cpu";
+	ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
+	ti,syscon-rev = <&scm_conf 0x600>;
+
+	/*
+	 * The three following nodes are marked with opp-suspend
+	 * because they can not be enabled simultaneously on a
+	 * single SoC.
+	 */
+	opp50@300000000 {
+		opp-hz = /bits/ 64 <300000000>;
+		opp-microvolt = <950000 931000 969000>;
+		opp-supported-hw = <0x06 0x0010>;
+		opp-suspend;
+	};
+
+	opp100@275000000 {
+		opp-hz = /bits/ 64 <275000000>;
+		opp-microvolt = <1100000 1078000 1122000>;
+		opp-supported-hw = <0x01 0x00FF>;
+		opp-suspend;
+	};
+
+	opp100@300000000 {
+		opp-hz = /bits/ 64 <300000000>;
+		opp-microvolt = <1100000 1078000 1122000>;
+		opp-supported-hw = <0x06 0x0020>;
+		opp-suspend;
+	};
+
+	opp100@500000000 {
+		opp-hz = /bits/ 64 <500000000>;
+		opp-microvolt = <1100000 1078000 1122000>;
+		opp-supported-hw = <0x01 0xFFFF>;
+	};
+
+	opp100@600000000 {
+		opp-hz = /bits/ 64 <600000000>;
+		opp-microvolt = <1100000 1078000 1122000>;
+		opp-supported-hw = <0x06 0x0040>;
+	};
+
+	opp120@600000000 {
+		opp-hz = /bits/ 64 <600000000>;
+		opp-microvolt = <1200000 1176000 1224000>;
+		opp-supported-hw = <0x01 0xFFFF>;
+	};
+
+	opp120@720000000 {
+		opp-hz = /bits/ 64 <720000000>;
+		opp-microvolt = <1200000 1176000 1224000>;
+		opp-supported-hw = <0x06 0x0080>;
+	};
+
+	oppturbo@720000000 {
+		opp-hz = /bits/ 64 <720000000>;
+		opp-microvolt = <1260000 1234800 1285200>;
+		opp-supported-hw = <0x01 0xFFFF>;
+	};
+
+	oppturbo@800000000 {
+		opp-hz = /bits/ 64 <800000000>;
+		opp-microvolt = <1260000 1234800 1285200>;
+		opp-supported-hw = <0x06 0x0100>;
+	};
+
+	oppnitro@1000000000 {
+		opp-hz = /bits/ 64 <1000000000>;
+		opp-microvolt = <1325000 1298500 1351500>;
+		opp-supported-hw = <0x04 0x0200>;
+	};
+};
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq

[Viresh Kumar]

On 27-10-16, 16:41, Dave Gerlach wrote:
> Add the device tree bindings document for the TI CPUFreq/OPP driver
> on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
> to provide an opp-supported-hw property for each OPP to define when
> it is available. This driver is responsible for reading and parsing
> registers to determine which OPPs can be selectively enabled based
> on the specific SoC in use by matching against the opp-supported-hw
> data.
> 
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> v2->v3:
> - Move ti,syscon-* properties under opp table instead of cpu node, as
>   that is a better location for them.
> - For the opp table do not use platform specific compatible strings
>   but instead a operating-points-v2-ti-cpu
> 
>  .../devicetree/bindings/cpufreq/ti-cpufreq.txt     | 132 +++++++++++++++++++++
>  1 file changed, 132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> new file mode 100644
> index 000000000000..467ad29c75c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
> @@ -0,0 +1,132 @@
> +TI CPUFreq and OPP bindings
> +================================
> +
> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
> +families support different OPPs depending on the silicon variant in use.
> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
> +provide the OPP framework with supported hardware information. This is
> +used to determine which OPPs from the operating-points-v2 table get enabled
> +when it is parsed by the OPP framework.
> +
> +Required properties:
> +--------------------
> +In 'cpus' nodes:
> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
> +
> +In 'operating-points-v2' table:
> +- compatible: Should be 'operating-points-v2-ti-cpu' for am335x, am43xx,
> +	      and dra7xx/am57xx SoCs
> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
> +		   mask, and efuse register shift to get the relevant bits
> +		   that describe OPP availability.
> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
> +
> +Optional properties:
> +--------------------
> +For each opp entry in 'operating-points-v2' table:
> +- opp-supported-hw: Two bitfields indicating:
> +	1. Which revision of the SoC the OPP is supported by
> +	2. Which eFuse bits indicate this OPP is available
> +
> +	A bitwise AND is performed against these values and if any bit
> +	matches, the OPP gets enabled. Not providing the property for an
> +	entry indicates that an OPP is always supported.
> +
> +Example:
> +--------
> +
> +/* From arch/arm/boot/dts/am33xx.dtsi */
> +cpus {
> +	#address-cells = <1>;
> +	#size-cells = <0>;
> +	cpu@0 {
> +		compatible = "arm,cortex-a8";
> +		device_type = "cpu";
> +		reg = <0>;
> +
> +		operating-points-v2 = <&cpu0_opp_table>;
> +
> +		clocks = <&dpll_mpu_ck>;
> +		clock-names = "cpu";
> +
> +		clock-latency = <300000>; /* From omap-cpufreq driver */
> +	};
> +};
> +
> +/*
> + * cpu0 has different OPPs depending on SoC revision and some on revisions
> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
> + */
> +cpu0_opp_table: opp_table0 {
> +	compatible = "operating-points-v2-ti-am3352-cpu";
> +	ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
> +	ti,syscon-rev = <&scm_conf 0x600>;
> +
> +	/*
> +	 * The three following nodes are marked with opp-suspend
> +	 * because they can not be enabled simultaneously on a
> +	 * single SoC.
> +	 */
> +	opp50@300000000 {
> +		opp-hz = /bits/ 64 <300000000>;
> +		opp-microvolt = <950000 931000 969000>;
> +		opp-supported-hw = <0x06 0x0010>;
> +		opp-suspend;
> +	};
> +
> +	opp100@275000000 {
> +		opp-hz = /bits/ 64 <275000000>;
> +		opp-microvolt = <1100000 1078000 1122000>;
> +		opp-supported-hw = <0x01 0x00FF>;
> +		opp-suspend;
> +	};
> +
> +	opp100@300000000 {
> +		opp-hz = /bits/ 64 <300000000>;
> +		opp-microvolt = <1100000 1078000 1122000>;
> +		opp-supported-hw = <0x06 0x0020>;
> +		opp-suspend;

Only one OPP in the table can be marked as suspend OPP.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq

[Dave Gerlach]

Hi,
On 11/01/2016 10:59 PM, Viresh Kumar wrote:
> On 27-10-16, 16:41, Dave Gerlach wrote:
>> Add the device tree bindings document for the TI CPUFreq/OPP driver
>> on AM33xx and AM43xx SoCs. The operating-points-v2 binding allows us
>> to provide an opp-supported-hw property for each OPP to define when
>> it is available. This driver is responsible for reading and parsing
>> registers to determine which OPPs can be selectively enabled based
>> on the specific SoC in use by matching against the opp-supported-hw
>> data.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
>> ---
>> v2->v3:
>> - Move ti,syscon-* properties under opp table instead of cpu node, as
>>   that is a better location for them.
>> - For the opp table do not use platform specific compatible strings
>>   but instead a operating-points-v2-ti-cpu
>>
>>  .../devicetree/bindings/cpufreq/ti-cpufreq.txt     | 132 +++++++++++++++++++++
>>  1 file changed, 132 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>>
>> diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> new file mode 100644
>> index 000000000000..467ad29c75c9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
>> @@ -0,0 +1,132 @@
>> +TI CPUFreq and OPP bindings
>> +================================
>> +
>> +Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
>> +families support different OPPs depending on the silicon variant in use.
>> +The ti_cpufreq driver can use revision and an efuse value from the SoC to
>> +provide the OPP framework with supported hardware information. This is
>> +used to determine which OPPs from the operating-points-v2 table get enabled
>> +when it is parsed by the OPP framework.
>> +
>> +Required properties:
>> +--------------------
>> +In 'cpus' nodes:
>> +- operating-points-v2: Phandle to the operating-points-v2 table to use.
>> +
>> +In 'operating-points-v2' table:
>> +- compatible: Should be 'operating-points-v2-ti-cpu' for am335x, am43xx,
>> +	      and dra7xx/am57xx SoCs
>> +- ti,syscon-efuse: Syscon phandle, offset to efuse register, efuse register
>> +		   mask, and efuse register shift to get the relevant bits
>> +		   that describe OPP availability.
>> +- ti,syscon-rev: Syscon and offset used to look up revision value on SoC.
>> +
>> +Optional properties:
>> +--------------------
>> +For each opp entry in 'operating-points-v2' table:
>> +- opp-supported-hw: Two bitfields indicating:
>> +	1. Which revision of the SoC the OPP is supported by
>> +	2. Which eFuse bits indicate this OPP is available
>> +
>> +	A bitwise AND is performed against these values and if any bit
>> +	matches, the OPP gets enabled. Not providing the property for an
>> +	entry indicates that an OPP is always supported.
>> +
>> +Example:
>> +--------
>> +
>> +/* From arch/arm/boot/dts/am33xx.dtsi */
>> +cpus {
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	cpu@0 {
>> +		compatible = "arm,cortex-a8";
>> +		device_type = "cpu";
>> +		reg = <0>;
>> +
>> +		operating-points-v2 = <&cpu0_opp_table>;
>> +
>> +		clocks = <&dpll_mpu_ck>;
>> +		clock-names = "cpu";
>> +
>> +		clock-latency = <300000>; /* From omap-cpufreq driver */
>> +	};
>> +};
>> +
>> +/*
>> + * cpu0 has different OPPs depending on SoC revision and some on revisions
>> + * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
>> + */
>> +cpu0_opp_table: opp_table0 {
>> +	compatible = "operating-points-v2-ti-am3352-cpu";
>> +	ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
>> +	ti,syscon-rev = <&scm_conf 0x600>;
>> +
>> +	/*
>> +	 * The three following nodes are marked with opp-suspend
>> +	 * because they can not be enabled simultaneously on a
>> +	 * single SoC.
>> +	 */
>> +	opp50@300000000 {
>> +		opp-hz = /bits/ 64 <300000000>;
>> +		opp-microvolt = <950000 931000 969000>;
>> +		opp-supported-hw = <0x06 0x0010>;
>> +		opp-suspend;
>> +	};
>> +
>> +	opp100@275000000 {
>> +		opp-hz = /bits/ 64 <275000000>;
>> +		opp-microvolt = <1100000 1078000 1122000>;
>> +		opp-supported-hw = <0x01 0x00FF>;
>> +		opp-suspend;
>> +	};
>> +
>> +	opp100@300000000 {
>> +		opp-hz = /bits/ 64 <300000000>;
>> +		opp-microvolt = <1100000 1078000 1122000>;
>> +		opp-supported-hw = <0x06 0x0020>;
>> +		opp-suspend;
>
> Only one OPP in the table can be marked as suspend OPP.
>

Does that still apply when opp-supported-hw is involved? Based on the 
comment at the start of the table, those OPPs are all mutually exclusive 
and will not ever be enabled on the same piece of silicon, they 
represent the lowest OPP for each of three different supported-hw 
configurations.

Regards,
Dave

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/3] Documentation: dt: add bindings for ti-cpufreq

[Viresh Kumar]

On 02-11-16, 11:03, Dave Gerlach wrote:
> >>+cpu0_opp_table: opp_table0 {
> >>+	compatible = "operating-points-v2-ti-am3352-cpu";
> >>+	ti,syscon-efuse = <&scm_conf 0x7fc 0x1fff 0>;
> >>+	ti,syscon-rev = <&scm_conf 0x600>;
> >>+
> >>+	/*
> >>+	 * The three following nodes are marked with opp-suspend
> >>+	 * because they can not be enabled simultaneously on a
> >>+	 * single SoC.
> >>+	 */

I missed reading this comment :(

>>+	opp50@300000000 {
> >>+		opp-hz = /bits/ 64 <300000000>;
> >>+		opp-microvolt = <950000 931000 969000>;
> >>+		opp-supported-hw = <0x06 0x0010>;
> >>+		opp-suspend;
> >>+	};
> >>+
> >>+	opp100@275000000 {
> >>+		opp-hz = /bits/ 64 <275000000>;
> >>+		opp-microvolt = <1100000 1078000 1122000>;
> >>+		opp-supported-hw = <0x01 0x00FF>;
> >>+		opp-suspend;
> >>+	};
> >>+
> >>+	opp100@300000000 {
> >>+		opp-hz = /bits/ 64 <300000000>;
> >>+		opp-microvolt = <1100000 1078000 1122000>;
> >>+		opp-supported-hw = <0x06 0x0020>;
> >>+		opp-suspend;
> >
> >Only one OPP in the table can be marked as suspend OPP.
> >
> 
> Does that still apply when opp-supported-hw is involved? Based on the
> comment at the start of the table, those OPPs are all mutually exclusive and
> will not ever be enabled on the same piece of silicon, they represent the
> lowest OPP for each of three different supported-hw configurations.

You are right, its fine.

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/3] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

[Dave Gerlach]

Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
have different OPPs available for the MPU depending on which specific
variant of the SoC is in use. This can be determined through use of the
revision and an eFuse register present in the silicon. Introduce a
ti-cpufreq driver that can read the aformentioned values and provide
them as version matching data to the opp framework. Through this the
opp-supported-hw dt binding that is part of the operating-points-v2
table can be used to indicate availability of OPPs for each device.

This driver also creates the "cpufreq-dt" platform_device after passing
the version matching data to the OPP framework so that the cpufreq-dt
handles the actual cpufreq implementation. Even without the necessary
data to pass the version matching data the driver will still create this
device to maintain backwards compatibility with operating-points v1
tables.

Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
v2-v3:
 - Use common ti compatible as described in binding and then match
   against machine type for platform data.
 - Use newly exposed dev_pm_opp_of_get_opp_desc_node to get
   operating-points-v2 table now that properties needed by driver are
   there.
 - Parse syscon properties from operating-points-v2 node rather
   than cpu node.
 - Do not make ti-cpufreq a module-platform-driver and do not allow
   building as module.

 drivers/cpufreq/Kconfig.arm  |  11 ++
 drivers/cpufreq/Makefile     |   1 +
 drivers/cpufreq/ti-cpufreq.c | 288 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 300 insertions(+)
 create mode 100644 drivers/cpufreq/ti-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index d89b8afe23b6..665f11dbdaef 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -234,6 +234,17 @@ config ARM_TEGRA124_CPUFREQ
 	help
 	  This adds the CPUFreq driver support for Tegra124 SOCs.
 
+config ARM_TI_CPUFREQ
+	bool "Texas Instruments CPUFreq support"
+	depends on ARCH_OMAP2PLUS
+	help
+	  This driver enables valid OPPs on the running platform based on
+	  values contained within the SoC in use. Enable this in order to
+	  use the cpufreq-dt driver on all Texas Instruments platforms that
+	  provide dt based operating-points-v2 tables with opp-supported-hw
+	  data provided. Required for cpufreq support on AM335x, AM437x,
+	  DRA7x, and AM57x platforms.
+
 config ARM_PXA2xx_CPUFREQ
 	tristate "Intel PXA2xx CPUfreq driver"
 	depends on PXA27x || PXA25x
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 0a9b6a093646..5b1b6ec0a9f0 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_ARM_SPEAR_CPUFREQ)		+= spear-cpufreq.o
 obj-$(CONFIG_ARM_STI_CPUFREQ)		+= sti-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)	+= tegra20-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA124_CPUFREQ)	+= tegra124-cpufreq.o
+obj-$(CONFIG_ARM_TI_CPUFREQ)		+= ti-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ)	+= vexpress-spc-cpufreq.o
 obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
 obj-$(CONFIG_MACH_MVEBU_V7)		+= mvebu-cpufreq.o
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
new file mode 100644
index 000000000000..afbaef967b65
--- /dev/null
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -0,0 +1,288 @@
+/*
+ * TI CPUFreq/OPP hw-supported driver
+ *
+ * Copyright (C) 2016 Texas Instruments, Inc.
+ *	 Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/cpu.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_opp.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define REVISION_MASK				0xF
+#define REVISION_SHIFT				28
+
+#define AM33XX_800M_ARM_MPU_MAX_FREQ		0x1E2F
+#define AM43XX_600M_ARM_MPU_MAX_FREQ		0xFFA
+
+#define DRA7_EFUSE_HAS_OD_MPU_OPP		11
+#define DRA7_EFUSE_HAS_HIGH_MPU_OPP		15
+#define DRA7_EFUSE_HAS_ALL_MPU_OPP		23
+
+#define DRA7_EFUSE_NOM_MPU_OPP			BIT(0)
+#define DRA7_EFUSE_OD_MPU_OPP			BIT(1)
+#define DRA7_EFUSE_HIGH_MPU_OPP			BIT(2)
+
+#define VERSION_COUNT				2
+
+struct ti_cpufreq_data;
+
+struct ti_cpufreq_soc_data {
+	unsigned long (*efuse_xlate)(struct ti_cpufreq_data *opp_data,
+				     unsigned long efuse);
+	unsigned long efuse_fallback;
+};
+
+struct ti_cpufreq_data {
+	struct device *cpu_dev;
+	struct device_node *opp_node;
+	struct regmap *opp_efuse;
+	struct regmap *revision;
+	const struct ti_cpufreq_soc_data *soc_data;
+};
+
+static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+				      unsigned long efuse)
+{
+	if (!efuse)
+		efuse = opp_data->soc_data->efuse_fallback;
+	/* AM335x and AM437x use "OPP disable" bits, so invert */
+	return ~efuse;
+}
+
+static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data *opp_data,
+				      unsigned long efuse)
+{
+	unsigned long calculated_efuse = DRA7_EFUSE_NOM_MPU_OPP;
+
+	/*
+	 * The efuse on dra7 and am57 parts contains a specific
+	 * value indicating the highest available OPP.
+	 */
+
+	switch (efuse) {
+	case DRA7_EFUSE_HAS_ALL_MPU_OPP:
+	case DRA7_EFUSE_HAS_HIGH_MPU_OPP:
+		calculated_efuse |= DRA7_EFUSE_HIGH_MPU_OPP;
+	case DRA7_EFUSE_HAS_OD_MPU_OPP:
+		calculated_efuse |= DRA7_EFUSE_OD_MPU_OPP;
+	}
+
+	return calculated_efuse;
+}
+
+static struct ti_cpufreq_soc_data am3x_soc_data = {
+	.efuse_xlate = amx3_efuse_xlate,
+	.efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,
+};
+
+static struct ti_cpufreq_soc_data am4x_soc_data = {
+	.efuse_xlate = amx3_efuse_xlate,
+	.efuse_fallback = AM43XX_600M_ARM_MPU_MAX_FREQ,
+};
+
+static struct ti_cpufreq_soc_data dra7_soc_data = {
+	.efuse_xlate = dra7_efuse_xlate,
+};
+
+/**
+ * ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @efuse_value: Set to the value parsed from efuse
+ *
+ * Returns error code if efuse not read properly.
+ */
+static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
+				u32 *efuse_value)
+{
+	struct device *dev = opp_data->cpu_dev;
+	struct device_node *np = opp_data->opp_node;
+	unsigned int efuse_offset;
+	u32 efuse, efuse_mask, efuse_shift, vals[4];
+	int ret;
+
+	ret = of_property_read_u32_array(np, "ti,syscon-efuse", vals, 4);
+	if (ret) {
+		dev_err(dev, "ti,syscon-efuse cannot be read %s: %d\n",
+			np->full_name, ret);
+		return ret;
+	}
+
+	efuse_offset = vals[1];
+	efuse_mask = vals[2];
+	efuse_shift = vals[3];
+
+	ret = regmap_read(opp_data->opp_efuse, efuse_offset, &efuse);
+	if (ret) {
+		dev_err(dev,
+			"Failed to read the efuse value from syscon: %d\n",
+			ret);
+		return ret;
+	}
+
+	efuse = (efuse & efuse_mask) >> efuse_shift;
+
+	*efuse_value = opp_data->soc_data->efuse_xlate(opp_data, efuse);
+
+	return 0;
+}
+
+/**
+ * ti_cpufreq_get_rev() - Parse and return rev value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @revision_value: Set to the value parsed from revision register
+ *
+ * Returns error code if revision not read properly.
+ */
+static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
+			      u32 *revision_value)
+{
+	struct device *dev = opp_data->cpu_dev;
+	struct device_node *np = opp_data->opp_node;
+	unsigned int revision_offset;
+	u32 revision;
+	int ret;
+
+	ret = of_property_read_u32_index(np, "ti,syscon-rev",
+					 1, &revision_offset);
+	if (ret) {
+		dev_err(dev,
+			"No revision offset provided %s [%d]\n",
+			np->full_name, ret);
+		return ret;
+	}
+
+	ret = regmap_read(opp_data->revision, revision_offset, &revision);
+	if (ret) {
+		dev_err(dev,
+			"Failed to read the revision number from syscon: %d\n",
+			ret);
+		return ret;
+	}
+
+	*revision_value = BIT((revision >> REVISION_SHIFT) & REVISION_MASK);
+
+	return 0;
+}
+
+static int ti_cpufreq_setup_syscon_registers(struct ti_cpufreq_data *opp_data)
+{
+	struct device *dev = opp_data->cpu_dev;
+	struct device_node *np = opp_data->opp_node;
+
+	opp_data->opp_efuse = syscon_regmap_lookup_by_phandle(np,
+							"ti,syscon-efuse");
+	if (IS_ERR(opp_data->opp_efuse)) {
+		dev_err(dev,
+			"\"ti,syscon-efuse\" is missing, cannot use OPPv2 table.\n");
+		return PTR_ERR(opp_data->opp_efuse);
+	}
+
+	opp_data->revision = syscon_regmap_lookup_by_phandle(np,
+							"ti,syscon-rev");
+	if (IS_ERR(opp_data->revision)) {
+		dev_err(dev,
+			"\"ti,syscon-rev\" is missing, cannot use OPPv2 table.\n");
+		return PTR_ERR(opp_data->revision);
+	}
+
+	return 0;
+}
+
+static const struct of_device_id ti_cpufreq_of_match[] = {
+	{ .compatible = "ti,am33xx", .data = &am3x_soc_data, },
+	{ .compatible = "ti,am4372", .data = &am4x_soc_data, },
+	{ .compatible = "ti,dra7", .data = &dra7_soc_data },
+	{},
+};
+
+static int ti_cpufreq_init(void)
+{
+	u32 version[VERSION_COUNT];
+	struct device_node *np;
+	const struct of_device_id *match;
+	struct ti_cpufreq_data *opp_data;
+	int ret;
+
+	np = of_find_node_by_path("/");
+	match = of_match_node(ti_cpufreq_of_match, np);
+	if (!match)
+		return -ENODEV;
+
+	opp_data = kzalloc(sizeof(*opp_data), GFP_KERNEL);
+	if (!opp_data)
+		return -ENOMEM;
+
+	opp_data->soc_data = match->data;
+
+	opp_data->cpu_dev = get_cpu_device(0);
+	if (!opp_data->cpu_dev) {
+		pr_err("%s: Failed to get device for CPU0\n", __func__);
+		return -ENODEV;
+	}
+
+	opp_data->opp_node = dev_pm_opp_of_get_opp_desc_node(opp_data->cpu_dev);
+	if (!opp_data->opp_node) {
+		dev_info(opp_data->cpu_dev,
+			 "OPP-v2 not supported, cpufreq-dt will attempt to use legacy tables.\n");
+		goto register_cpufreq_dt;
+	}
+
+	ret = ti_cpufreq_setup_syscon_registers(opp_data);
+	if (ret)
+		goto fail_put_node;
+
+	/*
+	 * OPPs determine whether or not they are supported based on
+	 * two metrics:
+	 *	0 - SoC Revision
+	 *	1 - eFuse value
+	 */
+	ret = ti_cpufreq_get_rev(opp_data, &version[0]);
+	if (ret)
+		goto fail_put_node;
+
+	ret = ti_cpufreq_get_efuse(opp_data, &version[1]);
+	if (ret)
+		goto fail_put_node;
+
+	of_node_put(opp_data->opp_node);
+
+	ret = dev_pm_opp_set_supported_hw(opp_data->cpu_dev, version,
+					  VERSION_COUNT);
+	if (ret) {
+		dev_err(opp_data->cpu_dev,
+			"Failed to set supported hardware\n");
+		goto fail_put_node;
+	}
+
+register_cpufreq_dt:
+	platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+
+	return 0;
+
+fail_put_node:
+	of_node_put(opp_data->opp_node);
+
+	return ret;
+}
+module_init(ti_cpufreq_init);
+
+MODULE_DESCRIPTION("TI CPUFreq/OPP hw-supported driver");
+MODULE_AUTHOR("Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 3/3] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime

[Viresh Kumar]

On 27-10-16, 16:41, Dave Gerlach wrote:
> Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
> have different OPPs available for the MPU depending on which specific
> variant of the SoC is in use. This can be determined through use of the
> revision and an eFuse register present in the silicon. Introduce a
> ti-cpufreq driver that can read the aformentioned values and provide
> them as version matching data to the opp framework. Through this the
> opp-supported-hw dt binding that is part of the operating-points-v2
> table can be used to indicate availability of OPPs for each device.
> 
> This driver also creates the "cpufreq-dt" platform_device after passing
> the version matching data to the OPP framework so that the cpufreq-dt
> handles the actual cpufreq implementation. Even without the necessary
> data to pass the version matching data the driver will still create this
> device to maintain backwards compatibility with operating-points v1
> tables.
> 
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> v2-v3:
>  - Use common ti compatible as described in binding and then match
>    against machine type for platform data.
>  - Use newly exposed dev_pm_opp_of_get_opp_desc_node to get
>    operating-points-v2 table now that properties needed by driver are
>    there.
>  - Parse syscon properties from operating-points-v2 node rather
>    than cpu node.
>  - Do not make ti-cpufreq a module-platform-driver and do not allow
>    building as module.
> 
>  drivers/cpufreq/Kconfig.arm  |  11 ++
>  drivers/cpufreq/Makefile     |   1 +
>  drivers/cpufreq/ti-cpufreq.c | 288 +++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 300 insertions(+)
>  create mode 100644 drivers/cpufreq/ti-cpufreq.c

Acked-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

-- 
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html