[RFC PATCH] dt-bindings: riscv: Add YAML documentation for PMU

[Zong Li]

On Mon, Jul 27, 2020 at 9:13 PM Anup Patel <anup at brainfault.org> wrote:
>
> On Mon, Jul 27, 2020 at 1:57 PM Zong Li <zong.li at sifive.com> wrote:
> >
> > Add device tree bindings for performance monitor unit. It passes the
> > dt_binding_check verification.
> >
> > Signed-off-by: Zong Li <zong.li at sifive.com>
> > ---
> >  .../devicetree/bindings/riscv/pmu.yaml        | 71 +++++++++++++++++++
> >  1 file changed, 71 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/riscv/pmu.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/pmu.yaml b/Documentation/devicetree/bindings/riscv/pmu.yaml
> > new file mode 100644
> > index 000000000000..0c49039a5d3b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/pmu.yaml
> > @@ -0,0 +1,71 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/pmu.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V Performance Monitor Units
> > +
> > +maintainers:
> > +  - Zong Li <zong.li at sifive.com>
> > +  - Paul Walmsley <paul.walmsley at sifive.com>
> > +  - Palmer Dabbelt <palmer at dabbelt.com>
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - const: riscv,pmu
> > +
> > +  riscv,width-hpmcntr:
> > +    description: The width of hpmcounter CSRs. Default is 64.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +  riscv,n-hpmcntr:
> > +    description: The number of hpmcounter CSRs. Default is zero.
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +  riscv,hw-event-map:
> > +    description: The mapping of generic hardware events to values of hpmcounter.
> > +      The key is the encoding of generic hardware events, and the value is the
> > +      actual value which is implemented by platform. If there is no a key-value
> > +      pair for specific generic hardware event, view the generic hardware event
> > +      as not supported. CYCLE and INSTRET be mapped by default, so we shouldn't
> > +      list PERF_COUNT_HW_CPU_CYCLES and PERF_COUNT_HW_INSTRUCTIONS here.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  riscv,hw-cache-event-map:
> > +    description: The mapping of generic hardware cache events to values of
> > +      hpmcounter. The key is encoding of generic hardware cache events, and the
> > +      value is the actual value which is implemented by platform. If there is no
> > +      a key-value pair for specific generic hardware cache event, view the
> > +      generic hardware cache event as not supported.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +  riscv,hpmcntr-of-event:
> > +    description: The mapping of platform hardware events to allowed hmpcounters.
> > +      The key is the platform hardware event, and the value is the bitmap for
> > +      hmpcounters which support this event. If there is no a key-value pair for
> > +      specific platform hardware events, view the platform hardware events as
> > +      supported by all hpmcounters.
> > +    $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +required:
> > +  - compatible
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    pmu {
> > +      compatible = "riscv,pmu";
> > +      riscv,width-hpmcntr = <40>;
> > +      riscv,n-hpmcntr = <2>;
> > +      riscv,hw-event-map = <0x3 0x0202
> > +                            0x4 0x4000>;
> > +      riscv,hw-cache-event-map = <0x010201 0x0102
> > +                                  0x010204 0x0802>;
> > +      riscv,hpmcntr-of-event = <0x100 0x18
> > +                                0x400 0x10>;
> > +    };
> > +
> > +...
> > --
> > 2.27.0
> >
>
> I don't see the point of sending DT bindings documents
> until the SBI PMU extension is defined and accepted
> by everyone.
>

It seems to me that it doesn't conflict with the SBI PMU extension.
SBI PMU extension is the interface for communication with the lower
privilege levels, we still can come out the DT in parallel, and make
sure what information is needed by m-mode firmware. OTOH, we also need
a Linux driver which has to parse the dtb when we build Linux as nommu
and run it on m-mode privilege, so if we could define the DT for PMU
node, we can go the driver for nommu first (the implementation would
also consider HW counter, SW counter together). I think you have got
the picture about m-mode firmware, it would be great to start to
collect the idea of DT.

> Regards,
> Anup