On Wed, Apr 17, 2024 at 12:51 AM Sebastian Huber <
sebastian.hu...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
