Hi Leo,
On Thu, 5 Sep 2019 at 10:06, Leo Yan leo.yan@linaro.org wrote:
Hi Mike,
On Tue, Sep 03, 2019 at 10:29:02AM +0100, Mike Leach wrote:
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.
Thanks a lot for sharing this info. I just curious, how about to parse the integration control registers on DB410c and Hikey board?
I think it's valuable to use some tool to parse integration control registers (thus software engineers don't need to talk to silicon engineer and can get to know the connections).
mmap would be the best method at present as the only the CTI driver has options to expose these registers at present.
There are issues with power here too -- Juno powers everything up but other boards may be trickier.
Anyway, I think we could take this as low priority and firstly focus on upstreaming this patch set.
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.
Okay, this is fine. I totally agree we can use simple method as the first step.
TBH, sorry I have no sense for this; "does not guarantee a usable system" will lead to what's result? Just the wrong configuration or some serious issue, like system hang?
It could be either - the result is just not predictable.
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.
[...]
};/* 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.
From my understanding, here should have no dependency.
'etm1' node can be accessed by using phandle and retrieve its properies with 'of' related functions; it doesn't mean we must access 'etm1' node after the 'etm1' device has been probed.
Bear in mind that ETM is optional - we still need cpu.
Thanks, Leo Yan
[...]
regards
Mike
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK