| Message ID | 1461259256-28529-1-git-send-email-bjorn.andersson@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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 --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>; + }; +};