> Yes, I do have some remarks: due to legacy issues (I think to remember),
> we have a lot of unbalanced irq-enable/disable code out there. IRQs are
> currently enabled after registering a handler, but are not disabled on
> detach. That's because of problems with Linux when letting it take over
> a disabled IRQ,

let's consider possible use cases one by one :

1) single interrupt object for a given IRQ in the primary mode

I guess, this is the most wide-spread use case for the legacy code.

possible problems:

o  unbalanced enable/disable calls - e.g. a few consecutive disable calls but
   a single enable call is supposed to re-enable the IRQ line afterwards.

   the only workaround - review and fix such code :)


2) a few interrupt objects in the primary domain.

new mode so there should not be too much code that use it out there.

Actually, here goes a problem.

rtdm_irq_request();     // doesn't enable the IRQ line
...
rtdm_irq_enable();      // explicitly enables the IRQ line


the same code is called for every ISR that share this IRQ line.

so how the internal counter is supposed to be used then?

i.e. we should avoid printing a warning when the counter becomes 0.

 int xnintr_enable (xnintr_t *intr)

 {
    int ret = 0;
    spl_t s;

    xnlock_get_irqsave(&nklock,s);

    switch (__xnintr_depth(intr,0))
        {
        case 0:
-           xnlogerr("xnintr_enable() : depth == 0. "
-                    "Unbalanced enable/disable calls for IRQ%d!\n",intr->irq);
            break;
        case 1:
            ret = xnarch_irq_enable(intr->irq);
        default:
            __xnintr_depth(intr,-1);
        }

    xnlock_put_irqrestore(&nklock,s);
    return ret;
 }

and, in fact, in the shared mode a driver can't rely on the fact that
the IRQ line is still disabled
after attaching to the IRQ line.

driver 2:

rtdm_irq_request(..., SHARED, ...);     // we have attached to the shared
IRQ line which is already enabled

... // this code can't expect that it's executed with the IRQ line off.

rtdm_irq_enable();      // explicitly enables the IRQ line


does it make sense to enable the IRQ line when attaching to the line?

rtdm_irq_request();
// the line is already enabled


3) the IRQ line is shared across domains (both primary and linux).

yep, new interface doesn't fit this case well.

Maybe, it would be possible to use the same "counter" accounting scheme
for xnintr_enable/disable() in the primary domain and
enable_irq/disable_irq() in the linux one.


> Another thing I have on my mind ATM is providing an additional IRQ
> model: threaded IRQs. This is certainly not the best default model, but
> it could help in certain scenarios to reduce prio-inversions due to
> overloaded IRQ handler jobs (like we face from time to time with devices
> on the slow ISA-bus...).

In the simplest case, I guess, one may just defer part of the work to
the bottom half -
a thread of a given priority. And bottom halves (threads) for
different ISRs may have different
priorities (== thread's priority).

Concerning the general support, RTDM layer would be likely preferable
but I'm not sure that all necessary
bits are available on this layer.

e.g.

it would be better to run the following code from xnintr_shirq_handler()
...
    while (intr)
        {
        s |= intr->isr(intr) & XN_ISR_BITMASK;
        ++intr->hits;
        intr = intr->next;
        }
...

already from the thread context.


--
Best regards,
Dmitry Adamushko

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to