All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Taniya Das <tdas@codeaurora.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Stephen Boyd <sboyd@kernel.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	devicetree@vger.kernel.org, skannan@codeaurora.org,
	linux-arm-msm@vger.kernel.org, amit.kucheria@linaro.org,
	evgreen@google.com
Subject: Re: [PATCH v10 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings
Date: Mon, 26 Nov 2018 12:58:08 -0600	[thread overview]
Message-ID: <20181126185808.GA32621@bogus> (raw)
In-Reply-To: <20181121180236.GS22824@google.com>

On Wed, Nov 21, 2018 at 10:02:36AM -0800, Matthias Kaehlcke wrote:
> On Wed, Nov 21, 2018 at 04:12:46PM +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 the hardware engine.
> > 
> > Signed-off-by: Taniya Das <tdas@codeaurora.org>
> > ---
> >  .../bindings/cpufreq/cpufreq-qcom-hw.txt           | 172 +++++++++++++++++++++
> >  1 file changed, 172 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> > new file mode 100644
> > index 0000000..90e396b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt
> > @@ -0,0 +1,172 @@
> > +Qualcomm Technologies, Inc. CPUFREQ Bindings
> > +
> > +CPUFREQ HW 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-hw".
> > +
> > +- clocks
> > +	Usage:		required
> > +	Value type:	<phandle> From common clock binding.
> > +	Definition:	clock handle for XO clock and GPLL0 clock.
> > +
> > +- clock-names
> > +	Usage:		required
> > +	Value type:	<string> From common clock binding.
> > +	Definition:	must be "xo", "cpu_clk".
> > +
> > +- reg
> > +	Usage:		required
> > +	Value type:	<prop-encoded-array>
> > +	Definition:	Addresses and sizes for the memory of the HW bases in
> > +			each frequency domain.
> > +- reg-names
> > +	Usage:		Optional
> > +	Value type:	<string>
> > +	Definition:	Frequency domain name i.e.
> > +			"freq-domain0", "freq-domain1".
> > +
> > +- freq-domain-cells:
> > +	Usage:		required.
> > +	Definition:	Number of cells in a freqency domain specifier.
> > +
> > +* Property qcom,freq-domain
> > +Devices supporting freq-domain must set their "qcom,freq-domain" property with
> > +phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node.
> > +
> > +
> > +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 = <&cpufreq_hw 0>;
> > +			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 = <&cpufreq_hw 0>;
> > +			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 = <&cpufreq_hw 0>;
> > +			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 = <&cpufreq_hw 0>;
> > +			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 = <&cpufreq_hw 1>;
> > +			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 = <&cpufreq_hw 1>;
> > +			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 = <&cpufreq_hw 1>;
> > +			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 = <&cpufreq_hw 1>;
> > +			L2_700: l2-cache {
> > +				compatible = "cache";
> > +				next-level-cache = <&L3_0>;
> > +			};
> > +		};
> > +	};
> > +
> > + soc {
> > +	cpufreq_hw: cpufreq@17d43000 {
> > +		compatible = "qcom,cpufreq-hw";
> > +		reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>;
> > +		reg-names = "freq-domain0", "freq-domain1";
> > +
> > +		clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
> > +		clock-names = "xo", "gcc_cpuss_gpll0_clk_src";
> 
> I don't have/find the document with the clock configuration of this
> IP block, but the 'clock-names' sound more like aliases for the actual
> clocks specified in the 'clocks' property (especially
> 'gcc_cpuss_gpll0_clk_src') than input signals from the IP POV, which
> I'd expect to have more generic names.

Also, this doesn't match the documented value above.

Rob

  reply	other threads:[~2018-11-26 18:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-21 10:42 [PATCH v10 0/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver Taniya Das
2018-11-21 10:42 ` [PATCH v10 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings Taniya Das
2018-11-21 18:02   ` Matthias Kaehlcke
2018-11-26 18:58     ` Rob Herring [this message]
2018-12-02  3:43       ` Taniya Das
2018-12-02  3:44     ` Taniya Das
2018-11-21 10:42 ` [PATCH v10 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver Taniya Das
2018-11-21 18:23   ` Stephen Boyd
2018-11-21 18:23     ` Stephen Boyd
2018-12-02  3:47     ` Taniya Das
2018-11-21 18:41   ` Matthias Kaehlcke
2018-12-02  3:46     ` Taniya Das
2018-11-21 22:06   ` Matthias Kaehlcke
2018-11-22  5:07     ` Viresh Kumar
2018-11-26 23:30       ` Matthias Kaehlcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181126185808.GA32621@bogus \
    --to=robh@kernel.org \
    --cc=amit.kucheria@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=evgreen@google.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mka@chromium.org \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@kernel.org \
    --cc=skannan@codeaurora.org \
    --cc=tdas@codeaurora.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.