[PATCH] yenta: irq-routing for TI bridges

[Daniel Ritz]

On Tuesday 24 February 2004 02:06, Pavel Roskin wrote:
> On Tue, 24 Feb 2004, Daniel Ritz wrote:
> > ok, not good. what about: read the routing in MFUNC0, test if it works,
> > only set to PCI if it doesn't work. the problem is we can't test if
> > another device already sits on that irq. we shouldn't do anything then.
>
> What if we just check if irqmux is 0.  Is it 0 on your card?  I believe
> the only problem is the the cards that don't have irqmux initialized from
> EEPROM.

not good. newer chips (eg 1520) have a default value != 0. when a manufacter
forgets the serial ROM and does nothing in the BIOS you end up with default
values (eg. the 1520 has all serial interrupts). for the 1410 irqmux defaults to 0.

>
> I think that your fix is too intrusive.  I'm not sure it's worth it.

currently yes, i try to do better in the next version.

> After all, we are not going to support every possible piece of broken
> hardware, only those that are relatively widespread.  I have one, you have
> one (presumably), let's see what we have.
>

not broken hardware. uninitialized hardware. hardware that doesn't work with
yenta_socket but works with some redmond os...bad...

> Could you please give more information about your hardware?  My hardware
> is a card based on TI PCI1410 with broken EEPROM.  It has one slot.
> irqmux is 0 on startup.  Attempts to write to EEPROM damage the card
> permanently.  It stops working as a valid PCI device and prevents booting
> Linux with PCI support.

it's a 1410. and it's working. almost. with the redmond os it works, with linux
it works too and with freebsd the laptop dies as soon as inserting a card.

it's programmed for serial interrputs and PCI, INTA is routed. so not really
a problem there. (and my patch does _nothing_ there :)

>
> I'm concerned that you are reading irqmux in ti_override(), which is also
> used in bridges without irqmux.  Those bridges only need changes in devctl
> if any.  The fix should be in ti12xx_override() or even ti1250_override().

good catch...ti113x is one w/o irqmux...so yes ti12xx_override is the right place.
another bug in the disabled code...and i think in 2.4 too)

>
> > yeah, not as it is now. more checks are needed, PCI fallback only if
> > nothing else works. may be we should just make it a module param like in
> > pcmcia-cs i82365.c?
>
> The parameter would be the last resort.  Shifting the problem to the users
> is more like a surrender than a victory.  Not to mention that such
> approach won't work well with multiple card and/or solid kernel.

of course a module param would suck. that's why i didn't write code.

there's another bug btw. one that is probably never hit and harmless too:
rmk's notbook has parellel isa interrupts, INTA is _not_ routed. if it happens
that all the interrupts are taken by other devices the resource manager falls
back to routing the card to PCI which we know is not working...however
it is not happening on a notebook.