PCI1410 Interrupt Problems

PCI1410 Interrupt Problems

[Jochen Friedrich]

Hi,

when using this PCI Cardbus bridge, i got an interrupt assigned to the
card by the BIOS, but no interrupts were ever delivered, at all. So no
insert/remove events have been handled and devices couldn't generate
interrupts, as well:

02:0a.0 Class 0607: 104c:ac50 (rev 01)
02:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
        Flags: bus master, medium devsel, latency 168, IRQ 9
        Memory at 14000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
        Memory window 0: 14400000-147ff000 (prefetchable)
        Memory window 1: 14800000-14bff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        16-bit legacy interface ports at 0001

It looks like the designers of this card "forgot" to put a sane
configuration of the Multifunction Routing Register (0x8C) in their
EEPROM. After setting up the INTA output pin of the PCI1410, the device
started to work like a charm :-)

This i added to yenta_config_init():

config_writew(socket, 0x8C, 0x02);

I'm not sure if this will help with all of these devices of if it even
makes problems on others. But it might be an idea to add a config option
for this hack...

Thanks,
--jochen

Re: PCI1410 Interrupt Problems

[Russell King]

On Sun, Aug 03, 2003 at 10:15:09PM +0200, Jochen Friedrich wrote:
> when using this PCI Cardbus bridge, i got an interrupt assigned to the
> card by the BIOS, but no interrupts were ever delivered, at all. So no
> insert/remove events have been handled and devices couldn't generate
> interrupts, as well:
> 
> 02:0a.0 Class 0607: 104c:ac50 (rev 01)
> 02:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
>         Flags: bus master, medium devsel, latency 168, IRQ 9
>         Memory at 14000000 (32-bit, non-prefetchable) [size=4K]
>         Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
>         Memory window 0: 14400000-147ff000 (prefetchable)
>         Memory window 1: 14800000-14bff000
>         I/O window 0: 00004000-000040ff
>         I/O window 1: 00004400-000044ff
>         16-bit legacy interface ports at 0001
> 
> It looks like the designers of this card "forgot" to put a sane
> configuration of the Multifunction Routing Register (0x8C) in their
> EEPROM. After setting up the INTA output pin of the PCI1410, the device
> started to work like a charm :-)
> 
> This i added to yenta_config_init():
> 
> config_writew(socket, 0x8C, 0x02);
> 
> I'm not sure if this will help with all of these devices of if it even
> makes problems on others. But it might be an idea to add a config option
> for this hack...

Can you provide the kernel messages without the hack applied please?

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

Re: PCI1410 Interrupt Problems

[Jochen Friedrich]

Hi Russell,

> Can you provide the kernel messages without the hack applied please?

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.

--jochen

Re: PCI1410 Interrupt Problems

[Russell King]

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

Re: PCI1410 Interrupt Problems

[Jochen Friedrich]

Hi Russel,

> 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

rt1-sp:~# setpci -s 00:11.0 0x40.l
00000000

Thanks,
--jochen

Re: PCI1410 Interrupt Problems

[Russell King]

On Fri, Aug 08, 2003 at 07:40:19AM +0200, Jochen Friedrich wrote:
> Hi Russel,

Grumble.

> > 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
> 
> rt1-sp:~# setpci -s 00:11.0 0x40.l
> 00000000

Ok, so no subvendor/subdevice IDs to identify the hardware variant.
Hmm, this isn't going to be an easy one to automatically fix up.
Maybe we can pick up on the host bridge IDs - can you send me the
complete output of lspci -vv please?

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

Re: PCI1410 Interrupt Problems

[Jochen Friedrich]

Hi Russell,

> Grumble.

Sorry. It was too early in the morning after too little time for sleep
:-(.

> Ok, so no subvendor/subdevice IDs to identify the hardware variant.
> Hmm, this isn't going to be an easy one to automatically fix up.
> Maybe we can pick up on the host bridge IDs - can you send me the
> complete output of lspci -vv please?

The particular piece of hardware is a PCI card which can be installed in
any PIC PC, so i guess the host bridge ID might vary depending on the host
where the card is installed...

rt1-sp:~# lspci -vv
00:00.0 Host bridge: Intel Corp. 430FX - 82437FX TSC [Triton I] (rev 02)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 64

00:07.0 ISA bridge: Intel Corp. 82371FB PIIX ISA [Triton I] (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0

00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (prog-if 00 [VGA])
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop+ ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 0
        Region 0: Memory at ff000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:11.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 168, cache line size 08
        Interrupt: pin A routed to IRQ 9
        Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
        Memory window 0: 10400000-107ff000 (prefetchable)
        Memory window 1: 10800000-10bff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
        16-bit legacy interface ports at 0001

--jochen

Re: PCI1410 Interrupt Problems

[Jochen Friedrich]

Hi Russell,

> 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.

after thinking a bit, i believe, you're right here. Initially, i just
wanted to have an option to mess with this register, but there is already
the setpci tool which can do exactly this. So for now, i just added the
setpci command to my modules.conf and i'm set.

It's just a shame that PCI/Cardbus bridge manufacturers try to save a few
cents by not soldering the configuration EEPROM to their board and supply
some specialized drivers for Win just to make their crap work. So if you
place 2 different cards in the same PC with the same PCI1410 but different
pin mapping, you're doomed...

--jochen

Re: PCI1410 Interrupt Problems

[David Hinds]

On Mon, Aug 11, 2003 at 08:33:23PM +0200, Jochen Friedrich wrote:
> Hi Russell,
> 
> > 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.
> 
> after thinking a bit, i believe, you're right here. Initially, i just
> wanted to have an option to mess with this register, but there is already
> the setpci tool which can do exactly this. So for now, i just added the
> setpci command to my modules.conf and i'm set.
> 
> It's just a shame that PCI/Cardbus bridge manufacturers try to save a few
> cents by not soldering the configuration EEPROM to their board and supply
> some specialized drivers for Win just to make their crap work. So if you
> place 2 different cards in the same PC with the same PCI1410 but different
> pin mapping, you're doomed...

I do think there is room for having some sane default settings to be
used when an unconfigured bridge is detected.  For most of the TI
bridges, there is only one reasonable default for how to enable PCI
interrupt delivery.  The important part here is "unconfigured bridge":
never fool with interrupt delivery on a bridge that has been set up
by the BIOS, which covers essentially all laptops.

-- Dave

Re: PCI1410 Interrupt Problems

[Russell King]

On Mon, Aug 11, 2003 at 12:00:48PM -0700, David Hinds wrote:
> I do think there is room for having some sane default settings to be
> used when an unconfigured bridge is detected.  For most of the TI
> bridges, there is only one reasonable default for how to enable PCI
> interrupt delivery.  The important part here is "unconfigured bridge":
> never fool with interrupt delivery on a bridge that has been set up
> by the BIOS, which covers essentially all laptops.

Note that I will be looking into this shortly - I've been putting off
a lot of kernel work over the last week due to the rediculously high
temperatures we've been experiencing in the UK, not wanting to add
any extra heat from either people or machines to an already baking
house.

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