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

[Pavel Roskin]

On Fri, 5 Mar 2004, Daniel Ritz wrote:

> > 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 don't see any interest to your efforts from anybody who can apply your
patches.  I wonder if we are wasting time.

> > I appreciate that you restarted this topic, but I double that your

Spellchecking while sleepy.  I meant "I doubt" and I still do :-(

> > 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 really appreciate that you care about other users.  Many people don't.
That say, we should write good code to realize our good intentions.

As I understand, laptops may come with a replacement PCMCIA driver for
Windows in the standard one doesn't work.  Other the laptop-specific code
tweaks the registry used by the driver.

We are trying something more ambitious, namely we want one driver to
support different hardware without user's or system integrator's
assistance.

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

Please be exact.  I think you mean this:

        /*
         * If ISA interrupts don't work, then fall back to routing card
         * interrupts to the PCI interrupt of the socket.
         *
         * Tweaking this when we are using serial PCI IRQs causes hangs
         *   --rmk
         */

I think you are missing an important fact here.  The comment precedes an
old patch that didn't check if irqmux (a.k.a mfunc) was 0.

If irqmux was incorrectly initialized (0 or not 0), then the driver would
simply not work without that old patch, but it would hang with the patch.
It's not my understanding of the comment.  In absence of more details I
assume that the driver was _working_, but stopped working after the patch
started causing hangs.

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

Well, you are trying to fix a problem that you don't have, and I'm trying
to fix a problem that I have.

My patch is based on the assumption that all cards with irqmux
uninitialized are PCI cards.  I believe that if the hardware designers
cared to use something more sophisticated than parallel PCI interrupt,
they also cared to initialize irqmux in hardware.

If you can challenge my assumption by facts, I'm ready to add support for
the hardware you show me.  In absence of such hardware, I see no reason to
add support for it.

I'm not against generic solutions.  I'm not against supporting XT drives
on PPC64 or something as rare as that, if the needed changes don't add
unreasonable complexity.

I'm against complex solutions for badly defined problems, when we try to
support buggy hardware we haven't seen by probing it, which can break a
lot of other hardware, including mass produced systems.

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

OK, who has the problem you are trying to solve?  Where's the description
of the problem, including devctl and irqmux values?  Alternatively, who
should I ask to give me details?

-- 
Regards,
Pavel Roskin