[parisc-linux] Status SPIFI SCSI

[Christoph Plattner]

Hallo Ryan,

here some comments on my non-successful work so far.

I did code reading and used debug instrumented code
to understand the structure behind the linux SCSI
handling.

Further I studied the NetBSD code. 

One major point: We do not get any interrupts.
For my analysis I only had a look on the first
steps of SCSI initialization, so this was the
INQUERY command.

The spifi command routine is called correctly,
but it has a wrong logical implementation. As I 
have seen on other (older) linux driver, the
xxx_command() has to block, after the command was
successful completed by interrupt. But the interrupt
never comes !! Even a "long" delay for simulating
blocking does not solve this problem.

>From base of the NetBSD code, I cannot follow your
code resetting the spifi subsystem. I think you have
this from HP-UX code. Especially the 

  __raw_writel(CMD_RESET, dev->hpa + IO_MODULE_COMMAND);

Is this a reset method via the IO PDC address space
common for all HP devices ? In the NetBSD the full
reset is done only via the `auxctrl' register, which
you use for releasing the reset state.

So we have a principal problem here, not having correct
access to the spifi subsystem. Except: the SCSI-ID is
read out correctly, I think, as ...

SCSI subsystem driver Revision: 1.00
DEBUG: 0xfff74c00
Device: Sahp Baat Kiuh SCSI
scsi0 : SPIFI SCSI: scsi_id: 7 IRQ: 34 type: SPIFI-3 (SE) parity
checking: enabled

... is reported !

Is everything around the interrupt subsystem setup correctly ?
The `cat /proc/interrupts' tells ...

bash# cat /proc/interrupts 
          CPU396195552 
 32:     124925      PARISC-CPU  timer
 33:      19767      PARISC-CPU  lasi
 34:          0      PARISC-CPU  spifi
 87:      19767            Lasi  i82596

... which is no surprise ... !

Till soon,
Christoph P.





-- 
-------------------------------------------------------
private:	christoph.plattner@gmx.at
company:	christoph.plattner@alcatel.at