[PATCH v2 13/17] riscv: vector: Support xtheadvector save/restore
Charlie Jenkins
charlie at rivosinc.com
Wed Apr 17 15:00:07 PDT 2024
On Wed, Apr 17, 2024 at 03:50:24PM +0100, Conor Dooley wrote:
> On Mon, Apr 15, 2024 at 09:12:10PM -0700, Charlie Jenkins wrote:
>
> > diff --git a/arch/riscv/kernel/vector.c b/arch/riscv/kernel/vector.c
> > index 6727d1d3b8f2..f42eaa8178e9 100644
> > --- a/arch/riscv/kernel/vector.c
> > +++ b/arch/riscv/kernel/vector.c
> > @@ -33,10 +33,24 @@ int riscv_v_setup_vsize(void)
> > {
> > unsigned long this_vsize;
> >
> > - /* There are 32 vector registers with vlenb length. */
> > - riscv_v_enable();
> > - this_vsize = csr_read(CSR_VLENB) * 32;
> > - riscv_v_disable();
> > + /*
> > + * This is called before alternatives have been patched so can't use
> > + * riscv_has_vendor_extension_unlikely
>
> () after that function name please.
>
> > + */
> > + if (has_xtheadvector_no_alternatives()) {
> > + /*
> > + * Although xtheadvector states that th.vlenb exists and
> > + * overlaps with the vector 1.0 vlenb, an illegal instruction is
> > + * raised if read. These systems all currently have a fixed
> > + * vector length of 128, so hardcode that value.
>
> I had this written before the meeting, so pasting it anyway:
> -- >8 --
> From 5ed25d0f841e755b8dd4f1f6a3ea824601758d8e Mon Sep 17 00:00:00 2001
> From: Conor Dooley <conor.dooley at microchip.com>
> Date: Wed, 17 Apr 2024 14:39:36 +0100
> Subject: [PATCH] dt-bindings: riscv: cpus: add a vlen register length property
>
> Add a property analogous to the vlenb CSR so that software can detect
> the vector length of each CPU prior to it being brought online.
> Currently software has to assume that the vector length read from the
> boot CPU applies to all possible CPUs. On T-Head CPUs implementing
> pre-ratification vector, reading the th.vlenb CSR may produce an illegal
> instruction trap, so this property is required on such systems.
>
> Signed-off-by: Conor Dooley <conor.dooley at microchip.com>
> ---
> We could actually enforce the latter since we know the compatibles of
> the relevant CPUs and can tell if xtheadvector is present.
> ---
> Documentation/devicetree/bindings/riscv/cpus.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index d067f2a468ee..2a6449a0f1d7 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -95,6 +95,12 @@ properties:
> description:
> The blocksize in bytes for the Zicboz cache operations.
>
> + riscv,vlenb:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + VLEN/8, the vector register length in bytes. This property is required in
> + systems where the vector register length is not identical on all harts.
> +
> # RISC-V has multiple properties for cache op block sizes as the sizes
> # differ between individual CBO extensions
> cache-op-block-size: false
> --
> 2.43.0
>
>
>
> > + */
> > + this_vsize = 128;
> > + } else {
> > + /* There are 32 vector registers with vlenb length. */
> > + riscv_v_enable();
> > + this_vsize = csr_read(CSR_VLENB) * 32;
> > + riscv_v_disable();
> > + }
Thank you for this, I can add this patch to my v3.
- Charlie
More information about the linux-riscv
mailing list