[PATCH] yenta: irq-routing for TI bridges...again

[Pavel Roskin]

On Wed, 3 Mar 2004, Daniel Ritz wrote:

> stupid me...this on goes on top...

Sorry for delay with the reply.  Your patch doesn't work on my TI
PCI1410 with Linux 2.6.4-rc2.

Yenta: CardBus bridge found at 0000:01:01.0 [0000:0000]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket cf514bf8, mfunc 00000000, devctl 66
Yenta TI: sock cf514bf8 changing mfunc to 00001000
Yenta TI: sock cf514bf8 falling back to parallel PCI interrupts
Yenta TI: sock cf514bf8 changing mfunc to 00000002
Yenta TI: sock cf514bf8 changing mfunc to 00001002
Yenta TI: sock cf514bf8 falling back to PCI interrupts
Yenta: ISA IRQ mask 0x0000, PCI irq 5
Socket status: 30000006

Explanation:

mfunc_old is assigned 0 in the beginning of ti12xx_override().  It's never
changed.  Now let's find the third (i.e. the last) "changing mfunc to".
The driver sets mfunc it has printed (00001002), calls yenta_probe_irq()
and then silently restores mfunc_old, which is still 0.  My card needs 2
in that register.  All that needs to be unset is 0x1000.

I wrote you already that mfunc_old in your code serves two different
functions (the value at the previous step and the value at startup), and
one could be confused.  You dismissed my arguments, and now you got in
that trap!

I appreciate that you restarted this topic, but I double that your
overengineered patches will be applied, even if you make them work from
the fifth iteration.

I'm believe my patch can be applied even if it doesn't fix all problems
because it's minimal.

You you want your hardware to be fixed, please provide the details
(whether it's an integrated socket, product name, "lspci -v" output, mfunc
and devctl at startup, the values you need), and I'll gladly add a minimal
fixup for your specific hardware.

-- 
Regards,
Pavel Roskin