| Message ID | 20190814125012.8700-2-vkoul@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: dts: qcom: sm8150: Add SM8150 DTS | expand |
Quoting Vinod Koul (2019-08-14 05:49:51) > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi > new file mode 100644 > index 000000000000..cd9fcadaeacb > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi > @@ -0,0 +1,269 @@ > +// SPDX-License-Identifier: BSD-3-Clause > +// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved. > +// Copyright (c) 2019, Linaro Limited > + > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include <dt-bindings/clock/qcom,gcc-sm8150.h> > + > +/ { > + interrupt-parent = <&intc>; > + > + #address-cells = <2>; > + #size-cells = <2>; > + > + chosen { }; > + > + clocks { > + xo_board: xo-board { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <19200000>; Is it 19.2 or 38.4 MHz? It seems like lately there are dividers, but I guess it doesn't really matter in the end. > + clock-output-names = "xo_board"; > + }; > + > + sleep_clk: sleep-clk { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <32764>; > + clock-output-names = "sleep_clk"; Does it matter to have this property anymore? Presumably it's OK if the name is now sleep-clk instead of sleep_clk because the name doesn't matter to connect clk tree. > + }; > + }; > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + CPU0: cpu@0 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x0>; > + enable-method = "psci"; > + next-level-cache = <&L2_0>; > + L2_0: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + L3_0: l3-cache { > + compatible = "cache"; > + }; > + }; > + }; > + > + CPU1: cpu@100 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x100>; > + enable-method = "psci"; > + next-level-cache = <&L2_100>; > + L2_100: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + > + }; > + > + CPU2: cpu@200 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x200>; > + enable-method = "psci"; > + next-level-cache = <&L2_200>; > + L2_200: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU3: cpu@300 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x300>; > + enable-method = "psci"; > + next-level-cache = <&L2_300>; > + L2_300: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU4: cpu@400 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x400>; > + enable-method = "psci"; > + next-level-cache = <&L2_400>; > + L2_400: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU5: cpu@500 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x500>; > + enable-method = "psci"; > + next-level-cache = <&L2_500>; > + L2_500: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU6: cpu@600 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; > + reg = <0x0 0x600>; > + enable-method = "psci"; > + next-level-cache = <&L2_600>; > + L2_600: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + > + CPU7: cpu@700 { > + device_type = "cpu"; > + compatible = "qcom,kryo485"; Is this compatible documented? > + reg = <0x0 0x700>; > + enable-method = "psci"; > + next-level-cache = <&L2_700>; > + L2_700: l2-cache { > + compatible = "cache"; > + next-level-cache = <&L3_0>; > + }; > + }; > + }; > + > + firmware { > + scm: scm { > + compatible = "qcom,scm-sm8150", "qcom,scm"; > + #reset-cells = <1>; > + }; > + }; > + > + memory@80000000 { > + device_type = "memory"; > + /* We expect the bootloader to fill in the size */ > + reg = <0 0x80000000 0 0>; > + }; > + > + psci { > + compatible = "arm,psci-1.0"; > + method = "smc"; > + }; > + > + soc: soc@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0 0 0xffffffff>; > + compatible = "simple-bus"; > + > + gcc: clock-controller@100000 { > + compatible = "qcom,gcc-sm8150"; > + reg = <0x00100000 0x1f0000>; > + #clock-cells = <1>; > + #reset-cells = <1>; > + #power-domain-cells = <1>; > + clock-names = "bi_tcxo", "sleep_clk"; > + clocks = <&xo_board>, <&sleep_clk>; > + }; > + > + qupv3_id_1: geniqup@ac0000 { > + compatible = "qcom,geni-se-qup"; > + reg = <0x00ac0000 0x6000>; > + clock-names = "m-ahb", "s-ahb"; > + clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>, > + <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + status = "disabled"; > + > + uart2: serial@a90000 { > + compatible = "qcom,geni-debug-uart"; > + reg = <0x00a90000 0x4000>; > + clock-names = "se"; > + clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>; > + interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>; > + status = "disabled"; > + }; > + }; > + > + intc: interrupt-controller@17a00000 { > + compatible = "arm,gic-v3"; > + interrupt-controller; > + #interrupt-cells = <3>; > + reg = <0x17a00000 0x10000>, /* GICD */ > + <0x17a60000 0x100000>; /* GICR * 8 */ > + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; Is there an its node? Probably the same as sdm845? > + }; > + > + timer@17c20000 { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + compatible = "arm,armv7-timer-mem"; > + reg = <0x17c20000 0x1000>; > + clock-frequency = <19200000>; This property shouldn't be necessary. Please remove. > + > + frame@17c21000{ > + frame-number = <0>; > + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
On Wed 14 Aug 09:58 PDT 2019, Stephen Boyd wrote: > Quoting Vinod Koul (2019-08-14 05:49:51) > > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi [..] > > + clocks { > > + xo_board: xo-board { > > + compatible = "fixed-clock"; > > + #clock-cells = <0>; > > + clock-frequency = <19200000>; > > Is it 19.2 or 38.4 MHz? It seems like lately there are dividers, but I > guess it doesn't really matter in the end. > As with previous platforms, the board's XO feeds the PMIC at 38.4MHz and the SoC's CXO_IN pin (i.e. bi_tcxo) is fed from the PMIC's LNBBCLK1, which is ticking at 19.2MHz. [..] > > + gcc: clock-controller@100000 { > > + compatible = "qcom,gcc-sm8150"; > > + reg = <0x00100000 0x1f0000>; > > + #clock-cells = <1>; > > + #reset-cells = <1>; > > + #power-domain-cells = <1>; > > + clock-names = "bi_tcxo", "sleep_clk"; > > + clocks = <&xo_board>, <&sleep_clk>; So this first one should actually be <&rpmhcc LNBBCLK1>. But while we now should handle this gracefully in the clock driver I think we still have problems with the cascading probe deferral that follows - last time I tried to do this the serial driver probe deferred past user space initialization and the system crashed as we didn't have a /dev/console. So, I think we should s/xo_board/lnbbclk1/ (at 19.2MHz) to make it represent the schematics and then once we have rpmhcc and validated that the system handles this gracefully we can switch it out. Regards, Bjorn
On Wed 14 Aug 05:49 PDT 2019, Vinod Koul wrote: > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi [..] > + soc: soc@0 { > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0 0 0xffffffff>; I'm expecting that we'll run into the same problems as we saw on 845 when bringing in the smmu nodes, so please make the cells 2 - and ranges should likely be the same 36 bits. Regards, Bjorn
Quoting Bjorn Andersson (2019-08-14 10:44:39) > On Wed 14 Aug 09:58 PDT 2019, Stephen Boyd wrote: > > > Quoting Vinod Koul (2019-08-14 05:49:51) > > > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi > [..] > > > + clocks { > > > + xo_board: xo-board { > > > + compatible = "fixed-clock"; > > > + #clock-cells = <0>; > > > + clock-frequency = <19200000>; > > > > Is it 19.2 or 38.4 MHz? It seems like lately there are dividers, but I > > guess it doesn't really matter in the end. > > > > As with previous platforms, the board's XO feeds the PMIC at 38.4MHz and > the SoC's CXO_IN pin (i.e. bi_tcxo) is fed from the PMIC's LNBBCLK1, > which is ticking at 19.2MHz. > > [..] > > > + gcc: clock-controller@100000 { > > > + compatible = "qcom,gcc-sm8150"; > > > + reg = <0x00100000 0x1f0000>; > > > + #clock-cells = <1>; > > > + #reset-cells = <1>; > > > + #power-domain-cells = <1>; > > > + clock-names = "bi_tcxo", "sleep_clk"; > > > + clocks = <&xo_board>, <&sleep_clk>; > > So this first one should actually be <&rpmhcc LNBBCLK1>. Hrmm LNBBCLK1 doesn't make any sense to me. That's a buffer that is technically the net connected to the XO pin on the Soc, but it isn't really supposed to be used by anything from what I recall. Last time I tried to use the buffers the RPM team told me I was using the wrong resource and I should just use the XO resource instead. Doesn't RPMh expose the other "XO" resource that is supposed to prevent XO shutdown? Just mark it critical for now so that XO isn't turned off at runtime. > > But while we now should handle this gracefully in the clock driver I > think we still have problems with the cascading probe deferral that > follows - last time I tried to do this the serial driver probe deferred > past user space initialization and the system crashed as we didn't have > a /dev/console. Does the serial driver probe eventually? Maybe you can run agetty when the device appears based on some uevent for /dev/console. Or we have a bug where /dev/console is created by devtmpfs when there isn't actually a console? > > > So, I think we should s/xo_board/lnbbclk1/ (at 19.2MHz) to make it > represent the schematics and then once we have rpmhcc and validated that > the system handles this gracefully we can switch it out. > Sure, some sort of approach that switches it later on is fine, just want to make sure that the board clk frequency is accurately reflected in the DT.
On Wed 14 Aug 11:35 PDT 2019, Stephen Boyd wrote: > Quoting Bjorn Andersson (2019-08-14 10:44:39) > > On Wed 14 Aug 09:58 PDT 2019, Stephen Boyd wrote: > > > > > Quoting Vinod Koul (2019-08-14 05:49:51) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi > > [..] > > > > + clocks { > > > > + xo_board: xo-board { > > > > + compatible = "fixed-clock"; > > > > + #clock-cells = <0>; > > > > + clock-frequency = <19200000>; > > > > > > Is it 19.2 or 38.4 MHz? It seems like lately there are dividers, but I > > > guess it doesn't really matter in the end. > > > > > > > As with previous platforms, the board's XO feeds the PMIC at 38.4MHz and > > the SoC's CXO_IN pin (i.e. bi_tcxo) is fed from the PMIC's LNBBCLK1, > > which is ticking at 19.2MHz. > > > > [..] > > > > + gcc: clock-controller@100000 { > > > > + compatible = "qcom,gcc-sm8150"; > > > > + reg = <0x00100000 0x1f0000>; > > > > + #clock-cells = <1>; > > > > + #reset-cells = <1>; > > > > + #power-domain-cells = <1>; > > > > + clock-names = "bi_tcxo", "sleep_clk"; > > > > + clocks = <&xo_board>, <&sleep_clk>; > > > > So this first one should actually be <&rpmhcc LNBBCLK1>. > > Hrmm LNBBCLK1 doesn't make any sense to me. That's a buffer that is > technically the net connected to the XO pin on the Soc, but it isn't > really supposed to be used by anything from what I recall. Last time I > tried to use the buffers the RPM team told me I was using the wrong > resource and I should just use the XO resource instead. Doesn't RPMh > expose the other "XO" resource that is supposed to prevent XO shutdown? So while it's the LNBBCLK1 pin we're referring to, it's the RPMH_CXO_CLK which has some level of magic involved that we should actually use in the software. > Just mark it critical for now so that XO isn't turned off at runtime. > > > > > But while we now should handle this gracefully in the clock driver I > > think we still have problems with the cascading probe deferral that > > follows - last time I tried to do this the serial driver probe deferred > > past user space initialization and the system crashed as we didn't have > > a /dev/console. > > Does the serial driver probe eventually? Maybe you can run agetty when > the device appears based on some uevent for /dev/console. Or we have a > bug where /dev/console is created by devtmpfs when there isn't actually > a console? > I don't remember the exact outcome, but presume it would depend on the implementation details of early user space (e.g. my regression test suite would not deal with this). > > > > > > So, I think we should s/xo_board/lnbbclk1/ (at 19.2MHz) to make it > > represent the schematics and then once we have rpmhcc and validated that > > the system handles this gracefully we can switch it out. > > > > Sure, some sort of approach that switches it later on is fine, just want > to make sure that the board clk frequency is accurately reflected in the > DT. > We introduced the xo_board fixed clock to have a parent of gcc, but given that there is a clock named "XO" and it is not the clock being connected to gcc, nor is it ticking at the right frequency I think it should at least have a different name. Regards, Bjorn
diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qcom/sm8150.dtsi new file mode 100644 index 000000000000..cd9fcadaeacb --- /dev/null +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi @@ -0,0 +1,269 @@ +// SPDX-License-Identifier: BSD-3-Clause +// Copyright (c) 2017-2019, The Linux Foundation. All rights reserved. +// Copyright (c) 2019, Linaro Limited + +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include <dt-bindings/clock/qcom,gcc-sm8150.h> + +/ { + interrupt-parent = <&intc>; + + #address-cells = <2>; + #size-cells = <2>; + + chosen { }; + + clocks { + xo_board: xo-board { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <19200000>; + clock-output-names = "xo_board"; + }; + + sleep_clk: sleep-clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32764>; + clock-output-names = "sleep_clk"; + }; + }; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + L3_0: l3-cache { + compatible = "cache"; + }; + }; + }; + + CPU1: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x100>; + enable-method = "psci"; + next-level-cache = <&L2_100>; + L2_100: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + + }; + + CPU2: cpu@200 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x200>; + enable-method = "psci"; + next-level-cache = <&L2_200>; + L2_200: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU3: cpu@300 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x300>; + enable-method = "psci"; + next-level-cache = <&L2_300>; + L2_300: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU4: cpu@400 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x400>; + enable-method = "psci"; + next-level-cache = <&L2_400>; + L2_400: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU5: cpu@500 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x500>; + enable-method = "psci"; + next-level-cache = <&L2_500>; + L2_500: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU6: cpu@600 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x600>; + enable-method = "psci"; + next-level-cache = <&L2_600>; + L2_600: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU7: cpu@700 { + device_type = "cpu"; + compatible = "qcom,kryo485"; + reg = <0x0 0x700>; + enable-method = "psci"; + next-level-cache = <&L2_700>; + L2_700: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + }; + + firmware { + scm: scm { + compatible = "qcom,scm-sm8150", "qcom,scm"; + #reset-cells = <1>; + }; + }; + + memory@80000000 { + device_type = "memory"; + /* We expect the bootloader to fill in the size */ + reg = <0 0x80000000 0 0>; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + + soc: soc@0 { + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0 0xffffffff>; + compatible = "simple-bus"; + + gcc: clock-controller@100000 { + compatible = "qcom,gcc-sm8150"; + reg = <0x00100000 0x1f0000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + clock-names = "bi_tcxo", "sleep_clk"; + clocks = <&xo_board>, <&sleep_clk>; + }; + + qupv3_id_1: geniqup@ac0000 { + compatible = "qcom,geni-se-qup"; + reg = <0x00ac0000 0x6000>; + clock-names = "m-ahb", "s-ahb"; + clocks = <&gcc GCC_QUPV3_WRAP_1_M_AHB_CLK>, + <&gcc GCC_QUPV3_WRAP_1_S_AHB_CLK>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + status = "disabled"; + + uart2: serial@a90000 { + compatible = "qcom,geni-debug-uart"; + reg = <0x00a90000 0x4000>; + clock-names = "se"; + clocks = <&gcc GCC_QUPV3_WRAP1_S4_CLK>; + interrupts = <GIC_SPI 357 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + }; + }; + + intc: interrupt-controller@17a00000 { + compatible = "arm,gic-v3"; + interrupt-controller; + #interrupt-cells = <3>; + reg = <0x17a00000 0x10000>, /* GICD */ + <0x17a60000 0x100000>; /* GICR * 8 */ + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + + timer@17c20000 { + #address-cells = <1>; + #size-cells = <1>; + ranges; + compatible = "arm,armv7-timer-mem"; + reg = <0x17c20000 0x1000>; + clock-frequency = <19200000>; + + frame@17c21000{ + frame-number = <0>; + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c21000 0x1000>, + <0x17c22000 0x1000>; + }; + + frame@17c23000 { + frame-number = <1>; + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c23000 0x1000>; + status = "disabled"; + }; + + frame@17c25000 { + frame-number = <2>; + interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c25000 0x1000>; + status = "disabled"; + }; + + frame@17c27000 { + frame-number = <3>; + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c26000 0x1000>; + status = "disabled"; + }; + + frame@17c29000 { + frame-number = <4>; + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c29000 0x1000>; + status = "disabled"; + }; + + frame@17c2b000 { + frame-number = <5>; + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c2b000 0x1000>; + status = "disabled"; + }; + + frame@17c2d000 { + frame-number = <6>; + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; + reg = <0x17c2d000 0x1000>; + status = "disabled"; + }; + }; + + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 1 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 2 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 3 IRQ_TYPE_LEVEL_LOW>, + <GIC_PPI 0 IRQ_TYPE_LEVEL_LOW>; + }; +};
This add base DTS file with cpu, psci, firmware and clock node to enable boot to console Signed-off-by: Vinod Koul <vkoul@kernel.org> --- arch/arm64/boot/dts/qcom/sm8150.dtsi | 269 +++++++++++++++++++++++++++ 1 file changed, 269 insertions(+) create mode 100644 arch/arm64/boot/dts/qcom/sm8150.dtsi