linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Zong Li <zong.li@sifive.com>
To: Anup Patel <anup@brainfault.org>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [RFC PATCH] dt-bindings: riscv: Add YAML documentation for PMU
Date: Tue, 28 Jul 2020 12:08:31 +0800	[thread overview]
Message-ID: <CANXhq0oJ9pMnVHfx25yZMJo3yThAZRix_8=BWEo_diNfxxdugQ@mail.gmail.com> (raw)
In-Reply-To: <CAAhSdy1TKf4CidGR9pOB29iPuV6hPKr=n7gt=s==v8pu8m8a=Q@mail.gmail.com>

On Tue, Jul 28, 2020 at 11:27 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Tue, Jul 28, 2020 at 8:35 AM Zong Li <zong.li@sifive.com> wrote:
> >
> > On Mon, Jul 27, 2020 at 9:13 PM Anup Patel <anup@brainfault.org> wrote:
> > >
> > > On Mon, Jul 27, 2020 at 1:57 PM Zong Li <zong.li@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@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@sifive.com>
> > > > +  - Paul Walmsley <paul.walmsley@sifive.com>
> > > > +  - Palmer Dabbelt <palmer@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.
>
> The RISC-V PMU DT binding is not just for Linux. Even M-mode
> runtime firmware (OpenSBI) will be using this binding.
>
> The DT bindings you are proposing is conflicting with the
> expected RISC-V PMU DT bindings:
> 1. The event-map should be mapping SBI PMU event_idx
> to HARDWARE HPMEVENT value whereas this binding
> defines event-map as mapping Linux perf event types to
> HPMEVENT value.

It is more suitable by using Linux perf event types directly here. On
nommu Linux, it doesn't have additional m-mode firmware, so it doesn't
have the rule like SMI PMU event_idx. Unless we apply the same rule in
nommu pmu drivers as well, it doesn't need to translate the event_idx
to Linux perf event types in Linux nommu driver.

> 2. Each HPMCOUNTER can support a different set of events
> so this DT bindings won't work for it.

There is a property "riscv,hpmcntr-of-event" to indicate which
counters can serve the specific event, if we don't list the particular
event in this property, we view this event could be served by all
counters.

> 3. The SBI PMU driver can have optional edge-triggered
> per-HART interrupts for overflow detection. This DT bindings
> does not consider this as well.
>

We don't have an overflow interrupt mechanism in RISC-V spec now, we
should postpone and add the properties of interrupt stuff after the
mechanism is standardized.

> The SBI PMU event_idx definition is not yet finalized. Please
> wait for SBI PMU extension to be finalized.
>

As I mentioned above, it need to be discussed whether we should do id
translation in Linux nommu driver.

> Please avoid adding DT bindings without SBI PMU extension
> being finalized.
>
> Regards,
> Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2020-07-28  4:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  8:27 [RFC PATCH] dt-bindings: riscv: Add YAML documentation for PMU Zong Li
2020-07-27 13:13 ` Anup Patel
2020-07-28  3:05   ` Zong Li
2020-07-28  3:27     ` Anup Patel
2020-07-28  4:08       ` Zong Li [this message]
2020-07-28 12:10         ` Anup Patel
2020-07-28 16:58           ` Atish Patra
2020-07-30  5:53           ` Zong Li
2020-07-31  9:44             ` Anup Patel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANXhq0oJ9pMnVHfx25yZMJo3yThAZRix_8=BWEo_diNfxxdugQ@mail.gmail.com' \
    --to=zong.li@sifive.com \
    --cc=anup@brainfault.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).