Re: [PATCH v2 2/4] dt-bindings: arm: Add binding document for Coresight Control Unit device.

[Suzuki K Poulose]

On 08/07/2024 11:25, JieGan wrote:
> On Mon, Jul 08, 2024 at 06:10:28PM +0800, JieGan wrote:
> > On Mon, Jul 08, 2024 at 10:41:55AM +0100, Suzuki K Poulose wrote:
> > > On 05/07/2024 10:00, Jie Gan wrote:
> > > > Add binding document for Coresight Control Unit device.
> > >
> > > nit: This is again too generic ? corsight-tmc-control-unit ? After all
> > > thats what it is and not a *generic* coresight control unit ?
> > coresight-tmc-control-unit is much better. We will check it.
> >   
> > > > Signed-off-by: Jie Gan <quic_jiegan@xxxxxxxxxxx>
> > > > ---
> > > >    .../bindings/arm/qcom,coresight-ccu.yaml      | 87 +++++++++++++++++++
> > > >    1 file changed, 87 insertions(+)
> > > >    create mode 100644 Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
> > > > new file mode 100644
> > > > index 000000000000..9bb8ced393a7
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/qcom,coresight-ccu.yaml
> > > > @@ -0,0 +1,87 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/arm/qcom,coresight-ccu.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: CoreSight Control Unit
> > > > +
> > > > +maintainers:
> > > > +  - Yuanfang Zhang <quic_yuanfang@xxxxxxxxxxx>
> > > > +  - Mao Jinlong <quic_jinlmao@xxxxxxxxxxx>
> > > > +  - Jie Gan <quic_jiegan@xxxxxxxxxxx>
> > > > +
> > > > +description:
> > > > +  The Coresight Control unit controls various Coresight behaviors.
> > > > +  Used to enable/disable ETR’s data filter function based on trace ID.
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    const: qcom,coresight-ccu
> > > > +
> > > > +  reg:
> > > > +    maxItems: 1
> > > > +
> > > > +  clocks:
> > > > +    maxItems: 1
> > > > +
> > > > +  clock-names:
> > > > +    items:
> > > > +      - const: apb_pclk
> > > > +
> > > > +  reg-names:
> > > > +    items:
> > > > +      - const: ccu-base
> > > > +
> > > > +  in-ports:
> > > > +    $ref: /schemas/graph.yaml#/properties/ports
> > > > +
> > > > +    unevaluatedProperties:
> > > > +      patternProperties:
> > > > +        '^port(@[0-7])?$':
> > > > +          description: Input connections from CoreSight Trace bus
> > > > +          $ref: /schemas/graph.yaml#/properties/port
> > > > +
> > > > +          properties:
> > > > +            qcom,ccu-atid-offset:
> > >
> > > Why do we need this atid offset ? Couldn't this be mapped to the "port"
> > > number ?
> > >
> > > e.g, input-port 0 on CCU => Offset x
> > >       input-port 1 on CCU => (Offset x + Size of 1 region)
> > If the first ATID offset remains constant, it appears to be feasible.
> > We will consider the possibility of this solution.
> We just checked the ATID offset varies across different hardware platforms.
> It defined as 0xf4 on some platforms, and some others defined as 0xf8.

What do you mean ? The offset where you apply the filter changes across
different platforms ? or different "tmc-control-unit" implementations ?
Is this discoverable from the device ? We could use different
compatibles for different "types" of the "devices". Simply adding
something in the DT is not the right way.

> So I think it should be better to define it in device tree node.

No. See above.

Suzuki

> > > I believe I mentioned this in the previous posting too ?
> > Yes, you mentioned before. I moved it from TMC filed to CCU filed.
> >
> > > Suzuki