On Thu, Feb 17, 2005 at 03:50:27PM -0600, Barbier, Renaud (GE Infrastructure)
wrote:
> I have a question regarding interrupt and irq locking.
> I derived (or copied from somehwere)a library (linux 2.4.26) for the 440GX
> from ppc4xx_pic.c to take care of the last interrupt register (UIC2).
> This a newbie question regarding get_irq/spin_lock
> here is get_irq:
> ...
> bits = mfdcr(DCRN_UIC_MSR(UICBASE));
> if ((bits & 0x40000000) == 0x40000000)
> {
> bits = mfdcr(DCRN_UIC_MSR(UIC0));
> irq = ( ffs(bits));
> irq = 32-irq;
> }
> ...
>
> my question is what guarantee that the code is executed atomically?
ppc_md.get_irq is called with hard irqs disabled, this makes
its execution context atomic.
> The reason I asked is that we have a driver that did the following in the
> ioctl call:
>
> disable_irq(26);
> /* do something */
> enable_irq(26);
>
> as you noticed there is not any spin_lock.
> Sometimes, this leads get_irq to see UICBASE indicating an irq in UIC0 and
> UIC0_MSR to return 0. hence you get irq 32 (MAL_SERR) and an infinite loop.
> My current fix is to use irqsave/irqrestore in the driver which I
> think is the correct way to do (but I may be wrong please help).
Yes, this is preferable to disable/enable_irq.
> However, I have a colleague (here is the human problem of my
> questions: him or me is the problem) that insists that I should do
> something in get_irq to have atomic execution.
No, it's already atomic.
Probably it's a race which cannot be avoided anyway because external
IRQs are completely async, and your version of ppc4xx_pic.c just has a
bug. I'll think about it a little more.
Could you try 2.6 version of ppc_4xx_pic.c? I don't think 2.4 has any
official support for UIC2 anyway.
--
Eugene.
