[parisc-linux] EISA support

[parisc-linux] EISA support

[Matthew Wilcox]

Anyone want to review a patch that makes EISA work?  I've only
tested it on a 715/75 with a Mongoose chip; but Wax is
supposed to be programmatically identical.  The patch is
18k, so rather than post it to the list, it's available from
ftp://puffin.external.hp.com/pub/parisc/src/eisa.diff

Re: [parisc-linux] EISA support

[Michael S.Zick]

On Wednesday 10 October 2001 01:24 am, Matthew Wilcox wrote:
> Anyone want to review a patch that makes EISA work?  
>
>  * I decided that to support old drivers, EISA port numbers should be
>    between 0-0xffff, so I reserved bus number 0 for EISA.  This involved
>    messing with inb/outb in pci.c.
>
Willy,

A comment, for your consideration:

Old ISA boards only do a 10-bit decode and it is a frequent occurance
that old drivers don't "clean up" the unused high 6 bits.

Would it be reasonable to mask port numbers to 10 bits for ISA in the
inb/outb routines?

Mike

Re: [parisc-linux] EISA support

[Alan Modra]

On Wed, Oct 10, 2001 at 03:32:09AM -0500, Michael S. Zick wrote:
> 
> Old ISA boards only do a 10-bit decode and it is a frequent occurance
> that old drivers don't "clean up" the unused high 6 bits.
> 
> Would it be reasonable to mask port numbers to 10 bits for ISA in the
> inb/outb routines?

No.  Some old ISA boards do decode the top bits, and actually use them.

RE: [parisc-linux] EISA support

[Pedot, Wolfgang]

> Anyone want to review a patch that makes EISA work?  I've only
> tested it on a 715/75 with a Mongoose chip; but Wax is
> supposed to be programmatically identical.  The patch is
> 18k, so rather than post it to the list, it's available from
> ftp://puffin.external.hp.com/pub/parisc/src/eisa.diff
>=20
I=B4ve just tested this patch on my 715/75 and it seems the =
EISA-Subsystem works.
Since I don=B4t have an EISA-Card I=B4ve tried an old ISA-Nic (NE2000) =
but the
driver-module has problems detecting the interrupt of the card and i =
have no
idea which one to use.....
I can give the module any irq i want and it says everything is fine but =
of
course no network-traffic possible.....
Is there any chance to bring this card to life?

greetings
Wolfgang

Re: [parisc-linux] EISA support

[Richard Hirst]

On Wed, Oct 10, 2001 at 07:24:41AM +0100, Matthew Wilcox wrote:
> 
> Anyone want to review a patch that makes EISA work?  I've only

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

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.

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.

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.

I had to hack the scsi driver a bit to change the parity generation/
checking options, otherwise the chip just sat there saying its external
abort signal was true.  The chip supports the idea of passing parity
through from scsi bus to host bus, but I've no idea what features
might be implemented on my HP cards.  I tried a Compaq card as well,
which behaved the same except (a) I didn't need to do the parity hack,
and (b) it wasn't reported in the devices list on kernel boot.  With
an HP card in, it is listed as 'unknown device at 0xfc001000'.

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

Richard


              (c) Copyright Hewlett-Packard Company, 1991, 1992, 1993           
Portions of this code are (c) Copyright Samsung Electronics Co., Ltd, 91, 92    
                                                                                
ROM: 9000/715/75                                                                
                                                                                
PDC ROM rev. 1.1                                                                
IODC ROM rev. 1.0                                                               
96 MB of memory have been configured.                                           
                                                                                
Warning: one or more EISA cards could not be configured.                        
Autoselect and search will ignore unconfigured cards.                           
                                                                                
                                                                                
Searching for Potential Boot Devices.                                           
To terminate search, press and hold the ESCAPE key.                             
                                                                                
Device Selection      Device Path              Device Type                      
----------------------------------------------------------------------------    
                                                                                
P0                    scsi.6.0                 MICROP  2112                     
P1                    scsi.5.0                 SEAGATE ST32430N                 
P2                    scsi.3.0                 HP      HP35470A                 
P3                    lan.0002b3-218a14.0.0    moose                            
                                                                                
                                                                                
                                                                                
