| Message ID | 1528109194-16864-2-git-send-email-tdas@codeaurora.org (mailing list archive) |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
On Mon, Jun 04, 2018 at 04:16:33PM +0530, Taniya Das wrote: > Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's > SoCs. This is required for managing the cpu frequency transitions which are > controlled by firmware. > > Signed-off-by: Taniya Das <tdas@codeaurora.org> > --- > .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 +++++++++++++++++++++ > 1 file changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > new file mode 100644 > index 0000000..e3087ec > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > @@ -0,0 +1,173 @@ > +Qualcomm Technologies, Inc. CPUFREQ Bindings > + > +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) > +SoCs to manage frequency in hardware. It is capable of controlling frequency > +for multiple clusters. > + > +Properties: > +- compatible > + Usage: required > + Value type: <string> > + Definition: must be "qcom,cpufreq-fw". > + > +* Property qcom,freq-domain > +Devices supporting freq-domain must set their "qcom,freq-domain" property with > +phandle to a freq_domain_table in their DT node. > + > +* Frequency Domain Table Node > + > +This describes the frequency domain belonging to a device. > +This node can have following properties: > + > +- reg > + Usage: required > + Value type: <prop-encoded-array> > + Definition: Addresses and sizes for the memory of the perf > + , lut and enable bases. > + perf - indicates the base address for the desired > + performance state to be set. > + lut - indicates the look up table base address for the > + cpufreq driver to read frequencies. > + enable - indicates the enable register for firmware. > +- reg-names > + Usage: required > + Value type: <stringlist> > + Definition: Address names. Must be "perf", "lut", "enable". > + Must be specified in the same order as the reg property. > + [...] > + > + qcom,cpufreq-fw { > + compatible = "qcom,cpufreq-fw"; > + > + #address-cells = <1>; > + #size-cells = <1>; > + > + freq_domain_table0 : freq_table0 { > + reg = <0x17d43920 0x4>, <0x17d43110 0x500>, > + <0x17d41000 0x4>; Are "perf", "lut", "enable" registers part of single IP block / share memory ? I am just trying to understand the reason for separate entries in this fashion as part of DT register property. I am wondering if there will be multiple entries that fall with the page size. -- Regards, Sudeep
On 04-06-18, 16:16, Taniya Das wrote: > Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's > SoCs. This is required for managing the cpu frequency transitions which are > controlled by firmware. > > Signed-off-by: Taniya Das <tdas@codeaurora.org> > --- > .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 +++++++++++++++++++++ > 1 file changed, 173 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > new file mode 100644 > index 0000000..e3087ec > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt > @@ -0,0 +1,173 @@ > +Qualcomm Technologies, Inc. CPUFREQ Bindings > + > +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) > +SoCs to manage frequency in hardware. It is capable of controlling frequency > +for multiple clusters. > + > +Properties: > +- compatible > + Usage: required > + Value type: <string> > + Definition: must be "qcom,cpufreq-fw". > + > +* Property qcom,freq-domain > +Devices supporting freq-domain must set their "qcom,freq-domain" property with > +phandle to a freq_domain_table in their DT node. > + > +* Frequency Domain Table Node > + > +This describes the frequency domain belonging to a device. > +This node can have following properties: > + > +- reg > + Usage: required > + Value type: <prop-encoded-array> > + Definition: Addresses and sizes for the memory of the perf > + , lut and enable bases. > + perf - indicates the base address for the desired > + performance state to be set. > + lut - indicates the look up table base address for the > + cpufreq driver to read frequencies. > + enable - indicates the enable register for firmware. > +- reg-names > + Usage: required > + Value type: <stringlist> > + Definition: Address names. Must be "perf", "lut", "enable". > + Must be specified in the same order as the reg property. > + > +Example: > + > +Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch > +DCVS state together. > + > +/ { > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + CPU0: cpu@0 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x0>; > + enable-method = "psci"; > + next-level-cache = <&L2_0>; > + qcom,freq-domain = <&freq_domain_table0>; > + L2_0: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + L3_0: l3-cache { > + compatible = "cache"; > + }; > + }; > + }; > + > + CPU1: cpu@100 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x100>; > + enable-method = "psci"; > + next-level-cache = <&L2_100>; > + qcom,freq-domain = <&freq_domain_table0>; > + L2_100: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU2: cpu@200 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x200>; > + enable-method = "psci"; > + next-level-cache = <&L2_200>; > + qcom,freq-domain = <&freq_domain_table0>; > + L2_200: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU3: cpu@300 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x300>; > + enable-method = "psci"; > + next-level-cache = <&L2_300>; > + qcom,freq-domain = <&freq_domain_table0>; > + L2_300: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU4: cpu@400 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x400>; > + enable-method = "psci"; > + next-level-cache = <&L2_400>; > + qcom,freq-domain = <&freq_domain_table1>; > + L2_400: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU5: cpu@500 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x500>; > + enable-method = "psci"; > + next-level-cache = <&L2_500>; > + qcom,freq-domain = <&freq_domain_table1>; > + L2_500: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU6: cpu@600 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x600>; > + enable-method = "psci"; > + next-level-cache = <&L2_600>; > + qcom,freq-domain = <&freq_domain_table1>; > + L2_600: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU7: cpu@700 { > + device_type = "cpu"; > + compatible = "qcom,kryo385"; > + reg = <0x0 0x700>; > + enable-method = "psci"; > + next-level-cache = <&L2_700>; > + qcom,freq-domain = <&freq_domain_table1>; > + L2_700: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + }; > + > + qcom,cpufreq-fw { > + compatible = "qcom,cpufreq-fw"; > + > + #address-cells = <1>; > + #size-cells = <1>; > + > + freq_domain_table0 : freq_table0 { > + reg = <0x17d43920 0x4>, <0x17d43110 0x500>, > + <0x17d41000 0x4>; > + reg-names = "perf", "lut", "enable"; > + }; > + > + freq_domain_table1 : freq_table1 { > + reg = <0x17d46120 0x4>, <0x17d45910 0x500>, > + <0x17d45800 0x4> ; > + reg-names = "perf", "lut", "enable"; > + }; > + }; Looks better now from design point of view now, no ugly CPU lists :) Unless Rob finds something wrong with the bindings: Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Hello Sudeep, Thanks for the review comments. On 6/4/2018 4:25 PM, Sudeep Holla wrote: > On Mon, Jun 04, 2018 at 04:16:33PM +0530, Taniya Das wrote: >> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's >> SoCs. This is required for managing the cpu frequency transitions which are >> controlled by firmware. >> >> Signed-off-by: Taniya Das <tdas@codeaurora.org> >> --- >> .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 +++++++++++++++++++++ >> 1 file changed, 173 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >> >> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >> new file mode 100644 >> index 0000000..e3087ec >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >> @@ -0,0 +1,173 @@ >> +Qualcomm Technologies, Inc. CPUFREQ Bindings >> + >> +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) >> +SoCs to manage frequency in hardware. It is capable of controlling frequency >> +for multiple clusters. >> + >> +Properties: >> +- compatible >> + Usage: required >> + Value type: <string> >> + Definition: must be "qcom,cpufreq-fw". >> + >> +* Property qcom,freq-domain >> +Devices supporting freq-domain must set their "qcom,freq-domain" property with >> +phandle to a freq_domain_table in their DT node. >> + >> +* Frequency Domain Table Node >> + >> +This describes the frequency domain belonging to a device. >> +This node can have following properties: >> + >> +- reg >> + Usage: required >> + Value type: <prop-encoded-array> >> + Definition: Addresses and sizes for the memory of the perf >> + , lut and enable bases. >> + perf - indicates the base address for the desired >> + performance state to be set. >> + lut - indicates the look up table base address for the >> + cpufreq driver to read frequencies. >> + enable - indicates the enable register for firmware. >> +- reg-names >> + Usage: required >> + Value type: <stringlist> >> + Definition: Address names. Must be "perf", "lut", "enable". >> + Must be specified in the same order as the reg property. >> + > > [...] > >> + >> + qcom,cpufreq-fw { >> + compatible = "qcom,cpufreq-fw"; >> + >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + freq_domain_table0 : freq_table0 { >> + reg = <0x17d43920 0x4>, <0x17d43110 0x500>, >> + <0x17d41000 0x4>; > > Are "perf", "lut", "enable" registers part of single IP block / share memory ? > I am just trying to understand the reason for separate entries in this fashion > as part of DT register property. I am wondering if there will be multiple > entries that fall with the page size. > They are part of the same IP block and these are the only register offsets which is required to be accessed by HLOS. > -- > Regards, > Sudeep >
On 07/06/18 08:20, Taniya Das wrote: > Hello Sudeep, > > Thanks for the review comments. > > On 6/4/2018 4:25 PM, Sudeep Holla wrote: >> On Mon, Jun 04, 2018 at 04:16:33PM +0530, Taniya Das wrote: >>> Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's >>> SoCs. This is required for managing the cpu frequency transitions >>> which are >>> controlled by firmware. >>> >>> Signed-off-by: Taniya Das <tdas@codeaurora.org> >>> --- >>> .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 >>> +++++++++++++++++++++ >>> 1 file changed, 173 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >>> >>> diff --git >>> a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >>> b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >>> new file mode 100644 >>> index 0000000..e3087ec >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt >>> @@ -0,0 +1,173 @@ >>> +Qualcomm Technologies, Inc. CPUFREQ Bindings >>> + >>> +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, >>> Inc. (QTI) >>> +SoCs to manage frequency in hardware. It is capable of controlling >>> frequency >>> +for multiple clusters. >>> + >>> +Properties: >>> +- compatible >>> + Usage: required >>> + Value type: <string> >>> + Definition: must be "qcom,cpufreq-fw". >>> + >>> +* Property qcom,freq-domain >>> +Devices supporting freq-domain must set their "qcom,freq-domain" >>> property with >>> +phandle to a freq_domain_table in their DT node. >>> + >>> +* Frequency Domain Table Node >>> + >>> +This describes the frequency domain belonging to a device. >>> +This node can have following properties: >>> + >>> +- reg >>> + Usage: required >>> + Value type: <prop-encoded-array> >>> + Definition: Addresses and sizes for the memory of the perf >>> + , lut and enable bases. >>> + perf - indicates the base address for the desired >>> + performance state to be set. >>> + lut - indicates the look up table base address for the >>> + cpufreq driver to read frequencies. >>> + enable - indicates the enable register for firmware. >>> +- reg-names >>> + Usage: required >>> + Value type: <stringlist> >>> + Definition: Address names. Must be "perf", "lut", "enable". >>> + Must be specified in the same order as the reg property. >>> + >> >> [...] >> >>> + >>> + qcom,cpufreq-fw { >>> + compatible = "qcom,cpufreq-fw"; >>> + >>> + #address-cells = <1>; >>> + #size-cells = <1>; >>> + >>> + freq_domain_table0 : freq_table0 { >>> + reg = <0x17d43920 0x4>, <0x17d43110 0x500>, >>> + <0x17d41000 0x4>; >> >> Are "perf", "lut", "enable" registers part of single IP block / share >> memory ? >> I am just trying to understand the reason for separate entries in this >> fashion >> as part of DT register property. I am wondering if there will be multiple >> entries that fall with the page size. >> > > They are part of the same IP block and these are the only register > offsets which is required to be accessed by HLOS. > HLOS ? Anyways, OS might touch one or 2 registers in lots of IP blocks. I am not sure why those are any different from these. Are you trying to align with any other bindings or specification. Are you trying to make this binding generic here ? I understand if it was trying to generalize the firmware interface, but you state it's a hardware engine. So I fail to see the need for such specificity here. Why not define the whole IP block and the driver knows where to access these specific ones as they are specific to this hardware block.
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt new file mode 100644 index 0000000..e3087ec --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt @@ -0,0 +1,173 @@ +Qualcomm Technologies, Inc. CPUFREQ Bindings + +CPUFREQ FW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) +SoCs to manage frequency in hardware. It is capable of controlling frequency +for multiple clusters. + +Properties: +- compatible + Usage: required + Value type: <string> + Definition: must be "qcom,cpufreq-fw". + +* Property qcom,freq-domain +Devices supporting freq-domain must set their "qcom,freq-domain" property with +phandle to a freq_domain_table in their DT node. + +* Frequency Domain Table Node + +This describes the frequency domain belonging to a device. +This node can have following properties: + +- reg + Usage: required + Value type: <prop-encoded-array> + Definition: Addresses and sizes for the memory of the perf + , lut and enable bases. + perf - indicates the base address for the desired + performance state to be set. + lut - indicates the look up table base address for the + cpufreq driver to read frequencies. + enable - indicates the enable register for firmware. +- reg-names + Usage: required + Value type: <stringlist> + Definition: Address names. Must be "perf", "lut", "enable". + Must be specified in the same order as the reg property. + +Example: + +Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch +DCVS state together. + +/ { + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&L2_0>; + qcom,freq-domain = <&freq_domain_table0>; + L2_0: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + L3_0: l3-cache { + compatible = "cache"; + }; + }; + }; + + CPU1: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x100>; + enable-method = "psci"; + next-level-cache = <&L2_100>; + qcom,freq-domain = <&freq_domain_table0>; + L2_100: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU2: cpu@200 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x200>; + enable-method = "psci"; + next-level-cache = <&L2_200>; + qcom,freq-domain = <&freq_domain_table0>; + L2_200: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU3: cpu@300 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x300>; + enable-method = "psci"; + next-level-cache = <&L2_300>; + qcom,freq-domain = <&freq_domain_table0>; + L2_300: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU4: cpu@400 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x400>; + enable-method = "psci"; + next-level-cache = <&L2_400>; + qcom,freq-domain = <&freq_domain_table1>; + L2_400: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU5: cpu@500 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x500>; + enable-method = "psci"; + next-level-cache = <&L2_500>; + qcom,freq-domain = <&freq_domain_table1>; + L2_500: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU6: cpu@600 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x600>; + enable-method = "psci"; + next-level-cache = <&L2_600>; + qcom,freq-domain = <&freq_domain_table1>; + L2_600: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU7: cpu@700 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x700>; + enable-method = "psci"; + next-level-cache = <&L2_700>; + qcom,freq-domain = <&freq_domain_table1>; + L2_700: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + }; + + qcom,cpufreq-fw { + compatible = "qcom,cpufreq-fw"; + + #address-cells = <1>; + #size-cells = <1>; + + freq_domain_table0 : freq_table0 { + reg = <0x17d43920 0x4>, <0x17d43110 0x500>, + <0x17d41000 0x4>; + reg-names = "perf", "lut", "enable"; + }; + + freq_domain_table1 : freq_table1 { + reg = <0x17d46120 0x4>, <0x17d45910 0x500>, + <0x17d45800 0x4> ; + reg-names = "perf", "lut", "enable"; + }; + };
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's SoCs. This is required for managing the cpu frequency transitions which are controlled by firmware. Signed-off-by: Taniya Das <tdas@codeaurora.org> --- .../bindings/cpufreq/cpufreq-qcom-fw.txt | 173 +++++++++++++++++++++ 1 file changed, 173 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-fw.txt -- Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member of the Code Aurora Forum, hosted by the Linux Foundation.