IRQ-Tables once again

[Stefan Reinauer]

Hi,

I'm trying to factor the IRQ Table generation a bit, since the
current way to write an IRQ Table plain sucks. This means

* gather all information before actually generating the table
* gather information in a readable and adjustable way.

I juggled with the Arima Hdama irq table, since this one seems to 
work. (See attachment)

Currently I have a couple of defines that are hardcoded into the file.
This should maybe be moved to the motherboard configuration files. 
(At least I would move them and the IRQ_SLOT_COUNT together)

#define IRQ_ROUTER_BUS          1
#define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
#define IRQ_ROUTER_VENDOR       0x1022
#define IRQ_ROUTER_DEVICE       0x746b
#define AVAILABLE_IRQS          0xdef8

Then I substituted the longish irq table entries with a macro
IRQ_SLOT which takes the following arguments:
 * slot number
 * bus,dev,fn
 * 4* irq link line id

Example:
/* PCI Slot 1 */
IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
/* Let Linux know about bus 1 */
IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),

If there are no objections, I am going to make this change in the code.
Who else is having IRQ Table trouble here?

Stefan

[ron minnich]

On Tue, 20 Jan 2004, Stefan Reinauer wrote:
> If there are no objections, I am going to make this change in the code.
> Who else is having IRQ Table trouble here?

looks fine.

Everyone is always having trouble. It may be best if we spend future
effort on generating IRQ tables from MP tables, if that is possible.

ron

[Stefan Reinauer]

* Stefan Reinauer  [040120 13:57]:
> I'm trying to factor the IRQ Table generation a bit, since the
> current way to write an IRQ Table plain sucks. This means
> gather all information before actually generating the table
> gather information in a readable and adjustable way.
>
> I juggled with the Arima Hdama irq table, since this one seems to 
> work. (See attachment)

On my Solo I still don't get further. 
The pci cards irqs get routed fine to the interrupt pins, but those
don't get any irq numbers.

Also, if I disable the amd8111 builtin ethernet card, the system hangs.

Best regards,
  Stefan Reinauer

[Stefan Reinauer]

* ron minnich  [040120 16:59]:
> looks fine.
>
> Everyone is always having trouble. It may be best if we spend future
> effort on generating IRQ tables from MP tables, if that is possible.

I am not sure if our current mp tables know enough of the hardware to
do so. Interrupts are often hardwired so there has to be knowledge in
LinuxBIOS on which slot gets which interrupt.

The configuration files should contain this knowledge.

< Bridges > -- 1:n -- < slots > -- 1:n(m:n?) -- < irqs >

Reading the Linux kernel sources it seems that Linux _does_ expect the
devices to have interrupts assigned already, which obviously LinuxBIOS
does not do. This has to be "fixed" if LinuxBIOS shall be open to
anybody not patching special kernels that do the right thing.

Is there any way to generate a decent mptable? The result from the
mptable utility in the freebios 1 tree seems not to do it's best on
AMD systems.

If we provide tables at all, can we maybe drop the irq table and only
use the mptable?

Best regards,
  Stefan Reinauer

[ron minnich]

On Tue, 20 Jan 2004, Stefan Reinauer wrote:
> Reading the Linux kernel sources it seems that Linux _does_ expect the
> devices to have interrupts assigned already, which obviously LinuxBIOS
> does not do. This has to be "fixed" if LinuxBIOS shall be open to
> anybody not patching special kernels that do the right thing.

no. In 2.4, in the right circumstances, the kernel can assign interrupts 
just fine.
> If we provide tables at all, can we maybe drop the irq table and only
> use the mptable?

no, sadly the kernel needs an irq table for pci bus scanning.

ron

[Stefan Reinauer]

* ron minnich  [040121 07:35]:
> > If we provide tables at all, can we maybe drop the irq table and only
> > use the mptable?
>
> no, sadly the kernel needs an irq table for pci bus scanning.

good. things seem to work now. Except that the secondary bus of the 
8151 gets set to 0, where it seems that in our case this should be 2
(the AGP device is visible on bus 2) Don't think this matters though

Stefan

[Li-Ta Lo]

On Thu, 2004-01-22 at 04:06, Stefan Reinauer wrote:
> ron minnich  [040121 07:35]:
> > > If we provide tables at all, can we maybe drop the irq table and only
> > > use the mptable?
> >
> > no, sadly the kernel needs an irq table for pci bus scanning.
>
> good. things seem to work now. Except that the secondary bus of the 
> 8151 gets set to 0, where it seems that in our case this should be 2
> (the AGP device is visible on bus 2) Don't think this matters though
>
> Stefan

Did you just dump the IRQ table from normal BIOS and put it in
LinuxBIOS ?

That is the same problem we found here. The normal BIOS tries to make
the secondary bus of 8151 as bus 0. It also tries to hide the bridge
from IRQ and/or MP table.

The way we are configuring the PCI system is too different from
what normal BIOS does on K8 systems. We can't just dump the table
from BIOS and expect it to work anymore.

Ollie

[Stefan Reinauer]

* Li-Ta Lo  [040122 17:22]:
> > good. things seem to work now. Except that the secondary bus of the 
> > 8151 gets set to 0, where it seems that in our case this should be 2
> > (the AGP device is visible on bus 2) Don't think this matters though
> Did you just dump the IRQ table from normal BIOS and put it in
> LinuxBIOS ?
> That is the same problem we found here. The normal BIOS tries to make
> the secondary bus of 8151 as bus 0. It also tries to hide the bridge
> from IRQ and/or MP table.

