Re: [PATCH V3 06/14] dts: bindings: Document device tree bindings for ETE

Suzuki K Poulose
2021-02-18T22:54:32Z

On 2/18/21 6:33 PM, Rob Herring wrote:
> On Wed, Feb 10, 2021 at 12:33:44PM +0000, Suzuki K Poulose wrote:
>> Hi Rob
>>
>> On 2/9/21 7:00 PM, Rob Herring wrote:
>>> On Wed, Jan 27, 2021 at 02:25:30PM +0530, Anshuman Khandual wrote:
>>>> From: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>
>>>> Document the device tree bindings for Embedded Trace Extensions.
>>>> ETE can be connected to legacy coresight components and thus
>>>> could optionally contain a connection graph as described by
>>>> the CoreSight bindings.
>>>>
>>>> Cc: devicetree@vger.kernel.org
>>>> Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> Cc: Mike Leach <mike.leach@linaro.org>
>>>> Cc: Rob Herring <robh@kernel.org>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>> ---
>>>> Changes in V3:
>>>>
>>>> - Fixed all DT yaml semantics problems
>>>>
>>>> Documentation/devicetree/bindings/arm/ete.yaml | 74 ++++++++++++++++++++++++++
>>>> 1 file changed, 74 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/ete.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/ete.yaml b/Documentation/devicetree/bindings/arm/ete.yaml
>>>> new file mode 100644
>>>> index 0000000..edc1fe2
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/ete.yaml
>>>> @@ -0,0 +1,74 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
>>>> +# Copyright 2021, Arm Ltd
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: "http://devicetree.org/schemas/arm/ete.yaml#"
>>>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>>>> +
>>>> +title: ARM Embedded Trace Extensions
>>>> +
>>>> +maintainers:
>>>> + - Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> + - Mathieu Poirier <mathieu.poirier@linaro.org>
>>>> +
>>>> +description: |
>>>> + Arm Embedded Trace Extension(ETE) is a per CPU trace component that
>>>> + allows tracing the CPU execution. It overlaps with the CoreSight ETMv4
>>>> + architecture and has extended support for future architecture changes.
>>>> + The trace generated by the ETE could be stored via legacy CoreSight
>>>> + components (e.g, TMC-ETR) or other means (e.g, using a per CPU buffer
>>>> + Arm Trace Buffer Extension (TRBE)). Since the ETE can be connected to
>>>> + legacy CoreSight components, a node must be listed per instance, along
>>>> + with any optional connection graph as per the coresight bindings.
>>>> + See bindings/arm/coresight.txt.
>>>> +
>>>> +properties:
>>>> + $nodename:
>>>> + pattern: "^ete([0-9a-f]+)$"
>>>> + compatible:
>>>> + items:
>>>> + - const: arm,embedded-trace-extension
>>>> +
>>>> + cpu:
>>>
>>> We've already established 'cpus' for this purpose.
>>>
>>
>> Please see : https://lkml.kernel.org/r/9417218b-6eda-373b-a2cb-869089ffc7cd@arm.com
>> for my response in the previous version to this and the one with out-ports.
>
> Okay, fair enough.
>
>>
>>>> + description: |
>>>> + Handle to the cpu this ETE is bound to.
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> +
>>>> + out-ports:
>>>> + type: object
>>>
>>> Replace with: $ref: /schemas/graph.yaml#/properties/ports
>>
>> So, just to confirm again :
>> The CoreSight graph bindings expect the input ports and output ports
>> grouped under in-ports{} and out-ports{} respectively to avoid having
>> to specify the direction of the ports in the individual "port" nodes.
>> i.e
>>
>> in-ports {
>>
>> property: ports
>> OR
>> property: port
>>
>> required:
>> OneOf:
>> ports
>> port
>
> No, 'ports' as a child of in-ports is not correct. There should only be
> 'port(@[0-9a-f]+)?' nodes. That's why you need the above $ref added. The
> $ref doesn't define the node name is 'ports', but what a 'ports' or
> 'foo-ports' contains.

Sorry, it is my bad. We don't expect ports{} under in-ports. So your
suggestion is the accurate one. I will respin.

>
>> }
>>
>> out-ports {
>>
>> # same as above
>> }
>>
>> So thats why I added out-ports as a new object, where the ports/port
>> could be a child node.
>>
>> Ideally the definition of out-ports /in-ports should go to a common schema
>> for CoreSight bindings, when we move to Yaml for the existing bindings,
>> which will follow in a separate series, later.
>
> Yes, maybe, but I'm not sure something common is going to help here.
> You'll still have to describe what each 'port' node does in each device
> specific binding.

For CoreSight components the end-point of the ports are system specific.
i.e, it could be anything on the other end. There is no fixed end-point
connection.

e.g, ETM could be connected to a Replicator or a Funnel. Same as here
above for ETE. Thus the driver must parse the endpoints and make
the connection path from devices to other devices.

Anyways, will come to that in a different series.

I will fix the in-ports/out-ports for the next version.

Thanks for your guidance.

Cheers
Suzuki

>
> Rob