[PATCH] yenta: irq-routing for TI bridges...again
proski at gnu.org
Sun Mar 14 16:35:52 GMT 2004
On Sat, 13 Mar 2004, 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.
I didn't realize that. I'll keep it in mind. We need some code to deal
with "superdevices", e.g. a static list of them with refcounts or
separating devices into masters and slaves, ensuring that only masters
can deal with the "superdevice" registers. I'll take the master/slave
approach for now because it's simpler.
> > > 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.
OK, I like this approach.
> > > 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.
Fine. Now let's define the scope of the changes.
If PCI interrupts are not working in the master unit, try to make them
work. We need it at least for CSC. Try serial and parallel PCI
Adjustments are only made if the PCI interrupts are not working, and only
to relevant bits.
ISA interrupts are irrelevant to the patch, don't try to fix them. We are
already probing for them.
Slave devices may make some adjustments that don't affect the masters.
I'll try to make a patch that implements that.
More information about the linux-pcmcia