b)    Boot from specified device                                                
s)    Search for bootable devices                                               
a)    Enter Boot Administration mode                                            
x)    Exit and continue boot sequence                                           
?)    Help                                                                      
                                                                                
Select from menu: b p3                                                          
                                                                                
Trying lan.0002b3-218a14.0.0                                                    
Boot path initialized.                                                          
Attempting to load IPL.                                                         
                                                                                
                                                                                
Hard booted.                                                                    
palo ipl 0.94 richard@beast Wed Oct 10 12:18:57 BST 2001                        
0/vmlinux32 3120379 bytes @ 0x7800                                              
                                                                                
Command line: 'HOME=/ TERM=linux root=/dev/sda1  console=ttyS0'                 
                                                                                
Kernel: partition 0 file /vmlinux                                               
Warning: kernel name doesn't end with 32 or 64... Guessing 32                   
ELF32 executable                                                                
Entry 00100000 first 00100000 n 6                                               
Segment 0 load 00100000 size 1611616 mediaptr 0x1000                            
Segment 1 load 0028a000 size 287736 mediaptr 0x18b000                           
Segment 2 load 002d4000 size 377904 mediaptr 0x1d2000                           
Segment 3 load 00334000 size 8192 mediaptr 0x22f000                             
Segment 4 load 00338000 size 32768 mediaptr 0x231000                            
Segment 5 load 00376770 size 82896 mediaptr 0x239770                            
branching to kernel entry point 0x00100000                                      
Linux version 2.4.9-pa45 (richard@beast) (gcc version 3.0.2 20010829 (prerelease
)) #16 Wed Oct 10 14:13:11 BST 2001                                             
FP[0] enabled: Rev 1 Model 9                                                    
The 32-bit Kernel has started...                                                
Determining PDC firmware type: Snake.                                           
model   00003160 00000481 00000000 00000000 782de278 ffffffff 00000004 0000000a 
0000000a                                                                        
vers    00000013                                                                
CPUID   vers 0 rev 0                                                            
model   9000/715                                                                
Total Memory: 96 Mb                                                             
pagetable_init                                                                  
On node 0 totalpages: 24576                                                     
zone(0): 24576 pages.                                                           
zone(1): 0 pages.                                                               
zone(2): 0 pages.                                                               
Kernel command line: HOME=/ TERM=linux root=/dev/sda1  console=ttyS0            
Error reading tod clock                                                         
Console: colour dummy device 160x64                                             
Calibrating delay loop... 74.75 BogoMIPS                                        
Memory: 93980k available                                                        
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)                 
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)                    
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)                    
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)                   
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)                   
Searching for devices...                                                        
Found devices:                                                                  
1. Stinger Optional Graphics (10) at 0xf4000000, versions 0x6, 0x0, 0x77        
2. Scorpio Sr. Core BA (11) at 0xf082f000, versions 0x19, 0x0, 0x70             
3. Scorpio Sr. Core SCSI (10) at 0xf0825000, versions 0x19, 0x0, 0x71           
4. Scorpio Sr. Core LAN (802.3) (10) at 0xf0826000, versions 0x19, 0x0, 0x72    
5. Scorpio Sr. Core HIL (10) at 0xf0821000, versions 0x19, 0x0, 0x73            
6. Scorpio Sr. Core RS-232 (10) at 0xf0823000, versions 0x19, 0x0, 0x75         
7. Scorpio Sr. Core RS-232 (10) at 0xf0822000, versions 0x19, 0x0, 0x75         
8. Scorpio Sr. Core Centronics (10) at 0xf0824000, versions 0x19, 0x0, 0x74     
9. Scorpio Sr. Audio (10) at 0xf1000000, versions 0x19, 0x0, 0x7b               
10. Scorpio Sr. EISA BA (11) at 0xfc000000, versions 0x19, 0x0, 0x76            
11. unknown device (10) at 0xfc001000, versions 0x0, 0x0, 0xfff                 
12. Scorpio Sr.(715/75) (0) at 0xfffbe000, versions 0x316, 0x0, 0x4             
13. Scorpio Sr. (1) at 0xfffbf000, versions 0x27, 0x0, 0x9                      
That's a total of 13 devices.                                                   
CPU(s): 1 x PA7100 (PCX-T) at 75.000000 MHz                                     
Mongoose EISA Adapter found at 0xfc000000                                       
Asp version 1 at 0xf0800000 found.                                              
LED (ASP-style) display at f0800020 registered                                  
POSIX conformance testing by UNIFIX                                             
Linux NET4.0 for Linux 2.4                                                      
Based upon Swansea University Computer Society NET3.039                         
Starting kswapd v1.8                                                            
parport_init_chip: enhanced parport-modes not supported.                        
parport0: PC-style at 0xf0824800, irq 88 [PCSPP]                                
STI byte mode ROM at f4000000, hpa=f4000000                                     
STI byte mode ROM, id 27f12392-40a00499, conforms to spec rev. 8.02             
STI device: HPA1991AC19                                                         
pty: 256 Unix98 ptys configured                                                 
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI en
abled                                                                           
ttyS00 at iomem 0xf0823800 (irq = 90) is a 16550A                               
ttyS01 at iomem 0xf0822800 (irq = 89) is a 16550A                               
Found HIL at 0xf0821000, IRQ 94                                                 
HIL: no keyboard present.                                                       
Warning : device (10, 0x19, 0x0, 0x73) NOT claimed by HIL                       
lp0: using parport0 (interrupt-driven).                                         
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)            
block: 128 slots per queue, batch=16                                            
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize           
loop: loaded (max 8 devices)                                                    
Found i82596 at 0xf0826000, IRQ 87                                              
82596.c: MAC of HP700 LAN read from EEPROM                                      
eth0: Couldn't get consistent shared memory                                     
eth0: 82596 at 0xf0826000, 08 00 09 87 E4 8F IRQ 87.                            
82596.c $Revision: 1.23 $                                                       
SCSI subsystem driver Revision: 1.00                                            

