[coreboot] [PATCH] artecgroup/dbe62: Route ethernet adapter IRQ correctly and reduce interrupt contention problems by using different IRQs for all the interrupt lines
Marc.Jones at amd.com
Mon May 5 19:06:05 CEST 2008
ron minnich wrote:
> (I'm hoping someone will do this :-)
> One issue I'm having is that the hfcpci card (or driver) can't
> tolerate shared interrupts.
> But we have shared interrupts on the various cs5536 boards, since we
> put USB interrupt info in the table.
> To allow us to have non-shared interrupts for all devices, we need to
> get the USB interrupts out of the PIR table. They are not really
> routed via the standard IRQ router anyway -- they are internal -- and
> don't need to share interrupt #s with the other devices that are
> actually routed via the interrupt routing hardware.
> Put simply, having the USB f.3,4,5 devices in the PIR table works, but
> is really a bit of a mistake.
> OK, where do we put the IRQ info for the USB devices? In the DTS for
> the cs5536.
> SO in DTS for the cs5536 we need three more properties,
> with reasonable settings for them. Then in the chipset init code, we
> need to see if these are set and, if so, set the IRQ line in the f.3,
> f.4, and f.5 devices.
> If this is confusing I can explain in more detail, but later, I'm
> tired, and the ISDN card just locked up again. How can such a simple
> driver have so many failure modes? Oh, wait, it's not simple, sigh.
> but, short form: on the cs5536, USB interrupts should not be described
> in the PIR table, but via settings derived from dts. They should be
> initialized in cs5536 setup code, no in the PIR setup code. That will
> allow us to have non-shared interrupts on the various PCI slots on,
> e.g., alix1c, and allow broken drivers like hfcpci to work.
I understand that you are addressing a problem but I have to disagree
that the 5536 USB controllers shouldn't be in the PIR table. Even if you
change the internal devices IRQs you should still put them in the table.
As for changing the IRQs. In PCI there is no interrupt contention. The
interrupts are level triggered. You should be able to put them all on a
single IRQ. It is easier to debug device driver issues if they are on
separate IRQs but that should be the only advantage. If IRQs are not
being serviced correctly and fast enough that is a Linux driver issue.
For your specific problems; Do you have a USB device plugged in? If not
there should be little to no activity from USB. How can that be the
problem? Since you do have a problem with that mainboard and card, I
think that any changes you make should be only for that mainboard.
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
More information about the coreboot