[PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

Wed Dec 1 05:28:05 PST 2021

Hi Atish,

Am Mittwoch, 1. Dezember 2021, 02:21:46 CET schrieb Atish Patra:
> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
> >
> > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich at vrull.eu> wrote:
> > >
> > > We did touch on this in our coordination call a few weeks ago: the
> > > grouping under mmu and the bool-entries were chosen because of their
> > > similarity to other extensions (i.e. for Zb[abcs] there could/should
> > > be a bool-entry under each cpu-node — for some Zv* entries a subnode
> > > might be needed with further parameters).
> > >
> > > The string-based approach (as in the originally proposed "mmu-type=")
> > > would like not scale with the proliferation of small & modular
> > > extensions.
> >
> > I don’t see why the Sv* extensions need to be under an mmu node then,
> > unless the intent is that every extension be grouped under a sub-node
> > (which doesn’t seem viable due to extensions like Zbk*, unless you
> > group by Ss, Sv and Z)?
> >
> 
> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> with prefix S,Z,H should be kept separate in a separate node for easy
> parsing.
> 
> "riscv,isa" dt property will not scale at all. Just look at the few
> extensions that were ratified this year
> and Linux kernel needs to support them.
> 
> "Sscofpmf", "Svpbmt", "Zicbom"
> 
> > Also, what is going to happen to the current riscv,isa? Will that
> > continue to exist and duplicate the info, or will kernels be required
> > to reconstruct the string themselves if they want to display it to
> > users?
> >
> 
> This is my personal preference:
> riscv,isa will continue to base Standard ISA extensions that have
> single letter extensions.
> 
> This new DT node will encode all the non-single letter extensions.
> I am not sure if it should include some provisions for custom
> extensions starting with X because
> that will be platform specific.
> 
> Again, this is just my personal preference. I will try to send a patch
> soon so that we can initiate a broader
> discussion of the scheme and agree/disagree on something.

that would be really helpful, as it currently looks like we have a number
of different points-of-view so discussing an actual implementation will
probably make things a lot easier compared to dancing around theoretic
cases :-) .

Out of curiosity, how soon is "soon" ? :-D

Heiko

> > As a FreeBSD developer I’m obviously not a part of many of these
> > discussions, but what the Linux community imposes as the device tree
> > bindings has a real impact on us.
> >
> > Jess
> >
> > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27 at jrtc27.com> wrote:
> > >>
> > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko at sntech.de> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko at sntech.de> wrote:
> > >>>>>
> > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> > >>>>>>> On 11/29/21 02:40, wefu at redhat.com wrote:
> > >>>>>>>> From: Wei Fu <wefu at redhat.com>
> > >>>>>>>>
> > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > >>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> > >>>>>>>>
> > >>>>>>>> Signed-off-by: Wei Fu <wefu at redhat.com>
> > >>>>>>>> Co-developed-by: Guo Ren <guoren at kernel.org>
> > >>>>>>>> Signed-off-by: Guo Ren <guoren at kernel.org>
> > >>>>>>>> Cc: Anup Patel <anup at brainfault.org>
> > >>>>>>>> Cc: Palmer Dabbelt <palmer at dabbelt.com>
> > >>>>>>>> Cc: Rob Herring <robh+dt at kernel.org>
> > >>>>>>>> ---
> > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> > >>>>>>>> 1 file changed, 10 insertions(+)
> > >>>>>>>>
> > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> @@ -63,6 +63,16 @@ properties:
> > >>>>>>>>      - riscv,sv48
> > >>>>>>>>      - riscv,none
> > >>>>>>>>
> > >>>>>>>> +  mmu:
> > >>>>>>>
> > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> > >>>>>>> mmu-type?
> > >>>>>>>
> > >>>>>>>> +    description:
> > >>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > >>>>>>>> +      These values originate from the RISC-V Privileged
> > >>>>>>>> +      Specification document, available from
> > >>>>>>>> +      https://riscv.org/specifications/
> > >>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > >>>>>>>> +    enum:
> > >>>>>>>> +      - riscv,svpmbt
> > >>>>>>>
> > >>>>>>> The privileged specification has multiple MMU related extensions:
> > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> > >>>>>>
> > >>>>>> I remember in some earlier version some way back there was the
> > >>>>>> suggestion of using a sub-node instead and then adding boolean
> > >>>>>> properties for the supported extensions.
> > >>>>>>
> > >>>>>> Aka something like
> > >>>>>>   mmu {
> > >>>>>>           riscv,svpbmt;
> > >>>>>>   };
> > >>>>>
> > >>>>> For the record, I'm talking about the mail from september
> > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > >>>>>
> > >>>>> So having a sub-node would make adding future extensions
> > >>>>> way nicer.
> > >>>>
> > >>>> Svpbmt is just an ISA extension, and should be treated like any other.
> > >>>> Let’s not invent two different ways of representing that in the device
> > >>>> tree.
> > >>>
> > >>> Heinrich asked how the other extensions should be handled
> > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> > >>
> > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> > >> a concrete plan for that yet, but that means you should speak with the
> > >> people involved with such extensions and come up with something
> > >> appropriate together.
> > >>
> > >> Jess
> > >>
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> 
> 
> --
> Regards,
> Atish
> 