Re: [parisc-linux] EISA support

[Michael S.Zick]

On Wednesday 10 October 2001 06:01 am, Alan Modra wrote:
> >
> > Would it be reasonable to mask port numbers to 10 bits for ISA in the
> > inb/outb routines?
>
> No.  Some old ISA boards do decode the top bits, and actually use them.

Alan,

Correct - 
16-bit ISA cards NEARLY ALWAYS decode the top bits; but 8-bit
cards don't (can't, the wires aren't on that part of the socket).

My comment was based on the i386 branch, which does have such a
config option for the (very) rare installation that needs to support such
a board.

I was only wondering if this would be a REASONABLE place in the 
code to put it.

Mike

Re: [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.

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Wed, Oct 10, 2001 at 03:32:09AM -0500, Michael S . Zick wrote:
> Old ISA boards only do a 10-bit decode and it is a frequent occurance
> that old drivers don't "clean up" the unused high 6 bits.
> 
> Would it be reasonable to mask port numbers to 10 bits for ISA in the
> inb/outb routines?

Actually, I currently do this, but I'm not sure I should be.  The EISA
adapter has to do different things for ISA port IO and EISA port IO.
I'm not sure which IO ports correspond the ISA and which to EISA.
Guessing based on the hp100 driver, I decided that ports less than 0x400
were ISA and the rest were EISA.  Anyone want to explain port numbers
to me properly?  The description in the Mongoose ERS assumes you know
a fair bit about EISA, and I don't.

Here's the current code for this:

+static inline unsigned long eisa_permute(u16 port)
+{
+       if (port >= 0x400) {
+               return 0xfc000000 | port;
+       } else {
+               return 0xfc000000 | ((port & 0x3f8) << 9) | (port & 7);
+       }
+}

The ERS adds in (port & 0xfc00) >> 6, but the test ensures those bits
are clear, so there's no point.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Wed, Oct 10, 2001 at 03:48:10PM +0100, Matthew Wilcox wrote:
> I'm not sure which IO ports correspond the ISA and which to EISA.
> Guessing based on the hp100 driver, I decided that ports less than 0x400
> were ISA and the rest were EISA.  Anyone want to explain port numbers
> to me properly?  The description in the Mongoose ERS assumes you know
> a fair bit about EISA, and I don't.

Ah, I found an appendix :-)

