[PATCH] yenta: irq-routing for TI bridges...again

[Pavel Roskin]

On Tue, 16 Mar 2004, Daniel Ritz wrote:

> > handlers:
> > [<f88b97b0>] (yenta_interrupt+0x0/0x30 [yenta_socket])
> > Disabling IRQ #12
>
> this is strange. there's the probe handler missing. which of the two
> yenta_probe_cb_irq() is responsible? can you add some printk's?

What happens is that when INTRTIE is set, both 00:08.0 and 00:08.1 have
"Interrupt: pin A routed to IRQ 12" in "lspci -vvv".  It I unset it,
00:08.1 has "Interrupt: pin B routed to IRQ 11" instead:

00:08.0 CardBus bridge: Texas Instruments PCI1221
	Subsystem: SCM Microsystems: Unknown device 1233
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168, Cache Line Size: 0x10 (64 bytes)
	Interrupt: pin A routed to IRQ 12
	Region 0: Memory at ef00a000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
	Memory window 0: ef000000-ef001000 (prefetchable)
	Memory window 1: ef002000-ef003000
	I/O window 0: 00004400-000044ff
	I/O window 1: 0000d000-0000d403
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
	16-bit legacy interface ports at 0001

00:08.1 CardBus bridge: Texas Instruments PCI1221
	Subsystem: SCM Microsystems: Unknown device 1233
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 168, Cache Line Size: 0x10 (64 bytes)
	Interrupt: pin B routed to IRQ 11
	Region 0: Memory at ef004000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
	Memory window 0: ef005000-ef006000 (prefetchable)
	Memory window 1: ef007000-ef008000
	I/O window 0: 00004800-000048ff
	I/O window 1: 0000e000-0000e403
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
	16-bit legacy interface ports at 0001

If I unset INTRTIE before 00:08.0 is probed, then by the time when 00:08.1
is probed, its dev->irq is already set to 11.  This means that
yenta_probe_handler() waits for irq 11, which doesn't arrive.

When the driver sets INTRTIE, dev->irq remains 11, and
yenta_probe_handler() still waits for irq 11.  Instead, irq 12 arrives to
yenta_interrupt(), which doesn't see any events.  This condition is
detected and the interrupt is disabled.

Here's the log with some additional debug data:

yenta_probe_cb_irq: dev=0000:00:08.0, pci_irq=12 cb_irq=12 io_irq=0
yenta_probe_handler for 0000:00:08.0
Yenta: ISA IRQ mask 0x0000, PCI irq 12
Socket status: 30000006
Yenta: CardBus bridge found at 0000:00:08.1 [133f:1233]
sysctl before: 0x0844d060
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:08.1, mfunc 0x0cc07d22, devctl 0x60
yenta_probe_cb_irq: dev=0000:00:08.1, pci_irq=11 cb_irq=11 io_irq=0
Yenta TI: socket 0000:00:08.1 probing PCI interrupt failed, trying to fix
parallel PCI
parallel PCI, mfunc = 0x0cc07d22, mfunc_old = 0x0cc07d22
parallel PCI, set INTRTIE
yenta_probe_cb_irq: dev=0000:00:08.1, pci_irq=11 cb_irq=11 io_irq=0
yenta_interrupt 12 - no events for 0000:00:08.0
[8 more lines]
yenta_interrupt 12 - no events for 0000:00:08.0
irq 12: nobody cared!
Call Trace:
 [<c01098f7>] __report_bad_irq+0x27/0x80
[backtrace skipped]
handlers:
[<f88b97b0>] (yenta_interrupt+0x0/0x90 [yenta_socket])
Disabling IRQ #12
parallel PCI, unset INTRTIE
Yenta TI: socket 0000:00:08.1 no PCI interrupts. Fish. Please report.
Yenta: ISA IRQ mask 0x0000, PCI irq 0


Possible solutions:

Give up the idea of adjusting INTRTIE.  Consider it a separate problem.

Simply set socket->cb_irq and socket->dev->irq to the same value as in
function 0.  Worked for me, although I simply hardcoded 12.  PCI
developers may be very angry.  Changing socket->cb_irq only is not enough
according to my tests.

Find why my card didn't produce irq 11 before INTRTIE was set.  Make it
work with two different interrupts and hope that it will work for other
cards as well.

-- 
Regards,
Pavel Roskin