-
Notifications
You must be signed in to change notification settings - Fork 588
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
soc/software: add irq_attach() / irq_detach() #1815
Conversation
I like it, thank you very much! I would add:
so we don't have to rely on the assumption the compiler will drop the irq parameter. |
Next step is a cleanup pass: i was either going to do something like you proposed or the more complete solution of adjusting the function signature. One concern with my proposal is that it increases ram usage for all targets by 128 byes. If this is a concern there are some clean ways to offer something like CONFIG_DYNAMIC_IRQ and have a constant table in rodata instead of bss. |
Could we limit the jump table to just the registered IRQ's? This will limit ram demand to 4 bytes per interrupt, seams quite reasonable.
This will add |
return irq_attach(irq, NULL); | ||
} | ||
|
||
void isr(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some considerations for isr(void):
- Assert if irq within NR_IRQ
- NR_IRQ can be generated in soc.py see soc/software: add irq_attach() / irq_detach() #1815 (comment)
litex/soc/software/libbase/uart.c
Outdated
@@ -110,6 +110,8 @@ void uart_init(void) | |||
|
|||
uart_ev_pending_write(uart_ev_pending_read()); | |||
uart_ev_enable_write(UART_EV_TX | UART_EV_RX); | |||
if (irq_attach) | |||
irq_attach(UART_INTERRUPT, (isr_t)uart_isr); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly need wrapper see #1815 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, or just change the function signature. I just avoided this initially to minimise diffs.
litex/soc/software/libbase/isr.c
Outdated
@@ -191,18 +191,46 @@ void isr(void) | |||
} | |||
|
|||
#else | |||
void isr(void) | |||
#define NR_IRQ 32 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generate this define using soc.py #1815 (comment)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - I like that solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, I have added my comments.
I'll make some tweaks soon, just not sure exactly when. |
Hmm just thinking here: When calling Unless ... you register the same interrupt handler for multiple interrupt lines: Then you will have to scan in your driver data for the structure/context for this particular interrupt. This extra jitter introduced by scanning could be reduced if we introduce a
We could even go the extra step to initialize a default interrupt handler at compile time removing the need for a NULL check in the main ISR: Putting it all together:
Static initialization with a default handler is of course optional might complicate things a from an include perspective. But the nice thing is that it can be done at compile time... and it saves us a NULL check in the main ISR:
|
I forgot the disable the interrupts when updating the irq_table in the above example.. |
Many isr interfaces include both irq and a content pointer. I'm not currently using either, but included irq as it was easy with minimal size implications and was compatible with the cpu interfaces that haven't been updated. It also allows for simple compile time integration if that is a requirement that needs to be maintained. Yes a context pointer could be useful one day, but chose to not add something i have no need for (currently) in a first pass at this. Following the principal of not letting perfect get in the way of good 😊 Is this something you would actually use? I'm likely to need it at some stage but thia is just a minor infrastructure tweak I want to upstream ASAP to reduce the number of patches I'm maintaining in our trees. |
I must admit, I don't need perfect either ;) |
cleaner mechanism for other software to use interrupts
Final cleanup - I've dropped the unused irq parameter to minimise pointless changes. This or a content pointer can be reconsidered in the future. |
I think NR_IRQ is a hangover from my time following linux coding styles :) |
cleaner mechanism for other software to use interrupts
NOTE: uart_isr(void) not changed to uart_isr(int) for compatibility with cpus that don't implement this interface yet.
This is a different approach to #1807 and #1735