[ath9k-devel] PCI IRQ Pins

[Karl Hiramoto <karl@hiramoto.org>]

Krzysztof Halasa wrote:
> 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.
>   
Without the CF plugged in it also occurs.  :-(


-- 

--
Karl Hiramoto