Krzysztof Halasa wrote:
> Karl Hiramoto <karl@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
