>We have about 12 interrupt controllers we end up using on PPC. I'm
>suspicious of any effort to base Linux/PPC generic interrupt control code
>paths on a software architecture that's been tested with 3. More to the
>point, we get ASIC's that roll in a standard interrupt controller and add
>some
>And I seriously doubt that PPC SMP irq handling has gotten _nearly_ the
>amount of testing and hard work that the x86 counterpart has. Things
>like support for CPU affinity, per-irq spinlocks, etc etc.
Some of those are the reason I moved part of the x86 irq.c code to PPC
indeed.
>Now, I'm not
We have about 12 interrupt controllers we end up using on PPC. I'm
suspicious of any effort to base Linux/PPC generic interrupt control code
paths on a software architecture that's been tested with 3. More to the
point, we get ASIC's that roll in a standard interrupt controller and add
some "imp
In article <[EMAIL PROTECTED]>,
Cort Dougan <[EMAIL PROTECTED]> wrote:
>
>More generic in terms of using irq_desc[] and some similar structures I can
>see. Making do_IRQ() and enable/disable use the same names and structures
>as x86 isn't sensible. They're different ports, with different design
>handled correctly, does nothing more than what we need (well it does, but
>those parts,
>mostly the irq locking, got already removed), etc...
Sorry, I meant mostly the irq probing
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
>More generic in terms of using irq_desc[] and some similar structures I can
>see. Making do_IRQ() and enable/disable use the same names and structures
>as x86 isn't sensible. They're different ports, with different design
>philosophies.
>
>I don't believe that the plan is a common irq.c - lets
} Also, we currently don't use the same mecanism as i386, and since Linus
} expressed his desire to have irq.c become generic, I'm trying to make sure
} I fully understand it before merging in PPC the bits that I didn't merge
} them yet.
More generic in terms of using irq_desc[] and some similar
>We do have broken interrupt controllers in this respect. We already have a
>way of handling it. Ben, take a look at set_lost().
Heh, I know, thanks ;)
However, our current scheme implies a hack to __sti() that I'd like to get
rid of since it adds an overhead allover the place that could proba
>In particular, if an edge-triggered interrupt comes in on an x86 IO-APIC
>while that interrupt is disabled, enabling the interrupt will have caused
>that irq to get dropped. And if it gets dropped, it will never ever happen
>again: the interrupt line is now active, and there will never be another
} > I don't have a simple way on PPC to cause the interrupt to happen again,
} > as you can imagine this is rather controller-specific. However, looking
} > at the code closely, I couldn't figure out a case where having
} > IRQ_PENDING in enable_irq() makes sense.
}
} It only makes sense for brok
On Sat, 3 Mar 2001, Benjamin Herrenschmidt wrote:
>
> Especially, my question is about the code in enable_irq() which checks
> for IRQ_PENDING, and then
> "replays" the interrupt by asking the APIC to issue it again.
>
> I don't have a simple way on PPC to cause the interrupt to happen again,
Hi Linus !
I've some questions regarding the behaviour of arch/i386/kernel/irq.c
regarding IRQ_PENDING and IRQ_REPLAY.
Especially, my question is about the code in enable_irq() which checks
for IRQ_PENDING, and then
"replays" the interrupt by asking the APIC to issue it again.
I don't have a s
12 matches
Mail list logo
