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, usbf3 usbf4 usbf5
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.
ron
Ron,
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.
Marc