On 08/01/06, Philippe Gerum <[EMAIL PROTECTED]> 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

Reply via email to