When the SMEM is probed it defers as it depends on the hardware lock, which
is not available yet. But the SMD bus and RPM regulators and clocks depend
on SMEM and they defer too. The problem with this is that the order of
registering the devices is not optimal and also we may end with messed
up serial console as the RPM clocks are not registered yet..
Signed-off-by: Georgi Djakov <georgi.djakov@xxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 7705207872a5..c497c7b1ae70 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -113,15 +113,6 @@
};
};
- smem {
- compatible = "qcom,smem";
-
- memory-region = <&smem_mem>;
- qcom,rpm-msg-ram = <&rpm_msg_ram>;
-
- hwlocks = <&tcsr_mutex 3>;
- };
-
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -512,6 +503,16 @@
};
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_mem>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
+
smd {
compatible = "qcom,smd";
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