My assumption that the secondary bus is 0 on the 8151 comes from reading
the SECONDARY_BUS register while creating the mptable.

This happens before the irq table is used for the first time.

Some  pirq tables I've looked at showed the complete device tree of 
the machine, including the 2 cpus and all the bridges. We could probably
generate a lot of this information automatically already.
For getting the slots described right we need an additional slot
command/tag in the config mechanism. 
Then we could just walk over all north/southbridges and generate both
an irq table and an mptable from the device tree.

Stefan

Stefan Reinauer  writes:
> Li-Ta Lo  [040122 17:22]:
> > > good. things seem to work now. Except that the secondary bus of the 
> > > 8151 gets set to 0, where it seems that in our case this should be 2
> > > (the AGP device is visible on bus 2) Don't think this matters though
> > Did you just dump the IRQ table from normal BIOS and put it in
> > LinuxBIOS ?
> > That is the same problem we found here. The normal BIOS tries to make
> > the secondary bus of 8151 as bus 0. It also tries to hide the bridge
> > from IRQ and/or MP table.
>
> My assumption that the secondary bus is 0 on the 8151 comes from reading
> the SECONDARY_BUS register while creating the mptable.

Hmm.  That sounds like a bug.
> This happens before the irq table is used for the first time.
>
> Some  pirq tables I've looked at showed the complete device tree of 
> the machine, including the 2 cpus and all the bridges. We could probably
> generate a lot of this information automatically already.
> For getting the slots described right we need an additional slot
> command/tag in the config mechanism. 
> Then we could just walk over all north/southbridges and generate both
> an irq table and an mptable from the device tree.

That is one of my informal requirements for a stable freebios 2.0 release.
To be able to generate the mptable and irq tables from the device tree.

Eric

Stefan Reinauer  writes:
> Hi,
>
> I'm trying to factor the IRQ Table generation a bit, since the
> current way to write an IRQ Table plain sucks. This means
> gather all information before actually generating the table
> gather information in a readable and adjustable way.
>
> I juggled with the Arima Hdama irq table, since this one seems to 
> work. (See attachment)
>
> Currently I have a couple of defines that are hardcoded into the file.
> This should maybe be moved to the motherboard configuration files. 
> (At least I would move them and the IRQ_SLOT_COUNT together)
>
> #define IRQ_ROUTER_BUS          1
> #define IRQ_ROUTER_DEVFN        PCI_DEVFN(4,3)
> #define IRQ_ROUTER_VENDOR       0x1022
> #define IRQ_ROUTER_DEVICE       0x746b
> #define AVAILABLE_IRQS          0xdef8
>
> Then I substituted the longish irq table entries with a macro
> IRQ_SLOT which takes the following arguments:
> slot number
> bus,dev,fn
> 4* irq link line id
>
> Example:
> /* PCI Slot 1 */
> IRQ_SLOT (1, 3,1,0, 2,3,4,1 ),
> /* Let Linux know about bus 1 */
> IRQ_SLOT (0, 1,4,3, 0,0,0,0 ),
>
> If there are no objections, I am going to make this change in the code.
> Who else is having IRQ Table trouble here?

Sounds like a good small step.  I object only on the grounds
it does not go far enough.  We should go at least as far as
we have with mptable generation, so we can be isolated from
bus renumbering.  And preferably we should go all of the way
to generating it from the device tree.

Eric

ron minnich  writes:
> On Tue, 20 Jan 2004, Stefan Reinauer wrote:
> > Reading the Linux kernel sources it seems that Linux _does_ expect the
> > devices to have interrupts assigned already, which obviously LinuxBIOS
> > does not do. This has to be "fixed" if LinuxBIOS shall be open to
> > anybody not patching special kernels that do the right thing.
>
> no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> just fine.

However the statement is still true that it is desirable that we
assign irqs to support non linux operating systems.

We should have enough information to do so when we can generate
the irq tables from the device tree.
> > If we provide tables at all, can we maybe drop the irq table and only
> > use the mptable?
>
> no, sadly the kernel needs an irq table for pci bus scanning.

In particular when the kernel does not see a pci-pci bridge
going to a pci bus, it will not scan it unless it sees it in pirq
table.  This is only true of the i386 kernel.  The x86-64 kernel uses
different logic to accomplish the same thing.

Regardless if we can our house it order it will be easy to provide
kernels with what they need.

Eric

[ron minnich]

On 22 Jan 2004, Eric W. Biederman wrote:
> > no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> > just fine.
>
> However the statement is still true that it is desirable that we
> assign irqs to support non linux operating systems.

yes, that is why we've started plugging support in: we needed it for EPIA
for Plan 9 ...

ron

ron minnich  writes:
> On 22 Jan 2004, Eric W. Biederman wrote:
> > > no. In 2.4, in the right circumstances, the kernel can assign interrupts 
> > > just fine.
> >
> > However the statement is still true that it is desirable that we
> > assign irqs to support non linux operating systems.
>
> yes, that is why we've started plugging support in: we needed it for EPIA
> for Plan 9 ...

And to be very clear the reason it is needed for the EPIA
is that VIA is slightly out of spec.  VIA chipsets instead
of just providing a scratch irq register, actually interpret
the value of that register for irq routing.

So while a general purpose solution should work in the EPIA case
the via chipsets may still require special casing.  Although
hopefully we can abstract an irq router well enough we won't
have to worry about it.

Eric