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

[Daniel Ritz]

On Tuesday 09 March 2004 19:15, Pavel Roskin wrote:
> 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.

linux-pcmcia is a low traffic list with not much people caring about. and
most of them don't have the problem.
and no, i don't think i'm wasting my 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.

registry is the answer to windows problems :)

> 
> 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
>          */

yes.

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

maybe yes, maybe it's not a problem if mfunc is 0. i don't know. i didn't add
the comment, so i don't know the details.

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

probably yes. pci cards. but checking for 0 is just not sufficent. it's another
hack IMHO. different chips different defaults.

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

a non-initialized TI1510 on a PCI board. please.
there are 1410s on PCI boards (elan digital systems for example) so why
not a 1510 (they're cheaper). google.

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

(not worth a comment)

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

what the f*** is wrong probing the PCI interrput and then the ISA ones
(when they are probed anyway)? it has no downsides on working setups.
we may produce a pci interrupt anyway when redoing card interrogation
on initialization.

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

check the CC, for more cases search in list archives. (not only the linux lists,
also look in xBSD lists)

> 
> -- 
> Regards,
> Pavel Roskin
> 
> 

-daniel