Message ID | 90114e06825e537c3aafd3de5c78743a9de6fadc.1564550873.git.saiprakash.ranjan@codeaurora.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Add coresight support for SDM845, MSM8998 and MSM8996 | expand |
Sai, This patch breaks boot on the 835 laptops. However, I haven't seen the same issue on the MTP. I wonder, is coresight expected to work with production fused devices? I wonder if thats the difference between the laptop and MTP that is causing the issue. Let me know what I can do to help debug. On Tue, Jul 30, 2019 at 11:59 PM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > Enable coresight support by adding device nodes for the > available source, sinks and channel blocks on MSM8998. > > Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> > Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> > Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> > --- > arch/arm64/boot/dts/qcom/msm8998.dtsi | 435 ++++++++++++++++++++++++++ > 1 file changed, 435 insertions(+) > > diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi > index c13ed7aeb1e0..ad661fcc9e1b 100644 > --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi > +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi > @@ -822,6 +822,441 @@ > #interrupt-cells = <0x2>; > }; > > + stm@6002000 { > + compatible = "arm,coresight-stm", "arm,primecell"; > + reg = <0x06002000 0x1000>, > + <0x16280000 0x180000>; > + reg-names = "stm-base", "stm-data-base"; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + stm_out: endpoint { > + remote-endpoint = <&funnel0_in7>; > + }; > + }; > + }; > + }; > + > + funnel@6041000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0x06041000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + funnel0_out: endpoint { > + remote-endpoint = > + <&merge_funnel_in0>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@7 { > + reg = <7>; > + funnel0_in7: endpoint { > + remote-endpoint = <&stm_out>; > + }; > + }; > + }; > + }; > + > + funnel@6042000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0x06042000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + funnel1_out: endpoint { > + remote-endpoint = > + <&merge_funnel_in1>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@6 { > + reg = <6>; > + funnel1_in6: endpoint { > + remote-endpoint = > + <&apss_merge_funnel_out>; > + }; > + }; > + }; > + }; > + > + funnel@6045000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0x06045000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + merge_funnel_out: endpoint { > + remote-endpoint = > + <&etf_in>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + merge_funnel_in0: endpoint { > + remote-endpoint = > + <&funnel0_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + merge_funnel_in1: endpoint { > + remote-endpoint = > + <&funnel1_out>; > + }; > + }; > + }; > + }; > + > + replicator@6046000 { > + compatible = "arm,coresight-dynamic-replicator", "arm,primecell"; > + reg = <0x06046000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + replicator_out: endpoint { > + remote-endpoint = <&etr_in>; > + }; > + }; > + }; > + > + in-ports { > + port { > + replicator_in: endpoint { > + remote-endpoint = <&etf_out>; > + }; > + }; > + }; > + }; > + > + etf@6047000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0x06047000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + etf_out: endpoint { > + remote-endpoint = > + <&replicator_in>; > + }; > + }; > + }; > + > + in-ports { > + port { > + etf_in: endpoint { > + remote-endpoint = > + <&merge_funnel_out>; > + }; > + }; > + }; > + }; > + > + etr@6048000 { > + compatible = "arm,coresight-tmc", "arm,primecell"; > + reg = <0x06048000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + arm,scatter-gather; > + > + in-ports { > + port { > + etr_in: endpoint { > + remote-endpoint = > + <&replicator_out>; > + }; > + }; > + }; > + }; > + > + etm@7840000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07840000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU0>; > + > + out-ports { > + port { > + etm0_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in0>; > + }; > + }; > + }; > + }; > + > + etm@7940000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07940000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU1>; > + > + out-ports { > + port { > + etm1_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in1>; > + }; > + }; > + }; > + }; > + > + etm@7a40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07a40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU2>; > + > + out-ports { > + port { > + etm2_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in2>; > + }; > + }; > + }; > + }; > + > + etm@7b40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07b40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU3>; > + > + out-ports { > + port { > + etm3_out: endpoint { > + remote-endpoint = > + <&apss_funnel_in3>; > + }; > + }; > + }; > + }; > + > + funnel@7b60000 { /* APSS Funnel */ > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07b60000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + apss_funnel_out: endpoint { > + remote-endpoint = > + <&apss_merge_funnel_in>; > + }; > + }; > + }; > + > + in-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + port@0 { > + reg = <0>; > + apss_funnel_in0: endpoint { > + remote-endpoint = > + <&etm0_out>; > + }; > + }; > + > + port@1 { > + reg = <1>; > + apss_funnel_in1: endpoint { > + remote-endpoint = > + <&etm1_out>; > + }; > + }; > + > + port@2 { > + reg = <2>; > + apss_funnel_in2: endpoint { > + remote-endpoint = > + <&etm2_out>; > + }; > + }; > + > + port@3 { > + reg = <3>; > + apss_funnel_in3: endpoint { > + remote-endpoint = > + <&etm3_out>; > + }; > + }; > + > + port@4 { > + reg = <4>; > + apss_funnel_in4: endpoint { > + remote-endpoint = > + <&etm4_out>; > + }; > + }; > + > + port@5 { > + reg = <5>; > + apss_funnel_in5: endpoint { > + remote-endpoint = > + <&etm5_out>; > + }; > + }; > + > + port@6 { > + reg = <6>; > + apss_funnel_in6: endpoint { > + remote-endpoint = > + <&etm6_out>; > + }; > + }; > + > + port@7 { > + reg = <7>; > + apss_funnel_in7: endpoint { > + remote-endpoint = > + <&etm7_out>; > + }; > + }; > + }; > + }; > + > + funnel@7b70000 { > + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; > + reg = <0x07b70000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + out-ports { > + port { > + apss_merge_funnel_out: endpoint { > + remote-endpoint = > + <&funnel1_in6>; > + }; > + }; > + }; > + > + in-ports { > + port { > + apss_merge_funnel_in: endpoint { > + remote-endpoint = > + <&apss_funnel_out>; > + }; > + }; > + }; > + }; > + > + etm@7c40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07c40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU4>; > + > + port{ > + etm4_out: endpoint { > + remote-endpoint = <&apss_funnel_in4>; > + }; > + }; > + }; > + > + etm@7d40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07d40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU5>; > + > + port{ > + etm5_out: endpoint { > + remote-endpoint = <&apss_funnel_in5>; > + }; > + }; > + }; > + > + etm@7e40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07e40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU6>; > + > + port{ > + etm6_out: endpoint { > + remote-endpoint = <&apss_funnel_in6>; > + }; > + }; > + }; > + > + etm@7f40000 { > + compatible = "arm,coresight-etm4x", "arm,primecell"; > + reg = <0x07f40000 0x1000>; > + > + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; > + clock-names = "apb_pclk", "atclk"; > + > + cpu = <&CPU7>; > + > + port{ > + etm7_out: endpoint { > + remote-endpoint = <&apss_funnel_in7>; > + }; > + }; > + }; > + > spmi_bus: spmi@800f000 { > compatible = "qcom,spmi-pmic-arb"; > reg = <0x800f000 0x1000>, > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 2019-10-01 09:13, Jeffrey Hugo wrote: > Sai, > > This patch breaks boot on the 835 laptops. However, I haven't seen > the same issue on the MTP. I wonder, is coresight expected to work > with production fused devices? I wonder if thats the difference > between the laptop and MTP that is causing the issue. > > Let me know what I can do to help debug. > I did test on MSM8998 MTP and didn't face any issue. I am guessing this is the same issue which you reported regarding cpuidle? Coresight ETM and cpuidle do not work well together since ETMs share the same power domain as CPU and they might get turned off when CPU enters idle states. Can you try with cpuidle.off=1 cmdline or just remove idle states from DT to confirm? If this is the issue, then we can try the below patch from Andrew Murray for ETM save and restore: https://patchwork.kernel.org/patch/11097893/ It is not merged yet. They would appreciate your tested by ;) Thanks, Sai
On Tue, Oct 1, 2019 at 11:04 AM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > On 2019-10-01 09:13, Jeffrey Hugo wrote: > > Sai, > > > > This patch breaks boot on the 835 laptops. However, I haven't seen > > the same issue on the MTP. I wonder, is coresight expected to work > > with production fused devices? I wonder if thats the difference > > between the laptop and MTP that is causing the issue. > > > > Let me know what I can do to help debug. > > > > I did test on MSM8998 MTP and didn't face any issue. I am guessing this > is the same issue which you reported regarding cpuidle? Coresight ETM Yes, its the same issue. Right now, I need both patches reverted to boot. > and cpuidle do not work well together since ETMs share the same power > domain as CPU and they might get turned off when CPU enters idle states. > Can you try with cpuidle.off=1 cmdline or just remove idle states from > DT to confirm? If this is the issue, then we can try the below patch > from Andrew Murray for ETM save and restore: > > https://patchwork.kernel.org/patch/11097893/ Is there still value in testing this if the idle states are removed, yet the coresight nodes still cause issues? Funny enough, I'm using the arm64 defconfig which doesn't seem to select CONFIG_CORESIGHT, so I'm not even sure what would be binding to the DT devices... > > It is not merged yet. They would appreciate your tested by ;) > > Thanks, > Sai
On 01/10/2019 18:14, Jeffrey Hugo wrote: > On Tue, Oct 1, 2019 at 11:04 AM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> On 2019-10-01 09:13, Jeffrey Hugo wrote: >>> Sai, >>> >>> This patch breaks boot on the 835 laptops. However, I haven't seen >>> the same issue on the MTP. I wonder, is coresight expected to work >>> with production fused devices? I wonder if thats the difference >>> between the laptop and MTP that is causing the issue. >>> >>> Let me know what I can do to help debug. >>> >> >> I did test on MSM8998 MTP and didn't face any issue. I am guessing this >> is the same issue which you reported regarding cpuidle? Coresight ETM > > Yes, its the same issue. Right now, I need both patches reverted to boot. > >> and cpuidle do not work well together since ETMs share the same power >> domain as CPU and they might get turned off when CPU enters idle states. >> Can you try with cpuidle.off=1 cmdline or just remove idle states from >> DT to confirm? If this is the issue, then we can try the below patch >> from Andrew Murray for ETM save and restore: >> >> https://patchwork.kernel.org/patch/11097893/ > > Is there still value in testing this if the idle states are removed, > yet the coresight nodes still cause issues? > > Funny enough, I'm using the arm64 defconfig which doesn't seem to > select CONFIG_CORESIGHT, so I'm not even sure what would be binding to > the DT devices... That looks like potentially missing Power domain support, either in the kernel or from the firmware. The Coresight components are also AMBA devices (with primecell compatible) and thus the AMBA bus layer does some probing to check the PIDRx registers to match the driver. The AMBA layer does try to get the power to the component, but someone is lying that it is powered. Suzuki
On 2019-10-01 10:14, Jeffrey Hugo wrote: > On Tue, Oct 1, 2019 at 11:04 AM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> On 2019-10-01 09:13, Jeffrey Hugo wrote: >> > Sai, >> > >> > This patch breaks boot on the 835 laptops. However, I haven't seen >> > the same issue on the MTP. I wonder, is coresight expected to work >> > with production fused devices? I wonder if thats the difference >> > between the laptop and MTP that is causing the issue. >> > >> > Let me know what I can do to help debug. >> > >> >> I did test on MSM8998 MTP and didn't face any issue. I am guessing >> this >> is the same issue which you reported regarding cpuidle? Coresight ETM > > Yes, its the same issue. Right now, I need both patches reverted to > boot. > >> and cpuidle do not work well together since ETMs share the same power >> domain as CPU and they might get turned off when CPU enters idle >> states. >> Can you try with cpuidle.off=1 cmdline or just remove idle states from >> DT to confirm? If this is the issue, then we can try the below patch >> from Andrew Murray for ETM save and restore: >> >> https://patchwork.kernel.org/patch/11097893/ > > Is there still value in testing this if the idle states are removed, > yet the coresight nodes still cause issues? > > Funny enough, I'm using the arm64 defconfig which doesn't seem to > select CONFIG_CORESIGHT, so I'm not even sure what would be binding to > the DT devices... > Haan then likely it's the firmware issue. We should probably disable coresight in soc dtsi and enable only for MTP. For now you can add a status=disabled for all coresight nodes in msm8998.dtsi and I will send the patch doing the same in a day or two(sorry I am travelling currently). Thanks, Sai
On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > On 2019-10-01 10:14, Jeffrey Hugo wrote: > > On Tue, Oct 1, 2019 at 11:04 AM Sai Prakash Ranjan > > <saiprakash.ranjan@codeaurora.org> wrote: > >> > >> On 2019-10-01 09:13, Jeffrey Hugo wrote: > >> > Sai, > >> > > >> > This patch breaks boot on the 835 laptops. However, I haven't seen > >> > the same issue on the MTP. I wonder, is coresight expected to work > >> > with production fused devices? I wonder if thats the difference > >> > between the laptop and MTP that is causing the issue. > >> > > >> > Let me know what I can do to help debug. > >> > > >> > >> I did test on MSM8998 MTP and didn't face any issue. I am guessing > >> this > >> is the same issue which you reported regarding cpuidle? Coresight ETM > > > > Yes, its the same issue. Right now, I need both patches reverted to > > boot. > > > >> and cpuidle do not work well together since ETMs share the same power > >> domain as CPU and they might get turned off when CPU enters idle > >> states. > >> Can you try with cpuidle.off=1 cmdline or just remove idle states from > >> DT to confirm? If this is the issue, then we can try the below patch > >> from Andrew Murray for ETM save and restore: > >> > >> https://patchwork.kernel.org/patch/11097893/ > > > > Is there still value in testing this if the idle states are removed, > > yet the coresight nodes still cause issues? > > > > Funny enough, I'm using the arm64 defconfig which doesn't seem to > > select CONFIG_CORESIGHT, so I'm not even sure what would be binding to > > the DT devices... > > > > Haan then likely it's the firmware issue. > We should probably disable coresight in soc dtsi and enable only for > MTP. For now you can add a status=disabled for all coresight nodes in > msm8998.dtsi and I will send the patch doing the same in a day or > two(sorry I am travelling currently). This sounds sane to me (and is what I did while bisecting the issue). When you do create the patch, feel free to add the following tags as you see fit. Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
On 2019-10-01 11:01, Jeffrey Hugo wrote: > On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: >> >> >> Haan then likely it's the firmware issue. >> We should probably disable coresight in soc dtsi and enable only for >> MTP. For now you can add a status=disabled for all coresight nodes in >> msm8998.dtsi and I will send the patch doing the same in a day or >> two(sorry I am travelling currently). > > This sounds sane to me (and is what I did while bisecting the issue). > When you do create the patch, feel free to add the following tags as > you see fit. > > Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Thanks Jeffrey, I will add them. Hope Mathieu and Suzuki are OK with this. Thanks, Sai
On Tue, 1 Oct 2019 at 12:05, Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> wrote: > > On 2019-10-01 11:01, Jeffrey Hugo wrote: > > On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan > > <saiprakash.ranjan@codeaurora.org> wrote: > >> > >> > >> Haan then likely it's the firmware issue. > >> We should probably disable coresight in soc dtsi and enable only for > >> MTP. For now you can add a status=disabled for all coresight nodes in > >> msm8998.dtsi and I will send the patch doing the same in a day or > >> two(sorry I am travelling currently). > > > > This sounds sane to me (and is what I did while bisecting the issue). > > When you do create the patch, feel free to add the following tags as > > you see fit. > > > > Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > Thanks Jeffrey, I will add them. > Hope Mathieu and Suzuki are OK with this. The problem here is that a debug and production device are using the same device tree, i.e msm8998.dtsi. Disabling coresight devices in the DTS file will allow the laptop to boot but completely disabled coresight blocks on the MTP board. Leaving things as is breaks the laptop but allows coresight to be used on the MTP board. One of three things can happen: 1) Nothing gets done and production board can't boot without DTS modifications. 2) Disable tags are added to the DTS file and the debug board can't use coresight without modifications. 2) The handling of the debug power domain is done properly on the MSM8998 rather than relying on the bootloader to enable it. 3) The DTS file is split or reorganised to account for debug/production devices. Which of the above ends up being the final solution is entirely up to David and Andy. Regards, Mathieu > > Thanks, > Sai
On 02/10/2019 17:03, Mathieu Poirier wrote: > The problem here is that a debug and production device are using the > same device tree, i.e msm8998.dtsi. Disabling coresight devices in > the DTS file will allow the laptop to boot but completely disabled > coresight blocks on the MTP board. Leaving things as is breaks the > laptop but allows coresight to be used on the MTP board. One of three > things can happen: > > 1) Nothing gets done and production board can't boot without DTS modifications. > 2) Disable tags are added to the DTS file and the debug board can't > use coresight without modifications. > 2) The handling of the debug power domain is done properly on the > MSM8998 rather than relying on the bootloader to enable it. > 3) The DTS file is split or reorganised to account for debug/production devices. I believe 3) is already the de facto situation. arch/arm64/boot/dts/qcom/msm8998.dtsi is the "base" config. arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi for the MTP board. arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi for the laptops. > Which of the above ends up being the final solution is entirely up to > David and Andy. 2498f8c1c668 ;-) Regards.
On Wed, Oct 02, 2019 at 05:21:23PM +0200, Marc Gonzalez wrote: > On 02/10/2019 17:03, Mathieu Poirier wrote: > > > The problem here is that a debug and production device are using the > > same device tree, i.e msm8998.dtsi. Disabling coresight devices in > > the DTS file will allow the laptop to boot but completely disabled > > coresight blocks on the MTP board. Leaving things as is breaks the > > laptop but allows coresight to be used on the MTP board. One of three > > things can happen: > > > > 1) Nothing gets done and production board can't boot without DTS modifications. > > 2) Disable tags are added to the DTS file and the debug board can't > > use coresight without modifications. > > 2) The handling of the debug power domain is done properly on the > > MSM8998 rather than relying on the bootloader to enable it. > > 3) The DTS file is split or reorganised to account for debug/production devices. > > I believe 3) is already the de facto situation. > > arch/arm64/boot/dts/qcom/msm8998.dtsi is the "base" config. > arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi for the MTP board. > arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi for the laptops. "DTS file", i.e msm8998.dtsi > > > Which of the above ends up being the final solution is entirely up to > > David and Andy. > > 2498f8c1c668 ;-) Then it is even easier to make a decision. > > Regards.
On Wed, Oct 2, 2019 at 9:34 AM Mathieu Poirier <mathieu.poirier@linaro.org> wrote: > > On Wed, Oct 02, 2019 at 05:21:23PM +0200, Marc Gonzalez wrote: > > On 02/10/2019 17:03, Mathieu Poirier wrote: > > > > > The problem here is that a debug and production device are using the > > > same device tree, i.e msm8998.dtsi. Disabling coresight devices in > > > the DTS file will allow the laptop to boot but completely disabled > > > coresight blocks on the MTP board. Leaving things as is breaks the > > > laptop but allows coresight to be used on the MTP board. One of three > > > things can happen: > > > > > > 1) Nothing gets done and production board can't boot without DTS modifications. > > > 2) Disable tags are added to the DTS file and the debug board can't > > > use coresight without modifications. > > > 2) The handling of the debug power domain is done properly on the > > > MSM8998 rather than relying on the bootloader to enable it. > > > 3) The DTS file is split or reorganised to account for debug/production devices. > > > > I believe 3) is already the de facto situation. > > > > arch/arm64/boot/dts/qcom/msm8998.dtsi is the "base" config. > > arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi for the MTP board. > > arch/arm64/boot/dts/qcom/msm8998-clamshell.dtsi for the laptops. > > "DTS file", i.e msm8998.dtsi Bjorn (the primary maintainer whom will likely be taking any DT patches) and I had a chat. We concluded on disabling the coresight components (by default) in the msm8998.dtsi, and then enabling them in the msm8998-mtp.dtsi. I think Bjorn would like to see some patches, which it sounds like Sai will post in a few days. This is probably how things should be moving forward for all qcom SoCs since its standard practice to disable the coresight components via efuse or other hardware mechanism for production products. > > > > > > Which of the above ends up being the final solution is entirely up to > > > David and Andy. > > > > 2498f8c1c668 ;-) > > Then it is even easier to make a decision. > > > > > Regards.
On Wed, Oct 02, 2019 at 09:03:59AM -0600, Mathieu Poirier wrote: > On Tue, 1 Oct 2019 at 12:05, Sai Prakash Ranjan > <saiprakash.ranjan@codeaurora.org> wrote: > > > > On 2019-10-01 11:01, Jeffrey Hugo wrote: > > > On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan > > > <saiprakash.ranjan@codeaurora.org> wrote: > > >> > > >> > > >> Haan then likely it's the firmware issue. > > >> We should probably disable coresight in soc dtsi and enable only for > > >> MTP. For now you can add a status=disabled for all coresight nodes in > > >> msm8998.dtsi and I will send the patch doing the same in a day or > > >> two(sorry I am travelling currently). > > > > > > This sounds sane to me (and is what I did while bisecting the issue). > > > When you do create the patch, feel free to add the following tags as > > > you see fit. > > > > > > Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > > Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > > > Thanks Jeffrey, I will add them. > > Hope Mathieu and Suzuki are OK with this. > > The problem here is that a debug and production device are using the > same device tree, i.e msm8998.dtsi. Disabling coresight devices in > the DTS file will allow the laptop to boot but completely disabled > coresight blocks on the MTP board. Leaving things as is breaks the > laptop but allows coresight to be used on the MTP board. One of three > things can happen: > > 1) Nothing gets done and production board can't boot without DTS modifications. > 2) Disable tags are added to the DTS file and the debug board can't > use coresight without modifications. > 2) The handling of the debug power domain is done properly on the > MSM8998 rather than relying on the bootloader to enable it. > 3) The DTS file is split or reorganised to account for debug/production devices. msm8998.dtsi is a SoC include file. Can't whatever default it adopts be reversed in the board include files such as msm8998-mtp.dtsi or msm8998-clamshell.dtsi ? Daniel.
On 10/03/2019 11:20 AM, Daniel Thompson wrote: > On Wed, Oct 02, 2019 at 09:03:59AM -0600, Mathieu Poirier wrote: >> On Tue, 1 Oct 2019 at 12:05, Sai Prakash Ranjan >> <saiprakash.ranjan@codeaurora.org> wrote: >>> >>> On 2019-10-01 11:01, Jeffrey Hugo wrote: >>>> On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan >>>> <saiprakash.ranjan@codeaurora.org> wrote: >>>>> >>>>> >>>>> Haan then likely it's the firmware issue. >>>>> We should probably disable coresight in soc dtsi and enable only for >>>>> MTP. For now you can add a status=disabled for all coresight nodes in >>>>> msm8998.dtsi and I will send the patch doing the same in a day or >>>>> two(sorry I am travelling currently). >>>> >>>> This sounds sane to me (and is what I did while bisecting the issue). >>>> When you do create the patch, feel free to add the following tags as >>>> you see fit. >>>> >>>> Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> >>>> Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> >>> >>> Thanks Jeffrey, I will add them. >>> Hope Mathieu and Suzuki are OK with this. >> >> The problem here is that a debug and production device are using the >> same device tree, i.e msm8998.dtsi. Disabling coresight devices in >> the DTS file will allow the laptop to boot but completely disabled >> coresight blocks on the MTP board. Leaving things as is breaks the >> laptop but allows coresight to be used on the MTP board. One of three >> things can happen: >> >> 1) Nothing gets done and production board can't boot without DTS modifications. >> 2) Disable tags are added to the DTS file and the debug board can't >> use coresight without modifications. >> 2) The handling of the debug power domain is done properly on the >> MSM8998 rather than relying on the bootloader to enable it. >> 3) The DTS file is split or reorganised to account for debug/production devices. > > msm8998.dtsi is a SoC include file. Can't whatever default it adopts be > reversed in the board include files such as msm8998-mtp.dtsi or > msm8998-clamshell.dtsi ? Or like Mathieu said, all the Coresight specific nodes could be moved in to say, msm8998-coresight.dtsi and could be included into the platforms where it actually works. Suzuki
On Thu, Oct 03, 2019 at 11:52:36AM +0100, Suzuki K Poulose wrote: > On 10/03/2019 11:20 AM, Daniel Thompson wrote: > > On Wed, Oct 02, 2019 at 09:03:59AM -0600, Mathieu Poirier wrote: > > > On Tue, 1 Oct 2019 at 12:05, Sai Prakash Ranjan > > > <saiprakash.ranjan@codeaurora.org> wrote: > > > > > > > > On 2019-10-01 11:01, Jeffrey Hugo wrote: > > > > > On Tue, Oct 1, 2019 at 11:52 AM Sai Prakash Ranjan > > > > > <saiprakash.ranjan@codeaurora.org> wrote: > > > > > > > > > > > > > > > > > > Haan then likely it's the firmware issue. > > > > > > We should probably disable coresight in soc dtsi and enable only for > > > > > > MTP. For now you can add a status=disabled for all coresight nodes in > > > > > > msm8998.dtsi and I will send the patch doing the same in a day or > > > > > > two(sorry I am travelling currently). > > > > > > > > > > This sounds sane to me (and is what I did while bisecting the issue). > > > > > When you do create the patch, feel free to add the following tags as > > > > > you see fit. > > > > > > > > > > Reported-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > > > > Tested-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> > > > > > > > > Thanks Jeffrey, I will add them. > > > > Hope Mathieu and Suzuki are OK with this. > > > > > > The problem here is that a debug and production device are using the > > > same device tree, i.e msm8998.dtsi. Disabling coresight devices in > > > the DTS file will allow the laptop to boot but completely disabled > > > coresight blocks on the MTP board. Leaving things as is breaks the > > > laptop but allows coresight to be used on the MTP board. One of three > > > things can happen: > > > > > > 1) Nothing gets done and production board can't boot without DTS modifications. > > > 2) Disable tags are added to the DTS file and the debug board can't > > > use coresight without modifications. > > > 2) The handling of the debug power domain is done properly on the > > > MSM8998 rather than relying on the bootloader to enable it. > > > 3) The DTS file is split or reorganised to account for debug/production devices. > > > > msm8998.dtsi is a SoC include file. Can't whatever default it adopts be > > reversed in the board include files such as msm8998-mtp.dtsi or > > msm8998-clamshell.dtsi ? > > Or like Mathieu said, all the Coresight specific nodes could be moved in > to say, msm8998-coresight.dtsi and could be included into the platforms > where it actually works. Sure, that works too. Maybe it depends in you view the mtp as including the feature or as the laptops as taking it away ;-) . Treating it as a feature a board can disable also works nicely on systems where the board include file should be setting secure-status a board (although that's probably not the case for these boards since the firmware is proprietary). Daniel.
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi index c13ed7aeb1e0..ad661fcc9e1b 100644 --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi @@ -822,6 +822,441 @@ #interrupt-cells = <0x2>; }; + stm@6002000 { + compatible = "arm,coresight-stm", "arm,primecell"; + reg = <0x06002000 0x1000>, + <0x16280000 0x180000>; + reg-names = "stm-base", "stm-data-base"; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + stm_out: endpoint { + remote-endpoint = <&funnel0_in7>; + }; + }; + }; + }; + + funnel@6041000 { + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; + reg = <0x06041000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + funnel0_out: endpoint { + remote-endpoint = + <&merge_funnel_in0>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@7 { + reg = <7>; + funnel0_in7: endpoint { + remote-endpoint = <&stm_out>; + }; + }; + }; + }; + + funnel@6042000 { + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; + reg = <0x06042000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + funnel1_out: endpoint { + remote-endpoint = + <&merge_funnel_in1>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@6 { + reg = <6>; + funnel1_in6: endpoint { + remote-endpoint = + <&apss_merge_funnel_out>; + }; + }; + }; + }; + + funnel@6045000 { + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; + reg = <0x06045000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + merge_funnel_out: endpoint { + remote-endpoint = + <&etf_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + merge_funnel_in0: endpoint { + remote-endpoint = + <&funnel0_out>; + }; + }; + + port@1 { + reg = <1>; + merge_funnel_in1: endpoint { + remote-endpoint = + <&funnel1_out>; + }; + }; + }; + }; + + replicator@6046000 { + compatible = "arm,coresight-dynamic-replicator", "arm,primecell"; + reg = <0x06046000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + replicator_out: endpoint { + remote-endpoint = <&etr_in>; + }; + }; + }; + + in-ports { + port { + replicator_in: endpoint { + remote-endpoint = <&etf_out>; + }; + }; + }; + }; + + etf@6047000 { + compatible = "arm,coresight-tmc", "arm,primecell"; + reg = <0x06047000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + etf_out: endpoint { + remote-endpoint = + <&replicator_in>; + }; + }; + }; + + in-ports { + port { + etf_in: endpoint { + remote-endpoint = + <&merge_funnel_out>; + }; + }; + }; + }; + + etr@6048000 { + compatible = "arm,coresight-tmc", "arm,primecell"; + reg = <0x06048000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + arm,scatter-gather; + + in-ports { + port { + etr_in: endpoint { + remote-endpoint = + <&replicator_out>; + }; + }; + }; + }; + + etm@7840000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07840000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU0>; + + out-ports { + port { + etm0_out: endpoint { + remote-endpoint = + <&apss_funnel_in0>; + }; + }; + }; + }; + + etm@7940000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07940000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU1>; + + out-ports { + port { + etm1_out: endpoint { + remote-endpoint = + <&apss_funnel_in1>; + }; + }; + }; + }; + + etm@7a40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07a40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU2>; + + out-ports { + port { + etm2_out: endpoint { + remote-endpoint = + <&apss_funnel_in2>; + }; + }; + }; + }; + + etm@7b40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07b40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU3>; + + out-ports { + port { + etm3_out: endpoint { + remote-endpoint = + <&apss_funnel_in3>; + }; + }; + }; + }; + + funnel@7b60000 { /* APSS Funnel */ + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07b60000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + apss_funnel_out: endpoint { + remote-endpoint = + <&apss_merge_funnel_in>; + }; + }; + }; + + in-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + apss_funnel_in0: endpoint { + remote-endpoint = + <&etm0_out>; + }; + }; + + port@1 { + reg = <1>; + apss_funnel_in1: endpoint { + remote-endpoint = + <&etm1_out>; + }; + }; + + port@2 { + reg = <2>; + apss_funnel_in2: endpoint { + remote-endpoint = + <&etm2_out>; + }; + }; + + port@3 { + reg = <3>; + apss_funnel_in3: endpoint { + remote-endpoint = + <&etm3_out>; + }; + }; + + port@4 { + reg = <4>; + apss_funnel_in4: endpoint { + remote-endpoint = + <&etm4_out>; + }; + }; + + port@5 { + reg = <5>; + apss_funnel_in5: endpoint { + remote-endpoint = + <&etm5_out>; + }; + }; + + port@6 { + reg = <6>; + apss_funnel_in6: endpoint { + remote-endpoint = + <&etm6_out>; + }; + }; + + port@7 { + reg = <7>; + apss_funnel_in7: endpoint { + remote-endpoint = + <&etm7_out>; + }; + }; + }; + }; + + funnel@7b70000 { + compatible = "arm,coresight-dynamic-funnel", "arm,primecell"; + reg = <0x07b70000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + out-ports { + port { + apss_merge_funnel_out: endpoint { + remote-endpoint = + <&funnel1_in6>; + }; + }; + }; + + in-ports { + port { + apss_merge_funnel_in: endpoint { + remote-endpoint = + <&apss_funnel_out>; + }; + }; + }; + }; + + etm@7c40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07c40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU4>; + + port{ + etm4_out: endpoint { + remote-endpoint = <&apss_funnel_in4>; + }; + }; + }; + + etm@7d40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07d40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU5>; + + port{ + etm5_out: endpoint { + remote-endpoint = <&apss_funnel_in5>; + }; + }; + }; + + etm@7e40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07e40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU6>; + + port{ + etm6_out: endpoint { + remote-endpoint = <&apss_funnel_in6>; + }; + }; + }; + + etm@7f40000 { + compatible = "arm,coresight-etm4x", "arm,primecell"; + reg = <0x07f40000 0x1000>; + + clocks = <&rpmcc RPM_SMD_QDSS_CLK>, <&rpmcc RPM_SMD_QDSS_A_CLK>; + clock-names = "apb_pclk", "atclk"; + + cpu = <&CPU7>; + + port{ + etm7_out: endpoint { + remote-endpoint = <&apss_funnel_in7>; + }; + }; + }; + spmi_bus: spmi@800f000 { compatible = "qcom,spmi-pmic-arb"; reg = <0x800f000 0x1000>,