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

[Daniel Ritz]

On Wednesday 17 March 2004 10:35, Pavel Roskin wrote:
> 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:
>
[deleted]
>
> 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.

ok, thanks for debugging. it makes complete sense now.

>
> 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.

ok, so far i think trying to route INTB is safe then...for the INTRTIE we
need to do more.

>
> 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.

yeah. if routing INTB doesn't work we need INTRTIE. and as you say we need
to adjust socket->cb_irq and dev->irq. it's not a problem to find the right
setting from function 0, but just setting dev->irq seems wrong. may be 
russell knows the correct way to do it.

i work on the patch later (when i'm at home). ie. resync with 2.6.5-rc1 and
change to irqs as in func0 before trying INTRTIE (the plain stupid way just
to try)...

[ as far as i can see pci_read_irq() in drivers/pci/probe.c would do the trick
  (after setting the INTRTIE bit),  but it's not exported and also
  pci_setup_device() is not exported. so may be the plain stupid way? ]

rgsd
-daniel