On 06/16/14 11:46, Bjorn Andersson wrote:
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt[...]
new file mode 100644
index 0000000..0366533
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpm.txt
@@ -0,0 +1,260 @@
+Qualcomm Resource Power Manager (RPM)
+
+
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: two entries specifying the RPM's message ram and ipc register
+
+- reg-names:
+ Usage: required
+ Value type: <string-array>
+ Definition: must contain the following, in order:
+ "msg_ram"
+ "ipc"
ipc is concerning....
+ rpm@108000 {
+ compatible = "qcom,rpm-msm8960";
+ reg = <0x108000 0x1000 0x2011008 0x4>;
+
(reg-names is missing from the example)
because ipc is actually a register inside the Krait complex's global
clock control/distribution hardware block (it's located at 0x2011000).
From what I can tell, this is the only non-clock/power register inside
there. I plan to send out a driver for this hardware block so that I can
switch the L2 aux source mux over to PLL8 instead of PXO (done with a
single register write to 0x2011028) and this mapping/use here is going
to conflict with that unless I only map the single register like is done
here.
I wonder if we'd be better off making this region a separate node and
having some phandle to it here in the RPM node? That way we have a
driver that provides a clock and some IPC handle the RPM driver can get.--
The SMD driver also uses the same register to kick other processors so
having some generic IPC handle may be useful there too.