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

[Suzuki K Poulose]

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 at 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 at vger.kernel.org
>>>> Cc: Mathieu Poirier <mathieu.poirier at linaro.org>
>>>> Cc: Mike Leach <mike.leach at linaro.org>
>>>> Cc: Rob Herring <robh at kernel.org>
>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose at arm.com>
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual at 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 at arm.com>
>>>> +  - Mathieu Poirier <mathieu.poirier at 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
>