[parisc-linux] EISA support

[Matthew Wilcox]

On Wed, Oct 10, 2001 at 01:45:26PM +0100, Richard Hirst wrote:
> Looks reasonable to me, but doesn't make any difference so far as
> EISA 53c710 cards in my 715/75 are concerned.  There seem to be two
> basic problems...

OK.  I'll commit this basic support then since it works better than
the current support.

> Interrupts - I can see from the 53c710 registers that it is generating
> an interrupt, but it doesn't seem to be enabled through to the processor.
> I didn't know which irq to request, so I guessed it might be one of the
> ASP ones (which I think cover 64 to 95), and did a request_irq for all
> 32 of them.  Didn't help.

I haven't written that code yet.  Basically, I need to allocate a new IRQ
region for EISA interrupts, then on receipt of Asp irq 21 read the EISA
interrupt number from 0xfc01f000.  It seems there may be some extra gunk
needed to handle the TI chipset, but I'll have a go at getting interrupts
to work later today.

Alternatively, we could hack the 53c710 script to generate CPU interrupts
directly :-)  Let me just document how that would work (Grant, please
correct me if I misunderstood):

Instead of generating a PCI/EISA interrupt, generate a write of an
allocated value to the CPU's EIRR (External Interrupt register).
This way, the CPU jumps straight to the scsi chip's interrupt handler
rather than Asp's, which then has to decode which Asp IRQ it was;
then jump to the EISA interrupt handler, decode which EISA IRQ it was,
finally calling the scsi interrupt handler.

We might need to work out some other infrastructure to handle this,
but it's something we should look into at some point.  Clearly I need
to get EISA interrupts working anyway :-)

> Bus mastering - the 53c710 is attempting to fetch and execute scripts
> from memory, but from what I can tell, it is picking up invalid data.
> Basically the chips script pointer has moved on one instruction and it
> is trying to generate an Illegal Instruction Detected interrupt, and
> the dsps register, which I think is used in script fetching, contains
> 0xffffffff.

OK, I haven't figured out how to do this yet.  In order for a device on
the EISA bus to access host ram, I have to program the IO Map in the
adapter.  I'm not sure Linux has an interface I can slot into for this.
Maybe the pci_alloc interface is the right one...

> atm I am using eisa_in32() to check the card signature, but then
> using readb and friends on (EISA_BASE + port) to access the card.
> The driver only supports memory mapped chip access on parisc, and
> as it is using memory mapped access for the on-board 53c700, it
> makes sense to do that for EISA cards as well.  I identify the
> card from a 32 bit signature at base+0xc80, which is apparently
> correct on Compaq cards, at least - dunno if that is standard.
> I'm pretty confident that I am accessing the chips registers ok.

>From the hp100 driver, and some of the other bits I've read, you should
probably be probing for the card along thse lines:

	for (ioaddr = 0x1c38; ioaddr < 0x10000; ioaddr += 0x400) {
		if (check_region(ioaddr, REGION_SIZE))
			continue;
		if (inw(ioaddr) == SIGNATURE)
			return 0;
	}

To access the card in memory mapped mode, just ioremap it and use
readb/writeb as usual.  This ought to work; I've written the code for
it :-).  I'm not sure how you discover the base address with EISA though
-- is there a register which holds this on the 53c7x0?

> Although the new code reports the EISA adaptor as Mongoose, that
> address has already been reported as "Scorpio Sr. EISA BA".

Right... just like Mirage Core BA gets reported as Lasi.  The Asp
driver, for some reason, trims 0xf082f000 down to 0xf0800000.

> 2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70
> 10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76

> Mongoose EISA Adapter found at 0xfc000000
> Asp version 1 at 0xf0800000 found.

-- 
Revolutions do not require corporate support.