On Tue, Feb 23, 2016 at 07:21:11PM +0200, Georgi Djakov wrote: > 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..
Re-ordering the DT is fragile at best, and not a real solution to this class of problem. Why can the drivers not defer probing in this case? Mark. > Signed-off-by: Georgi Djakov <[email protected]> > --- > 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 devicetree" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html >
