[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140108142541.GK6701@e106331-lin.cambridge.arm.com>
Date: Wed, 8 Jan 2014 14:25:41 +0000
From: Mark Rutland <mark.rutland@....com>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
David Brown <davidb@...eaurora.org>,
Rohit Vaswani <rvaswani@...eaurora.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
Kumar Gala <galak@...eaurora.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Russell King <linux@....linux.org.uk>
Subject: Re: [PATCH v2 2/9] devicetree: bindings: Document qcom,kpss-acc
On Tue, Dec 24, 2013 at 12:39:46AM +0000, Stephen Boyd wrote:
> The kpss acc binding describes the clock, reset, and power domain
> controller for a Krait CPU.
>
> Cc: <devicetree@...r.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 30 ++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> new file mode 100644
> index 0000000..1333db9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> @@ -0,0 +1,30 @@
> +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
> +
> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
> +There is one ACC register region per CPU within the KPSS remapped region as
> +well as an alias register region that remaps accesses to the ACC associated
> +with the CPU accessing the region.
Is the mapping of ACC register to a specific processor well-defined? I
assume it's just in order of MPIDR.Aff0.
To maintain our collective sanity in the face of possible future
implementations, do you have an idea as to whether this might need to be
extended in future for multiple clusters / reordered IDs and so on?
I assume we'd just allocate a new compatible string if those get a
little crazy.
> +
> +PROPERTIES
> +
> +- compatible:
> + Usage: required
> + Value type: <string>
> + Definition: should be one of:
> + "qcom,kpss-acc-v1"
> + "qcom,kpss-acc-v2"
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: the first element specifies the base address and size of
> + the register region. An optional second element specifies
> + the base address and size of the alias register region.
> +
> +Example:
> +
> + clock-controller@...8000 {
> + compatible = "qcom,kpss-acc-v2";
> + reg = <0x02088000 0x1000>,
> + <0x02008000 0x1000>;
> + };
Otherwise, this looks fine to me.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists