Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework Xtensa interrupt dispatch #40435

Open
andyross opened this issue Nov 17, 2021 · 0 comments
Open

Rework Xtensa interrupt dispatch #40435

andyross opened this issue Nov 17, 2021 · 0 comments
Assignees
Labels
area: Xtensa Xtensa Architecture Enhancement Changes/Updates/Additions to existing features

Comments

@andyross
Copy link
Contributor

Interrupt dispatch on Xtensa hasn't ever really been great. There's a generator tool (entirely my fault, to be clear) that uses the core-isa.h header to emit handlers for a specific platform, which is a good idea. But it generates C code that produces really pretty upsetting code quality by inserting an extra 12-word frame on the stack. And it was never integrated automatically in the build (leading to the python script getting removed). And for the common case where there is only one interrupt on a ISR, it still needs to do all the bit testing needlessly. AND it integrates quite poorly with second-level interrupt controllers (which are pervasive on this platform owing to the small number of named interrupts), leading to most of the same work having to be duplicated there too.

On top of that the existing linkage for existing Xtensa VECBASE tables is a big mess, every vector needs to go into a different section, because the vector sizes change between devices, and immediates need to be linked earlier in memory, etc... The linker script is responsible for knowing all those numbers and repeating them. This scheme, I suspect, comes from some early Cadence linker scripts, but it's been repeated in variants in many, many places and it's being hand-maintained everywhere.

But all complexity that goes away if you can generate the block as a single thing in a single place, based on the very small number of platform inputs that define things. Really we should start with core-isa.h and devicetree/kconfig and emit a minimized assembly block for the platform at build time.

Write that script.

@andyross andyross added Enhancement Changes/Updates/Additions to existing features area: Xtensa Xtensa Architecture labels Nov 17, 2021
@andyross andyross self-assigned this Nov 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Xtensa Xtensa Architecture Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

No branches or pull requests

1 participant