| Message ID | 20170209153549.8354-1-d-gerlach@ti.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Delegated to: | Rafael Wysocki |
| Headers | show |
On Thu, Feb 9, 2017 at 9:35 AM, Dave Gerlach <d-gerlach@ti.com> wrote: > Add the device tree bindings document for the TI CPUFreq/OPP driver > on AM33xx, AM43xx, DRA7xx, and AM57xx 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. > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > --- > .../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++ > 1 file changed, 128 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt Acked-by: Rob Herring <robh@kernel.org> Rob -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 9, 2017 at 4:35 PM, Dave Gerlach <d-gerlach@ti.com> wrote: > Add the device tree bindings document for the TI CPUFreq/OPP driver > on AM33xx, AM43xx, DRA7xx, and AM57xx 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. > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Signed-off-by: Dave Gerlach <d-gerlach@ti.com> > --- I applied this (with the Rob's ACK) along with the rest of the series and I fixed up things that didn't apply and didn't build and I was not amused by that at all. In particular, Viresh, if you ACK something, please make sure that it doesn't conflict with your own patches. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09-02-17, 23:03, Rafael J. Wysocki wrote: > In particular, Viresh, if you ACK something, please make sure that it > doesn't conflict with your own patches. I hope you are talking about the patch 3/4 for which Arnd also sent a fix. I acked it back on 18th of January and Dave has been carrying my Ack since then. When he posted again, I didn't went into reviewing it again as I saw my Ack being there. Yes, he ended up using an API which just got updated after 18th of Jan and yes both me and Dave missed that. But I feel it is difficult to take care of scenarios like this. Perhaps he should have made sure that he base it of pm/linux-next and nothing would have gone wrong.
On Friday, February 10, 2017 08:43:49 AM Viresh Kumar wrote: > On 09-02-17, 23:03, Rafael J. Wysocki wrote: > > In particular, Viresh, if you ACK something, please make sure that it > > doesn't conflict with your own patches. > > I hope you are talking about the patch 3/4 for which Arnd also sent a > fix. I acked it back on 18th of January and Dave has been carrying my > Ack since then. When he posted again, I didn't went into reviewing it > again as I saw my Ack being there. Well, OK, but you did know that the OPP API had changed in the meantime, so it wouldn't have hurt to double check I suppose? > Yes, he ended up using an API which just got updated after 18th of Jan > and yes both me and Dave missed that. But I feel it is difficult to > take care of scenarios like this. Perhaps he should have made sure > that he base it of pm/linux-next and nothing would have gone wrong. Yes, that would help, but then how to enforce that? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/10/2017 06:28 AM, Rafael J. Wysocki wrote: > On Friday, February 10, 2017 08:43:49 AM Viresh Kumar wrote: >> On 09-02-17, 23:03, Rafael J. Wysocki wrote: >>> In particular, Viresh, if you ACK something, please make sure that it >>> doesn't conflict with your own patches. >> >> I hope you are talking about the patch 3/4 for which Arnd also sent a >> fix. I acked it back on 18th of January and Dave has been carrying my >> Ack since then. When he posted again, I didn't went into reviewing it >> again as I saw my Ack being there. > > Well, OK, but you did know that the OPP API had changed in the meantime, > so it wouldn't have hurt to double check I suppose? > >> Yes, he ended up using an API which just got updated after 18th of Jan >> and yes both me and Dave missed that. But I feel it is difficult to >> take care of scenarios like this. Perhaps he should have made sure >> that he base it of pm/linux-next and nothing would have gone wrong. > > Yes, that would help, but then how to enforce that? I apologize, I was unaware of the conflicting series. I'm not sure of a good way to enforce it but I do agree I will make sure to rebase and test against pm/linux-next before sending in the future. Regards, Dave > > Thanks, > Rafael > -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt new file mode 100644 index 000000000000..ba0e15ad5bd9 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt @@ -0,0 +1,128 @@ +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 +- syscon: A phandle pointing to a syscon node representing the control module + register space of the 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. + +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-table { + compatible = "operating-points-v2-ti-cpu"; + syscon = <&scm_conf>; + + /* + * 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>; + }; +};