| 180bb41d | 17-Aug-2023 |
Alexandre Ghiti <alexghiti@rivosinc.com> |
Documentation: riscv: Update boot image header since EFI stub is supported
The EFI stub is supported on RISC-V so update the documentation that
explains how the boot image header was reused to suppo
Documentation: riscv: Update boot image header since EFI stub is supported
The EFI stub is supported on RISC-V so update the documentation that
explains how the boot image header was reused to support it.
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/20230817130734.10387-3-alexghiti@rivosinc.com
show more ...
|
| bcc87900 | 19-Jun-2023 |
Palmer Dabbelt <palmer@rivosinc.com> |
RISC-V: Document that V registers are clobbered on syscalls
This is included in the ISA manual, but it's pretty common for bits of
the ISA manual that are actually ABI to change. So let's document
RISC-V: Document that V registers are clobbered on syscalls
This is included in the ISA manual, but it's pretty common for bits of
the ISA manual that are actually ABI to change. So let's document it
explicitly.
Reviewed-by: Björn Töpel <bjorn@rivosinc.com>
Link: https://lore.kernel.org/r/20230619190142.26498-1-palmer@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
| 62a31d6e | 07-Apr-2023 |
Evan Green <evan@rivosinc.com> |
RISC-V: hwprobe: Support probing of misaligned access performance
This allows userspace to select various routines to use based on the
performance of misaligned access on the target hardware.
Rathe
RISC-V: hwprobe: Support probing of misaligned access performance
This allows userspace to select various routines to use based on the
performance of misaligned access on the target hardware.
Rather than adding DT bindings, this change taps into the alternatives
mechanism used to probe CPU errata. Add a new function pointer alongside
the vendor-specific errata_patch_func() that probes for desirable errata
(otherwise known as "features"). Unlike the errata_patch_func(), this
function is called on each CPU as it comes up, so it can save
feature information per-CPU.
The T-head C906 has fast unaligned access, both as defined by GCC [1],
and in performing a basic benchmark, which determined that byte copies
are >50% slower than a misaligned word copy of the same data size (source
for this test at [2]):
bytecopy size f000 count 50000 offset 0 took 31664899 us
wordcopy size f000 count 50000 offset 0 took 5180919 us
wordcopy size f000 count 50000 offset 1 took 13416949 us
[1] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/riscv/riscv.cc#L353
[2] https://pastebin.com/EPXvDHSW
Co-developed-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Evan Green <evan@rivosinc.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
Link: https://lore.kernel.org/r/20230407231103.2622178-5-evan@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
| 00e76e2c | 07-Apr-2023 |
Evan Green <evan@rivosinc.com> |
RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA
We have an implicit set of base behaviors that userspace depends on,
which are mostly defined in various ISA specifications.
Co-deve
RISC-V: hwprobe: Add support for RISCV_HWPROBE_BASE_BEHAVIOR_IMA
We have an implicit set of base behaviors that userspace depends on,
which are mostly defined in various ISA specifications.
Co-developed-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Evan Green <evan@rivosinc.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Tested-by: Heiko Stuebner <heiko.stuebner@vrull.eu>
Reviewed-by: Paul Walmsley <paul.walmsley@sifive.com>
Link: https://lore.kernel.org/r/20230407231103.2622178-4-evan@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
| a39c6365 | 06-Dec-2022 |
Palmer Dabbelt <palmer@rivosinc.com> |
Documentation: RISC-V: patch-acceptance: s/implementor/implementer
Implementor does appear to be a word, but it's not very common.
Suggested-by: Conor Dooley <conor@kernel.org>
Reviewed-by: Anup Pa
Documentation: RISC-V: patch-acceptance: s/implementor/implementer
Implementor does appear to be a word, but it's not very common.
Suggested-by: Conor Dooley <conor@kernel.org>
Reviewed-by: Anup Patel <anup@brainfault.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20221207020815.16214-5-palmer@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
| 68eabc72 | 06-Dec-2022 |
Palmer Dabbelt <palmer@rivosinc.com> |
Documentation: RISC-V: Mention the UEFI Standards
The current patch acceptance policy requires that specifications are
approved by the RISC-V foundation, but we rely on external
specifications as we
Documentation: RISC-V: Mention the UEFI Standards
The current patch acceptance policy requires that specifications are
approved by the RISC-V foundation, but we rely on external
specifications as well. This explicitly calls out the UEFI
specifications that we're starting to depend on.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Atish Patra <atishp@rivosinc.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20221207020815.16214-4-palmer@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
| 936100d4 | 06-Dec-2022 |
Palmer Dabbelt <palmer@rivosinc.com> |
Documentation: RISC-V: Allow patches for non-standard behavior
The patch acceptance policy forbids accepting support for non-standard
behavior. This policy was written in order to both steer implem
Documentation: RISC-V: Allow patches for non-standard behavior
The patch acceptance policy forbids accepting support for non-standard
behavior. This policy was written in order to both steer implementers
towards the standards and to avoid coupling the upstream kernel too
tightly to vendor-specific features. Those were good goals, but in
practice the policy just isn't working: every RISC-V system we have
needs vendor-specific behavior in the kernel and we end up taking that
support which violates the policy. That's confusing for contributors,
which is the main reason we have a written policy in the first place.
So let's just start taking code for vendor-defined behavior.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
Link: https://lore.kernel.org/all/alpine.DEB.2.21.999.2211181027590.4480@utopia.booyaka.com/
[Palmer: merge in Paul's suggestions]
Link: https://lore.kernel.org/r/20221207020815.16214-3-palmer@rivosinc.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|