On 30/05/14 19:15, Tomasz Figa wrote:
On 30.05.2014 20:05, Thomas Abraham wrote:
Hi Mark,
On Fri, May 30, 2014 at 6:38 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
Hi,
Apologies for being somewhat late w.r.t. review on this.
On Fri, May 30, 2014 at 10:01:17AM +0100, Thomas Abraham wrote:
From: Thomas Abraham <thomas.ab@xxxxxxxxxxx>
Add a new optional boost-frequency binding for specifying the frequencies
usable in boost mode.
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: Pawel Moll <pawel.moll@xxxxxxx>
Cc: Mark Rutland <mark.rutland@xxxxxxx>
Cc: Ian Campbell <ijc+devicetree@xxxxxxxxxxxxxx>
Cc: Kumar Gala <galak@xxxxxxxxxxxxxx>
Signed-off-by: Thomas Abraham <thomas.ab@xxxxxxxxxxx>
Acked-by: Viresh Kumar <viresh.kumar@xxxxxxxxxx>
Acked-by: Nishanth Menon <nm@xxxxxx>
Acked-by: Lukasz Majewski <l.majewski@xxxxxxxxxxx>
---
.../devicetree/bindings/cpufreq/cpufreq-boost.txt | 38 ++++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
new file mode 100644
index 0000000..63ed0fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-boost.txt
@@ -0,0 +1,38 @@
+* Device tree binding for CPU boost frequency (aka over-clocking)
+
+Certain CPU's can be operated in optional 'boost' mode (or sometimes referred as
Nit: CPUs (we're not greengrocers [1])
+overclocking) in which the CPU can operate at frequencies which are not
+specified by the manufacturer as CPU's operating frequency.
+
+Optional Properties:
+- boost-frequencies: list of frequencies in KHz to be used only in boost mode.
+ This list should be a subset of frequencies listed in "operating-points"
+ property. Refer to Documentation/devicetree/bindings/power/opp.txt for
+ details about "operating-points" property.
What is 'boost-mode'?
boost-mode activates additional one or more cpu clock speeds (which
are not specified as operating frequency of the cpu by the
manufacturer). The cpu is allowed to operate in these boost mode
speeds when the boost mode is active. The boost mode speeds are
usually undocumented. Some of the chip samples could be clocked in
boost mode speeds and only such samples can be safely operated in
boost mode.
IMHO the most important part that I believe should be stated in the
documentation is that CPU usually can operate in boost mode for limited
amount of time, which depends on thermal conditions, which makes the
boost operating points separate from normal ones, which can be used at
any time.
Yes exactly what I mentioned couple of times on previous version of this
patch set[1][2]
The mechanism of entry into and exit out of boost mode is outside the
scope of this documentation.
What are the limitations on boost frequencies? When is a CPU expected to
go to these frequencies and for now long? When should I as a dt author
place elements in boost-frequencies?
I will add these details in the next revision of this patch.
Why are these in both operating-points and boost-frequencies? It'll be
really easy to accidentally forget to mark something as a
boost-frequency this way. Why not have a boost-points instead?
I was told that index is not preferred based on the previous discussions
when the OPP bindings were designed. In addition the OPP binding doesn't
enforce any ordering. There are thermal bindings that assume otherwise and
is broken. So boost-points is not feasible.
Does boost-points mean a set of clock speeds which are not listed as
part of operating-points property? If yes, that also is a possible
implementation (it was implemented in one of the earlier version of
this series). Could you confirm that you want the boost mode speeds to
be exclusive of the speeds listed in operating-points?
It seems reasonable to have boost operating points completely separate
from normal ones, so that a kernel without support for boost mode will
not use them. Also considering my comment above, logically boost
operating points are not considered normal operating points, due to
various constraints that need to be met to use them (i.e. mostly thermal
conditions).
IMO, at-least the existing OPP binding can't distinguish between under-,
nominal- and over-drive OPP points. So my suggestion was to have a property
that provides the beginning of these 3 points on the OPP curve.
Regards,
Sudeep
[1] https://www.mail-archive.com/linux-samsung-soc@xxxxxxxxxxxxxxx/msg26250.html
[2] http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/31552
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
