On 18/06/14 00:59, Stephen Boyd wrote:
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
Can't we use syscon based on regmap here? syscon is a better way to
share a common register space across multiple drivers.
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.
--
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
