We'd like to start including the CPU name as the compatible under the
"soc" node so that we can get rid of it from the top-level compatible
string.
Suggested-by: Stephen Boyd <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
---
Probably needs a .yaml file somewhere?
Changes in v3:
- ("sc7280: Add the CPU compatible to the soc@0 node") new for v3.
arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index 618ae0407cd6..2bfc919d4018 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -573,7 +573,7 @@ soc: soc@0 {
#size-cells = <2>;
ranges = <0 0 0 0 0x10 0>;
dma-ranges = <0 0 0 0 0x10 0>;
- compatible = "simple-bus";
+ compatible = "qcom,sc7280", "simple-bus";
gcc: clock-controller@100000 {
compatible = "qcom,gcc-sc7280";
--
2.35.0.rc2.247.g8bbb082509-goog
Quoting Douglas Anderson (2022-02-02 13:23:47)
> We'd like to start including the CPU name as the compatible under the
> "soc" node so that we can get rid of it from the top-level compatible
> string.
>
> Suggested-by: Stephen Boyd <[email protected]>
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
Reviewed-by: Stephen Boyd <[email protected]>
On Wed 02 Feb 15:23 CST 2022, Douglas Anderson wrote:
> We'd like to start including the CPU name as the compatible under the
> "soc" node so that we can get rid of it from the top-level compatible
> string.
>
> Suggested-by: Stephen Boyd <[email protected]>
> Signed-off-by: Douglas Anderson <[email protected]>
> ---
> Probably needs a .yaml file somewhere?
>
> Changes in v3:
> - ("sc7280: Add the CPU compatible to the soc@0 node") new for v3.
>
> arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> index 618ae0407cd6..2bfc919d4018 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> @@ -573,7 +573,7 @@ soc: soc@0 {
> #size-cells = <2>;
> ranges = <0 0 0 0 0x10 0>;
> dma-ranges = <0 0 0 0 0x10 0>;
> - compatible = "simple-bus";
> + compatible = "qcom,sc7280", "simple-bus";
To me this implies that /soc represents the sc7280, but as noted earlier
I don't think that's accurate. E.g. if this node represents the sc7280,
why are the cpus described outside this node?
Further more, if we look at the reg nodes on this bus it's clear that
this is some mmio bus, which per the ranges has 36 bit address width.
But not all buses in the sc7280 has 36 bit address width, so it's not
inconceivable that one would actually have to split /soc into more than
one entity with different dma-ranges. Perhaps not today, but I don't
like the precedence it sets.
Regards,
Bjorn
>
> gcc: clock-controller@100000 {
> compatible = "qcom,gcc-sc7280";
> --
> 2.35.0.rc2.247.g8bbb082509-goog
>
Quoting Bjorn Andersson (2022-02-04 13:51:44)
> On Wed 02 Feb 15:23 CST 2022, Douglas Anderson wrote:
>
> > We'd like to start including the CPU name as the compatible under the
> > "soc" node so that we can get rid of it from the top-level compatible
> > string.
> >
> > Suggested-by: Stephen Boyd <[email protected]>
> > Signed-off-by: Douglas Anderson <[email protected]>
> > ---
> > Probably needs a .yaml file somewhere?
> >
> > Changes in v3:
> > - ("sc7280: Add the CPU compatible to the soc@0 node") new for v3.
> >
> > arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > index 618ae0407cd6..2bfc919d4018 100644
> > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
> > @@ -573,7 +573,7 @@ soc: soc@0 {
> > #size-cells = <2>;
> > ranges = <0 0 0 0 0x10 0>;
> > dma-ranges = <0 0 0 0 0x10 0>;
> > - compatible = "simple-bus";
> > + compatible = "qcom,sc7280", "simple-bus";
>
> To me this implies that /soc represents the sc7280, but as noted earlier
> I don't think that's accurate. E.g. if this node represents the sc7280,
> why are the cpus described outside this node?
They're outside the soc node because cpus have historically been
described at the root of the DT. The concept of an 'soc' node came after
the cpu nodes.
>
> Further more, if we look at the reg nodes on this bus it's clear that
> this is some mmio bus, which per the ranges has 36 bit address width.
> But not all buses in the sc7280 has 36 bit address width, so it's not
> inconceivable that one would actually have to split /soc into more than
> one entity with different dma-ranges. Perhaps not today, but I don't
> like the precedence it sets.
>
That should be fine. We can separate the nodes inside the soc node if we
need to by having different bus nodes underneath the soc node and then
change the dma-ranges within those bus nodes accordingly. We wouldn't
introduce another soc node to solve this problem.