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 <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 devicetree" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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
