PCI IRQ routing change broke PCMCIA/prism54 driver

[Russell King]

On Sat, Aug 14, 2004 at 03:08:42PM -0600, Bjorn Helgaas wrote:
> On Friday 13 August 2004 5:39 pm, Russell King wrote:
> > On Fri, Aug 13, 2004 at 05:09:28PM -0600, Bjorn Helgaas wrote:
> > > I recently changed the way PCI interrupt routing is done.  We used to
> > > go through all the ACPI _PRTs at boot-time, programming IOSAPICs and
> > > setting pci_dev->irq.  That all happened before any drivers got involved.
> > 
> > Note that you shouldn't set pci_dev->irq for any devices below the
> > cardbus bridge (since the cardbus code knows better than anyone else
> > which IRQ must be used.)
> 
> We now DO set pci_dev->irq in pci_enable_device() (specifically, in
> acpi_pci_irq_enable()).  In this case, the ACPI _PRT seemed to supply
> the same IRQ that cardbus_assign_irqs() assigned, but I don't understand
> enough about how cardbus is different from a regular pci-pci bridge to
> feel confident.

With normal P2P bridges, it's common to have 4 IRQ lines rotated
between each slot and swizzled across bridges.  Or in a PC you have
some complex mapping between the IRQ lines and the devices on the
motherboard.

However, with Cardbus, the socket is multi-purpose (it can contain
a PCMCIA card or Cardbus card) and the meaning of the various signals
is dependent on the type of card inserted.  Therefore, only the
Cardbus bridge itself knows the purpose of the signals from the
socket.

When in Cardbus mode, there is only one interrupt line for child
devices, and this will be forwarded upstream from the bridge using
the Cardbus bridge IRQ itself.  Therefore, all child devices of a
Cardbus bridge will always have the same PCI IRQ as the Cardbus
bridge to which it is connected.

> > > One problem is that prism54 quit working.  As far as I can see,
> > > prism54 and yenta_socket are doing the right thing.  But there's
> > > a lot of interrupt magic in there that I don't understand at all.
> > 
> > Define "quit working" - how did it stop working?  Is it just that
> > prism54 receives no interrupts?  Do socket status change interrupts
> > still work?
> 
> I don't have a lot of details, but Cyrille reported that prism54
> seemed to be able to receive, but not send packets.  Inserting and
> removing the device still caused driver init and cleanup, so those
> interrupts seem to work.

Ok, still need more information though - eg, whether the IRQ count in
/proc/interrupts increases for packets received.

However, if packets are received, that seems to suggest that IRQs are
working, and the problem has been caused by some other change - maybe
in the Prism54 drivers themselves?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core