linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: viresh.kumar@linaro.org (Viresh Kumar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 1/1] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation
Date: Thu, 23 Jul 2015 15:22:54 +0530	[thread overview]
Message-ID: <20150723095254.GN5322@linux> (raw)
In-Reply-To: <1437478420-26419-1-git-send-email-lee.jones@linaro.org>

Cc'ing few more people who were involved in opp-v2 discussions.

Guys, please take a closer look as this is the first user platform
that wants to extend opp-v2 bindings with platform specific stuff.

On 21-07-15, 12:33, Lee Jones wrote:
> Cc: devicetree at vger.kernel.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> 
> Only submitting the binding document as requested by Viresh.
> 
> v2 => v3:
>  - Using OPP v2
>  - Moved OPPs out of the CPU node into their own one
>  - Using generic 'opp-hz' property
> 
>  .../devicetree/bindings/cpufreq/cpufreq-st.txt     | 77 ++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt
> new file mode 100644
> index 0000000..a478eec
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-st.txt

These are used by cpufreq, but they aren't really cpufreq bindings.

These are opp bindings and must present at:
Documentation/devicetree/bindings/power/opp/st.txt and we should move
opp.txt in that folder as well..

> @@ -0,0 +1,77 @@
> +Binding for ST's CPUFreq driver
> +===============================
> +
> +Required properties [for working voltage scaling]:
> +-------------------------------------------------
> +
> +Located in CPU's node:

I hope below registers are used to define which OPPs are valid for the
CPU and so shouldn't these be present under opp node instead of CPU?

> +- st,syscfg		: Phandle to Major number register
> +				First cell: offset to major number
> +- st,syscfg-eng		: Phandle to Minor number and Pcode registers
> +				First cell: offset to process code
> +				Second cell: offset to minor number
> +
> +Located in 'cpu0-opp-list' node [to be provided ONLY by the bootloader]:
> +
> + - opp{1..N} 		: Each 'oppX' subnode will contain the following properties:
> +  - opp-hz		: CPU frequency [Hz] for this OPP

Not sure if you are required to re define it. In case you want to, the
please add a link here to the bindings that define it. So that we
don't think they are newer bindings.

> +  - st,avs		: List of available voltages [uV] indexed by process code
> +  - st,cuts		: Cut version this OPP is suitable for [0xFF means ALL]
> +  - st,substrate	: Substrate version this OPP is suitable for [0xFF means ALL]

@Stephen: Any idea if these can be relevant for other platforms and we
can move them to generic bindings?

> +WARNING: The cpu0-opp-list will be provided by the bootloader.  Do not attempt to
> +	 artificially synthesise the cpu0-opp-list node or any of its descendants.
> +	 They are very platform specific and may damage the hardware if created
> +	 incorrectly.
> +
> +Required properties [if voltage scaling properties are missing]:
> +-------------------------------------------------------------------
> +
> +Located in CPU's node:
> +
> +- operating-points	: [See: ../power/opp.txt]
> +
> +Example [safe]:
> +--------------
> +
> +cpus {
> +	cpu at 0 {
> +				 /* kHz     uV   */
> +		operating-points = <1500000 0
> +				    1200000 0
> +				    800000  0
> +				    500000  0>;
> +	};
> +};

Why do you want to keep these as well?

> +Example [unsafe]:
> +----------------
> +
> +cpus {
> +	cpu at 0 {
> +		st,syscfg		= <&syscfg [major_offset]>;
> +		st,syscfg-eng   	= <&syscfg_eng [pcode_offset] [minor_offset]>;
> +		operating-points-v2	= <&cpu0_opp_list>;
> +	};
> +};
> +
> +/* ############################################################ */
> +/* # WARNING: Do not attempt to copy/replicate this node,     # */
> +/* #          it is only to be supplied by the bootloader !!! # */
> +/* ############################################################ */
> +cpu0-opp-list {
> +	compatible = "operating-points-v2-sti";
> +	opp0 {
> +		opp-hz		= <1200000000>;
> +		st,avs		= <1110 1150 1100 1080 1040 1020 980 930>;
> +		st,substrate	= <0xff>;
> +		st,cuts		= <0xff>;
> +	};
> +	opp1 {
> +		opp-hz		= <1500000000>;
> +		st,avs		= <1200 1200 1200 1200 1170 1140 1100 1070>;
> +		st,substrate	= <0xff>;
> +		st,cuts		= <0x2>;
> +	};
> +};

-- 
viresh

  reply	other threads:[~2015-07-23  9:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-21 11:33 [PATCH v3 1/1] dt: cpufreq: st: Provide bindings for ST's CPUFreq implementation Lee Jones
2015-07-23  9:52 ` Viresh Kumar [this message]
2015-07-23 11:11   ` Lee Jones

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=20150723095254.GN5322@linux \
    --to=viresh.kumar@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).