Hi Leo,
On Tue, 3 Sep 2019 at 09:19, Leo Yan leo.yan@linaro.org wrote:
On Mon, Aug 19, 2019 at 10:13:58PM +0100, Mike Leach wrote:
Adds system and CPU bound CTI definitions for Qualcom msm8916 platform (Dragonboard DB410C). System CTIs 2-11 are omitted as no information available at present.
Signed-off-by: Mike Leach mike.leach@linaro.org
arch/arm64/boot/dts/qcom/msm8916.dtsi | 85 +++++++++++++++++++++++++-- 1 file changed, 81 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index 5ea9fb8f2f87..9589fc2cba22 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -8,6 +8,7 @@ #include <dt-bindings/reset/qcom,gcc-msm8916.h> #include <dt-bindings/clock/qcom,rpmcc.h> #include <dt-bindings/thermal/thermal.h> +#include <dt-bindings/arm/coresight-cti-dt.h>
/ { interrupt-parent = <&intc>; @@ -1357,7 +1358,7 @@ cpu = <&CPU3>; };
etm@85c000 {
etm0: etm@85c000 { compatible = "arm,coresight-etm4x", "arm,primecell"; reg = <0x85c000 0x1000>;@@ -1375,7 +1376,7 @@ }; };
etm@85d000 {
etm1: etm@85d000 { compatible = "arm,coresight-etm4x", "arm,primecell"; reg = <0x85d000 0x1000>;@@ -1393,7 +1394,7 @@ }; };
etm@85e000 {
etm2: etm@85e000 { compatible = "arm,coresight-etm4x", "arm,primecell"; reg = <0x85e000 0x1000>;@@ -1411,7 +1412,7 @@ }; };
etm@85f000 {
etm3: etm@85f000 { compatible = "arm,coresight-etm4x", "arm,primecell"; reg = <0x85f000 0x1000>;@@ -1429,6 +1430,82 @@ }; };
/* System CTIs *//* CTI 0 - TMC connections */cti@810000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x810000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";I have one question for the CTIs which are connected to TMC and TPIU devices:
Should This kind CTI have fixed trigger signals to connect between CTI and TMC/TPIU? If so, usually, can we get to know which trigger signals are connected and need to use the DT binding to define these trigger signals?
CTI signals between components are implementation dependent - determined by the hardware designer, except for the connections between the v8 PE, ETM and CTI that are required by the v8 architecture. So, other than v8 cores we need either documentation or to explore the connections using the integration control registers on the device.
For Juno I did this some time ago by mmap-ing the Coresight memory spaces into user space and reading and writing locations directly. That gave the connections you see in the .dtsi for Juno. Unfortunately using the integration control registers does not guarantee a usable system after their use, so this method cannot be used a boot / probe time.
If you look at the Juno .dtsi you will see that there are a number of connections specified between TPIU, ETR, ETF, STM and CTIs.. The types will be the same for other systems, we just do not know which signal on which CTI they might be connected to without further information.
Or we just use the way in this patch without specifying any DT binding for trigger signals. Finally, the sysfs nodes allow to configure 0-7 triggers:
# cat /sys/bus/coresight/devices/cti_sys0/triggers0/in_signals 0-7 # cat /sys/bus/coresight/devices/cti_sys0/triggers0/in_types genio genio genio genio genio genio genio genio # cat /sys/bus/coresight/devices/cti_sys0/triggers0/out_signals 0-7 # cat /sys/bus/coresight/devices/cti_sys0/triggers0/out_types genio genio genio genio genio genio genio genio
This is the default position - this allows specification of the CTI using the MAX_TRIGS specifcation in the hardware ID register. This does not mean that all these triggers are connected, but does allow access to the ones that are.
};/* CTI 1 - TPIU connections */cti@811000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x811000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";};/* CTIs 2-11 - no information - not instantiated *//* Core CTIs; CTIs 12-15 *//* CTI - CPU-0 */cti@858000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x858000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";arm,cti-v8-arch;cpu = <&CPU0>;arm,cs-dev-assoc = <&etm0>;Redundant new line.
};/* CTI - CPU-1 */cti@859000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x859000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";arm,cti-v8-arch;cpu = <&CPU1>;arm,cs-dev-assoc = <&etm1>;Not sure if it's really redundant or not for 'cpu' node. Since we can see 'etm1' node also points to 'cpu' node, so actually we can get CPU related info by the path: arm,cs-dev-assoc -> etm1 -> cpu1.
By using this way, we can save one DT binding node? If you think this will cause much complexity for implementation, just ignore this comment.
We cannot be sure at probe time if etm1 has been discovered. Therefore it is useful to collect all the information for this component here and compete the probing in one go.
};/* CTI - CPU-2 */cti@85a000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x85a000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";arm,cti-v8-arch;cpu = <&CPU2>;arm,cs-dev-assoc = <&etm2>;};/* CTI - CPU-3 */cti@85b000 {compatible = "arm,coresight-cti", "arm,primecell";reg = <0x85b000 0x1000>;clocks = <&rpmcc RPM_QDSS_CLK>;clock-names = "apb_pclk";arm,cti-v8-arch;cpu = <&CPU3>;arm,cs-dev-assoc = <&etm3>;};Two new lines.
venus: video-codec@1d00000 { compatible = "qcom,msm8916-venus"; reg = <0x01d00000 0xff000>;-- 2.17.1
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Will fix new lines
Thanks
Mike