Re: PCI1410 Interrupt Problems

[Russell King <rmk@arm.linux.org.uk>]

On Sun, Aug 03, 2003 at 11:52:29PM +0200, Jochen Friedrich wrote:
> The kernel messages don't differ if the hack is applied or not. The hack
> simply configures the PCI1410 to use a particular pin for INTA output.
> Without the hack, the counter for IRQ9 in /proc/interrupt simply stays at 0.
> 
> Aug  3 14:51:02 rt1-sp kernel: Linux Kernel Card Services 3.1.22
> Aug  3 14:51:02 rt1-sp kernel:   options:  [pci] [cardbus] [pm]
> Aug  3 14:51:02 rt1-sp kernel: PCI: Enabling device 02:0a.0 (0000 -> 0002)
> Aug  3 14:51:02 rt1-sp kernel: PCI: Found IRQ 9 for device 02:0a.0
> Aug  3 14:51:02 rt1-sp kernel: Yenta IRQ list 0000, PCI irq9
> Aug  3 14:51:02 rt1-sp kernel: Socket status: 30000010
> Aug  3 14:51:03 rt1-sp kernel: cs: IO port probe 0x0c00-0x0cff: clean.
> Aug  3 14:51:03 rt1-sp kernel: cs: IO port probe 0x0800-0x08ff: clean.
> Aug  3 14:51:03 rt1-sp kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x377 0x3b8-0x3df 0x4d0-0x4d7
> Aug  3 14:51:03 rt1-sp kernel: cs: IO port probe 0x0a00-0x0aff: clean.
> Aug  3 14:51:03 rt1-sp kernel: cs: memory probe 0xa0000000-0xa0ffffff: clean.

Ok, well, register 0x8c is highly machine specific, so we need to find
a way to identify your machine and fix it up based on that information.

Unfortunately, there are some hacks in the kernel at the moment which
mess up the Cardbus IRQ routing by touching this register - the kernel
should not be the one to play with hardware design specific register
settings, especially when they are applied without thought across
many hardware variants.

I notice your lspci didn't list a subvendor / subdevice ID for your
cardbus bridges - can you confirm by reporting the output of:

# setpci -s bus:slot.func 0x40.l

Thanks.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html