EISA cards have a slot number which determines the upper nybble of their
IO port numbers.  Then within that 0xfff of space, they use 0-ff, 400-4ff,
800-8ff, c00-cff.  The rest are ISA ports (or aliases of ISA ports).

So here's the function to use:

static inline unsigned long eisa_permute(u16 port)
{
	if (port & 0x0300) {
		return 0xfc000000 | ((port & 0xfc00) >> 6) | ((port & 0x3f8) << 9) | (port & 7);
	} else {
		return 0xfc000000 | port;
	}
}

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Michael S.Zick]

On Wednesday 10 October 2001 10:38 am, Matthew Wilcox wrote:
>
> Ah, I found an appendix :-)
>
> EISA cards have a slot number which determines the upper nybble of their
> IO port numbers.  Then within that 0xfff of space, they use 0-ff, 400-4ff,
> 800-8ff, c00-cff.  The rest are ISA ports (or aliases of ISA ports).
>
Willy,
Sounds like you have it handled already - that 400-4ff range (plus 000-3ff) 
is the very old, 8-bit, ISA i/o port range (on i386 cards).
I think you just saved my very old PROM burner from the scrap heap.

On a separate subject related to your EISA work...
For 8/16-bit ISA cards that do not report resource requirements (i/o,
mem, dma, irq) and for the EISA cards without a "known" ID - perhaps
let the driver accept command line option(s) and leave the details to
the user.  For the IRQ mappings, perhaps something like: xyz_irq=8:zz,
xyz_dma=4:yy, etc. (without the ":ww" just map somewhere handy.)

Mike

Re: [parisc-linux] EISA support

[Grant Grundler]

> Instead of generating a PCI/EISA interrupt, generate a write of an
> allocated value to the CPU's EIRR (External Interrupt register).

Correct. That's what txn_alloc_irq() is for.
That interface needs to change slightly if someone really wants to start
using it on a broad range of platforms and busses. FWIW, this could
work on any platform which a "local SAPIC" (ie IA64).

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

excalty - this also cuts out a bunch of IO space reads (and possibly writes).

> 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 :-)

I think all the needed functions are in place already.

grant

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Wed, Oct 10, 2001 at 03:28:07PM +0100, Matthew Wilcox wrote:
> 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.

Turns out it's unsufferably ugly to do this right now, due to Mongoose
being a _sibling_ of Asp, not a _child_.  So I've put a nasty patch at
ftp://puffin.external.hp.com/pub/parisc/src/eisa-irq.c which works enough
that it seems to claim the IRQs; but the hp100 driver just allocates
IRQ3 and doesn't allow any kind of fixup, so I haven't actually tested it.

I have a plan to allocate Mongoose's IRQ in a nicer way, but that will
have to wait until tomorrow.  What do you think the best way would be
to fix EISA card IRQs?  I have a couple of thoughts:

 * Introduce a new EISA_IRQ_BASE macro that most architectures
   define to 0.
 * Reserve IRQ region 0 for EISA

Any better ideas?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Grant Grundler]

Matthew Wilcox wrote:
> I have a plan to allocate Mongoose's IRQ in a nicer way, but that will
> have to wait until tomorrow.  What do you think the best way would be
> to fix EISA card IRQs?  I have a couple of thoughts:
> 
>  * Introduce a new EISA_IRQ_BASE macro that most architectures
>    define to 0.

I don't know what other archs do or how hard that would be to drive
into the other arches.

>  * Reserve IRQ region 0 for EISA

reserve IRQ region 0 for EISA.
It's reserved now to catch broken PCI drivers that treat the IRQ number
as a byte instead of an int. So for machines w/o EISA, it could
continue to remain reserved for that purpose.

