kernel.git/arch/riscv/kernel/cpu.c, branch linux-6.0.y

RISC-V: Print SSTC in canonical order

2022-10-12T07:39:04Z

commit 61a41d16ad20657f93613229a8b17766c51dc849 upstream. This got out of order during a merge conflict, fix it by putting the entries in the correct order. Fixes: 7ab52f75a9cf ("RISC-V: Add Sstc extension support") Signed-off-by: Palmer Dabbelt Reviewed-by: Conor Dooley Reviewed-by: Heiko Stuebner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220920204518.10988-1-palmer@rivosinc.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman

RISC-V: Add Sstc extension support

2022-08-11T21:41:52Z

This series implements Sstc extension support which was ratified recently. Before the Sstc extension, an SBI call is necessary to generate timer interrupts as only M-mode have access to the timecompare registers. Thus, there is significant latency to generate timer interrupts at kernel. For virtualized enviornments, its even worse as the KVM handles the SBI call and uses a software timer to emulate the timecomapre register. Sstc extension solves both these problems by defining a stimecmp/vstimecmp at supervisor (host/guest) level. It allows kernel to program a timer and recieve interrupt without supervisor execution enviornment (M-mode/HS mode) intervention. * palmer/riscv-sstc: RISC-V: Prefer sstc extension if available RISC-V: Enable sstc extension parsing from DT RISC-V: Add SSTC extension CSR details

RISC-V: Enable sstc extension parsing from DT

2022-08-11T21:36:13Z

The ISA extension framework now allows parsing any multi-letter ISA extension. Enable that for sstc extension. Reviewed-by: Anup Patel Signed-off-by: Atish Patra Link: https://lore.kernel.org/r/20220722165047.519994-3-atishp@rivosinc.com Signed-off-by: Palmer Dabbelt

arch/riscv: add Zihintpause support

2022-08-11T15:03:49Z

Implement support for the ZiHintPause extension. The PAUSE instruction is a HINT that indicates the current hart’s rate of instruction retirement should be temporarily reduced or paused. Reviewed-by: Heiko Stuebner Tested-by: Heiko Stuebner Signed-off-by: Dao Lu [Palmer: Some minor merge conflicts.] Link: https://lore.kernel.org/all/20220620201530.3929352-1-daolu@rivosinc.com/ Link: https://lore.kernel.org/all/20220811053356.17375-1-palmer@rivosinc.com/ Signed-off-by: Palmer Dabbelt

riscv: implement Zicbom-based CMO instructions + the t-head variant

2022-08-11T03:49:32Z

This series is based on the alternatives changes done in my svpbmt series and thus also depends on Atish's isa-extension parsing series. It implements using the cache-management instructions from the Zicbom- extension to handle cache flush, etc actions on platforms needing them. SoCs using cpu cores from T-Head like the Allwinne D1 implement a different set of cache instructions. But while they are different, instructions they provide the same functionality, so a variant can easly hook into the existing alternatives mechanism on those. [Palmer: Some minor fixups, including a RISCV_ISA_ZICBOM dependency on MMU that's probably not strictly necessary. The Zicbom support will trip up sparse for users that have new toolchains, I just sent a patch.] Link: https://lore.kernel.org/all/20220706231536.2041855-1-heiko@sntech.de/ Link: https://lore.kernel.org/linux-sparse/20220811033138.20676-1-palmer@rivosinc.com/T/#u * palmer/riscv-zicbom: riscv: implement cache-management errata for T-Head SoCs riscv: Add support for non-coherent devices using zicbom extension dt-bindings: riscv: document cbom-block-size of: also handle dma-noncoherent in of_dma_is_coherent()

riscv: Add support for non-coherent devices using zicbom extension

2022-07-28T22:30:51Z

The Zicbom ISA-extension was ratified in november 2021 and introduces instructions for dcache invalidate, clean and flush operations. Implement cache management operations for non-coherent devices based on them. Of course not all cores will support this, so implement an alternative-based mechanism that replaces empty instructions with ones done around Zicbom instructions. As discussed in previous versions, assume the platform being coherent by default so that non-coherent devices need to get marked accordingly by firmware. Reviewed-by: Christoph Hellwig Signed-off-by: Heiko Stuebner Reviewed-by: Guo Ren Link: https://lore.kernel.org/r/20220706231536.2041855-4-heiko@sntech.de Signed-off-by: Palmer Dabbelt

riscv: cpu: Add 64bit hartid support on RV64

2022-07-19T23:39:14Z

The hartid can be a 64bit value on RV64 platforms. Add support for 64bit hartid in riscv_of_processor_hartid() and update its callers. Signed-off-by: Sunil V L Reviewed-by: Atish Patra Link: https://lore.kernel.org/r/20220527051743.2829940-5-sunilvl@ventanamicro.com Signed-off-by: Palmer Dabbelt

riscv: Don't output a bogus mmu-type on a no MMU kernel

2022-05-21T19:20:04Z

Currently on a 64-bit kernel built without CONFIG_MMU, /proc/cpuinfo will show the current MMU mode as sv57. While the device tree property "mmu-type" does have a value "riscv,none" to describe a CPU without a MMU, since commit 73c7c8f68e72 ("riscv: Use pgtable_l4_enabled to output mmu_type in cpuinfo"), we no longer rely on device tree to output the MMU mode. (Not even for CONFIG_32BIT.) Therefore, instead of readding code to look at the "mmu-type" device tree property, let's continue with the existing convention to use fixed values for configurations where we don't determine the MMU mode at runtime. Add a new fixed value for !CONFIG_MMU in order to output the correct MMU mode in cpuinfo. Signed-off-by: Niklas Cassel Link: https://lore.kernel.org/r/20220414173037.1381927-1-niklas.cassel@wdc.com Signed-off-by: Palmer Dabbelt

riscv: add RISC-V Svpbmt extension support

2022-05-12T04:36:33Z

Svpbmt (the S should be capitalized) is the "Supervisor-mode: page-based memory types" extension that specifies attributes for cacheability, idempotency and ordering. The relevant settings are done in special bits in PTEs: Here is the svpbmt PTE format: | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 N MT RSW D A G U X W R V ^ Of the Reserved bits [63:54] in a leaf PTE, the high bit is already allocated (as the N bit), so bits [62:61] are used as the MT (aka MemType) field. This field specifies one of three memory types that are close equivalents (or equivalent in effect) to the three main x86 and ARMv8 memory types - as shown in the following table. RISC-V Encoding & MemType RISC-V Description ---------- ------------------------------------------------ 00 - PMA Normal Cacheable, No change to implied PMA memory type 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory 11 - Rsvd Reserved for future standard use As the extension will not be present on all implementations, implement a method to handle cpufeatures via alternatives to not incur runtime penalties on cpu variants not supporting specific extensions and patch relevant code parts at runtime. Co-developed-by: Wei Fu Signed-off-by: Wei Fu Co-developed-by: Liu Shaohua Signed-off-by: Liu Shaohua Co-developed-by: Guo Ren Signed-off-by: Guo Ren [moved to use the alternatives mechanism] Signed-off-by: Heiko Stuebner Reviewed-by: Philipp Tomsich Link: https://lore.kernel.org/r/20220511192921.2223629-10-heiko@sntech.de Signed-off-by: Palmer Dabbelt

riscv: cpu.c: don't use kernel-doc markers for comments

2022-03-31T22:42:46Z

Repair kernel-doc build warnings caused by using "/**" kernel-doc markers for comments that are not in kernel-doc format: cpu.c:89: warning: cannot understand function prototype: 'struct riscv_isa_ext_data isa_ext_arr[] = ' cpu.c:114: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst Signed-off-by: Randy Dunlap Reported-by: kernel test robot Reviewed-by: Atish Patra Signed-off-by: Palmer Dabbelt