New API directives to enable/disable interrupt vectors
Gedare Bloom
gedare at rtems.org
Wed Jun 16 18:34:09 UTC 2021
On Wed, Jun 16, 2021 at 5:23 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> Hello,
>
> I work currently on an extension of the interrupt manager API:
>
> https://devel.rtems.org/ticket/3269
>
> This API is not related to the interrupt handling at processor level. It
> is related to the management of interrupts at the interrupt controller
> level.
>
What happens in case there's no controller?
> We need directives to enable and disable interrupt vectors.
> Unfortunately, rtems_interrupt_enable() and rtems_interrupt_disable()
> are already occupied. My first approach was to use
> rtems_interrupt_mask() and rtems_interrupt_unmask(), however, I noticed
> that rtems_interrupt_mask is already used. What about
>
> rtems_interrupt_permit()
>
> and
>
> rtems_interrupt_forbid()
>
> ?
>
Implicitly, rtems_interrupt_* means a directive oriented toward the
CPU side of the interrupt management? It seems there should be an
explicit indicator of API calls that target the controller side, like
rtems_interrupt_controller_xxx()?
Then you can reuse directive names, like
rtems_interrupt_controller_disable(). Unless there's a possibility to
enable/disable the controller itself. in which case, we'd need
something else like rtems_interrupt_controller_disable_irq(int irq) or
whatever, and perhaps rtems_interrupt_controller_disable_irqs().
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax: +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
More information about the devel
mailing list