grant

Re: [parisc-linux] EISA support

[Richard Hirst]

On Wed, Oct 10, 2001 at 03:28:07PM +0100, Matthew Wilcox wrote:
> 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.

If we make the scsi script do that, the scsi chip wont realise it
has generated an interrupt, so wont stop processing scripts.  The
driver expects th chip to be halted when the int handler is called.
If we had a driver specific to the 53c710 where the scsi script managed
queues of requests itself, there might be scope for emulating an
INTFLY instruction (which is found on newer chips) that way.  The
53c700 doesn't have the capability of writing memory locations from
script.

Richard

Re: [parisc-linux] EISA support

[Richard Hirst]

On Thu, Oct 11, 2001 at 02:40:10AM +0100, Matthew Wilcox wrote:
> Turns out it's unsufferably ugly to do this right now, due to Mongoose
> being a _sibling_ of Asp, not a _child_.  So I've put a nasty patch at
> ftp://puffin.external.hp.com/pub/parisc/src/eisa-irq.c which works enough
> that it seems to claim the IRQs; but the hp100 driver just allocates
> IRQ3 and doesn't allow any kind of fixup, so I haven't actually tested it.


asp_find_irq() wants changing:

-               case 0x76:      irq = 21; break; /* Centronics */
+               case 0x76:      irq = 17; break; /* EISA BA */

and needs a default case to avoid returning random irq values.

and you probably want something like this in eisa_probe():

        eisa_dev.region->action = kmalloc(sizeof(struct irqaction) * 32, GFP_ATOMIC);
        memset(eisa_dev.region->action, 0, sizeof(struct irqaction) * 32);

I'm sure '32' is wrong, but at least you need some range checking on
irq in eisa_irq() before using it to index in to the action array.

Now I get one EISA irq immediately that request_irq(irq, eisa_irq, 0, name, NULL)
is called, at which point the above allocation hasn't yet happened ==> bang.
Incidently, eisa_irq() reports "EISA irq 167" for that event so using irq
as a simple index into action[] is probably wrong.

I don't get any further eisa_irq() calls once my scsi card gerneates an
interrupt, but for all I know I may have to poke some registers in the
card before it allows interrupts out.

Richard

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Thu, Oct 11, 2001 at 12:23:51PM +0100, Richard Hirst wrote:
> asp_find_irq() wants changing:
> 
> -               case 0x76:      irq = 21; break; /* Centronics */
> +               case 0x76:      irq = 17; break; /* EISA BA */

Umm.  According to the Coral/Cobra (720/730/750) ERS I have here, irq 17
on Asp is error.  The Hardball ERS claims the same for the Cutoff ASIC
(someone's written in pencil `Asp 2' by it).  The comment is bogus;
I'll fix that.

> and needs a default case to avoid returning random irq values.

Yep, fixed in my tree.

> and you probably want something like this in eisa_probe():
> 
>         eisa_dev.region->action = kmalloc(sizeof(struct irqaction) * 32, GFP_ATOMIC);
>         memset(eisa_dev.region->action, 0, sizeof(struct irqaction) * 32);
> 
> I'm sure '32' is wrong, but at least you need some range checking on
> irq in eisa_irq() before using it to index in to the action array.

Probably something along those lines.  Apparently I should mask the byte
returned as well, but the docs say to see the Intel 82357 ISP data sheet
for details.  Grumble.

> I don't get any further eisa_irq() calls once my scsi card gerneates an
> interrupt, but for all I know I may have to poke some registers in the
> card before it allows interrupts out.

Looks like we're getting one error, and not resetting the bus.  Wonder why
we're getting an error...

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Matthew Wilcox]

OK, just committed 2.4.9-pa49 which makes my hp100 EISA card work:

64 bytes from 15.1.50.0: icmp_seq=1 ttl=255 time=0.5 ms

Haven't made any effort to support busmastering cards yet, but having
ioports, iomem & interrupts working should allow most cards to function.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Richard Hirst]

