On Mon, 26 Jun 2023 11:10:46 +0100, Conor Dooley wrote: > intro > ===== > > When the RISC-V dt-bindings were accepted upstream in Linux, the base > ISA etc had yet to be ratified. By the ratification of the base ISA, > incompatible changes had snuck into the specifications - for example the > Zicsr and Zifencei extensions were spun out of the base ISA. > > Fast forward to today, and the reason for this patch. > Currently the riscv,isa dt property permits only a specific subset of > the ISA string - in particular it excludes version numbering. > With the current constraints, it is not possible to discern whether > "rv64i" means that the hart supports the fence.i instruction, for > example. > Future systems may choose to implement their own instruction fencing, > perhaps using a vendor extension, or they may not implement the optional > counter extensions. Software needs a way to determine this. > > versioning schemes > ================== > > "Use the extension versions that are described in the ISA manual" you > may say, and it's not like this has not been considered. > Firstly, software that parses the riscv,isa property at runtime will > need to contain a lookup table of some sort that maps arbitrary versions > to versions it understands. There is not a consistent application of > version number applied to extensions, with a higgledy-piggledy > collection of tags, "bare" and versioned documents awaiting the reader > on the "recently ratified extensions" page: > https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions > > As an aside, and this is reflected in the patch too, since many > extensions have yet to appear in a release of the ISA specs, > they are defined by commits in their respective "working draft" > repositories. > > Secondly, there is an issue of backwards compatibility, whereby allowing > numbers in the ISA string, some parsers may be broken. This would > require an additional property to be created to even use the versions in > this manner. > > ~boolean properties~ string array property > ========================================== > > If a new property is needed, the whole approach may as well be looked at > from the bottom up. A string with limited character choices etc is > hardly the best approach for communicating extension information to > software. > > Switching to using properties that are defined on a per extension basis, > allows us to define explicit meanings for the DT representation of each > extension - rather than the current situation where different operating > systems or other bits of software may impart different meanings to > characters in the string. > Clearly the best source of meanings is the specifications themselves, > this just provides us the ability to choose at what point in time the > meaning is set. If an extension changes incompatibility in the future, > a new property will be required. > > Off-list, some of the RVI folks have committed to shoring up the wording > in either the ISA specifications, the riscv-isa-manual or > so that in the future, modifications to and additions or removals of > features will require a new extension. Codifying that assertion > somewhere would make it quite unlikely that compatibility would be > broken, but we have the tools required to deal with it, if & when it > crops up. > It is in our collective interest, as consumers of extension meanings, to > define a scheme that enforces compatibility. > > The use of individual properties, rather than elements in a single > string, will also permit validation that the properties have a meaning, > as well as potentially reject mutually exclusive combinations, or > enforce dependencies between extensions. That would not have be possible > with the current dt-schema infrastructure for arbitrary strings, as we > would need to add a riscv,isa parser to dt-validate! > That's not implemented in this patch, but rather left as future work (for > the brave, or the foolish). > > acpi > ==== > > The current ACPI ECR is based on having a single ISA string unfortunately, > but ideally ACPI will move to another method, perhaps GUIDs, that give > explicit meaning to extensions. > > parser simplicity > ================= > > Many systems that parse DT at runtime already implement an function that > can check for the presence of a string in an array of string, as it is > similar to the process for parsing a list of compatible strings, so a > bunch of new, custom, DT parsing should not be needed. > Getting rid of "riscv,isa" parsing would be a nice simplification, but > unfortunately for backwards compatibility with old dtbs, existing > parsers may not be removable - which may greatly simplify > dt parsing code. In Linux, for example, checking for whether a hart > supports an extension becomes as simple as: > of_property_match_string(node, "riscv,isa-extensions", "zicbom") > > vendor extensions > ================= > > Compared to riscv,isa, this proposed scheme promotes vendor extensions, > oft touted as the strength of RISC-V, to first-class citizens. > At present, extensions are defined as meaning what the RISC-V ISA > specifications say they do. There is no realistic way of using that > interface to provide cross-platform definitions for what vendor > extensions mean. Vendor extensions may also have even less consistency > than RVI do in terms of versioning, or no care about backwards > compatibility. > The new property allows us to assign explicit meanings on a per vendor > extension basis, backed up by a description of their meanings. > > fin > === > > Create a new file to store the extension meanings and a new > riscv,isa-base property to replace the aspect of riscv,isa that is > not represented by the new property - the base ISA implemented by a hart. > > As a starting point, add properties for extensions currently used in > Linux. > > Finally, mark riscv,isa as deprecated, as removing support for it in > existing programs would be an ABI break. > > CC: Palmer Dabbelt <pal...@dabbelt.com> > CC: Paul Walmsley <paul.walms...@sifive.com> > CC: Rob Herring <robh...@kernel.org> > CC: Krzysztof Kozlowski <krzysztof.kozlowski...@linaro.org> > CC: Alistair Francis <alistair.fran...@wdc.com> > CC: Andrew Jones <ajo...@ventanamicro.com> > CC: Anup Patel <apa...@ventanamicro.com> > CC: Atish Patra <ati...@atishpatra.org> > CC: Jessica Clarke <jrt...@jrtc27.com> > CC: Rick Chen <r...@andestech.com> > CC: Leo <ycli...@andestech.com> > CC: Oleksii <oleksii.kuroc...@gmail.com> > CC: linux-ri...@lists.infradead.org > CC: qemu-ri...@nongnu.org > CC: u-boot@lists.denx.de > CC: devicet...@vger.kernel.org > CC: linux-ker...@vger.kernel.org > Reviewed-by: Palmer Dabbelt <pal...@rivosinc.com> > Acked-by: Palmer Dabbelt <pal...@rivosinc.com> > Signed-off-by: Conor Dooley <conor.doo...@microchip.com> > --- > Changes in v3: > - Per Rob's suggestion, switch to an array of strings. Cuts down on the > size, compared to booleans. It has a standard mechanism for parsing > (you need to parse arrays of strings for compatibles). It still allows > for having a limited set of explicitly defined properties - so the > advantages over a free-form string still apply. > - Pick up Palmer's Ack and Review (although I expect that he will be the > one to apply this). > --- > .../devicetree/bindings/riscv/cpus.yaml | 43 ++- > .../devicetree/bindings/riscv/extensions.yaml | 245 ++++++++++++++++++ > 2 files changed, 265 insertions(+), 23 deletions(-) > create mode 100644 Documentation/devicetree/bindings/riscv/extensions.yaml >
Reviewed-by: Rob Herring <r...@kernel.org>
