[Xenomai-core] Re: [PATCH, RFC] nucleus:shared irq and possible ipipe problem

[Dmitry Adamushko <dmitry.adamushko@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

On 08/01/06, Philippe Gerum <rpm@xenomai.org> wrote:
>
> > [skiped]

> In ipipe_sync_stage() :

> > ...
> >             if (--cpudata->irq_pending_hits[irq] == 0) {
> >                  __clear_bit(rank,
> >                          &cpudata->irq_pending_lo[level]);
> >                  ipipe_mark_irq_delivery(ipd,irq,cpuid);
> >             }
> > (*)
> >
> > // run the corresponding isr handler
> >
> > This code drops the irq_pending_hits to 0 before running the handler.
> >
>
> > Doesn't it make the following code wrong ?
> >
> >     for (_cpuid = 0; _cpuid < nr_cpus; _cpuid++)
> >             while (ipd->cpudata[_cpuid].irq_pending_hits[irq] > 0)
> >                     cpu_relax();
> >
> >
> > as the handler still can be running / or even about to be run when
> > ipd->cpudata[_cpuid].irq_pending_hits[irq] is already 0.
> >
> > We can remove the (*) code at the end of ipipe_sync_stage() so that
> > irq_pending_hits[irq] may become 0 only after the corresponding isr
> > handler has completed.
> >
>
> I don't like the idea of having the interrupt bookkeeping stuff
> incompletely updated while calling a handler that might sleep and/or
> migrate to another CPU.
>
> Another option would be to check for SYNC flag; the syncer sets it
> before entering the dispatch loop.


It's unset for all domains but root when the corresponding irq handler is
running.

ipipe_sync_stage() :
...
            __clear_bit(IPIPE_SYNC_FLAG, &cpudata->status);
            ipd->irqs[irq].handler(irq, ipd->irqs[irq].cookie);
            __set_bit(IPIPE_SYNC_FLAG, &cpudata->status);

So it doesn't help here as it is used now.

Ok, so far I have built all synchronization completely on the nucleus layer,
provided that the "cookie" param is not used as it is passed to the handler
but is taken via the rthal_irq_cookie() service being in a protected
section.

The disadvantage so far is that the recently extended adeos irq interface is
not used as it is supposed to be (the "cookie" argument of the handler).

I'll post the current version of the patch in the separate mail.

--
>
> Philippe.
>



--
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 3761 bytes --]