All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: heiko@sntech.de
Cc: linux-riscv@lists.infradead.org, samuel@sholland.org,
	guoren@kernel.org, christoph.muellner@vrull.eu, heiko@sntech.de,
	Conor Dooley <conor.dooley@microchip.com>,
	linux-kernel@vger.kernel.org, heiko.stuebner@vrull.eu
Subject: Re: [PATCH RFC 0/2] RISC-V: T-Head vector handling
Date: Tue, 14 Mar 2023 22:29:41 -0700 (PDT)	[thread overview]
Message-ID: <mhng-6d6a325c-4adb-4d9a-98a0-012c75b4562e@palmer-ri-x1c9a> (raw)
In-Reply-To: <20230228215435.3366914-1-heiko@sntech.de>

On Tue, 28 Feb 2023 13:54:33 PST (-0800), heiko@sntech.de wrote:
> From: Heiko Stuebner <heiko.stuebner@vrull.eu>
>
> As is widely known the T-Head C9xx cores used for example in the
> Allwinner D1 implement an older non-ratified variant of the vector spec.
>
> While userspace will probably have a lot more problems implementing
> support for both, on the kernel side the needed changes are actually
> somewhat small'ish and can be handled via alternatives somewhat nicely.
>
> With this patchset I could run the same userspace program (picked from
> some riscv-vector-test repository) that does some vector additions on
> both qemu and a d1-nezha board. On both platforms it ran sucessfully and
> even produced the same results.
>
>
> As can be seen in the todo list, there are 2 places where the changed
> SR_VS location still needs to be handled in the next revision
> (assembly + ALTERNATIVES + constants + probably stringify resulted in
>  some grey hair so far already)
>
>
> ToDo:
> - follow along with the base vector patchset
> - handle SR_VS access in _save_context and _secondary_start_sbi
>
>
> Heiko Stuebner (2):
>   RISC-V: define the elements of the VCSR vector CSR
>   RISC-V: add T-Head vector errata handling
>
>  arch/riscv/Kconfig.erratas           |  13 +++
>  arch/riscv/errata/thead/errata.c     |  32 ++++++
>  arch/riscv/include/asm/csr.h         |  31 +++++-
>  arch/riscv/include/asm/errata_list.h |  62 +++++++++++-
>  arch/riscv/include/asm/vector.h      | 139 +++++++++++++++++++++++++--
>  5 files changed, 261 insertions(+), 16 deletions(-)

I have no opposition to calling the T-Head vector stuff an errata 
against V, the RISC-V folks have already made it quite apparent that 
anything goes here.  I would like to get the standard V uABI sorted out 
first, though, as there's still a lot of moving pieces there.  It's kind 
of hard here as T-Head got thrown under the bus, but I'm not sure what 
else to do about it.

WARNING: multiple messages have this Message-ID (diff)
From: Palmer Dabbelt <palmer@dabbelt.com>
To: heiko@sntech.de
Cc: linux-riscv@lists.infradead.org, samuel@sholland.org,
	guoren@kernel.org, christoph.muellner@vrull.eu, heiko@sntech.de,
	Conor Dooley <conor.dooley@microchip.com>,
	linux-kernel@vger.kernel.org, heiko.stuebner@vrull.eu
Subject: Re: [PATCH RFC 0/2] RISC-V: T-Head vector handling
Date: Tue, 14 Mar 2023 22:29:41 -0700 (PDT)	[thread overview]
Message-ID: <mhng-6d6a325c-4adb-4d9a-98a0-012c75b4562e@palmer-ri-x1c9a> (raw)
In-Reply-To: <20230228215435.3366914-1-heiko@sntech.de>

On Tue, 28 Feb 2023 13:54:33 PST (-0800), heiko@sntech.de wrote:
> From: Heiko Stuebner <heiko.stuebner@vrull.eu>
>
> As is widely known the T-Head C9xx cores used for example in the
> Allwinner D1 implement an older non-ratified variant of the vector spec.
>
> While userspace will probably have a lot more problems implementing
> support for both, on the kernel side the needed changes are actually
> somewhat small'ish and can be handled via alternatives somewhat nicely.
>
> With this patchset I could run the same userspace program (picked from
> some riscv-vector-test repository) that does some vector additions on
> both qemu and a d1-nezha board. On both platforms it ran sucessfully and
> even produced the same results.
>
>
> As can be seen in the todo list, there are 2 places where the changed
> SR_VS location still needs to be handled in the next revision
> (assembly + ALTERNATIVES + constants + probably stringify resulted in
>  some grey hair so far already)
>
>
> ToDo:
> - follow along with the base vector patchset
> - handle SR_VS access in _save_context and _secondary_start_sbi
>
>
> Heiko Stuebner (2):
>   RISC-V: define the elements of the VCSR vector CSR
>   RISC-V: add T-Head vector errata handling
>
>  arch/riscv/Kconfig.erratas           |  13 +++
>  arch/riscv/errata/thead/errata.c     |  32 ++++++
>  arch/riscv/include/asm/csr.h         |  31 +++++-
>  arch/riscv/include/asm/errata_list.h |  62 +++++++++++-
>  arch/riscv/include/asm/vector.h      | 139 +++++++++++++++++++++++++--
>  5 files changed, 261 insertions(+), 16 deletions(-)

I have no opposition to calling the T-Head vector stuff an errata 
against V, the RISC-V folks have already made it quite apparent that 
anything goes here.  I would like to get the standard V uABI sorted out 
first, though, as there's still a lot of moving pieces there.  It's kind 
of hard here as T-Head got thrown under the bus, but I'm not sure what 
else to do about it.

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

  parent reply	other threads:[~2023-03-15  5:31 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 21:54 [PATCH RFC 0/2] RISC-V: T-Head vector handling Heiko Stuebner
2023-02-28 21:54 ` Heiko Stuebner
2023-02-28 21:54 ` [PATCH RFC 1/2] RISC-V: define the elements of the VCSR vector CSR Heiko Stuebner
2023-02-28 21:54   ` Heiko Stuebner
2023-03-01  2:22   ` Guo Ren
2023-03-01  2:22     ` Guo Ren
2023-03-15 18:31   ` Conor Dooley
2023-03-15 18:31     ` Conor Dooley
2023-02-28 21:54 ` [PATCH RFC 2/2] RISC-V: add T-Head vector errata handling Heiko Stuebner
2023-02-28 21:54   ` Heiko Stuebner
2023-03-01  2:12   ` Guo Ren
2023-03-01  2:12     ` Guo Ren
2023-03-15 18:56   ` Conor Dooley
2023-03-15 18:56     ` Conor Dooley
2023-06-13  6:35   ` Stefan O'Rear
2023-06-13  6:35     ` Stefan O'Rear
2023-06-22 17:39     ` Heiko Stübner
2023-06-22 17:39       ` Heiko Stübner
2023-06-22 18:58       ` Stefan O'Rear
2023-06-22 18:58         ` Stefan O'Rear
2023-06-22 20:35         ` Heiko Stübner
2023-06-22 20:35           ` Heiko Stübner
2023-06-23  3:06           ` Stefan O'Rear
2023-06-23  3:06             ` Stefan O'Rear
2023-06-23 10:22             ` Heiko Stübner
2023-06-23 10:22               ` Heiko Stübner
2023-06-23 23:26               ` Heiko Stübner
2023-06-23 23:26                 ` Heiko Stübner
2023-06-24  3:23                 ` Stefan O'Rear
2023-06-24  3:23                   ` Stefan O'Rear
2023-06-23  9:12   ` Emil Renner Berthing
2023-06-23  9:12     ` Emil Renner Berthing
2023-03-01  2:21 ` [PATCH RFC 0/2] RISC-V: T-Head vector handling Guo Ren
2023-03-01  2:21   ` Guo Ren
2023-03-15  5:29 ` Palmer Dabbelt [this message]
2023-03-15  5:29   ` Palmer Dabbelt
2023-03-15  6:31   ` Heiko Stuebner
2023-03-15  6:31     ` Heiko Stuebner
2023-06-12 15:29   ` Palmer Dabbelt
2023-06-12 15:29     ` Palmer Dabbelt
2023-06-12 15:44     ` Heiko Stübner
2023-06-12 15:44       ` Heiko Stübner

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=mhng-6d6a325c-4adb-4d9a-98a0-012c75b4562e@palmer-ri-x1c9a \
    --to=palmer@dabbelt.com \
    --cc=christoph.muellner@vrull.eu \
    --cc=conor.dooley@microchip.com \
    --cc=guoren@kernel.org \
    --cc=heiko.stuebner@vrull.eu \
    --cc=heiko@sntech.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=samuel@sholland.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.