diff mbox

[v2.1,1/9] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

Message ID 1461259256-28529-1-git-send-email-bjorn.andersson@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Bjorn Andersson April 21, 2016, 5:20 p.m. UTC
From: Bjorn Andersson <bjorn.andersson@sonymobile.com>

The document defines the binding for a component that loads firmware for
and boots the Qualcomm WCNSS core.

Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Rob,

I got your Ack on v2, but I would like to make a small amendment before merging
this.


As we discussed related to the WiFi binding I should reference the mmio
registers by a phandle to a DT node specifying the two necessary register
blocks (ccu & dxe).

These two register blocks are part of the riva/pronto (the two major versions)
subsystem, that also contains the "pmu" register block, which is what I access
here.

Further more, the ccu block contains valuable information for debugging
purposes that the implementation of this binding would find useful.


I would therefor like to double this node (in the dts) as both the
riva/pronto-pil and the target for the mmio phandle reference from the WiFi
node.

This works fine, but unless using reg-names for defining the order or the regs
I get a messy ordering dependency between the two bindings. I do not know which
of the other 7-8 register blocks we will add for debugging, but with the below
change I can keep them in block order regardless of the order we implement them
in.

So, can I update the "reg" and add "reg-names" as below to the binding and
depend on reg-names for the ordering of reg? Or should I speculatively add all
ranges I know of to keep the order sane?

Regards,
Bjorn

Changes since v2:
- Modify definition of "reg"
- Add "reg-names"
- Update example

 .../bindings/remoteproc/qcom,wcnss-pil.txt         | 124 +++++++++++++++++++++
 1 file changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt

Comments

Rob Herring April 22, 2016, 4:22 p.m. UTC | #1
On Thu, Apr 21, 2016 at 12:20 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
>
> The document defines the binding for a component that loads firmware for
> and boots the Qualcomm WCNSS core.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Rob,
>
> I got your Ack on v2, but I would like to make a small amendment before merging
> this.
>
>
> As we discussed related to the WiFi binding I should reference the mmio
> registers by a phandle to a DT node specifying the two necessary register
> blocks (ccu & dxe).
>
> These two register blocks are part of the riva/pronto (the two major versions)
> subsystem, that also contains the "pmu" register block, which is what I access
> here.
>
> Further more, the ccu block contains valuable information for debugging
> purposes that the implementation of this binding would find useful.
>
>
> I would therefor like to double this node (in the dts) as both the
> riva/pronto-pil and the target for the mmio phandle reference from the WiFi
> node.
>
> This works fine, but unless using reg-names for defining the order or the regs
> I get a messy ordering dependency between the two bindings. I do not know which
> of the other 7-8 register blocks we will add for debugging, but with the below
> change I can keep them in block order regardless of the order we implement them
> in.

You should know based on the compatible string what the number and
order of register ranges are. reg is not something we want evolving
over time.

> So, can I update the "reg" and add "reg-names" as below to the binding and
> depend on reg-names for the ordering of reg? Or should I speculatively add all
> ranges I know of to keep the order sane?

I'm okay with using this for convenience of the client not having to
care which compatible the block is, but the above should still be met.

Also, you could add a cell which is the index to the register range you need.

Rob
Bjorn Andersson April 22, 2016, 4:54 p.m. UTC | #2
On Fri 22 Apr 09:22 PDT 2016, Rob Herring wrote:

> On Thu, Apr 21, 2016 at 12:20 PM, Bjorn Andersson
> <bjorn.andersson@linaro.org> wrote:
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >
> > The document defines the binding for a component that loads firmware for
> > and boots the Qualcomm WCNSS core.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> >
> > Rob,
> >
> > I got your Ack on v2, but I would like to make a small amendment before merging
> > this.
> >
> >
> > As we discussed related to the WiFi binding I should reference the mmio
> > registers by a phandle to a DT node specifying the two necessary register
> > blocks (ccu & dxe).
> >
> > These two register blocks are part of the riva/pronto (the two major versions)
> > subsystem, that also contains the "pmu" register block, which is what I access
> > here.
> >
> > Further more, the ccu block contains valuable information for debugging
> > purposes that the implementation of this binding would find useful.
> >
> >
> > I would therefor like to double this node (in the dts) as both the
> > riva/pronto-pil and the target for the mmio phandle reference from the WiFi
> > node.
> >
> > This works fine, but unless using reg-names for defining the order or the regs
> > I get a messy ordering dependency between the two bindings. I do not know which
> > of the other 7-8 register blocks we will add for debugging, but with the below
> > change I can keep them in block order regardless of the order we implement them
> > in.
> 
> You should know based on the compatible string what the number and
> order of register ranges are. reg is not something we want evolving
> over time.
> 

