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

Daniel Ritz daniel.ritz at gmx.ch
Sun Mar 14 23:58:35 GMT 2004


On Saturday 13 March 2004 10:46, Russell King wrote:
> On Sat, Mar 13, 2004 at 01:13:59AM +0100, Daniel Ritz wrote:
> > On Friday 12 March 2004 21:32, Pavel Roskin wrote:
> > > I'm a bit concerned that the driver is "trying to fix" something the
> > > second time when PCI interrupts should be working already.  See below.
> > 
> > doesn't look so good. fixed. the fallback-to-pci code needs to be outside
> > of the serial stuff (anyway, to handle the setting for parallel non working
> > ISA interrupts right). 
> 
> Indeed - some of these registers (MFUNC for instance) are shared between
> function 0 and function 1 in dual-socket bridges.  If we've setup and
> registered stuff for function 0, we shouldn't really be tweaking it
> while probing function 1.

yes, i know. the only thing that func1 should care about is INTB and INTRTIE
since only func1 can probe what's right.

> 
> > > And now we come to the need to define the scope of the problems we want to
> > > address.
> > > 
> > > 1) Do we want to deal with mfunc being random at startup or we only want
> > > to deal with 0 and/or certain specific values?  Can we just ignore the
> > > original value if we determine that it's incorrect?
> > 
> > don't trust it, trust the probe.
> 
> I'd suggest "trust it unless proven by probe that it is wrong" is the
> correct approach - you'll never be able to probe the correct MFUNC 
> value of 0xfba97543 in my laptop for instance.
> 

of course. that's what i meant. it's what my patch does.

> > > 3) Do we want to try to enable ISA interrupts if PCI interrupts are
> > > working and ISA interrupts are not?
> > 
> > don't know...why not?
> 
> I suspect probing them may be hazardous - sure it can be tried, but I
> think it should be treated as a separate problem to the present one.
> I think it'll need a lot more testing on more hardware.
> 

ok, so my current patch has the ISA part disabled. if ISA is not working
fall back to PCI directly...

my current patch:
 http://ritz.dnsalias.org/linux/pcmcia-ti-routing-7.patch

changes since the last one:
- don't play games with ISA interrupts
- make sure GPIO3 is INTA for chips where it matters
- different probe functions for func 0 and func 1 of the device:
  func0:  probe the right setting in devctl/mfunc (all-serial, parallel) for PCI INTA
  func1: probe PCI interrupt, route INTB or set INTRTIE. we need to do it here
  'cos we can only probe it here.

this one is compile tested only!

rgds
-daniel




More information about the linux-pcmcia mailing list