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

[Daniel Ritz]

On Friday 05 March 2004 00:03, Pavel Roskin wrote:
> 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.

thanks for testing..

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

you are right. fixed in the incremental patch attached..

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

wait. i didn't dismiss the problem, i wrote:
	"but it should really go back to the old value if serial interrupts
	  probing failed. then it would be correct."
(and i did it in my code but never sent it out 'cos i realized that working
 serial isa interrupts gives you no guarantee that all serial is right...that's
 why i did the pci probing stuff)

but i still dismiss that it serves two different functions. it does not. it is only
meant to be the state before changing the mfunc register. i don't care
about the startup value (what for?). i just forgot to set mfunc_old = mfunc
after a change is known to be correct.

(it's not good to write code after 9 hours setting up a network for video-on-demand
 with ATM nodes / a MPLS core / ADSL / settop-boxes and and and... )

> 
> 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 think it just sucks that some setups are not working under linux but work
under windows (be it with the built-in driver or a modified driver from the
notebook manufacter or whatever.
the point is: non-technical people cannot just fix it up. for them it's "my
pcmcia device is not working...windows is better." that cannot be right)

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

hmmm...it could hurt. remember the comment in the disabled INTA routing
code about falling back from all-serial causes hangs on some setups...
there can be setups with uninitialised chips where all-serial (default) is actually
right, just mfunc is wrong.

and the 125x / 1450 don't have an INTA setting in MFUNC0.

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

again, my noname craptop has a ti1410 chip which is actually initialized right.
(that is serial isa and parallel pci). if it wouldn't work it would take me 3 minutes
to fix it up myself. but then it's non-generic. and if you wanna do it specifc
you end up looking at the subsystem ids and patching again and again
every time a new non-worker is found...

so you see why my patch didn't work? i cannot really test it. all i can test is
if it hurts my working setup....i try to fix a problem other people have.

rgds
-daniel

ps: full patch at http://ritz.dnsalias.org/linux/


--- linux-2.6/drivers/pcmcia/ti113x.h~2	2004-03-05 00:16:49.000000000 +0100
+++ linux-2.6/drivers/pcmcia/ti113x.h	2004-03-05 01:44:06.000000000 +0100
@@ -361,11 +361,15 @@
 					config_writel(socket, TI122X_IRQMUX, mfunc);
 
 					pci = yenta_probe_cb_irq(socket);
-					if (pci)
+					if (pci) {
+						mfunc_old = mfunc;
 						goto probe_isa;
+					}
 
 					/* not working, back to old value */
 					mfunc = mfunc_old;
+					printk(KERN_INFO "Yenta TI: sock %p changing mfunc to %08x\n",
+					       socket, mfunc);
 					config_writel(socket, TI122X_IRQMUX, mfunc);
 				}
 		}
@@ -417,6 +421,15 @@
 
 	/* time to probe again */
 	pci = yenta_probe_cb_irq(socket);
+	if (pci == 1)
+		mfunc_old = mfunc;
+	else {
+		/* not working, back to old value */
+		mfunc = mfunc_old;
+		printk(KERN_INFO "Yenta TI: sock %p changing mfunc to %08x\n",
+		       socket, mfunc);
+		config_writel(socket, TI122X_IRQMUX, mfunc);
+	}
 
 probe_isa:
 	if (pci < 1)
@@ -467,6 +480,8 @@
 
 					/* not working, back to old value */
 					mfunc = mfunc_old;
+					printk(KERN_INFO "Yenta TI: sock %p changing mfunc to %08x\n",
+					       socket, mfunc);
 					config_writel(socket, TI122X_IRQMUX, mfunc);
 				}
 		}