| Message ID | 20230117024846.1367794-1-bryan.odonoghue@linaro.org |
|---|---|
| Headers | show |
| Series | Add MSM8939 SoC support with two devices | expand |
On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: > Add msm8939 a derivative SoC of msm8916. This SoC contains a number of key > differences to msm8916. > > - big.LITTLE Octa Core - quad 1.5GHz + quad 1.0GHz > - DRAM 1x800 LPDDR3 > - Camera 4+4 lane CSI > - Venus @ 1080p60 HEVC > - DSI x 2 > - Adreno A405 > - WiFi wcn3660/wcn3680b 802.11ac > > Co-developed-by: Shawn Guo <shawn.guo@linaro.org> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > Co-developed-by: Jun Nie <jun.nie@linaro.org> > Signed-off-by: Jun Nie <jun.nie@linaro.org> > Co-developed-by: Benjamin Li <benl@squareup.com> > Signed-off-by: Benjamin Li <benl@squareup.com> > Co-developed-by: James Willcox <jwillcox@squareup.com> > Signed-off-by: James Willcox <jwillcox@squareup.com> > Co-developed-by: Leo Yan <leo.yan@linaro.org> > Signed-off-by: Leo Yan <leo.yan@linaro.org> > Co-developed-by: Joseph Gates <jgates@squareup.com> > Signed-off-by: Joseph Gates <jgates@squareup.com> > Co-developed-by: Max Chen <mchen@squareup.com> > Signed-off-by: Max Chen <mchen@squareup.com> > Co-developed-by: Zac Crosby <zac@squareup.com> > Signed-off-by: Zac Crosby <zac@squareup.com> > Co-developed-by: Vincent Knecht <vincent.knecht@mailoo.org> > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> > Co-developed-by: Stephan Gerhold <stephan@gerhold.net> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Just to make sure when I get the question, you all co-developed this patch, right? > --- > arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++++++++++ > 1 file changed, 2393 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi > new file mode 100644 > index 0000000000000..8cd358a9fe623 > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi > @@ -0,0 +1,2393 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. > + * Copyright (c) 2020-2023, Linaro Limited > + */ > + > +#include <dt-bindings/clock/qcom,gcc-msm8939.h> > +#include <dt-bindings/clock/qcom,rpmcc.h> > +#include <dt-bindings/interconnect/qcom,msm8939.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> > +#include <dt-bindings/power/qcom-rpmpd.h> > +#include <dt-bindings/reset/qcom,gcc-msm8939.h> > +#include <dt-bindings/thermal/thermal.h> > + > +/ { > + interrupt-parent = <&intc>; > + > + #address-cells = <2>; > + #size-cells = <2>; Why do you use a default of 2? In particular since you reduce it to 1 in /soc... > + > + clocks { > + xo_board: xo-board { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <19200000>; > + }; > + > + sleep_clk: sleep-clk { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <32768>; > + }; > + }; [..] > + smp2p-hexagon { To avoid having people start sending patches that changes the sort order as soon as I merge this, could you please sort your nodes by address (not applicable for this one), then by node name alphabetically, then by label alphabetically. > + compatible = "qcom,smp2p"; > + qcom,smem = <435>, <428>; > + > + interrupts = <GIC_SPI 27 IRQ_TYPE_EDGE_RISING>; > + > + mboxes = <&apcs1_mbox 14>; > + > + qcom,local-pid = <0>; > + qcom,remote-pid = <1>; > + > + hexagon_smp2p_out: master-kernel { > + qcom,entry-name = "master-kernel"; > + > + #qcom,smem-state-cells = <1>; > + }; > + > + hexagon_smp2p_in: slave-kernel { > + qcom,entry-name = "slave-kernel"; > + > + interrupt-controller; > + #interrupt-cells = <2>; > + #address-cells = <0>; > + #size-cells = <0>; > + }; > + }; > + > + memory@80000000 { > + device_type = "memory"; > + /* We expect the bootloader to fill in the reg */ > + reg = <0x0 0x80000000 0x0 0x0>; > + }; > + [..] > + soc: soc@0 { [..] > + pronto: remoteproc@a204000 { > + compatible = "qcom,pronto-v2-pil", "qcom,pronto"; > + reg = <0x0a204000 0x2000>, > + <0x0a202000 0x1000>, > + <0x0a21b000 0x3000>; > + reg-names = "ccu", "dxe", "pmu"; > + > + interrupts-extended = <&intc 0 149 IRQ_TYPE_EDGE_RISING>, > + <&wcnss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, > + <&wcnss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, > + <&wcnss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, > + <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; > + interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; > + > + memory-region = <&wcnss_mem>; > + > + power-domains = <&rpmpd MSM8939_VDDCX>, > + <&rpmpd MSM8939_VDDMX_AO>; The purpose of the remoteproc driver's vote is to keep the rails powered while we're booting the remote, in the event that Linux decides to suspend and turn of the power rails while we're waiting... Once the remote pulls the "handover" interrupt, it signals that it has cast the necessary votes and need no more hand-holding. So it's unlikely that _AO is the right choice here. > + power-domain-names = "cx", "mx"; > + > + qcom,smem-states = <&wcnss_smp2p_out 0>; > + qcom,smem-state-names = "stop"; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&wcnss_pin_a>; > + > + status = "disabled"; > + > + iris { > + compatible = "qcom,wcn3620"; > + clocks = <&rpmcc RPM_SMD_RF_CLK2>; > + clock-names = "xo"; > + }; > + > + smd-edge { > + interrupts = <GIC_SPI 142 1>; > + qcom,ipc = <&apcs1_mbox 8 17>; > + qcom,smd-edge = <6>; > + qcom,remote-pid = <4>; > + > + label = "pronto"; > + > + wcnss { > + compatible = "qcom,wcnss"; > + qcom,smd-channels = "WCNSS_CTRL"; > + > + qcom,mmio = <&pronto>; > + > + bluetooth { > + compatible = "qcom,wcnss-bt"; > + }; > + > + wifi { > + compatible = "qcom,wcnss-wlan"; > + > + interrupts = <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "tx", "rx"; > + > + qcom,smem-states = <&apps_smsm 10>, > + <&apps_smsm 9>; > + qcom,smem-state-names = "tx-enable", > + "tx-rings-empty"; > + }; > + }; > + }; > + }; > + }; > + > + smd { "so" < "sm" > + compatible = "qcom,smd"; > + > + rpm { > + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>; > + qcom,ipc = <&apcs1_mbox 8 0>; > + qcom,smd-edge = <15>; > + > + rpm_requests: rpm-requests { > + compatible = "qcom,rpm-msm8936"; > + qcom,smd-channels = "rpm_requests"; > + > + rpmcc: clock-controller { > + compatible = "qcom,rpmcc-msm8936", "qcom,rpmcc"; > + #clock-cells = <1>; > + clock-names = "xo"; > + clocks = <&xo_board>; > + }; > + > + rpmpd: power-controller { > + compatible = "qcom,msm8939-rpmpd"; > + #power-domain-cells = <1>; > + operating-points-v2 = <&rpmpd_opp_table>; > + > + rpmpd_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + rpmpd_opp_ret: opp1 { > + opp-level = <1>; > + }; > + > + rpmpd_opp_svs_krait: opp2 { > + opp-level = <2>; > + }; > + > + rpmpd_opp_svs_soc: opp3 { > + opp-level = <3>; > + }; > + > + rpmpd_opp_nom: opp4 { > + opp-level = <4>; > + }; > + > + rpmpd_opp_turbo: opp5 { > + opp-level = <5>; > + }; > + > + rpmpd_opp_super_turbo: opp6 { > + opp-level = <6>; > + }; > + }; > + }; > + }; > + }; > + }; [..] > + > + /* Dummy regulator for our non-psci cpu@X defintions */ It's a power-supply... > + vreg_dummy: regulator-dummy { > + #power-domain-cells = <0>; > + }; > + > + smp2p-wcnss { This belongs up by the other smp2p node. Regards, Bjorn
On 17/01/2023 20:58, Bjorn Andersson wrote: > On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: >> Add msm8939 a derivative SoC of msm8916. This SoC contains a number of key >> differences to msm8916. >> >> - big.LITTLE Octa Core - quad 1.5GHz + quad 1.0GHz >> - DRAM 1x800 LPDDR3 >> - Camera 4+4 lane CSI >> - Venus @ 1080p60 HEVC >> - DSI x 2 >> - Adreno A405 >> - WiFi wcn3660/wcn3680b 802.11ac >> >> Co-developed-by: Shawn Guo <shawn.guo@linaro.org> >> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> >> Co-developed-by: Jun Nie <jun.nie@linaro.org> >> Signed-off-by: Jun Nie <jun.nie@linaro.org> >> Co-developed-by: Benjamin Li <benl@squareup.com> >> Signed-off-by: Benjamin Li <benl@squareup.com> >> Co-developed-by: James Willcox <jwillcox@squareup.com> >> Signed-off-by: James Willcox <jwillcox@squareup.com> >> Co-developed-by: Leo Yan <leo.yan@linaro.org> >> Signed-off-by: Leo Yan <leo.yan@linaro.org> >> Co-developed-by: Joseph Gates <jgates@squareup.com> >> Signed-off-by: Joseph Gates <jgates@squareup.com> >> Co-developed-by: Max Chen <mchen@squareup.com> >> Signed-off-by: Max Chen <mchen@squareup.com> >> Co-developed-by: Zac Crosby <zac@squareup.com> >> Signed-off-by: Zac Crosby <zac@squareup.com> >> Co-developed-by: Vincent Knecht <vincent.knecht@mailoo.org> >> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> >> Co-developed-by: Stephan Gerhold <stephan@gerhold.net> >> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> >> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > > Just to make sure when I get the question, you all co-developed this > patch, right? A long list but a fair one. >> --- >> arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++++++++++ >> 1 file changed, 2393 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi >> >> diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi >> new file mode 100644 >> index 0000000000000..8cd358a9fe623 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi >> @@ -0,0 +1,2393 @@ >> +// SPDX-License-Identifier: GPL-2.0-only >> +/* >> + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. >> + * Copyright (c) 2020-2023, Linaro Limited >> + */ >> + >> +#include <dt-bindings/clock/qcom,gcc-msm8939.h> >> +#include <dt-bindings/clock/qcom,rpmcc.h> >> +#include <dt-bindings/interconnect/qcom,msm8939.h> >> +#include <dt-bindings/interrupt-controller/arm-gic.h> >> +#include <dt-bindings/power/qcom-rpmpd.h> >> +#include <dt-bindings/reset/qcom,gcc-msm8939.h> >> +#include <dt-bindings/thermal/thermal.h> >> + >> +/ { >> + interrupt-parent = <&intc>; >> + >> + #address-cells = <2>; >> + #size-cells = <2>; > > Why do you use a default of 2? In particular since you reduce it to 1 in > /soc... You asked that before, and I took a note of the answer but, then because I was away from the main machine when I sent V2, I didn't have the log. Here's what I wrote down. " - address-cells/size-cells = 1 in /soc - Bjorn I experimentally changed address/cell sizes to 2 I'm finding that lk chokes " So AFAIR LK was unhappy about changing the top level address/size cells to <1> <1> and converting the /soc address/size cells to <2> <2> caused a number of breakages during boot. To be honest, this pattern is copied from the msm8916.dtsi original. msm8953.dtsi has the same thing. msm8994 too, and 8998. If you think it needs changing, then I'll have to see what can be done with soc@{} entries. > >> + >> + clocks { >> + xo_board: xo-board { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <19200000>; >> + }; >> + >> + sleep_clk: sleep-clk { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <32768>; >> + }; >> + }; > [..] >> + smp2p-hexagon { > > To avoid having people start sending patches that changes the sort order > as soon as I merge this, could you please sort your nodes by address > (not applicable for this one), then by node name alphabetically, then by > label alphabetically. ah. I sorted the contents of soc. I missed the upper level groupings. > >> + compatible = "qcom,smp2p"; >> + qcom,smem = <435>, <428>; >> + >> + interrupts = <GIC_SPI 27 IRQ_TYPE_EDGE_RISING>; >> + >> + mboxes = <&apcs1_mbox 14>; >> + >> + qcom,local-pid = <0>; >> + qcom,remote-pid = <1>; >> + >> + hexagon_smp2p_out: master-kernel { >> + qcom,entry-name = "master-kernel"; >> + >> + #qcom,smem-state-cells = <1>; >> + }; >> + >> + hexagon_smp2p_in: slave-kernel { >> + qcom,entry-name = "slave-kernel"; >> + >> + interrupt-controller; >> + #interrupt-cells = <2>; >> + #address-cells = <0>; >> + #size-cells = <0>; >> + }; >> + }; >> + >> + memory@80000000 { >> + device_type = "memory"; >> + /* We expect the bootloader to fill in the reg */ >> + reg = <0x0 0x80000000 0x0 0x0>; >> + }; >> + > [..] >> + soc: soc@0 { > [..] >> + pronto: remoteproc@a204000 { >> + compatible = "qcom,pronto-v2-pil", "qcom,pronto"; >> + reg = <0x0a204000 0x2000>, >> + <0x0a202000 0x1000>, >> + <0x0a21b000 0x3000>; >> + reg-names = "ccu", "dxe", "pmu"; >> + >> + interrupts-extended = <&intc 0 149 IRQ_TYPE_EDGE_RISING>, >> + <&wcnss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, >> + <&wcnss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, >> + <&wcnss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, >> + <&wcnss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; >> + interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; >> + >> + memory-region = <&wcnss_mem>; >> + >> + power-domains = <&rpmpd MSM8939_VDDCX>, >> + <&rpmpd MSM8939_VDDMX_AO>; > > The purpose of the remoteproc driver's vote is to keep the rails powered > while we're booting the remote, in the event that Linux decides to > suspend and turn of the power rails while we're waiting... > > Once the remote pulls the "handover" interrupt, it signals that it has > cast the necessary votes and need no more hand-holding. > > So it's unlikely that _AO is the right choice here. Yes, it's probably just VDDMX isn't it. I'll change that. --- bod
On Tue, Jan 17, 2023 at 10:48:37PM +0000, Bryan O'Donoghue wrote: > On 17/01/2023 20:58, Bjorn Andersson wrote: > > On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: > > > Add msm8939 a derivative SoC of msm8916. This SoC contains a number of key > > > differences to msm8916. > > > > > > - big.LITTLE Octa Core - quad 1.5GHz + quad 1.0GHz > > > - DRAM 1x800 LPDDR3 > > > - Camera 4+4 lane CSI > > > - Venus @ 1080p60 HEVC > > > - DSI x 2 > > > - Adreno A405 > > > - WiFi wcn3660/wcn3680b 802.11ac > > > > > > Co-developed-by: Shawn Guo <shawn.guo@linaro.org> > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > > Co-developed-by: Jun Nie <jun.nie@linaro.org> > > > Signed-off-by: Jun Nie <jun.nie@linaro.org> > > > Co-developed-by: Benjamin Li <benl@squareup.com> > > > Signed-off-by: Benjamin Li <benl@squareup.com> > > > Co-developed-by: James Willcox <jwillcox@squareup.com> > > > Signed-off-by: James Willcox <jwillcox@squareup.com> > > > Co-developed-by: Leo Yan <leo.yan@linaro.org> > > > Signed-off-by: Leo Yan <leo.yan@linaro.org> > > > Co-developed-by: Joseph Gates <jgates@squareup.com> > > > Signed-off-by: Joseph Gates <jgates@squareup.com> > > > Co-developed-by: Max Chen <mchen@squareup.com> > > > Signed-off-by: Max Chen <mchen@squareup.com> > > > Co-developed-by: Zac Crosby <zac@squareup.com> > > > Signed-off-by: Zac Crosby <zac@squareup.com> > > > Co-developed-by: Vincent Knecht <vincent.knecht@mailoo.org> > > > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> > > > Co-developed-by: Stephan Gerhold <stephan@gerhold.net> > > > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > > > > Just to make sure when I get the question, you all co-developed this > > patch, right? > > A long list but a fair one. > > > > --- > > > arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++++++++++ > > > 1 file changed, 2393 insertions(+) > > > create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi > > > > > > diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi > > > new file mode 100644 > > > index 0000000000000..8cd358a9fe623 > > > --- /dev/null > > > +++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi > > > @@ -0,0 +1,2393 @@ > > > +// SPDX-License-Identifier: GPL-2.0-only > > > +/* > > > + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. > > > + * Copyright (c) 2020-2023, Linaro Limited > > > + */ > > > + > > > +#include <dt-bindings/clock/qcom,gcc-msm8939.h> > > > +#include <dt-bindings/clock/qcom,rpmcc.h> > > > +#include <dt-bindings/interconnect/qcom,msm8939.h> > > > +#include <dt-bindings/interrupt-controller/arm-gic.h> > > > +#include <dt-bindings/power/qcom-rpmpd.h> > > > +#include <dt-bindings/reset/qcom,gcc-msm8939.h> > > > +#include <dt-bindings/thermal/thermal.h> > > > + > > > +/ { > > > + interrupt-parent = <&intc>; > > > + > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > > Why do you use a default of 2? In particular since you reduce it to 1 in > > /soc... > > You asked that before, and I took a note of the answer but, then because I > was away from the main machine when I sent V2, I didn't have the log. > > Here's what I wrote down. > > " - address-cells/size-cells = 1 in /soc - Bjorn > I experimentally changed address/cell sizes to 2 > I'm finding that lk chokes " > > So AFAIR LK was unhappy about changing the top level address/size cells to > <1> <1> and converting the /soc address/size cells to <2> <2> caused a > number of breakages during boot. > > To be honest, this pattern is copied from the msm8916.dtsi original. > msm8953.dtsi has the same thing. msm8994 too, and 8998. > > If you think it needs changing, then I'll have to see what can be done with > soc@{} entries. > Sounds like problems not worth pursuing further. How about leaving a comment for the next person here about LK's expectation of these being 2? Thanks, Bjorn
On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote: > Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua > and Square APQ8039 T2. > > MSM8939 is one of the older SoCs so we need to expand the list of > qcom,board-ids to allow for the bootloader DTS board-id matching > dependency. > The original LK bootloaders cannot boot your msm8939.dtsi correctly, because a spin-table implementation is required to get the other CPU cores up. This means that a modified bootloader is always needed from the upstream point of view, since I doubt anyone wants to use these devices with a single core only. lk2nd (as the primary spin-table implementation right now) has never required qcom,board-ids and any custom LK would be easy to patch to ignore these. Do you already have a bootloader with spin-table support deployed in the field that can be no longer easily modified to ignore the qcom,board-id? If not, and you're planning to keep using the downstream patches to bring the CPU cores up without spin-table/PSCI then you might as well add the qcom,board-id as downstream patch as well. If we don't support the original bootloaders in a usable way upstream then we should not add MSM8939 to the allow list of broken bootloaders either, in my opinion. Thanks, Stephan
On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: > Add msm8939 a derivative SoC of msm8916. This SoC contains a number of key > differences to msm8916. > > - big.LITTLE Octa Core - quad 1.5GHz + quad 1.0GHz > - DRAM 1x800 LPDDR3 > - Camera 4+4 lane CSI > - Venus @ 1080p60 HEVC > - DSI x 2 > - Adreno A405 > - WiFi wcn3660/wcn3680b 802.11ac > > Co-developed-by: Shawn Guo <shawn.guo@linaro.org> > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > Co-developed-by: Jun Nie <jun.nie@linaro.org> > Signed-off-by: Jun Nie <jun.nie@linaro.org> > Co-developed-by: Benjamin Li <benl@squareup.com> > Signed-off-by: Benjamin Li <benl@squareup.com> > Co-developed-by: James Willcox <jwillcox@squareup.com> > Signed-off-by: James Willcox <jwillcox@squareup.com> > Co-developed-by: Leo Yan <leo.yan@linaro.org> > Signed-off-by: Leo Yan <leo.yan@linaro.org> > Co-developed-by: Joseph Gates <jgates@squareup.com> > Signed-off-by: Joseph Gates <jgates@squareup.com> > Co-developed-by: Max Chen <mchen@squareup.com> > Signed-off-by: Max Chen <mchen@squareup.com> > Co-developed-by: Zac Crosby <zac@squareup.com> > Signed-off-by: Zac Crosby <zac@squareup.com> > Co-developed-by: Vincent Knecht <vincent.knecht@mailoo.org> > Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> > Co-developed-by: Stephan Gerhold <stephan@gerhold.net> > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > --- > arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++++++++++ > 1 file changed, 2393 insertions(+) > create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi > > diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi > new file mode 100644 > index 0000000000000..8cd358a9fe623 > --- /dev/null > +++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi > @@ -0,0 +1,2393 @@ > [...] > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + cpu0: cpu@100 { > + compatible = "arm,cortex-a53"; > + device_type = "cpu"; > + enable-method = "spin-table"; > + reg = <0x100>; > + next-level-cache = <&L2_1>; > + power-domains = <&vreg_dummy>; > + power-domain-names = "cpr"; Why are you adding a dummy power domain here? IMO this would be better added together with CPR. Especially because I would expect two power domains here later ("mx", "cpr"). For cpufreq you also need to make votes for the "MSM8939_VDDMX" power domain. > + qcom,acc = <&acc0>; > + qcom,saw = <&saw0>; > + cpu-idle-states = <&CPU_SLEEP_0>; > + clocks = <&apcs1_mbox>; > + #cooling-cells = <2>; > + L2_1: l2-cache { > + compatible = "cache"; > + cache-level = <2>; > + }; > + }; > [...] > + soc: soc@0 { > + compatible = "simple-bus"; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges = <0 0 0 0xffffffff>; > + > + rng@22000 { > + compatible = "qcom,prng"; > + reg = <0x00022000 0x200>; > + clocks = <&gcc GCC_PRNG_AHB_CLK>; > + clock-names = "core"; > + }; > + > + qfprom: qfprom@5c000 { > + compatible = "qcom,msm8916-qfprom", "qcom,qfprom"; > + reg = <0x0005c000 0x1000>; > + #address-cells = <1>; > + #size-cells = <1>; > + > + tsens_caldata: caldata@a0 { > + reg = <0xa0 0x5c>; > + }; > + cpr_efuse_init_voltage1: ivoltage1@dc { > + reg = <0xdc 0x4>; > + bits = <4 6>; > + }; > + cpr_efuse_init_voltage2: ivoltage2@da { > + reg = <0xda 0x4>; > + bits = <2 6>; > + }; > + cpr_efuse_init_voltage3: ivoltage3@d8 { > + reg = <0xd8 0x4>; > + bits = <0 6>; > + }; > + cpr_efuse_quot1: quot1@dd { > + reg = <0xdd 0x8>; > + bits = <2 12>; > + }; > + cpr_efuse_quot2: quot2@db { > + reg = <0xdb 0x8>; > + bits = <0x0 12>; > + }; > + cpr_efuse_ring1: ring1@de { > + reg = <0xde 0x4>; > + bits = <6 3>; > + }; > + cpr_efuse_revision: revision@5 { > + reg = <0x5 0x1>; > + bits = <5 1>; > + }; > + cpr_efuse_revision_high: revision-high@7 { > + reg = <0x7 0x1>; > + bits = <0 1>; > + }; > + cpr_efuse_pvs_version: pvs@3 { > + reg = <0x3 0x1>; > + bits = <5 1>; > + }; > + cpr_efuse_pvs_version_high: pvs-high@6 { > + reg = <0x6 0x1>; > + bits = <2 2>; > + }; > + cpr_efuse_speedbin: speedbin@c { > + reg = <0xc 0x1>; > + bits = <2 3>; > + }; Please add the CPR items later together with CPR. This will make the review a bit easier because we don't need to check that these are right for the initial submission. > + }; > [...] > + mdss: display-subsystem@1a00000 { > + compatible = "qcom,mdss"; > + reg = <0x01a00000 0x1000>, > + <0x01ac8000 0x3000>; > + reg-names = "mdss_phys", "vbif_phys"; > + > + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-controller; > + > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > + <&gcc GCC_MDSS_AXI_CLK>, > + <&gcc GCC_MDSS_VSYNC_CLK>; > + clock-names = "iface", > + "bus", > + "vsync"; > + > + power-domains = <&gcc MDSS_GDSC>; > + > + #address-cells = <1>; > + #size-cells = <1>; > + #interrupt-cells = <1>; > + ranges; > + > + mdp: display-controller@1a01000 { > + compatible = "qcom,mdp5"; > + reg = <0x01a01000 0x89000>; > + reg-names = "mdp_phys"; > + > + interrupt-parent = <&mdss>; > + interrupts = <0>; > + > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > + <&gcc GCC_MDSS_AXI_CLK>, > + <&gcc GCC_MDSS_MDP_CLK>, > + <&gcc GCC_MDSS_VSYNC_CLK>, > + <&gcc GCC_MDP_TBU_CLK>, > + <&gcc GCC_MDP_RT_TBU_CLK>; > + clock-names = "iface", > + "bus", > + "core", > + "vsync", > + "tbu", > + "tbu_rt"; > + > + iommus = <&apps_iommu 4>; > + > + interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>, > + <&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>, > + <&pcnoc MASTER_SPDM &snoc SLAVE_IMEM>; > + interconnect-names = "mdp0-mem", "mdp1-mem", "register-mem"; As I mentioned a already in a direct email at some point, AFAIU adding interconnects should be an [almost-] all or nothing step. If you only add interconnects for MDP then everything else that needs bandwidth will either break or only continue working as a mere side effect of MDP voting for permanent high bandwidth. This could break easily if someone has a board without display, or if the MDP5 driver is optimized to request the minimum necessary bandwidth only. I think strictly speaking "interconnects" properties are needed for everything that uses DMA, i.e. CPUs, SDHCI, USB, UART, I2C, SPI and also audio (in DSP bypass mode only). If you look at newer platforms they do have "interconnects" for most of these. (Semi-related side note: "register-mem" is neither documented nor used anywhere in the code?) > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + mdp5_intf1_out: endpoint { > + remote-endpoint = <&dsi0_in>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + mdp5_intf2_out: endpoint { > + remote-endpoint = <&dsi1_in>; > + }; > + }; > + }; > + }; > + > + dsi0: dsi@1a98000 { > + compatible = "qcom,msm8916-dsi-ctrl", > + "qcom,mdss-dsi-ctrl"; > + reg = <0x01a98000 0x25c>; > + reg-names = "dsi_ctrl"; > + > + interrupt-parent = <&mdss>; > + interrupts = <4>; > + > + power-domains = <&gcc MDSS_GDSC>; Why is MDSS_GDSC defined again here? The parent-child relationship of MDSS->MDP should ensure that the MDSS_GDSC from the parent mdss node is on when dsi is. > + > + clocks = <&gcc GCC_MDSS_MDP_CLK>, > + <&gcc GCC_MDSS_AHB_CLK>, > + <&gcc GCC_MDSS_AXI_CLK>, > + <&gcc GCC_MDSS_BYTE0_CLK>, > + <&gcc GCC_MDSS_PCLK0_CLK>, > + <&gcc GCC_MDSS_ESC0_CLK>; > + clock-names = "mdp_core", > + "iface", > + "bus", > + "byte", > + "pixel", > + "core"; > + assigned-clocks = <&gcc BYTE0_CLK_SRC>, > + <&gcc PCLK0_CLK_SRC>; > + assigned-clock-parents = <&dsi_phy0 0>, > + <&dsi_phy0 1>; > + > + phys = <&dsi_phy0>; > + status = "disabled"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + dsi0_in: endpoint { > + remote-endpoint = <&mdp5_intf1_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + dsi0_out: endpoint { > + }; > + }; > + }; > + }; > + > + dsi_phy0: phy@1a98300 { > + compatible = "qcom,dsi-phy-28nm-lp"; > + reg = <0x01a98300 0xd4>, > + <0x01a98500 0x280>, > + <0x01a98780 0x30>; > + reg-names = "dsi_pll", > + "dsi_phy", > + "dsi_phy_regulator"; > + > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > + <&rpmcc RPM_SMD_XO_CLK_SRC>; > + clock-names = "iface", "ref"; > + > + #clock-cells = <1>; > + #phy-cells = <0>; > + status = "disabled"; > + }; > + > + dsi1: dsi@1aa0000 { > + compatible = "qcom,msm8916-dsi-ctrl", > + "qcom,mdss-dsi-ctrl"; > + reg = <0x01aa0000 0x25c>; > + reg-names = "dsi_ctrl"; > + > + interrupt-parent = <&mdss>; > + interrupts = <5>; > + > + power-domains = <&gcc MDSS_GDSC>; > + > + clocks = <&gcc GCC_MDSS_MDP_CLK>, > + <&gcc GCC_MDSS_AHB_CLK>, > + <&gcc GCC_MDSS_AXI_CLK>, > + <&gcc GCC_MDSS_BYTE1_CLK>, > + <&gcc GCC_MDSS_PCLK1_CLK>, > + <&gcc GCC_MDSS_ESC1_CLK>; > + clock-names = "mdp_core", > + "iface", > + "bus", > + "byte", > + "pixel", > + "core"; > + assigned-clocks = <&gcc BYTE1_CLK_SRC>, > + <&gcc PCLK1_CLK_SRC>; > + assigned-clock-parents = <&dsi_phy1 0>, > + <&dsi_phy1 1>; Does this work? Confusingly, BYTE1/PCLK1_CLK_SRC can only have dsi0pll as parent in gcc-msm8939 and not the dsi1pll. <&dsi_phy1 0/1> is not a valid parent for those clocks. Actually I cannot find any mention of mdss_dsi1_pll at all in downstream. It seems a bit like the PLL functionality in dsi_phy1 is unused and the PLL in dsi_phy0 is used for both DSI interfaces instead. No idea why. If this is the case then assigned-clock-parents should refer to dsi_phy0 here. > + phys = <&dsi_phy1>; > + status = "disabled"; > + > + ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + dsi1_in: endpoint { > + remote-endpoint = <&mdp5_intf2_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + dsi1_out: endpoint { > + }; > + }; > + }; > + }; > + > + dsi_phy1: phy@1aa0300 { > + compatible = "qcom,dsi-phy-28nm-lp"; > + reg = <0x01aa0300 0xd4>, > + <0x01aa0500 0x280>, > + <0x01aa0780 0x30>; > + reg-names = "dsi_pll", > + "dsi_phy", > + "dsi_phy_regulator"; > + > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > + <&rpmcc RPM_SMD_XO_CLK_SRC>; > + clock-names = "iface", "ref"; > + > + #clock-cells = <1>; > + #phy-cells = <0>; > + status = "disabled"; > + }; > + }; > [...] > + blsp_dma: dma-controller@7884000 { > + compatible = "qcom,bam-v1.7.0"; > + reg = <0x07884000 0x23000>; > + interrupts = <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>; > + clocks = <&gcc GCC_BLSP1_AHB_CLK>; > + clock-names = "bam_clk"; > + #dma-cells = <1>; > + qcom,ee = <0>; > + status = "disabled"; Please enable this by default, see https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=for-next&id=0154d3594af3c198532ac7b4ab70f50fb5207a15 > + }; > [...] > + timer@b020000 { > + compatible = "arm,armv7-timer-mem"; > + reg = <0x0b020000 0x1000>; > + #address-cells = <1>; > + #size-cells = <1>; > + ranges; > + > + frame@b021000 { > + reg = <0x0b021000 0x1000>, > + <0x0b022000 0x1000>; > + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; These timer interrupts are still wrong. GIC_SPI 8/7 belong to the timer frame of the other cluster, 0x0b121000 instead of 0x0b021000. You need to change the reg addresses like in https://github.com/msm8916-mainline/linux/commit/0905a152ccb6fe6b94e8c16767993f05c608089c OR, alternatively: Fix all the interrupt numbers. From the LK source code we know that this timer frame specifically has GIC_SPI 257 as one of its interrupts, because LK is making use of it: https://git.codelinaro.org/clo/la/kernel/lk/-/blob/caf_migration/LA.BR.1.2.9.1_rb1.5/platform/msm8916/include/platform/irqs.h#L47-48 The other timer frames are likely also connected to some other interrupt number that you might find in documentation or using experiments. But the easier solution would be keeping the interrupts and just changing the "reg"s. > + frame-number = <0>; > + }; > + > + frame@b023000 { > + reg = <0x0b023000 0x1000>; > + interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <1>; > + status = "disabled"; > + }; > + > + frame@b024000 { > + reg = <0x0b024000 0x1000>; > + interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <2>; > + status = "disabled"; > + }; > + > + frame@b025000 { > + reg = <0x0b025000 0x1000>; > + interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <3>; > + status = "disabled"; > + }; > + > + frame@b026000 { > + reg = <0x0b026000 0x1000>; > + interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <4>; > + status = "disabled"; > + }; > + > + frame@b027000 { > + reg = <0x0b027000 0x1000>; > + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <5>; > + status = "disabled"; > + }; > + > + frame@b028000 { > + reg = <0x0b028000 0x1000>; > + interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>; > + frame-number = <6>; > + status = "disabled"; > + }; > + }; > [...] Thanks! Stephan
On 18/01/2023 09:59, Stephan Gerhold wrote: > On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: >> Add msm8939 a derivative SoC of msm8916. This SoC contains a number of key >> differences to msm8916. >> >> - big.LITTLE Octa Core - quad 1.5GHz + quad 1.0GHz >> - DRAM 1x800 LPDDR3 >> - Camera 4+4 lane CSI >> - Venus @ 1080p60 HEVC >> - DSI x 2 >> - Adreno A405 >> - WiFi wcn3660/wcn3680b 802.11ac >> >> Co-developed-by: Shawn Guo <shawn.guo@linaro.org> >> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> >> Co-developed-by: Jun Nie <jun.nie@linaro.org> >> Signed-off-by: Jun Nie <jun.nie@linaro.org> >> Co-developed-by: Benjamin Li <benl@squareup.com> >> Signed-off-by: Benjamin Li <benl@squareup.com> >> Co-developed-by: James Willcox <jwillcox@squareup.com> >> Signed-off-by: James Willcox <jwillcox@squareup.com> >> Co-developed-by: Leo Yan <leo.yan@linaro.org> >> Signed-off-by: Leo Yan <leo.yan@linaro.org> >> Co-developed-by: Joseph Gates <jgates@squareup.com> >> Signed-off-by: Joseph Gates <jgates@squareup.com> >> Co-developed-by: Max Chen <mchen@squareup.com> >> Signed-off-by: Max Chen <mchen@squareup.com> >> Co-developed-by: Zac Crosby <zac@squareup.com> >> Signed-off-by: Zac Crosby <zac@squareup.com> >> Co-developed-by: Vincent Knecht <vincent.knecht@mailoo.org> >> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> >> Co-developed-by: Stephan Gerhold <stephan@gerhold.net> >> Signed-off-by: Stephan Gerhold <stephan@gerhold.net> >> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >> --- >> arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++++++++++ >> 1 file changed, 2393 insertions(+) >> create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi >> >> diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi >> new file mode 100644 >> index 0000000000000..8cd358a9fe623 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi >> @@ -0,0 +1,2393 @@ >> [...] >> + cpus { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + cpu0: cpu@100 { >> + compatible = "arm,cortex-a53"; >> + device_type = "cpu"; >> + enable-method = "spin-table"; >> + reg = <0x100>; >> + next-level-cache = <&L2_1>; >> + power-domains = <&vreg_dummy>; >> + power-domain-names = "cpr"; > > Why are you adding a dummy power domain here? IMO this would be better > added together with CPR. Especially because I would expect two power > domains here later ("mx", "cpr"). For cpufreq you also need to make > votes for the "MSM8939_VDDMX" power domain. I'm pretty sure there's binding checks that demand this but, I will re-verify it. > >> + qcom,acc = <&acc0>; >> + qcom,saw = <&saw0>; >> + cpu-idle-states = <&CPU_SLEEP_0>; >> + clocks = <&apcs1_mbox>; >> + #cooling-cells = <2>; >> + L2_1: l2-cache { >> + compatible = "cache"; >> + cache-level = <2>; >> + }; >> + }; >> [...] >> + soc: soc@0 { >> + compatible = "simple-bus"; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + ranges = <0 0 0 0xffffffff>; >> + >> + rng@22000 { >> + compatible = "qcom,prng"; >> + reg = <0x00022000 0x200>; >> + clocks = <&gcc GCC_PRNG_AHB_CLK>; >> + clock-names = "core"; >> + }; >> + >> + qfprom: qfprom@5c000 { >> + compatible = "qcom,msm8916-qfprom", "qcom,qfprom"; >> + reg = <0x0005c000 0x1000>; >> + #address-cells = <1>; >> + #size-cells = <1>; >> + >> + tsens_caldata: caldata@a0 { >> + reg = <0xa0 0x5c>; >> + }; >> + cpr_efuse_init_voltage1: ivoltage1@dc { >> + reg = <0xdc 0x4>; >> + bits = <4 6>; >> + }; >> + cpr_efuse_init_voltage2: ivoltage2@da { >> + reg = <0xda 0x4>; >> + bits = <2 6>; >> + }; >> + cpr_efuse_init_voltage3: ivoltage3@d8 { >> + reg = <0xd8 0x4>; >> + bits = <0 6>; >> + }; >> + cpr_efuse_quot1: quot1@dd { >> + reg = <0xdd 0x8>; >> + bits = <2 12>; >> + }; >> + cpr_efuse_quot2: quot2@db { >> + reg = <0xdb 0x8>; >> + bits = <0x0 12>; >> + }; >> + cpr_efuse_ring1: ring1@de { >> + reg = <0xde 0x4>; >> + bits = <6 3>; >> + }; >> + cpr_efuse_revision: revision@5 { >> + reg = <0x5 0x1>; >> + bits = <5 1>; >> + }; >> + cpr_efuse_revision_high: revision-high@7 { >> + reg = <0x7 0x1>; >> + bits = <0 1>; >> + }; >> + cpr_efuse_pvs_version: pvs@3 { >> + reg = <0x3 0x1>; >> + bits = <5 1>; >> + }; >> + cpr_efuse_pvs_version_high: pvs-high@6 { >> + reg = <0x6 0x1>; >> + bits = <2 2>; >> + }; >> + cpr_efuse_speedbin: speedbin@c { >> + reg = <0xc 0x1>; >> + bits = <2 3>; >> + }; > > Please add the CPR items later together with CPR. This will make the > review a bit easier because we don't need to check that these are right > for the initial submission. I will excise this if I can, i.e. if the system will still boot once done. > >> + }; >> [...] >> + mdss: display-subsystem@1a00000 { >> + compatible = "qcom,mdss"; >> + reg = <0x01a00000 0x1000>, >> + <0x01ac8000 0x3000>; >> + reg-names = "mdss_phys", "vbif_phys"; >> + >> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; >> + interrupt-controller; >> + >> + clocks = <&gcc GCC_MDSS_AHB_CLK>, >> + <&gcc GCC_MDSS_AXI_CLK>, >> + <&gcc GCC_MDSS_VSYNC_CLK>; >> + clock-names = "iface", >> + "bus", >> + "vsync"; >> + >> + power-domains = <&gcc MDSS_GDSC>; >> + >> + #address-cells = <1>; >> + #size-cells = <1>; >> + #interrupt-cells = <1>; >> + ranges; >> + >> + mdp: display-controller@1a01000 { >> + compatible = "qcom,mdp5"; >> + reg = <0x01a01000 0x89000>; >> + reg-names = "mdp_phys"; >> + >> + interrupt-parent = <&mdss>; >> + interrupts = <0>; >> + >> + clocks = <&gcc GCC_MDSS_AHB_CLK>, >> + <&gcc GCC_MDSS_AXI_CLK>, >> + <&gcc GCC_MDSS_MDP_CLK>, >> + <&gcc GCC_MDSS_VSYNC_CLK>, >> + <&gcc GCC_MDP_TBU_CLK>, >> + <&gcc GCC_MDP_RT_TBU_CLK>; >> + clock-names = "iface", >> + "bus", >> + "core", >> + "vsync", >> + "tbu", >> + "tbu_rt"; >> + >> + iommus = <&apps_iommu 4>; >> + >> + interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>, >> + <&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>, >> + <&pcnoc MASTER_SPDM &snoc SLAVE_IMEM>; >> + interconnect-names = "mdp0-mem", "mdp1-mem", "register-mem"; > > As I mentioned a already in a direct email at some point, AFAIU adding > interconnects should be an [almost-] all or nothing step. If you only > add interconnects for MDP then everything else that needs bandwidth will > either break or only continue working as a mere side effect of MDP > voting for permanent high bandwidth. We did discuss that. You'll also recall we concluded we would have to revert this patch to make that happen. commit 76a748e2c1aa976d0c7fef872fa6ff93ce334a8a Author: Leo Yan <leo.yan@linaro.org> Date: Sat Apr 16 09:26:34 2022 +0800 interconnect: qcom: msm8939: Use icc_sync_state but then why not revert for all of these SoCs too ? drivers/interconnect/qcom/msm8939.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/msm8974.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/msm8996.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/osm-l3.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sc7180.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sc7280.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sc8180x.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sc8280xp.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sdm845.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sdx55.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sdx65.c: .sync_state = icc_sync_state, drivers/interconnect/qcom/sm6350.c: .sync_state = icc_sync_state, until such time as we have an all or nothing interconnect setup for each of those SoCs ? Yes I take your point "some peripherals will appear to work only as a result of the AHB vote the MDP casts here" but, that is a bug in the definition of that hypothetical peripheral. The MDP/display won't run without the interconnect here and the only way to pull it is to remove sync_state which begs the question why not pull sync_state for all SoCs without a perfect interconnect description ? I think that would be a retrograde step. > (Semi-related side note: "register-mem" is neither documented nor used > anywhere in the code?) Oh do you have me there though, this is a holdover from the Android dtsi. I'll see if it makes a difference dropping this. > >> + >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + mdp5_intf1_out: endpoint { >> + remote-endpoint = <&dsi0_in>; >> + }; >> + }; >> + >> + port@1 { >> + reg = <1>; >> + mdp5_intf2_out: endpoint { >> + remote-endpoint = <&dsi1_in>; >> + }; >> + }; >> + }; >> + }; >> + >> + dsi0: dsi@1a98000 { >> + compatible = "qcom,msm8916-dsi-ctrl", >> + "qcom,mdss-dsi-ctrl"; >> + reg = <0x01a98000 0x25c>; >> + reg-names = "dsi_ctrl"; >> + >> + interrupt-parent = <&mdss>; >> + interrupts = <4>; >> + >> + power-domains = <&gcc MDSS_GDSC>; > > Why is MDSS_GDSC defined again here? The parent-child relationship of > MDSS->MDP should ensure that the MDSS_GDSC from the parent mdss node > is on when dsi is. > >> + >> + clocks = <&gcc GCC_MDSS_MDP_CLK>, >> + <&gcc GCC_MDSS_AHB_CLK>, >> + <&gcc GCC_MDSS_AXI_CLK>, >> + <&gcc GCC_MDSS_BYTE0_CLK>, >> + <&gcc GCC_MDSS_PCLK0_CLK>, >> + <&gcc GCC_MDSS_ESC0_CLK>; >> + clock-names = "mdp_core", >> + "iface", >> + "bus", >> + "byte", >> + "pixel", >> + "core"; >> + assigned-clocks = <&gcc BYTE0_CLK_SRC>, >> + <&gcc PCLK0_CLK_SRC>; >> + assigned-clock-parents = <&dsi_phy0 0>, >> + <&dsi_phy0 1>; >> + >> + phys = <&dsi_phy0>; >> + status = "disabled"; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + port@0 { >> + reg = <0>; >> + dsi0_in: endpoint { >> + remote-endpoint = <&mdp5_intf1_out>; >> + }; >> + }; >> + >> + port@1 { >> + reg = <1>; >> + dsi0_out: endpoint { >> + }; >> + }; >> + }; >> + }; >> + >> + dsi_phy0: phy@1a98300 { >> + compatible = "qcom,dsi-phy-28nm-lp"; >> + reg = <0x01a98300 0xd4>, >> + <0x01a98500 0x280>, >> + <0x01a98780 0x30>; >> + reg-names = "dsi_pll", >> + "dsi_phy", >> + "dsi_phy_regulator"; >> + >> + clocks = <&gcc GCC_MDSS_AHB_CLK>, >> + <&rpmcc RPM_SMD_XO_CLK_SRC>; >> + clock-names = "iface", "ref"; >> + >> + #clock-cells = <1>; >> + #phy-cells = <0>; >> + status = "disabled"; >> + }; >> + >> + dsi1: dsi@1aa0000 { >> + compatible = "qcom,msm8916-dsi-ctrl", >> + "qcom,mdss-dsi-ctrl"; >> + reg = <0x01aa0000 0x25c>; >> + reg-names = "dsi_ctrl"; >> + >> + interrupt-parent = <&mdss>; >> + interrupts = <5>; >> + >> + power-domains = <&gcc MDSS_GDSC>; >> + >> + clocks = <&gcc GCC_MDSS_MDP_CLK>, >> + <&gcc GCC_MDSS_AHB_CLK>, >> + <&gcc GCC_MDSS_AXI_CLK>, >> + <&gcc GCC_MDSS_BYTE1_CLK>, >> + <&gcc GCC_MDSS_PCLK1_CLK>, >> + <&gcc GCC_MDSS_ESC1_CLK>; >> + clock-names = "mdp_core", >> + "iface", >> + "bus", >> + "byte", >> + "pixel", >> + "core"; >> + assigned-clocks = <&gcc BYTE1_CLK_SRC>, >> + <&gcc PCLK1_CLK_SRC>; >> + assigned-clock-parents = <&dsi_phy1 0>, >> + <&dsi_phy1 1>; > > Does this work? Confusingly, BYTE1/PCLK1_CLK_SRC can only have dsi0pll > as parent in gcc-msm8939 and not the dsi1pll. <&dsi_phy1 0/1> is not a > valid parent for those clocks. No you're right, its all wrong. I will correct it mdss_dsi0: qcom,mdss_dsi@1a98000 { compatible = "qcom,mdss-dsi-ctrl"; label = "MDSS DSI CTRL->0"; cell-index = <0>; reg = <0x1a98000 0x25c>, <0x1a98500 0x2b0>, <0x193e000 0x30>; reg-names = "dsi_ctrl", "dsi_phy", "mmss_misc_phys"; qcom,mdss-fb-map = <&mdss_fb0>; qcom,mdss-mdp = <&mdss_mdp>; gdsc-supply = <&gdsc_mdss>; vdda-supply = <&pm8916_l2>; vdd-supply = <&pm8916_l17>; vddio-supply = <&pm8916_l6>; clocks = <&clock_gcc clk_gcc_mdss_mdp_clk>, <&clock_gcc clk_gcc_mdss_ahb_clk>, <&clock_gcc clk_gcc_mdss_axi_clk>, <&clock_gcc_mdss clk_gcc_mdss_byte0_clk>, <&clock_gcc_mdss clk_gcc_mdss_pclk0_clk>, <&clock_gcc clk_gcc_mdss_esc0_clk>; --- bod
On 18/01/2023 08:47, Stephan Gerhold wrote: > On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote: >> Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua >> and Square APQ8039 T2. >> >> MSM8939 is one of the older SoCs so we need to expand the list of >> qcom,board-ids to allow for the bootloader DTS board-id matching >> dependency. >> > > The original LK bootloaders cannot boot your msm8939.dtsi correctly, > because a spin-table implementation is required to get the other CPU > cores up. This means that a modified bootloader is always needed from > the upstream point of view, since I doubt anyone wants to use these > devices with a single core only. lk2nd (as the primary spin-table > implementation right now) has never required qcom,board-ids and any > custom LK would be easy to patch to ignore these. The system boots just fine with the shipped LK. We get display, USB, SD, WiFi. We just don't support booting the second cluster via any other means than lk2nd right now. You could also not use lk2nd, stick with your default LK and import LPM patches. Default LK: root@linaro-alip:~# cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 root@linaro-alip:~# iw wlan0 info Interface wlan0 ifindex 6 wdev 0x1 addr e2:b9:a0:ef:3a:ba type managed wiphy 0 channel 52 (5260 MHz), width: 80 MHz, center1: 5290 MHz txpower 20.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 0 0 0 0 0 0 0 root@linaro-alip:~# uname -a Linux linaro-alip 6.2.0-rc4-next-20230116-00029-gf1a46ff9e812-dirty #392 SMP PREEMPT Tue Jan 17 23:46:42 GMT 2023 aarch64 GNU/Linux LK2ND: root@linaro-alip:~# cat /proc/cpuinfo processor : 0 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 2 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 3 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 4 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 5 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 6 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 7 BogoMIPS : 38.40 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 root@linaro-alip:~# iw wlan0 info Interface wlan0 ifindex 6 wdev 0x1 addr 02:00:0e:66:5c:21 type managed wiphy 0 channel 64 (5320 MHz), width: 80 MHz, center1: 5290 MHz txpower 20.00 dBm multicast TXQ: qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets 0 0 0 0 0 0 0 0 0 root@linaro-alip:~# uname -a Linux linaro-alip 6.2.0-rc4-next-20230116-00029-gf1a46ff9e812-dirty #392 SMP PREEMPT Tue Jan 17 23:46:42 GMT 2023 aarch64 GNU/Linux --- bod
On 18/01/2023 11:50, Bryan O'Donoghue wrote: >>> + clocks = <&gcc GCC_MDSS_MDP_CLK>, >>> + <&gcc GCC_MDSS_AHB_CLK>, >>> + <&gcc GCC_MDSS_AXI_CLK>, >>> + <&gcc GCC_MDSS_BYTE1_CLK>, >>> + <&gcc GCC_MDSS_PCLK1_CLK>, >>> + <&gcc GCC_MDSS_ESC1_CLK>; >>> + clock-names = "mdp_core", >>> + "iface", >>> + "bus", >>> + "byte", >>> + "pixel", >>> + "core"; >>> + assigned-clocks = <&gcc BYTE1_CLK_SRC>, >>> + <&gcc PCLK1_CLK_SRC>; >>> + assigned-clock-parents = <&dsi_phy1 0>, >>> + <&dsi_phy1 1>; >> >> Does this work? Confusingly, BYTE1/PCLK1_CLK_SRC can only have dsi0pll >> as parent in gcc-msm8939 and not the dsi1pll. <&dsi_phy1 0/1> is not a >> valid parent for those clocks. > > No you're right, its all wrong. I will correct it > > mdss_dsi0: qcom,mdss_dsi@1a98000 { > compatible = "qcom,mdss-dsi-ctrl"; > label = "MDSS DSI CTRL->0"; > cell-index = <0>; > reg = <0x1a98000 0x25c>, > <0x1a98500 0x2b0>, > <0x193e000 0x30>; > reg-names = "dsi_ctrl", "dsi_phy", "mmss_misc_phys"; > qcom,mdss-fb-map = <&mdss_fb0>; > qcom,mdss-mdp = <&mdss_mdp>; > gdsc-supply = <&gdsc_mdss>; > vdda-supply = <&pm8916_l2>; > vdd-supply = <&pm8916_l17>; > vddio-supply = <&pm8916_l6>; > clocks = <&clock_gcc clk_gcc_mdss_mdp_clk>, > <&clock_gcc clk_gcc_mdss_ahb_clk>, > <&clock_gcc clk_gcc_mdss_axi_clk>, > <&clock_gcc_mdss clk_gcc_mdss_byte0_clk>, > <&clock_gcc_mdss clk_gcc_mdss_pclk0_clk>, > <&clock_gcc clk_gcc_mdss_esc0_clk>; Sorry what am I saying that's the wrong dsiX Here's downstream - byte1, plck1, esc1 exist mdss_dsi1: qcom,mdss_dsi@1aa0000 { compatible = "qcom,mdss-dsi-ctrl"; label = "MDSS DSI CTRL->1"; cell-index = <1>; reg = <0x1aa0000 0x25c>, <0x1aa0500 0x2b0>, <0x193e000 0x30>; reg-names = "dsi_ctrl", "dsi_phy", "mmss_misc_phys"; qcom,mdss-fb-map = <&mdss_fb0>; qcom,mdss-mdp = <&mdss_mdp>; gdsc-supply = <&gdsc_mdss>; vdda-supply = <&pm8916_l2>; vdd-supply = <&pm8916_l17>; vddio-supply = <&pm8916_l6>; clocks = <&clock_gcc clk_gcc_mdss_mdp_clk>, <&clock_gcc clk_gcc_mdss_ahb_clk>, <&clock_gcc clk_gcc_mdss_axi_clk>, <&clock_gcc_mdss clk_gcc_mdss_byte1_clk>, <&clock_gcc_mdss clk_gcc_mdss_pclk1_clk>, <&clock_gcc clk_gcc_mdss_esc1_clk>; clock-names = "mdp_core_clk", "iface_clk", "bus_clk", "byte_clk", "pixel_clk", "core_clk"; Parent clock is gpll0a but they waggle different rcgr addresses static struct clk_rcg2 byte0_clk_src = { .cmd_rcgr = 0x4d044, <- here .hid_width = 5, .parent_map = gcc_xo_gpll0a_dsibyte_map, .clkr.hw.init = &(struct clk_init_data){ .name = "byte0_clk_src", static struct clk_rcg2 byte1_clk_src = { .cmd_rcgr = 0x4d0b0, <- and here .hid_width = 5, .parent_map = gcc_xo_gpll0a_dsibyte_map, .clkr.hw.init = &(struct clk_init_data){ .name = "byte1_clk_src", It *should* work even with the wrong name but, I will send a GCC update to address the naming, which looks wrong. --- bod
On 17.01.2023 03:48, Bryan O'Donoghue wrote: > The XO crystal input is buffered through the PMIC and controlled by RPM. > Create the relevant clock gate representation in the RPM clock definitions. > > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Konrad > drivers/clk/qcom/clk-smd-rpm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c > index 8f6e274c60301..6f23ca4828f44 100644 > --- a/drivers/clk/qcom/clk-smd-rpm.c > +++ b/drivers/clk/qcom/clk-smd-rpm.c > @@ -574,6 +574,8 @@ static const struct rpm_smd_clk_desc rpm_clk_msm8916 = { > }; > > static struct clk_smd_rpm *msm8936_clks[] = { > + [RPM_SMD_XO_CLK_SRC] = &clk_smd_rpm_branch_bi_tcxo, > + [RPM_SMD_XO_A_CLK_SRC] = &clk_smd_rpm_branch_bi_tcxo_a, > [RPM_SMD_PCNOC_CLK] = &clk_smd_rpm_bus_0_pcnoc_clk, > [RPM_SMD_PCNOC_A_CLK] = &clk_smd_rpm_bus_0_pcnoc_a_clk, > [RPM_SMD_SNOC_CLK] = &clk_smd_rpm_bus_1_snoc_clk,
On Wed, Jan 18, 2023 at 12:05:50PM +0000, Bryan O'Donoghue wrote: > On 18/01/2023 08:47, Stephan Gerhold wrote: > > On Tue, Jan 17, 2023 at 02:48:39AM +0000, Bryan O'Donoghue wrote: > > > Document the MSM8939 and supported boards in upstream Sony "Tulip" M4 Aqua > > > and Square APQ8039 T2. > > > > > > MSM8939 is one of the older SoCs so we need to expand the list of > > > qcom,board-ids to allow for the bootloader DTS board-id matching > > > dependency. > > > > > > > The original LK bootloaders cannot boot your msm8939.dtsi correctly, > > because a spin-table implementation is required to get the other CPU > > cores up. This means that a modified bootloader is always needed from > > the upstream point of view, since I doubt anyone wants to use these > > devices with a single core only. lk2nd (as the primary spin-table > > implementation right now) has never required qcom,board-ids and any > > custom LK would be easy to patch to ignore these. > > The system boots just fine with the shipped LK. We get display, USB, SD, > WiFi. > > We just don't support booting the second cluster via any other means than > lk2nd right now. > > You could also not use lk2nd, stick with your default LK and import LPM > patches. > My point is: If you import out of tree LPM patches you can also just import an extra patch that adds the qcom,board-id property where needed. The qcom,board-id is only needed/used in configurations where you need to add those extra LPM patches on top anyway. Those configurations are (sadly) not supported from the upstream point of view, since only PSCI or spin-table are supposed to be used for CPU bring-up/idle. Anyway, for me personally there is no difference if the funky qcom,board-id properties are there or not, so I'll leave it up to Rob/Krzysztof to decide if the board-id exception is warranted here or not. :) Thanks, Stephan
On Wed, Jan 18, 2023 at 11:50:20AM +0000, Bryan O'Donoghue wrote: > On 18/01/2023 09:59, Stephan Gerhold wrote: > > On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: > [...] > > > + mdss: display-subsystem@1a00000 { > > > + compatible = "qcom,mdss"; > > > + reg = <0x01a00000 0x1000>, > > > + <0x01ac8000 0x3000>; > > > + reg-names = "mdss_phys", "vbif_phys"; > > > + > > > + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; > > > + interrupt-controller; > > > + > > > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > > > + <&gcc GCC_MDSS_AXI_CLK>, > > > + <&gcc GCC_MDSS_VSYNC_CLK>; > > > + clock-names = "iface", > > > + "bus", > > > + "vsync"; > > > + > > > + power-domains = <&gcc MDSS_GDSC>; > > > + > > > + #address-cells = <1>; > > > + #size-cells = <1>; > > > + #interrupt-cells = <1>; > > > + ranges; > > > + > > > + mdp: display-controller@1a01000 { > > > + compatible = "qcom,mdp5"; > > > + reg = <0x01a01000 0x89000>; > > > + reg-names = "mdp_phys"; > > > + > > > + interrupt-parent = <&mdss>; > > > + interrupts = <0>; > > > + > > > + clocks = <&gcc GCC_MDSS_AHB_CLK>, > > > + <&gcc GCC_MDSS_AXI_CLK>, > > > + <&gcc GCC_MDSS_MDP_CLK>, > > > + <&gcc GCC_MDSS_VSYNC_CLK>, > > > + <&gcc GCC_MDP_TBU_CLK>, > > > + <&gcc GCC_MDP_RT_TBU_CLK>; > > > + clock-names = "iface", > > > + "bus", > > > + "core", > > > + "vsync", > > > + "tbu", > > > + "tbu_rt"; > > > + > > > + iommus = <&apps_iommu 4>; > > > + > > > + interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>, > > > + <&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>, > > > + <&pcnoc MASTER_SPDM &snoc SLAVE_IMEM>; > > > + interconnect-names = "mdp0-mem", "mdp1-mem", "register-mem"; > > > > As I mentioned a already in a direct email at some point, AFAIU adding > > interconnects should be an [almost-] all or nothing step. If you only > > add interconnects for MDP then everything else that needs bandwidth will > > either break or only continue working as a mere side effect of MDP > > voting for permanent high bandwidth. > > We did discuss that. You'll also recall we concluded we would have to revert > this patch to make that happen. > > commit 76a748e2c1aa976d0c7fef872fa6ff93ce334a8a > Author: Leo Yan <leo.yan@linaro.org> > Date: Sat Apr 16 09:26:34 2022 +0800 > > interconnect: qcom: msm8939: Use icc_sync_state > > but then why not revert for all of these SoCs too ? > > drivers/interconnect/qcom/msm8939.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/msm8974.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/msm8996.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/osm-l3.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sc7180.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sc7280.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sc8180x.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sc8280xp.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sdm845.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sdx55.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sdx65.c: .sync_state = icc_sync_state, > drivers/interconnect/qcom/sm6350.c: .sync_state = icc_sync_state, > > until such time as we have an all or nothing interconnect setup for each of > those SoCs ? > > Yes I take your point "some peripherals will appear to work only as a result > of the AHB vote the MDP casts here" but, that is a bug in the definition of > that hypothetical peripheral. > > The MDP/display won't run without the interconnect here and the only way to > pull it is to remove sync_state which begs the question why not pull > sync_state for all SoCs without a perfect interconnect description ? > > I think that would be a retrograde step. > Most of the SoCs you list do have "interconnects" defined for most components, which means the situation for them is quite a different level. It's probably not necessary to have the interconnect setup absolutely perfect before enabling it. However to avoid frustration for people with slightly different board setups it should at the very least cover more than one component. Should the icc_sync_state() change be reverted for some of these SoCs? If you ask me: Yes! Perhaps a real example makes my concern more understandable: As I mentioned, you rely on MDP providing the necessary bandwidth for the entire system. This works fine in your case, but it can happen easily that MDSS/MDP is not enabled at all, e.g.: - On a board without display. - During early bring-up: I usually start with UART, USB and SDHCI before I even think about enabling the display. I simulated this on the BQ Aquaris M5 (MSM8939) that has most functionality set up already in postmarketOS. First the results without any changes (interconnects enabled like in your patch here): -> Boots into rootfs in about *18 seconds*, feels fine Now I just disable MDSS in the device tree and boot again: &mdss { status = "disabled"; }; -> Boots into rootfs in about *80 seconds*, everything feels sluggish This is 4 times the normal boot time, and nothing in dmesg tells me that it's because I don't have display enabled. Someone porting a new device, especially without UART, might have given up already before waiting so long. Plus, what would I do to fix this on a board without display? :/ Now I try removing icc_sync_state: -> Boots into rootfs in about 17 seconds, feels fine IMO it is clear that adding icc_sync_state() too early is a bad idea, and *will* break some setups. Thanks, Stephan
On Tue, 17 Jan 2023 02:48:38 +0000, Bryan O'Donoghue wrote: > V3: > - Happily I don't currently depend on any other series to be merged. > Bjorn and Chanwoo picked up everything I need to unblock this series. ＼(^o^)／ > > - Moves xo_board to RPM/PMIC clock gated CXO, not including rpmcc: obvs - Konrad/Bjorn > - qcom,msm-id = <239 0> - left as in V2 valid according to Sony references - bod > - cpu-release-addr - as stated below we rely on lk2nd to take the second cluster > out of reset - bod > - smem child node update - Konrad > - Whitespace updates - Konrad > - gpu no interconnect - Konrad - No bod > - 19.2 MHz dropped from timer@b020000 - Konrad > - Added vreg_dummy comment - Konrad > - sdc_pins grouped - Konrad > - startup-delay-us = <0> - left as is > - bias - added no-bias - Konrad > - :g/msmgpio/s//tlmm/g - Konrad > - mdss/s//display-controller - Konrad > - l11 set-load - Korad > > [...] Applied, thanks! [4/8] clk: qcom: smd-rpm: msm8936: Add PMIC gated RPM_SMD_XO_* commit: d03de4179540e9cee6e3f664e1b65178f07bb612 Best regards,
On 18/01/2023 08:47, Stephan Gerhold wrote: > If we don't support the original bootloaders in a usable way upstream > then we should not add MSM8939 to the allow list of broken bootloaders > either, in my opinion. Yes but, a vendor could just as easily cherry-pick the spin-table enabling lk2nd patches back to their lk implementation and begin to drop the ongoing burden of supporting the LPM stuff. We certainly do and should support booting stock lk. There's no sense in setting the bar to upstream even higher by imposing a chainloaded bootloader on our hypothetical new user. The right thing to do is to enable the vanilla path but, give the user the extra option. --- bod
On 18/01/2023 17:33, Stephan Gerhold wrote: > On Wed, Jan 18, 2023 at 11:50:20AM +0000, Bryan O'Donoghue wrote: >> On 18/01/2023 09:59, Stephan Gerhold wrote: >>> On Tue, Jan 17, 2023 at 02:48:43AM +0000, Bryan O'Donoghue wrote: >> [...] >>>> + mdss: display-subsystem@1a00000 { >>>> + compatible = "qcom,mdss"; >>>> + reg = <0x01a00000 0x1000>, >>>> + <0x01ac8000 0x3000>; >>>> + reg-names = "mdss_phys", "vbif_phys"; >>>> + >>>> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; >>>> + interrupt-controller; >>>> + >>>> + clocks = <&gcc GCC_MDSS_AHB_CLK>, >>>> + <&gcc GCC_MDSS_AXI_CLK>, >>>> + <&gcc GCC_MDSS_VSYNC_CLK>; >>>> + clock-names = "iface", >>>> + "bus", >>>> + "vsync"; >>>> + >>>> + power-domains = <&gcc MDSS_GDSC>; >>>> + >>>> + #address-cells = <1>; >>>> + #size-cells = <1>; >>>> + #interrupt-cells = <1>; >>>> + ranges; >>>> + >>>> + mdp: display-controller@1a01000 { >>>> + compatible = "qcom,mdp5"; >>>> + reg = <0x01a01000 0x89000>; >>>> + reg-names = "mdp_phys"; >>>> + >>>> + interrupt-parent = <&mdss>; >>>> + interrupts = <0>; >>>> + >>>> + clocks = <&gcc GCC_MDSS_AHB_CLK>, >>>> + <&gcc GCC_MDSS_AXI_CLK>, >>>> + <&gcc GCC_MDSS_MDP_CLK>, >>>> + <&gcc GCC_MDSS_VSYNC_CLK>, >>>> + <&gcc GCC_MDP_TBU_CLK>, >>>> + <&gcc GCC_MDP_RT_TBU_CLK>; >>>> + clock-names = "iface", >>>> + "bus", >>>> + "core", >>>> + "vsync", >>>> + "tbu", >>>> + "tbu_rt"; >>>> + >>>> + iommus = <&apps_iommu 4>; >>>> + >>>> + interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>, >>>> + <&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>, >>>> + <&pcnoc MASTER_SPDM &snoc SLAVE_IMEM>; >>>> + interconnect-names = "mdp0-mem", "mdp1-mem", "register-mem"; >>> >>> As I mentioned a already in a direct email at some point, AFAIU adding >>> interconnects should be an [almost-] all or nothing step. If you only >>> add interconnects for MDP then everything else that needs bandwidth will >>> either break or only continue working as a mere side effect of MDP >>> voting for permanent high bandwidth. >> >> We did discuss that. You'll also recall we concluded we would have to revert >> this patch to make that happen. >> >> commit 76a748e2c1aa976d0c7fef872fa6ff93ce334a8a >> Author: Leo Yan <leo.yan@linaro.org> >> Date: Sat Apr 16 09:26:34 2022 +0800 >> >> interconnect: qcom: msm8939: Use icc_sync_state >> >> but then why not revert for all of these SoCs too ? >> >> drivers/interconnect/qcom/msm8939.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/msm8974.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/msm8996.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/osm-l3.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sc7180.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sc7280.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sc8180x.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sc8280xp.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sdm845.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sdx55.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sdx65.c: .sync_state = icc_sync_state, >> drivers/interconnect/qcom/sm6350.c: .sync_state = icc_sync_state, >> >> until such time as we have an all or nothing interconnect setup for each of >> those SoCs ? >> >> Yes I take your point "some peripherals will appear to work only as a result >> of the AHB vote the MDP casts here" but, that is a bug in the definition of >> that hypothetical peripheral. >> >> The MDP/display won't run without the interconnect here and the only way to >> pull it is to remove sync_state which begs the question why not pull >> sync_state for all SoCs without a perfect interconnect description ? >> >> I think that would be a retrograde step. >> > > Most of the SoCs you list do have "interconnects" defined for most > components, which means the situation for them is quite a different > level. 8974 defines two interconnects one for the mdp, one of the gpu. So a headless setup as you describe would encounter the same situation potentially. > I simulated this on the BQ Aquaris M5 (MSM8939) that has most > functionality set up already in postmarketOS. First the results without > any changes (interconnects enabled like in your patch here): To me, that is indicative of more work being required to vote appropriately for required bandwidth - AHB clocks basically in our hypothetical setup. The display certainly won't work without voting for bandwidth it needs. If there's work to be done to _enable_ headless mode - and there is, we can do the work to figure out who isn't voting for bandwidth. Probably the CPU - absent cpufreq, CPR, the operating points. A good - probably correct guess is we aren't ramping cpufreq, aren't ramping CCI and aren't voting for the inter-chip CCI "front side" so when the system boots headless and "does stuff" the cpufrequency stays low, the votes aren't cast and everything seems to crawl. I still think its a contrived example though. CPR will come right after the core dtsi and we can put the theory to the test. ;) --- bod
On 17/01/2023 20:58, Bjorn Andersson wrote: > Once the remote pulls the "handover" interrupt, it signals that it has > cast the necessary votes and need no more hand-holding. > > So it's unlikely that _AO is the right choice here. For the record here's the downstream _AO is what it says pronto: wcnss@a204000 { compatible = "qcom,pronto-v2-pd-pil", "qcom,pronto"; reg = <0x0a204000 0x2000>, <0x0a202000 0x1000>, <0x0a21b000 0x3000>; power-domains = <&rpmpd MSM8939_VDDCX>, <&rpmpd MSM8939_VDDMX_AO>; power-domain-names = "vddcx", "vddmx"; }; --- bod
On 20/01/2023 00:40, Bryan O'Donoghue wrote: > > pronto: wcnss@a204000 { > compatible = "qcom,pronto-v2-pd-pil", "qcom,pronto"; > reg = <0x0a204000 0x2000>, <0x0a202000 0x1000>, <0x0a21b000 > 0x3000>; > > power-domains = <&rpmpd MSM8939_VDDCX>, > <&rpmpd MSM8939_VDDMX_AO>; > power-domain-names = "vddcx", "vddmx"; > }; > > --- > bod Doh. I opened the 4.19 kernel ... not 3.18 *facepalm*
On 20/01/2023 00:42, Bryan O'Donoghue wrote: > On 20/01/2023 00:40, Bryan O'Donoghue wrote: >> >> pronto: wcnss@a204000 { >> compatible = "qcom,pronto-v2-pd-pil", "qcom,pronto"; >> reg = <0x0a204000 0x2000>, <0x0a202000 0x1000>, <0x0a21b000 >> 0x3000>; >> >> power-domains = <&rpmpd MSM8939_VDDCX>, >> <&rpmpd MSM8939_VDDMX_AO>; >> power-domain-names = "vddcx", "vddmx"; >> }; >> >> --- >> bod > > Doh. > > I opened the 4.19 kernel ... not 3.18 > > *facepalm* But *this* is the downstream qcom,wcnss-wlan@0a000000 { compatible = "qcom,wcnss_wlan"; qcom,pronto-vddmx-supply = <&pm8916_l3_corner_ao>; qcom,pronto-vddcx-supply = <&pm8916_s2_corner>; }; it is an _ao --- bod
On 18/01/2023 09:59, Stephan Gerhold wrote: > Why are you adding a dummy power domain here? IMO this would be better > added together with CPR. Especially because I would expect two power > domains here later ("mx", "cpr"). For cpufreq you also need to make > votes for the "MSM8939_VDDMX" power domain. Confirmed power-domain is a required property, dtbs check will complain without it. I'll leave further discussion on the format of CPR for the CPR series but our working example supposes the below as a starting point. I'm not aware of VDDMX in the CPR path but its not at this node. CPU2: cpu@102 { device_type = "cpu"; compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x102>; next-level-cache = <&L2_1>; enable-method = "qcom,kpss-acc-v2"; qcom,acc = <&acc2>; qcom,saw = <&saw2>; clocks = <&apcs1>; operating-points-v2 = <&cluster1_opp_table>; power-domains = <&cpr>; power-domain-names = "cpr"; #cooling-cells = <2>; capacity-dmips-mhz = <1024>; }; cluster1_opp_table: cluster1-opp-table { compatible = "operating-points-v2-qcom-cpu"; opp-shared; /* Used by qcom-cpufreq-nvmem.c */ nvmem-cells = <&cpr_efuse_speedbin_pvs>; nvmem-cell-names = "cpr_efuse_speedbin_pvs"; opp-200000000 { opp-hz = /bits/ 64 <200000000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; opp-345600000 { opp-hz = /bits/ 64 <345600000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; }; cpr_opp_table: cpr-opp-table { compatible = "operating-points-v2-qcom-level"; cpr_opp1: opp1 { opp-hz = /bits/ 64 <200000000>; opp-level = <1>; qcom,opp-fuse-level = <1>; }; cpr_opp2: opp2 { opp-hz = /bits/ 64 <345600000>; opp-level = <2>; qcom,opp-fuse-level = <1>; }; cpr_opp3: opp3 { opp-hz = /bits/ 64 <400000000>; opp-level = <3>; qcom,opp-fuse-level = <1>; }; }; /* etc */ }; --- bod
V3: - Happily I don't currently depend on any other series to be merged. Bjorn and Chanwoo picked up everything I need to unblock this series. ＼(^o^)／ - Moves xo_board to RPM/PMIC clock gated CXO, not including rpmcc: obvs - Konrad/Bjorn - qcom,msm-id = <239 0> - left as in V2 valid according to Sony references - bod - cpu-release-addr - as stated below we rely on lk2nd to take the second cluster out of reset - bod - smem child node update - Konrad - Whitespace updates - Konrad - gpu no interconnect - Konrad - No bod - 19.2 MHz dropped from timer@b020000 - Konrad - Added vreg_dummy comment - Konrad - sdc_pins grouped - Konrad - startup-delay-us = <0> - left as is - bias - added no-bias - Konrad - :g/msmgpio/s//tlmm/g - Konrad - mdss/s//display-controller - Konrad - l11 set-load - Korad - l12 upper voltage raised to 3.3v since this is what the downstream kernel says when I boot and interrogate it - bod - sdhc@address - Discussed with Krzysztof and implemented as discussed - snoc-mm fix - Discussed with Krzysztof implemented if:then:else:not - dtc -I dtb -fs apq8039-t2.dtb prodcues /soc@0/i2c@78b5000: duplicate unit-address as does every other component that uses this polymorphic dts node - Renamed type-c i2c port manager IC to "typec" - Krzysztof /smsm/hexagon@1: Missing #address-cells in interrupt provider Same output as other upstream and recently upstreamed SoCs I left these alone for now link: https://lore.kernel.org/lkml/20230103010904.3201835-1-bryan.odonoghue@linaro.org/T/ bootable: https://git.linaro.org/people/bryan.odonoghue/kernel.git/log/?h=linux-next-23-01-16-msm8939-nocpr V2: - Sorts core dtsi node list by address followed by alpahbetical sorting within address sorted nodes - Bjorn - Drops use of 8916-pins - Bjorn - Adds msm8939-pm8916.dtsi - Stephan - Fixes every dts splat from previous submission minus non-converted .txt compat strings [1] and one yaml error in Bjorn's tree not in -next yet - I haven't applied Dmitry's change for tsens since that's not been picked up yet - Picks up a number of suggestions and fixes from Stephan Gerhold and Vincent Knecht - Depends on Applied: [PATCH v4 0/7] remoteproc: qcom_q6v5_mss: Add MSM8909 and MSM8953 https://lore.kernel.org/linux-arm-msm/167216232800.738877.17567287056128563074.b4-ty@kernel.org/ [PATCH v6 0/5] remoteproc: qcom: Add support for pronto-v3 https://lore.kernel.org/linux-arm-msm/167216232801.738877.15895916910585144737.b4-ty@kernel.org/ [PATCH v6 00/18] mdss-dsi-ctrl binding and dts fixes https://lore.kernel.org/linux-arm-msm/167233461766.1099840.17628700245792986354.b4-ty@kernel.org/ Awaiting application: https://lore.kernel.org/linux-arm-msm/20221228133058.213886-1-bryan.odonoghue@linaro.org/ - Previous https://lore.kernel.org/linux-arm-msm/20220419010903.3109514-1-bryan.odonoghue@linaro.org/ - Bootable tree https://git.linaro.org/people/bryan.odonoghue/kernel.git/log/?h=linux-next-23-01-03-msm8939-no-cpr - [1] DTC_CHK arch/arm64/boot/dts/qcom/apq8039-t2.dtb Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt qcom/apq8039-t2.dtb: idle-states: cpu-sleep-0:compatible:0: 'qcom,idle-state-spc' is not one of ['arm,idle-state', 'riscv,idle-state'] From schema: Documentation/devicetree/bindings/cpu/idle-states.yaml qcom/apq8039-t2.dtb: idle-states: cpu-sleep-0:compatible: ['qcom,idle-state-spc', 'arm,idle-state'] is too long From schema: Documentation/devicetree/bindings/cpu/idle-states.yaml arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /cpus/idle-states/cpu-sleep-0: failed to match any schema with compatible: ['qcom,idle-state-spc', 'arm,idle-state'] Documentation/devicetree/bindings/iommu/qcom,iommu.txt arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1ef0000: failed to match any schema with compatible: ['qcom,msm8916-iommu', 'qcom,msm-iommu-v1'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1ef0000/iommu-ctx@4000: failed to match any schema with compatible: ['qcom,msm-iommu-v1-ns'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1ef0000/iommu-ctx@5000: failed to match any schema with compatible: ['qcom,msm-iommu-v1-sec'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1f08000: failed to match any schema with compatible: ['qcom,msm8916-iommu', 'qcom,msm-iommu-v1'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1f08000/iommu-ctx@1000: failed to match any schema with compatible: ['qcom,msm-iommu-v1-ns'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/iommu@1f08000/iommu-ctx@2000: failed to match any schema with compatible: ['qcom,msm-iommu-v1-ns'] arch/arm64/boot/dts/qcom/pm8916.dtsi f5d7bca55425c8 qcom/apq8039-t2.dtb: pmic@0: 'extcon@1300' does not match any of the regexes: '(.*)?(wled|leds)@[0-9a-f]+$', '^adc-tm@[0-9a-f]+$', '^adc@[0-9a-f]+$', '^audio-codec@[0-9a-f]+$', '^charger@[0-9a-f]+$', '^mpps@[0-9a-f]+$', '^rtc@[0-9a-f]+$', '^temp-alarm@[0-9a-f]+$', '^usb-detect@[0-9a-f]+$', '^usb-vbus-regulator@[0-9a-f]+$', '^vibrator@[0-9a-f]+$', 'gpio@[0-9a-f]+$', 'pinctrl-[0-9]+', 'pon@[0-9a-f]+$' From schema: Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml Documentation/devicetree/bindings/sound/qcom,msm8916-wcd-analog.txt arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/spmi@200f000/pmic@1/audio-codec@f000: failed to match any schema with compatible: ['qcom,pm8916-wcd-analog-codec'] yaml documentation error not yet in -next arm64/boot/dts/qcom/apq8039-t2.dtb: remoteproc@4080000: qcom,halt-regs:0: [33] is too short From schema: Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/usb@78d9000: failed to match any schema with compatible: ['qcom,ci-hdrc'] Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt: compatible = "qcom,kpss-acc-v2"; arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b088000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b098000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b0a8000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b0b8000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b188000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b198000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b1a8000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] arch/arm64/boot/dts/qcom/apq8039-t2.dtb:0:0: /soc@0/clock-controller@b1b8000: failed to match any schema with compatible: ['qcom,kpss-acc-v2'] V1: This series adds in MSM8939 SoC support with two supported devices. - CPU MSM8939 is a non-PSCI compliant device. As such in the downstreaming shipped image custom code is used to bring non-boot cores out of reset. This drop specifies the boot-method as spin-table instead and is completely standard. To accomplish this, we rely on lk2nd. https://github.com/msm8916-mainline/lk2nd/pull/142 - Serial - i2c - USB - eMMC - MDP/DSI - WiFi - Bluetooth What's not included - CPR We have CPR working in a 4.19 kernel quite well but for now it feels like putting the cart before the horse to gate the SoC and boards on CPR. - Venus I've been told this works but I haven't tried it myself and right now consider it maybe working but probably not 100%. - Sound We have a copy-exactly from the 4.19 kernel here in the DTS. I haven't run the sound through any sort of reasonable test. Vincent Knecht has some PostmarketOS kernels which use a 5.17 version of this DTS to get sound up so, I think sound is in good shape. - CAMSS There are slight differences between msm8916 and msm8939 for CAMSS. It doesn't feel like tons of work but, right now it is work we haven't even started. - Devices I've booted on the Square device obviously and this is my regular hardware for upstream development. I've also booted on the Sony Xperia M4 Aqua including mutli-core bring-up, WiFi and ADB. Dependencies for this drop: qcom-cpufreq-nvmem: Add msm8939 with some fixups link: https://lore.kernel.org/linux-arm-msm/20220418162226.2983117-1-bryan.odonoghue@linaro.org/T/#t Fix apq8016 compat string link: https://lore.kernel.org/linux-arm-msm/20220418230956.3059563-1-bryan.odonoghue@linaro.org/T/#t dt-bindings: soc: qcom: smd-rpm: Fix missing MSM8936 compatible link: https://lore.kernel.org/linux-arm-msm/20220418231857.3061053-1-bryan.odonoghue@linaro.org/T/#u Bootable tree here: https://git.linaro.org/people/bryan.odonoghue/kernel.git/log/?h=v5.18-rc2%2bapq8039-without-cpr Bryan O'Donoghue (7): dt-bindings: arm: qcom: Document MSM8939 SoC binding dt-bindings: soc: qcom: smd-rpm: Exclude MSM8936 from glink-channels dt-bindings: interconnect: Exclude all non msm8939 from snoc-mm clk: qcom: smd-rpm: msm8936: Add PMIC gated RPM_SMD_XO_* arm64: dts: qcom: Add msm8939 SoC arm64: dts: qcom: Add Square apq8039-t2 board arm64: dts: qcom: Add msm8939 Sony Xperia M4 Aqua Stephan Gerhold (1): arm64: dts: qcom: Add msm8939-pm8916.dtsi include .../devicetree/bindings/arm/qcom.yaml | 8 + .../bindings/interconnect/qcom,rpm.yaml | 73 +- .../bindings/soc/qcom/qcom,smd-rpm.yaml | 1 + arch/arm64/boot/dts/qcom/Makefile | 2 + arch/arm64/boot/dts/qcom/apq8039-t2.dts | 555 ++++ arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi | 82 + .../qcom/msm8939-sony-xperia-kanuti-tulip.dts | 466 ++++ arch/arm64/boot/dts/qcom/msm8939.dtsi | 2393 +++++++++++++++++ drivers/clk/qcom/clk-smd-rpm.c | 2 + 9 files changed, 3551 insertions(+), 31 deletions(-) create mode 100644 arch/arm64/boot/dts/qcom/apq8039-t2.dts create mode 100644 arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi create mode 100644 arch/arm64/boot/dts/qcom/msm8939-sony-xperia-kanuti-tulip.dts create mode 100644 arch/arm64/boot/dts/qcom/msm8939.dtsi