At best I can make an educated guess based on some downstream debug code
on what regs we do have. But I've already found two of the ranges being
incorrect.

> > So, can I update the "reg" and add "reg-names" as below to the binding and
> > depend on reg-names for the ordering of reg? Or should I speculatively add all
> > ranges I know of to keep the order sane?
> 
> I'm okay with using this for convenience of the client not having to
> care which compatible the block is, but the above should still be met.
> 

Okay, I will throw in the 3 I know for now, saying those are required.
And then we add the debug regions as optionals after those, based on
which ones we need. Hopefully I haven't missed any required regions...

> Also, you could add a cell which is the index to the register range you need.
> 

I'm afraid I feel that is just reimplementing reg-names, for the sake of
not using reg-names.


Thanks for your answer, I'll spin the two bindings and send them about
again.

Regards,
Bjorn
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
new file mode 100644
index 000000000000..2ddca9be893e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -0,0 +1,124 @@ 
+Qualcomm WCNSS Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm WCNSS core.
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,riva-pil",
+		    "qcom,pronto-v1-pil",
+		    "qcom,pronto-v2-pil"
+
+- reg:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: must contain base address and size of riva/pronto PMU
+		    registers
+
+- reg-names:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must contain "pmu"
+
+- interrupts-extended:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: must list the watchdog and fatal IRQs and may specify the
+		    ready, handover and stop-ack IRQs
+
+- interrupt-names:
+	Usage: required
+	Value type: <stringlist>
+	Definition: should be "wdog", "fatal", optionally followed by "ready",
+		    "handover", "stop-ack"
+
+- vddmx-supply:
+- vddcx-supply:
+- vddpx-supply:
+	Usage: required
+	Value type: <phandle>
+	Definition: reference to the regulators to be held on behalf of the
+		    booting of the WCNSS core
+
+- qcom,state:
+	Usage: optional
+	Value type: <prop-encoded-array>
+	Definition: reference to the SMEM state used to indicate to WCNSS that
+		    it should shut down
+
+- qcom,state-names:
+	Usage: optional
+	Value type: <stringlist>
+	Definition: should be "stop"
+
+= SUBNODES
+A single subnode of the WCNSS PIL describes the attached rf module and its
+resource dependencies.
+
+- compatible:
+	Usage: required
+	Value type: <string>
+	Definition: must be one of:
+		    "qcom,wcn3620",
+		    "qcom,wcn3660",
+		    "qcom,wcn3680"
+
+- clocks:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: should specify the xo clock and optionally the rf clock
+
+- clock-names:
+	Usage: required
+	Value type: <stringlist>
+	Definition: should be "xo", optionally followed by "rf"
+
+- vddxo-supply:
+- vddrfa-supply:
+- vddpa-supply:
+- vdddig-supply:
+	Usage: required
+	Value type: <phandle>
+	Definition: reference to the regulators to be held on behalf of the
+		    booting of the WCNSS core
+
+= EXAMPLE
+The following example describes the resources needed to boot control the WCNSS,
+with attached WCN3680, as it is commonly found on MSM8974 boards.
+
+pronto@fb21b000 {
+	compatible = "qcom,pronto-v2-pil";
+	reg = <0xfb21b000 0x3000>;
+	reg-names = "pmu";
+
+	interrupts-extended = <&intc 0 149 1>,
+			      <&wcnss_smp2p_slave 0 0>,
+			      <&wcnss_smp2p_slave 1 0>,
+			      <&wcnss_smp2p_slave 2 0>,
+			      <&wcnss_smp2p_slave 3 0>;
+	interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+	vddmx-supply = <&pm8841_s1>;
+	vddcx-supply = <&pm8841_s2>;
+	vddpx-supply = <&pm8941_s3>;
+
+	qcom,state = <&wcnss_smp2p_out 0>;
+	qcom,state-names = "stop";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&wcnss_pin_a>;
+
+	iris {
+		compatible = "qcom,wcn3680";
+
+		clocks = <&rpmcc RPM_CXO_CLK_SRC>, <&rpmcc RPM_CXO_A2>;
+		clock-names = "xo", "rf";
+
+		vddxo-supply = <&pm8941_l6>;
+		vddrfa-supply = <&pm8941_l11>;
+		vddpa-supply = <&pm8941_l19>;
+		vdddig-supply = <&pm8941_s3>;
+	};
+};