On Fri, Oct 12, 2001 at 07:44:49AM +0100, Matthew Wilcox wrote:
> 
> OK, just committed 2.4.9-pa49 which makes my hp100 EISA card work:
> 
> 64 bytes from 15.1.50.0: icmp_seq=1 ttl=255 time=0.5 ms
> 
> Haven't made any effort to support busmastering cards yet, but having
> ioports, iomem & interrupts working should allow most cards to function.

Still can't get any interrupts out of my EISA scsi card in 715/75.

Richard

Re: [parisc-linux] EISA support

[Richard Hirst]

On Fri, Oct 12, 2001 at 09:47:19AM +0100, Richard Hirst wrote:
> On Fri, Oct 12, 2001 at 07:44:49AM +0100, Matthew Wilcox wrote:
> > 
> > OK, just committed 2.4.9-pa49 which makes my hp100 EISA card work:
> > 
> > 64 bytes from 15.1.50.0: icmp_seq=1 ttl=255 time=0.5 ms
> > 
> > Haven't made any effort to support busmastering cards yet, but having
> > ioports, iomem & interrupts working should allow most cards to function.
> 
> Still can't get any interrupts out of my EISA scsi card in 715/75.

I tried adding a handler for irq 81 (64 + 17), as you said that was
asp error, at the end of asp_init_chip().

        request_irq(81, asp_error, 0, "asp error", asp);

That handler gets called as soon as it is registered.  Is it likely that
EISA interrupts are blocked until that error is cleared down somehow?

Richard

Re: [parisc-linux] EISA support

[Tom]

On Wed, 10 Oct 2001, Matthew Wilcox wrote:
> Anyone want to review a patch that makes EISA work?  I've only
> tested it on a 715/75 with a Mongoose chip; but Wax is
> supposed to be programmatically identical.  The patch is
> 18k, so rather than post it to the list, it's available from
> ftp://puffin.external.hp.com/pub/parisc/src/eisa.diff

I've updated my 715/100 to -pa57, which gives me startup messages that the
Mirage Was EISA BA is recognized. I plugged in a 3Com 3c597 NIC as a test
card; what I get from the PDC is that an unconfigured EISA card is in and
it'll ignore it, then on boot the NIC is seen as eth0. Unfortunately, when
DHCP tries to pull an address, I get errors that command 0x5800 and 0x2804
didn't complete (twice as a pair), plus a 0x3002 didn't complete when the
DHCP request is sent. Never does pull an IP, but does show as up and
active on eth0. Tonight I'm going to try plugging a static IP into it and
see what happens...

If someone working this wants some dmesg output or anything feel free to
holler...

Re: [parisc-linux] EISA support

[Jochen Friedrich]

Hi Tom,

> I've updated my 715/100 to -pa57, which gives me startup messages that the
> Mirage Was EISA BA is recognized.

Similar for 720. Here i got the message:

Mongoose EISA Adapter found at 0xfc000000

An IBM Auto 16/4 Token Ring card is recognized, but doesn't work (instead, 
i randomly get a stack dump during the module load).

Another comment:

parisc_ksyms.c is missing the exports for memcpy_toio and memcpy_fromio.

Cheers,
Jochen

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Tue, Oct 16, 2001 at 09:46:01PM +0200, Jochen Friedrich wrote:
> An IBM Auto 16/4 Token Ring card is recognized, but doesn't work (instead, 
> i randomly get a stack dump during the module load).

Hmm.. could you try with the driver built in?  People have been reporting
that modules aren't working any more.

> parisc_ksyms.c is missing the exports for memcpy_toio and memcpy_fromio.

OK, that's easily fixed.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Jochen Friedrich]

Hi Matthew,

> Hmm.. could you try with the driver built in?  People have been reporting
> that modules aren't working any more.

Looks a bit better now:

