On Wed, Oct 2, 2019 at 1:28 AM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > Hello, > > the interrupt extension API implementation is already quite complex and > not covered by the test suite: > > https://git.rtems.org/rtems/tree/bsps/shared/irq > > In order to write generic tests for this we have to know which interrupt > vector can be controlled by software. One approach would be to add an > rtems_interrupt_get_capabilities() function: > > /** > * @brief A bit field indicating interrupt capabilities. > */ I don't care for the term 'capabilities' here, maybe 'attributes' is OK? Can we overload these fields onto rtems_attribute?
> typedef struct { > /** > * @brief Is set, if the interrupt can be enabled through > * rtems_interrupt_vector_enable(), otherwise cleared. > */ > unsigned int can_enable : 1; > > /** > * @brief Is set, if the interrupt can be enabled through > * rtems_interrupt_vector_enable(), otherwise cleared. disabled / disable() > */ > unsigned int can_disable : 1; Curious: are there vectors that can be enabled but not disabled (or vice versa)? > > /** > * @brief Is set, if the interrupt can be raised through > * rtems_interrupt_raise(), otherwise cleared. > */ > unsigned int can_raise : 1; > > /** > * @brief Is set, if the interrupt can be cleared through > * rtems_interrupt_clear(), otherwise cleared. > */ > unsigned int can_clear : 1; > > /** > * @brief Is set, if the interrupt supports a setting of its priority > through > * rtems_interrupt_set_priority(), otherwise cleared. > */ > unsigned int can_set_priority : 1; > > /** > * @brief Is set, if the interrupt supports a setting of its processor > * affinity through rtems_interrupt_set_affinity(), otherwise cleared. > */ > unsigned int can_set_affinity : 1; > > /** > * @brief Is set, if the interrupt has a pending state which can be > obtained > * through rtems_interrupt_is_pending(), otherwise cleared. > */ > unsigned int has_pending_state : 1; This is strange wording, because it implies a currently pending state. Maybe, "can_be_pending"? > > /** > * @brief Is set, if the interrupt has an active state which can be > obtained > * through rtems_interrupt_is_active(), otherwise cleared. > */ > unsigned int has_active_state : 1; ditto: can_be_active? > > /** > * @brief Is set, if the interrupt is connected to a peripheral, > otherwise > * cleared. > */ > unsigned int has_peripheral : 1; > I guess this one is more a statement of fact. > /** > * @brief Is set, if the interrupt must be raised through > * rtems_interrupt_raise_on(), otherwise cleared. > */ > unsigned int needs_target : 1; > > /** > * @brief Is set, if the interrupt is triggered by a raising signal edge, > * otherwise cleared. > */ > unsigned int is_raising_edge_triggered : 1; > > /** > * @brief Is set, if the interrupt is triggered by a falling signal edge, > * otherwise cleared. > */ > unsigned int is_falling_edge_triggered : 1; > > /** > * @brief Is set, if the interrupt is triggered by a low signal level, > * otherwise cleared. > */ > unsigned int is_low_level_triggered : 1; > > /** > * @brief Is set, if the interrupt is triggered by a high signal level, > * otherwise cleared. > */ > unsigned int is_high_level_triggered : 1; > } rtems_interrupt_capabilities; > > /** > * @brief Gets the capabilities of the specified interrupt. > * > * @retval RTEMS_SUCCESSFUL Successful operation. > * @retval RTEMS_INVALID_ID The specified vector number is invalid. > */ > rtems_status_code rtems_interrupt_get_capabilities( > rtems_vector_number vector, > rtems_interrupt_capabilities *capabilities > ); > > Interrupts with cap.can_raise set and cap.has_peripheral cleared can be > safely software controlled and used for tests. Why not just have an "is_software_triggered"? > > -- > Sebastian Huber, embedded brains GmbH > > Address : Dornierstr. 4, D-82178 Puchheim, Germany > Phone : +49 89 189 47 41-16 > Fax : +49 89 189 47 41-09 > E-Mail : sebastian.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel