From: Jessica Clarke <jrtc27@jrtc27.com>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Conor Dooley <conor@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Palmer Dabbelt <palmer@sifive.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>,
Conor Dooley <conor.dooley@microchip.com>
Subject: Re: [PATCH 0/2] riscv: Allow vlenb to be probed from DT
Date: Thu, 16 May 2024 01:58:29 +0100 [thread overview]
Message-ID: <6DDF33DF-07D6-4230-8674-F91A91660686@jrtc27.com> (raw)
In-Reply-To: <ZkVAYeNnvj99YHXt@ghost>
On 16 May 2024, at 00:08, Charlie Jenkins <charlie@rivosinc.com> wrote:
>
> On Wed, May 15, 2024 at 11:25:16PM +0100, Jessica Clarke wrote:
>> On 15 May 2024, at 22:50, Charlie Jenkins <charlie@rivosinc.com> wrote:
>>>
>>> The kernel currently requires all harts to have the same value in the
>>> vlenb csr that is present when a hart supports vector. In order to read
>>> this csr, the kernel needs to boot the hart. Adding vlenb to the DT will
>>> allow the kernel to detect the inconsistency early and not waste time
>>> trying to boot harts that it doesn't support.
>>
>> That doesn’t seem sufficient justification to me. If it can be read
>> from the hardware, why should we have to put it in the FDT? The whole
>> point of the FDT is to communicate the hardware configuration that
>> isn’t otherwise discoverable.
>
> Yes you are correct in that vlenb is discoverable on any conforming
> chip. However, the motivation here is for making decisions about how to
> boot a hart before it is booted. By placing it in the device tree, we
> are able to disable vector before the chip is booted instead of trying
> to boot the chip with vector enabled only to disable it later. In both
> cases when there is different vlenb on different harts, all harts still
> boot and the outcome is that vector is disabled. The difference is that
> with the DT entry, no vector setup code needs to be ran on a booting
> hart when the outcome will be that vector is not enabled.
Why does vlen get this special treatment? You could make exactly the
same argument for the number of asid bits. The precedent in the kernel,
whether RISC-V or other architectures, is to not do this. You can
detect it, so you should, especially since optimising for an
exceptional, unexpected error case is not worthwhile.
>> As for T-HEAD stuff, if they need it they can have a custom property.
>> Though naively I’d assume there’s a way to avoid it still...
>
> T-Head does not expose vlenb on all of their chips so I do not know of
> any other way of getting the vlenb without having it be provided in a
> DT. That was the motivation for this patch in the first place, but
> making this available to all vendors allows optimizations to happen
> during boot.
How does userspace read it then? But if T-HEAD need it, that means it
should be a thead,vlen, not a riscv,vlen.
Jess
next prev parent reply other threads:[~2024-05-16 0:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-15 21:50 [PATCH 0/2] riscv: Allow vlenb to be probed from DT Charlie Jenkins
2024-05-15 21:50 ` [PATCH 1/2] dt-bindings: riscv: cpus: add a vlen register length property Charlie Jenkins
2024-05-15 21:50 ` [PATCH 2/2] riscv: vector: Use vlenb from DT Charlie Jenkins
2024-05-15 22:25 ` [PATCH 0/2] riscv: Allow vlenb to be probed " Jessica Clarke
2024-05-15 23:08 ` Charlie Jenkins
2024-05-16 0:58 ` Jessica Clarke [this message]
2024-05-20 20:11 ` Charlie Jenkins
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=6DDF33DF-07D6-4230-8674-F91A91660686@jrtc27.com \
--to=jrtc27@jrtc27.com \
--cc=aou@eecs.berkeley.edu \
--cc=charlie@rivosinc.com \
--cc=conor.dooley@microchip.com \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=palmer@sifive.com \
--cc=paul.walmsley@sifive.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).