Re: PCI IRQ Pins

[Krzysztof Halasa <khc@pm.waw.pl>]

Karl Hiramoto <karl@hiramoto.org> writes:

> Krzysztof, you mentioned clearing the IRQ in the platform code, is
> there an example of this somewhere?

Sure, e.g. in the patches I posted yesterday (not IRQ-related but
you can do that the same way):

static void __init gmlr_setup_nec(struct pci_dev *dev)
{
...
}

DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB,
			 gmlr_setup_nec);

Or:
static int __init gmlr_pci_init(void)
 {
	if (!machine_is_goramo_mlr())
		return 0;

	pci_common_init(&gmlr_hw_pci);

 	if (xxx) {
		/* need to adjust number of USB ports on NEC chip */
		u32 value, addr = BIT(32 - SLOT_NEC) | 0xE0;
		if (!ixp4xx_pci_read(addr, NP_CMD_CONFIGREAD, &value)) {
			value &= ~7;
			value |= (hw_bits & CONFIG_HW_USB_PORTS);
			ixp4xx_pci_write(addr, NP_CMD_CONFIGWRITE, value);
		}
	}
}

> There is a Compact flash on hda connected the the HPT371N,  looking at 
> the IDE code it looks like the drive my not be ready,  or the drive may 
> raise the IRQ..

Non-DMA flash, I had issues with those and a VIA-based card.

> As soon as request_irq is called, the IRQ happens.

Right. This means either the driver hasn't prepared the chip completely
(perhaps there is some exception which isn't normally signalled?) or
it's the other chip asking for interrupt.

But

> irq 28: nobody cared (try booting with the "irqpoll" option)
...
> [<c0054bf8>] (request_threaded_irq+0x0/0xe0) from [<c01783c0>] 
> (ide_host_register+0x444/0x60c)
> [<c0177f7c>] (ide_host_register+0x0/0x60c) from [<c017c158>] 
> (ide_pci_init_one+0xdc/0x10c)
> [<c017c07c>] (ide_pci_init_one+0x0/0x10c) from [<c024cec0>] 
> (hpt366_init_one+0x344/0x3a8)
>  r8:c0321cac r7:c38737a0 r6:00000000 r5:c3814400 r4:c0321920
> [<c024cb7c>] (hpt366_init_one+0x0/0x3a8) from [<c0015998>] 
> (ide_scan_pcibus+0x50/0x124)
>  r7:c0015948 r6:c0319330 r5:c3814400 r4:c0318fb4
> [<c0015948>] (ide_scan_pcibus+0x0/0x124) from [<c0020290>] 
> (do_one_initcall+0x58/0x190)
>  r8:c0321cac r7:c0015948 r6:00000000 r5:c001c840 r4:c001c784
> [<c0020238>] (do_one_initcall+0x0/0x190) from [<c0008744>] 

> handlers:
> [<c0174bc0>] (ide_intr+0x0/0x220)

And

> irq 28: nobody cared (try booting with the "irqpoll" option)

> [<c0054bf8>] (request_threaded_irq+0x0/0xe0) from [<bf0a65cc>] 
> (ath_pci_probe+0x1a8/0x294 [ath9k])
> [<bf0a6424>] (ath_pci_probe+0x0/0x294 [ath9k]) from [<c0152678>] 
> (local_pci_probe+0x20/0x24)

> handlers:
> [<c0174bc0>] (ide_intr+0x0/0x220)
> [<bf09fde4>] (ath_isr+0x0/0x2cc [ath9k])
> Disabling IRQ #28

(it's ath9k and not ath5k as I previously thought).

That means that both drivers (IRQ handlers) don't recognize the IRQ
source. So either one of the drivers is very seriously broken (which
I find hard to believe) or one of the chips generates an IRQ which isn't
normally used (thus not checked for).
But I would try to use a DMA-able CF first, perhaps it's the CF IRQ?
And/or try to boot without the CF.
-- 
Krzysztof Halasa