Messages in this thread | | | Date | Wed, 25 Feb 2004 16:20:02 -0500 (EST) | From | Pavel Roskin <> | Subject | Re: [PATCH] yenta: irq-routing for TI bridges - take 2 |
| |
On Wed, 25 Feb 2004, Daniel Ritz wrote:
> > Yenta: CardBus bridge found at 0000:00:08.0 [133f:1233] > > Yenta: Enabling burst memory read transactions > > Yenta: Using CSCINT to route CSC interrupts to PCI > > Yenta: Routing CardBus interrupts to PCI > > Yenta TI: mfunc 0cc07d92, devctl 60 > > mfunc0 is inta, mfunc1 is irq9, mfunc2 is activity led, mfunc3 is irq7, > mfunc4 GPI3, mfunc5 is the other led, mfunc6 is irq12... > > this would give you irq7,9,12 but device control says parallel PCI only..
That's not surprising. The card is a PCI device, it's not connected to the ISA bus.
[snip] > that's just an uninitialized ti1410. so we're using PCI > > > > Yenta TI: changing mfunc to 00001000 > > Yenta TI: falling back to PCI interrupts
By the way, I looked through your mails an I still don't quite understand what the above is for. I understand you are trying serial ISA interrupts first. What's the reason for that? Do you know any device that needs this? I would prefer not to add any code unless it's known to be needed. Any probe is potentially dangerous. The known problems are with PCI cards, which have PCI interrupts and don't need anything else. I believe laptops are engineered better and don't need any fixes.
> > Yenta TI: changing mfunc to 00001002 > > Yenta: ISA IRQ mask 0x0000, PCI irq 12
Apparently you are enabling INTA. Shouldn't you disable serial ISA interrupts if they didn't work?
I also think you are using mfunc_old incorrectly. Either it should be the current value of irqmux, in which case you should change it when testing serial ISA interrupts, or it's the initial value of irqmux, in which case you shouldn't compare it to mfunc the second time. You cannot have it both ways. Please create one more variable, e.g. mfunc_current.
-- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |