Message ID | 20230228215435.3366914-1-heiko@sntech.de |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp3274553wrd; Tue, 28 Feb 2023 13:59:33 -0800 (PST) X-Google-Smtp-Source: AK7set8wDy8GBB0OEOuYtJc41O0UmV8O7h1vPcPP+1hHK61an8BrpVkzYGg++HqGW69wo0g1vsq0 X-Received: by 2002:a17:906:9f19:b0:8b1:7eb4:6bea with SMTP id fy25-20020a1709069f1900b008b17eb46beamr6413975ejc.38.1677621573316; Tue, 28 Feb 2023 13:59:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677621573; cv=none; d=google.com; s=arc-20160816; b=K3OKFgb+hDUN92ZZfrYgNLrb60LzGlLonGwefmgAgCbH5ccvVf+OOBCCOxbzJuDCDz Js7gOF0whGFzx14F7UUkos1UwS1WtEKgy8BeJ7ylyFKKaV1JoUuJ8vsnuYUKJpZ+Eo/m D9hFgBhZPXEOIzvpnj3b07G8ILSQDkUSvH1ve7IkNDFbvjbe8DzgJiqC03gUxXKvndC3 dKRWBWyuxZaV1r4k/lVya4R5irgMLOMWKIHCZuqjNiHtrfubSBgbZFnt2ctppQ0n9Sog MKisoE8W59XoCz/6454tbO7yWKKcs10S5ZAJgkexGRabt0mvgsdojRpP79umbzsbjgoL GFZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=SBT99J/opohA9RXsVKQQkW8K6VGSRck7UgGeLO6UIuI=; b=n/T6gneK00PVLS3M6i9lzoFPdjWBOWm8Hyk1dlNkTgVA6hfKybV0WkUnGr4zvR8Plt YSh6Xy8D1GkqxaKJakUyi7hXKtekKftyLr42HfS3T+YgYO2fUTHUJXouiUCYRp9sil1m B6V0aO7aW/uNo31cJd8Xr5VHTH5Ck5h+b9yf0T9hI+uWeSg/y81Zq+xq58Bkk8FVeenS k4tX4eoPaI2M+EB4nnJ1n+9GfSc5R4zUZ9l0Ea99YlbpCksqQi+BliCOzSoihrK6UbLd Ljni+pxb4DUzKBZ+3CwZrZh+MpJByQoTBixkGHa5C3iy4gIZ9zH61G+bkQwKKO4wqP9+ YjKg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a1-20020a170906244100b008dd84b08a23si392403ejb.272.2023.02.28.13.59.10; Tue, 28 Feb 2023 13:59:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=sntech.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229896AbjB1VzF (ORCPT <rfc822;aaron.seo0120@gmail.com> + 99 others); Tue, 28 Feb 2023 16:55:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjB1VzD (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 28 Feb 2023 16:55:03 -0500 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF5F532E61 for <linux-kernel@vger.kernel.org>; Tue, 28 Feb 2023 13:54:54 -0800 (PST) Received: from ip5b412258.dynamic.kabel-deutschland.de ([91.65.34.88] helo=phil.lan) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <heiko@sntech.de>) id 1pX7vm-0005hs-FY; Tue, 28 Feb 2023 22:54:42 +0100 From: Heiko Stuebner <heiko@sntech.de> To: palmer@dabbelt.com Cc: linux-riscv@lists.infradead.org, samuel@sholland.org, guoren@kernel.org, christoph.muellner@vrull.eu, heiko@sntech.de, conor.dooley@microchip.com, linux-kernel@vger.kernel.org, Heiko Stuebner <heiko.stuebner@vrull.eu> Subject: [PATCH RFC 0/2] RISC-V: T-Head vector handling Date: Tue, 28 Feb 2023 22:54:33 +0100 Message-Id: <20230228215435.3366914-1-heiko@sntech.de> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS, T_SPF_HELO_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759113719018892435?= X-GMAIL-MSGID: =?utf-8?q?1759113719018892435?= |
Series |
RISC-V: T-Head vector handling
|
|
Message
Heiko Stübner
Feb. 28, 2023, 9:54 p.m. UTC
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(-)
Comments
On Wed, Mar 1, 2023 at 5:54 AM Heiko Stuebner <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. Great! Thx. > > > 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(-) > > -- > 2.39.0 >
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.
Hi Palmer, Am Mittwoch, 15. März 2023, 06:29:41 CET schrieb Palmer Dabbelt: > 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. yeah, that's the reason the series is an RFC and is based on the main vector series and I fully expect the main support to land first :-) . > 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. Thankfully on the kernel-side the differences to implemeent both "at the same time" are not that huge - userspace of course will need to figure out their own solution. Heiko
On Tue, 14 Mar 2023 22:29:41 PDT (-0700), Palmer Dabbelt wrote: > 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. The V-1.0 support has been merged, so I think we're good to go. Does someone mind re-spinning this against for-next so it lines up with all the new user interfaces?