ibmtr.c: v1.3.57   8/ 7/94 Peter De Schrijver and Mark Swanson
v2.1.125 10/20/98 Paul Norton    <pnorton@ieee.org>
v2.2.0   12/30/98 Joel Sloan     <jjs@c-me.com>
v2.2.1   02/08/00 Mike Sullivan  <sullivam@us.ibm.com>
v2.2.2   07/27/00 Burt Silverman <burts@us.ibm.com>
v2.4.0   03/01/01 Mike Sullivan <sullivan@us.ibm.com>
tr0: ISA P&P Auto 16/4 Adapter found
tr0: using irq 9, PIOaddr a20, 16K shared RAM.
tr0: Hardware address : 00:04:AC:35:AE:E7
tr0: Shared RAM paging enabled. Page size: 16K Shared Ram size 63K
tr0: Maximum Receive Internet Protocol MTU 16Mbps: 16344, 4Mbps: 6104
tr1: Could not grab PIO range. Halting driver.
tr2: Could not grab PIO range. Halting driver.
tr3: Could not grab PIO range. Halting driver.
tr4: Could not grab PIO range. Halting driver.
tr5: Could not grab PIO range. Halting driver.
tr6: Could not grab PIO range. Halting driver.
tr7: Could not grab PIO range. Halting driver.

It recognizes the adapter correctly, but then the driver seems to find 
some "shadow devices" which it tries to configure and, of course, fails to 
do so...

However, the device still doesn't work:

hp720:~# ifconfig tr0 1.1.1.1
SIOCSIFFLAGS: Resource temporarily unavailable

This *might* have to do with interrupts, though...

Cheers,
Jochen

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Wed, Oct 17, 2001 at 12:26:22AM +0200, Jochen Friedrich wrote:
> tr0: ISA P&P Auto 16/4 Adapter found
> tr0: using irq 9, PIOaddr a20, 16K shared RAM.
> tr0: Hardware address : 00:04:AC:35:AE:E7
> tr0: Shared RAM paging enabled. Page size: 16K Shared Ram size 63K
> tr0: Maximum Receive Internet Protocol MTU 16Mbps: 16344, 4Mbps: 6104

That's cool.

> This *might* have to do with interrupts, though...

Maybe.  I'm not sure that interrupts 8-15 work; may need to program the
intel chipset to do it properly.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] EISA support

[Tom]

On Wed, 10 Oct 2001, Matthew Wilcox wrote:
> Anyone want to review a patch that makes EISA work?  I've only
[snip]
> I seem to have chosen a not-quite-supported EISA card to test with.
> The ID is plausible, so I don't think it's a byteswapping issue or
> anything.

Okay - I just brought things up with -pa61 and get the same errors about
commands not finishing when DHCP tries to use the 3c597 EISA NIC. However,
I scrounged up a static IP, plugged it in, and brought it online. It
*appears* to take the IP and work fine, but I get console errors that
various hexadecimal commands aren't finishing, then a comment that
"perhaps IRQ3 isn't available?" I also can't find a config program to try
resetting the card's IO etc. info - 3c5x9config from stable doesn't appear
to like the HP and I don't have an EISA-based PC to use the DOS utils
on...

Anyone have any ideas? Or, perhaps I can use the DOS utils (if I find an
EISA PC) and set the card to something that -pa61 detects, so they match?

Re: [parisc-linux] EISA support

[Matthew Wilcox]

On Thu, Oct 18, 2001 at 06:31:18AM -0800, Tom wrote:
> Okay - I just brought things up with -pa61 and get the same errors about
> commands not finishing when DHCP tries to use the 3c597 EISA NIC. However,
> I scrounged up a static IP, plugged it in, and brought it online. It
> *appears* to take the IP and work fine, but I get console errors that
> various hexadecimal commands aren't finishing, then a comment that
> "perhaps IRQ3 isn't available?" I also can't find a config program to try
> resetting the card's IO etc. info - 3c5x9config from stable doesn't appear
> to like the HP and I don't have an EISA-based PC to use the DOS utils
> on...

3c597 isn't going to work until someone (probably me...) gets EISA DMA
working.  That depends on getting consensus for how to implement the pci_*
host DMA mapping support (which I think we have now).  Implementing it
is going to depend on some changes such as the iotree.  rbrad & I have
been working on that, and I think we're close to getting finished.

-- 
Revolutions do not require corporate support.