Testing the interrupt extension API?

[Gedare Bloom]

On Wed, Oct 2, 2019 at 1:28 AM Sebastian Huber
<sebastian.huber at 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.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel