arch/xtensa: Automatically generate interrupt handlers (finally) #72768
+44
−288
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
The script to generate the _soc_inthandlers.h header has been run manually for years, only because I was a cmake novice at the time and unsure how to integrate it into the build. So every new platform has to find the script and template file and figure out how to generate the file. And in a few cases it looks like we've tried to EDIT the resulting files in the tree. Let's finally do this right. The file is now dropped (for every xtensa platform) as a "xtensa_handlers.h" file, and there is a Kconfig to control whether the original/manual file or the new one is used by the platform code. We can migrate the other platforms slowly as people have time to validate. Signed-off-by: Andy Ross <[email protected]>
Some oddballs cores can be generated without an "NMI" interrupt, in which case core-isa.h will not define XCHAL_NMILEVEL. This code is trying to unconditionally mask interrupts, so XCHAL_EXCM_LEVEL is the pedantically correct choice anyway (NMI's by definition, cannot be masked). Signed-off-by: Andy Ross <[email protected]>
The original code would (unsurprisingly) only emit handler functions for interrupt levels with interrupts associated with them. But it turns out that it's possible to configure an xtensa device with an empty-but-otherwise-real interrupt level (specifically mt8195 has a "Level 3" interrupt not associated with any input IRQS, it's one level above EXCM_LEVEL and one level below the DEBUG exception). This script is old, and not set up to parse the full core-isa.h directly, so modifying it to detect this condition is difficult. Instead, just emit all 15 possible interrupt handlers, even empty ones. The extra stubs are harmless as they'll be dropped if uncalled. Signed-off-by: Andy Ross <[email protected]>
|
I include the integration for dc233c only as that's all I can smoke test easily. Other platforms can set the kconfig and remove their own _soc_inthandlers.h at leisure. |
nashif
reviewed
May 14, 2024
The script runs as part of the build now. Use that feature and remove the old static file from the manually-run script. Signed-off-by: Andy Ross <[email protected]>
iuliana-prodan
approved these changes
May 15, 2024
dcpleung
approved these changes
May 20, 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.
The script to generate the _soc_inthandlers.h header has been run manually for years, only because I was a cmake novice at the time and unsure how to integrate it into the build. So every new platform has to find the script and template file and figure out how to generate the file. And in a few cases it looks like we've tried to EDIT the resulting files in the tree.
Let's finally do this right. The file is now dropped (for every xtensa platform) as a "xtensa_handlers.h" file, and there is a Kconfig to control whether the original/manual file or the new one is used by the platform code. We can migrate the other platforms slowly as people have time to validate.