[PATCH] yenta: irq-routing for TI bridges - take 2

[Pavel Roskin]

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