I can't explain the underlying details of the kernel, but I can tell you
it is safe to return FALSE if you dont need additional work to be
completed in the workloop - even if you are sharing interrupts.
Brett.
Udi Brazilai wrote:
> Hello everyone,
>
>
>
> We're using IOFilterInterruptEventSource for one of our device drivers.
> On some systems this device shares its interrupt with other devices, and
> on some it gets its own interrupt.
>
> As I understand from the documentation Filter() should return a
> true/false value indicating whether the interrupt originated from our
> device or not, and when Filter() returns true, the secondary interrupt
> handler will be called in workloop context to handle the interrupt.
>
>
>
> In many cases, however, we can easily finish the handling of the
> interrupt within the filter function without requiring the invocation of
> the secondary handler, e.g. by simply acknowledging the interrupt to the
> HW and incrementing a counter in memory.
>
> Theoretically it could be ok to return false from the Filter() in such
> a case and waive the secondary handler, but this contradicts with the
> implied role of Filter() which is to determine where the interrupt came
> from. This could result in OS code seeing an interrupt that nobody
> claims responsibility for; a paranoid OS could assume that the interrupt
> remains unacknowledged in the HW and choose to protect itself by
> disabling the interrupt source altogether (to prevent an infinite
> interrupt loop).
>
>
>
> So the question is, what is the requirement from the return value of
> Filter()? Do I always need to return true if my device generated the
> interrupt, or is it safe to return false if the interrupt was completely
> handled by the Filter()? Following the documentation to the letter it
> seems that the latter is true, but I still can't be certain about it.
>
>
>
> Thanks,
>
> Udi.
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Darwin-drivers mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-drivers mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-drivers/email@hidden
This email sent to email@hidden
