The following two patches remove request_8xxirq and redesign how we
handle interrupts. There's patches both against 2.5 (For inclusion
first, mainly for comment tho) and for 2.4 (which has been tested but is
intended for inclusion much later, probably 2.4.21 time-frame).
The new interrupt handling scheme allows all 8xx interrupt handlers to be
installed via the standard request_irq() function. This required a
"flattened" representation of the interrupt vectors from all interrupt
controllers so that we can uniquely identify any interrupt source with a
single integer. The interrupt vector numbers used by request_irq() are:
request_irq vector interrupt source
------------------ ----------------
0 - 15 SIU interrupt vectors 0 to 15
16 - 47 CPM interrupt vectors 0 to 31
48 - 63 8259 interrupt vectors 0 to 15 (MBX only)
In the 2.4 version of this patch, cpm_install_handler and request_8xxirq
still work as expected. The 2.5 version removes both of bits of
backwards compatibility (since there will no doubt be numerous other
changes for drivers to take into consideration for 2.4.xx vs 2.6.xx).
The first benefit of all of these changes is that it gets PCI working on
MBX (and any other 8xx system with PCI). The second benefit is that it
lets all of the otherwise properly written PCMCIA drivers just work
(such as orinoco_cs) which would previously panic() on request_irq().
The bulk of this work was done by Andy Lowe and then moved up to current
kernels and expanded slightly by myself.
Comments?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2002-06-20 16:58:49
The other problem is the "namespace" of request_irq() usually assumes
numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
use these numbers.
Not that much actually. Look at pmac, I have nothing even close to
the 0..15 ISA namespace. Of course, a few crappy legacy ISA drivers
are broken, but we don't use them on PMAC, and you can eventually
hack them if you need them on embedded until a proper fix gets done.
BTW. At least serial.c is beeing redesigned by Russel King (ARM) ;)
Ben.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-06-20 21:04:17
Tom Rini wrote:
The first benefit of all of these changes is that it gets PCI working on
MBX (and any other 8xx system with PCI).
No, it doesn't. It just enables the 8259 to kinda work. The PCI on MBX
does not work well, and this does nothing to improve it. Does anyone have
a working MBX anymore?
Comments?
There is more to these patches than just the interrupt change. Why is
the CPM microcode, and so much of commproc.c changed?
Of course, I don't like it, but oh well.......It's just another hack that
doesn't do anything different. Most importantly, I hate shit like this:
request_irq(CPM_IRQ_OFFSET + CPMVEC_SMC2, ......
because you have to program the CPM with only the CPM vector number, not the
vector plus offset. I want a real cascaded interrupt design, not just another
hack that opens the possibility to calling a generic PC function with the
wrong parameters. The OpenPIC/EPIC are hacked just as badly, and there are
new integrated controllers coming that would benefit from a real design improvement
instead of just another hack.
I'm most concerned with the updates outside of just the interrupt stuff, and
I hope someone tests this.
Whatever you want......Have fun........
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Thu, Jun 20, 2002 at 05:04:17PM -0400, Dan Malek wrote:
Tom Rini wrote:
quoted
The first benefit of all of these changes is that it gets PCI working on
MBX (and any other 8xx system with PCI).
No, it doesn't. It just enables the 8259 to kinda work. The PCI on MBX
does not work well, and this does nothing to improve it. Does anyone have
a working MBX anymore?
Yes, Andy who did that part of the code and claims that PCI does indeed
work on it.
quoted
Comments?
There is more to these patches than just the interrupt change. Why is
the CPM microcode, and so much of commproc.c changed?
I think I forgot to strip out a few things. And so much of commproc.c
changed because the interrupt handling/assignment stuffs changed. Aside
from the !CONFIG_UCODE_PATCH changes (which are seperate, I'll do those
later..) the rest is related to the changes themselves, or are updating
the callers to the new mechanisms (The old ones do still work and infact
did most of my testing that way).
Of course, I don't like it, but oh well.......It's just another hack that
doesn't do anything different. Most importantly, I hate shit like this:
request_irq(CPM_IRQ_OFFSET + CPMVEC_SMC2, ......
because you have to program the CPM with only the CPM vector number, not the
vector plus offset.
I don't follow you here. Is this just another complaint about how the
normal way of handling cascades is ugly?
I want a real cascaded interrupt design, not just
another
hack that opens the possibility to calling a generic PC function with the
wrong parameters.
If a 'generic PC function' calls with the wrong parameters, fix the
function. Right now we happily panic() on all of the correctly written
drivers as well as the broken ones. This makes it possible to actually
test drivers to see which ones are broken and fix them.
The OpenPIC/EPIC are hacked just as badly, and there are
new integrated controllers coming that would benefit from a real design
improvement instead of just another hack.
Perhaps sometime later in 2.5 a 'real design improvement' will happen.
But I also don't see what that has to do with this, other than the
8xx/8260 way of doing things is going.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
From: Dan Malek <hidden> Date: 2002-06-20 22:03:42
Tom Rini wrote:
Yes, Andy who did that part of the code and claims that PCI does indeed
work on it.
I know Andy is sitting on a ton of 82xx PCI changes that would be nice
to see checked in some day. :-)
I don't follow you here. Is this just another complaint about how the
normal way of handling cascades is ugly?
Sort of. The problem is you often have to program the CPM interrupt
vector for a particular device into the CPM. For example, you may have
to tell the SCC2 device on the CPM what vector to use, which in turn
is also used to configure the interrupt controller. Using this scheme
of this patch, these two numbers are different because you give request_irq()
a different number than you program into the CPM for this device. There
are more and more integrated controllers that do this, and using hardcoded
values with offsets isn't going to work in those cases.
The other problem is the "namespace" of request_irq() usually assumes
numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
use these numbers. Now, on the 8xx and 8260, you have changed what these
values mean. I believe I saw a patch from Wolfgang that left request_irq()
alone (and left the other 8xx and CPM interrupt request functions as they were),
but in request_irq() he remapped the number to be something meaningful on 8xx.
I would kind of prefer his patches to this one.
If a 'generic PC function' calls with the wrong parameters, fix the
function. Right now we happily panic() on all of the correctly written
drivers as well as the broken ones. This makes it possible to actually
test drivers to see which ones are broken and fix them.
See Wolfgang's patches......
Perhaps sometime later in 2.5 a 'real design improvement' will happen.
But I also don't see what that has to do with this, other than the
8xx/8260 way of doing things is going.
The 8xx is more complicated due to its multiple cascaded interrupts.
The 8260 removed the CPM cascade, making it more simple to implement.
What do Andy's patches for 8260+PCI look like? There has to be a
cascade in there someplace that isn't represented in any of these patches.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Thu, Jun 20, 2002 at 06:03:42PM -0400, Dan Malek wrote:
Tom Rini wrote:
quoted
Yes, Andy who did that part of the code and claims that PCI does indeed
work on it.
I know Andy is sitting on a ton of 82xx PCI changes that would be nice
to see checked in some day. :-)
Well, Andy says that to get PCI happy all he had to do was to stop using
request_8xxirq. So that patch should make PCI nice 'n happy there, but
it's untested.
quoted
I don't follow you here. Is this just another complaint about how the
normal way of handling cascades is ugly?
Sort of. The problem is you often have to program the CPM interrupt
vector for a particular device into the CPM. For example, you may have
to tell the SCC2 device on the CPM what vector to use, which in turn
is also used to configure the interrupt controller. Using this scheme
of this patch, these two numbers are different because you give
request_irq()
a different number than you program into the CPM for this device. There
are more and more integrated controllers that do this, and using hardcoded
values with offsets isn't going to work in those cases.
'hardcoded == bad', mental note made.
The other problem is the "namespace" of request_irq() usually assumes
numbers 0 to 15 are an 8259, and many legacy devices are hardcoded to
use these numbers. Now, on the 8xx and 8260, you have changed what these
values mean. I believe I saw a patch from Wolfgang that left request_irq()
alone (and left the other 8xx and CPM interrupt request functions as they
were),
but in request_irq() he remapped the number to be something meaningful on
8xx.
I would kind of prefer his patches to this one.
I believe this is tied into the "let the good drivers actually work and
the bad ones give a 'meaningful' blow-up" part of the patch.
quoted
If a 'generic PC function' calls with the wrong parameters, fix the
function. Right now we happily panic() on all of the correctly written
drivers as well as the broken ones. This makes it possible to actually
test drivers to see which ones are broken and fix them.
See Wolfgang's patches......
I don't see how that fixes the panic() in request_irq().
quoted
Perhaps sometime later in 2.5 a 'real design improvement' will happen.
But I also don't see what that has to do with this, other than the
8xx/8260 way of doing things is going.
The 8xx is more complicated due to its multiple cascaded interrupts.
The 8260 removed the CPM cascade, making it more simple to implement.
What do Andy's patches for 8260+PCI look like? There has to be a
cascade in there someplace that isn't represented in any of these patches.