Ollie Lho <[EMAIL PROTECTED]> writes:

> do the rest things. I really have no idea how to do this in 2.2.x kernel.

Duh.  I forgot that 2.2.x doesn't have that code.
If you have an io_apic and an SMP kernel you can get the 2.2.x to
do the routing for you though.  You need to setup MP tables though.

If you are trully ambitions you can get linuxBIOS to interpret set
up the interrupts itself.  Which would make 2.2.x and dos work... :)

> 
> P.S. Actually I don't understand the PIRQ very well niether. I just dump it from
> 
> normal AWARD bios and "manually" translate it to C. I am working on a utility
> which can scan your F segment and generate the PIRQ table.

I guess this should be safe, but take a close look when you do that
and make certain no slots are left out.

The executive summary of what is going on is:
* Each pci slot has 4 interrupt lines.
* Nothing in the pci architecture says how those interrupt lines
  should get to a cpu.
* Devices compatible with the PIIXE or the IO_APIC receive the
  pci interrupt lines. (Usually they are shared with other slots)
* pirq table (PIIXE) or MP-table (IO_APIC) descripe how the interrupts
  from the pci slots get to the interrupt router.
* The kernel then knows how to program interrupt router (PIIXE & IO_APIC)
  and select the irqs that the it will see.

The IO_APIC is the better interface.   As it allows more than
just the 16 legacy interrupt lines.

Ollie do you know if the SIS630 has an IO-APIC?  If so generating an
MP-table is probably the better route to take.  Espcially if people
want to run 2.2.  2.4 can use the an IO-APIC even in uniprocessor
mode which should be as efficient as you can get.

For a really different data point some alpha machines have a seperate
interrupt line for every pci interrupt going into their interrupt
controller.

Eric

Reply via email to