[PATCH] bsps/arm: Improve GICv3 support

[Kinsey Moore]

On Wed, Apr 17, 2024 at 12:51 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 16.04.24 16:51, Kinsey Moore wrote:
> > This adds warnings for arm_interrupt_enable_interrupts and
> > arm_interrupt_restore_interrupts. I suspect a missing header. They also
> > generate a link error on the a53_lp64_qemu bsp. I also dislike the
> > while(true), but I don't think we officially have anything against it
> > and there are existing examples in the codebase.
>
> Did you test this with the latest master? Actually, I committed a
> similar patch for the GICv2 and then noticed that this broke the GICv3
> support. This is fixed by the current patch.
>
> What would be your alternative to this while (true) loop?
>
> void bsp_interrupt_dispatch(void)
> {
>    while (true) {
>      uint32_t icciar = READ_SR(ICC_IAR1);
>      rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
>      uint32_t status;
>
>      if (!bsp_interrupt_is_valid_vector(vector)) {
>        break;
>      }
>
>      status = arm_interrupt_enable_interrupts();
>      bsp_interrupt_handler_dispatch_unchecked(vector);
>      arm_interrupt_restore_interrupts(status);
>
>      WRITE_SR(ICC_EOIR1, icciar);
>    }
> }
>

You're right, I was a couple patches behind when I checked this out. That's
my fault. When I tried again just now the patch wouldn't apply because it
was already committed.

As far as the loop, the sequence of calls just doesn't lead to a clean
implementation since it's the above example, adding a loop prologue with
duplicated code, duplicating a check, or stuffing several calls including
an assignment into the conditional.

In any case, I suppose the point is moot since it's already upstream and
there's not a clear answer for "better".

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240417/9983a831/attachment.htm>