risc-v clic update #66759
Merged
risc-v clic update #66759
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
zephyrbot
added
area: Testsuite
zephyrbot
requested review from
aaronemassey,
asemjonovs,
carlocaione,
edersondisouza,
fkokosinski,
jeremybettis,
katsuster,
kgugala,
mgielda,
npitre,
tgorochowik and
yperess
raffi-g
force-pushed
the
riscv-clic
branch
2 times, most recently
from
ccc7acd
to
d6c4ad3
Compare
carlocaione
reviewed
Dec 27, 2023
raffi-g
force-pushed
the
riscv-clic
branch
5 times, most recently
from
2600fb3
to
5f250e4
Compare
carlocaione
reviewed
Jan 9, 2024
fkokosinski
reviewed
Jan 11, 2024
The irq priority has to be called for dynamic and direct irqs, too. For direct isrs, this was missing completely, for direct irqs just for the clic. For dynamic irqs, I replaced the current implementation with `z_riscv_irq_priority_set`. For the plic, this is exaclty the same. Signed-off-by: Greter Raffael <rgreter@baumer.com>
The trig field of clicintattr is indeed in bits 2:1. However, the mask `CLIC_INTATTR_TRIG_Msk` is only applied directly to the bitfield `INTATTR.b.trg`. Therefore it doesn't have to be shifted additionally. Signed-off-by: Greter Raffael <rgreter@baumer.com>
The mechanism for hardware vectoring has changed in the clic spec (https://github.com/riscv/riscv-fast-interrupt) in 2019. Before vectoring was enabled via `mode` bits in `mtvec`. Support for this was added in fc480c9. With more current clic implementations, this does not work anymore. Changing the `mode` bits is reserved. Vectoring can be enabled individually in the `shv` bit of `clicintattr[i]`. Since the old mechanism is still used, I added a new Kconfig for it. If this Kconfig is not set, we use the `shv` bit for harware vectoring. Signed-off-by: Greter Raffael <rgreter@baumer.com>
If CONFIG_LEGACY_CLIC is disabled, i.e. we adhere to the current CLIC spec, the mode bits of mtvec have to be 0x3. Everything else is reserved. Therefore if CONFIG_RISCV_VECTORED_MODE is enabled, the current implementation is correct. If CONFIG_RISCV_VECTORED_MODE is disabled, the mode bits have to be set, too. Signed-off-by: Greter Raffael <rgreter@baumer.com>
In a clic the mip register does not exist and software irq are triggered in the clicintip register. Signed-off-by: Greter Raffael <rgreter@baumer.com>
The CLIC has different software-triggerable irqs than the PLIC. I adjusted them. Additionally, in a clic the the irq flag 0 would mean triggering on a positive level. To work with software-triggering, the irqs have to trigger on a positive edge, i.e. 1. Signed-off-by: Greter Raffael <rgreter@baumer.com>
According to the clic specification (https://github.com/riscv/riscv-fast-interrupt), the mnxti register has be written, in order to clear the pending bit for non-vectored interrupts. For vectored interrupts, this is automatically done. From the spec: "If the pending interrupt is edge-triggered, hardware will automatically clear the corresponding pending bit when the CSR instruction that accesses xnxti includes a write." I added a kconfig `RISCV_SOC_HAS_CUSTOM_IRQ_HANDLING` to allow custom irq handling. If enabled, `__soc_handle_all_irqs` has to be implemented. For clic, non-vectored mode, I added a `__soc_handle_all_irqs`, that handles the pending interrupts according to the pseudo code in the spec. Signed-off-by: Greter Raffael <rgreter@baumer.com>
fkokosinski
approved these changes
Jan 16, 2024
|
@carlocaione can you take another look? as you've requested, I've moved the hooks into a new, ECLIC-specific file (intc_nuclei_eclic.S) |
carlocaione
approved these changes
Jan 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes the HW vectoring functionality for more current CLIC interrupt controllers.
The mechanism for hardware vectoring has changed in the CLIC spec in 2019. Before, vectoring was enabled via
modebits inmtvec. Support for this was added in fc480c9.For more current CLICs, this does not work anymore. Changing the
modebits is reserved. Vectoring can be enabled individually in theshvbit ofclicintattr[i](if the controller supports this feature).I added the kconfig option
CONFIG_LEGACY_CLIC, s.t. we can still support the "old" method. (as discussed some time ago with @carlocaione on Discord)Another big thing is the usage of
mnxtiin the interrupt handling. Currentlymcauseis used to figure out the interrupt number. This works, but the pending bit is not reset like this.According to the CLIC spec, the pending bit is always reset for edge-triggered interrupts in vectored mode. But in non-vectored mode, we have to write to the
mnxtiregister. I adjusted the interrupt handling accordingly in this case.The rest of the commits should be minor, more or less straight forward adjustments.
I tested the changes using a longan_nano board and the gen_isr_table test.
(I also had to slightly adjust some files for the
gd32vf103controller. This is however done in my other PR #66760.)