Hi Rajat,
I was just restating what i had originally said in my first mail,
which is
>>>
Lets for this discussion say one interrupt number 5 is shared amongst 3
devices(d1, d2, d3) .(obviously the interrupt is level as its shared, otherwise we would miss if multiple of them are fired)
at time T0 d3 fires an interrupt 5
at T1 d1 also fires an interrupt.
and finally at T2 the kernel finds out (or gets ready to service the int) that int 5 was fired.
Kernel
starts iterating its list of handlers and call d1's INT handler.
d1's INT services the interrupt and returns INT_HANDLED (even though device d1
wasn't the first to fire an Interrupt to start with).
but the int
line is still high/low(d3's int hasn't been handled yet),
so the kernel goes over the process again and calls d1's
handler this time it sees it has nothing to service and moves on to call d2's ISR and
finally d3's ISR.
What i'm getting at is that if d3 is sharing an
interrupt line with a device/s which generate a lot of interrupt it could
be possible that d3 would have a high interrupt latency(in other word, would
have to wait longer to get its INT serviced).
<<<<
Actually as i was re-reading it, i just realized d3 won't have a wait a lot longer as any time an INT comes in kernel would go though all the ISRs ( no matter what order they came in)
only thing what matters is like you, Mike said is to make sure the ISR are as quick as possible.
Thanks,
Bisla
> Date: Fri, 4 May 2007 08:21:55 +0530
> From: rajat.noida.india@xxxxxxxxx
> To: k_bisla@xxxxxxxxxxx
> Subject: Re: Shared Interrupt handling.
> CC: vapier.adi@xxxxxxxxx; kernelnewbies@xxxxxxxxxxxx
>
> On 5/4/07, k b <k_bisla@xxxxxxxxxxx> wrote:
> > hmm... so then how does the int handler know if it needs to service an
> > interrupt.
> >
> > I mean it could be that the handler was invoked by the kernel when it walked
> > through all the int handlers.
> > so how does the handler know if there is actually an interrupt to be
> > serviced if there's not hardware reg on the device to tell that.
> >
>
> Hi KB,
>
> What Mike is getting at is this: It is upon the handler to determine
> whether the device it services, has actually generated this interrupt.
> How the ISR enquires the IRQ status from the device is device
> specific. In most of the situations, the device has a register which
> says so.
>
> However, I could not understand your reasoning behind the statement
> that a device generating seldom interrupts should not be sharing the
> IRQ line with a device device generic IRQs often. Can you please
> elaborate?
>
> Thanks,
>
> Rajat
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! Try it!
