>>> This assumes a world where everything is managed by magic BIOS/OF >>> initialization. That's not the case for this user's board port. >> >> The OS (Linux, specifically) won't do it for you. It has to be set up >> beforehand. Unless "embedded Linux" gets this the wrong way around >> as well. > > This isn't an "embedded Linux" (whatever that is) thing.
That;s why I put quotes around it :-) > It is a > non-full-featured firmware thing. If you take a look at MIPS, ARM, > SH, PPC embedded platforms you'll see a similar thing. But wait, > you'll even see interrupt routing tables in the decidedly not embedded > Alpha architecture. :) Linux does do it, and there is a very clear > infrastructure for managing routing tables and standard/non-standard > PCI swizzle mechanisms. Sure. But the interrupt _assignment_ should be done by firmware. >> and b) it is wrong. On the >> majority of platforms, you can route any PCI IRQ to any number you >> want. >> The firmware will tell you where it ends up (over PCI config space). > On commodity platforms that's true. But on just about every single > dedicated purpose platform (embedded systems), interrupt routing is > a static board layout/design decision. And the firmware should still program the final interrupt number into the PCI device's config space. > No, it also tells you which pin it is routed to (A-D). That's > an important piece of information when routing interrupts. Sure. The firmware is still *required* by the PCI spec to fill the IRQ # config space field, though. > Again, on some platforms, not this one. Let's just agree that > not everything is a x86/BIOS or ppc64/pmac/OF machine that > has this done in some blackbox firmware. Oh, I believe that. But the firmware should be fixed, not a terrible hack added to Linux. Segher p.s. And I know this isn't always practically possible; but why then support a product like that at all, in the Open Source community?
