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

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

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

>
> Nope, good spot, that could indeed happen in SMP configs. The code is
> expected to shut the given interrupt source _before_ calling
> rthal_irq_release(). But, the root of the problem is that
> rthal_irq_release() doesn't make sure that all _pending_ IRQs from the
> given kind are synchronized before processing. We need the equivalent of
> Linux's synchronize_irq() here, and I would tend to implement this in
> the Adeos layer directly, in ipipe_virtualize_irq() for the NULL handler
> case, since it's a matter of general consistency.


Yep, I thought about the analogue of Linux's synchronize_irq() too.
I guess, what we need to provide is the guarantee that the "cookie" argument
(as well as a "handler") remains valid as long as there is a given irq
handler in execution.

i.e.

o  ipipe_virtualize_irq(THIS_IRQ, handler=NULL, cookie=NULL) call _removes_
the IPIPE_HANDLE_FLAG so that new occurences of the THIS_IRQ is no more
accepted for the given domain;

o  then ipipe_virtualize_irq is buzy waiting (ipipe_synchronize_irq() or
smth like this) until the active ipd->irqs[THIS_IRQ].handler() is completed.
If there is not currently active handler we may drop all
cpudata->irq_pending_hits for THIS_IRQ to zero. But ipipe_sync_stage()
should check for IPIPE_HANDLE_FLAG then since this is a sign that a given
irq is no more handled (even if there are some pending ones).

o  as a final step, ipd->irqs[THIS_IRQ].handler/cookie are set to zero.

Ok, repeating myself, the main idea is to keep the "cookie" unchanged as
long as the corresponding handler is active. This would partialy resolve the
sync. problem I have got on the nucleus layer.

err... I have to orginize some issues next few days so I'll be out of my
notebook. Then I'll finilize the ipipe-irq-related patch so to be ready for
the .01 version.

--
Best regards,
Dmitry Adamushko

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