Hi suzuki,

On Thu, 24 Sep 2020 at 10:43, Suzuki K Poulose [off-list ref] wrote:

On 09/18/2020 04:35 PM, Mike Leach wrote:

quoted

On Fri, 11 Sep 2020 at 09:41, Suzuki K Poulose [off-list ref] wrote:

quoted

Document the bindings for ETMv4.4 and later with only system register
access.

Cc: devicetree@vger.kernel.org
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <redacted>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
  Documentation/devicetree/bindings/arm/coresight.txt | 6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/coresight.txt b/Documentation/devicetree/bindings/arm/coresight.txt
index d711676b4a51..cfe47bdda728 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt

@@ -34,9 +34,13 @@ its hardware characteristcs.
                                         Program Flow Trace Macrocell:
                         "arm,coresight-etm3x", "arm,primecell";

-               - Embedded Trace Macrocell (version 4.x):
+               - Embedded Trace Macrocell (version 4.x), with memory mapped access.
                         "arm,coresight-etm4x", "arm,primecell";

+               - Embedded Trace Macrocell (version 4.4 and later) with system
+                 register access only.
+                       "arm,coresight-etm-v4.4";

Any version of ETM can implement register access - including those pre
ETM 4.4. Perhaps the new name should simply reflect sys reg access
rather than a version.

You're right. I got it confused with the v8.4 SelfHosted Extensions, which
mandates the sysreg access and makes the mem I/O obsolete. How about :

        "arm,coresight-etm4x-sysreg" ?

Seems reasonable.
Perhaps ensure that the accompanying comment mentions that this is
aarch64 access (to cover the unlikely event that some outlier
implementation does come along with v8 aarch32 + ETMv4 + sysreg
access!)

quoted

Given that the two compatibility strings should be mutually exclusive
for a given device, should the bindings doc (or at least the etm4x
component part) be re-written into the .yaml format so that this can
be enforced?

I will take a look, haven't played with the yaml.

I used it to describe the CTI bindings as these were brand new.
Reasonably straight forwards - there are plenty of examples and the
checking tools are pretty good.

Regards

Mike

Thanks for the review !

Suzuki

-- 
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel