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.
He says they just work.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/