On Mon, Jul 08, 2024 at 01:50:11PM +0100, Suzuki K Poulose wrote: > 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. I got your point here. I believe we should consult our hardware engineers first to check it. We need to figure out the design of ATID offset from hardware perspective. Then we can propose an alternative approach, such as associating the offset with a compitable value, to resolve this issue. > > > > > 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 > > > > > > > > Thanks, Jie
