Re: [parisc-linux] Re: Status SPIFI SCSI

[Christoph Plattner <christoph.plattner@gmx.at>]

Hello Ryan,

I think usinf the logic analyser will not help you on the
SCSI bus. You need the logic analyser on the SPIFI chip!!!

As I already mentioned in another mail, I think, we
DO NOT access the real device. As I have mentioned, 
we only read out 0x0000ff00 at each address and we
"write" the SCSI command in an invalid space ! So this
is "OK", that the chip do not produce any interrupts !

I think, this is a very basic problem of the bus or
i/o bus initilization or the Loquix init, or whatever.

I do not expect any frame on the SCSI output !

Bye
Christoph


Ryan Bradetich wrote:
> 
> Hello Christoph,
> 
> On Sun, 2002-09-15 at 17:25, Christoph Plattner wrote:
> > 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.
> 
> This is where I am also currently stuck :(  The
> ESIEE guys are going to hook up an analyzer to the
> box and see if the target device is getting the command
> (ie... did we send the command correctly to the device)
> or if the device returns a command (do we catch the
> command the device is returning).  I have been studyting
> the setup routines in the HP-UX driver and I believe
> I have the chip initialized properly ... but I am not
> sure why I am not getting any interrupts.   Hopefully
> between ESIEE, you, and myself and anyone else
> interested we can figure this out.
> 
> > 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.
> 
> That is highly possible.  The driver skeleton is just
> a test harness for me right now.  I am just trying to see
> what I can get returned from the spifi chip (that is why
> most of the functions are stubs with printk.  Once I see
> an interrupt come in, I'll start working on putting that piece
> togeather.
> 
> > 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);
> 
> Yes, this is part of the initizlization from the HP-UX
> driver.  The Loquix chip sits between the HP-PB bus, and
> the spifi scsi chip.  According to the HP-UX driver, the
> Loquix chip also required some setup.  Once again, I
> do not actually have the Loquix documentation, but I might
> have a lead on it.  Will have to wait and see if that lead
> pans out.
> 
> > 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.
> 
> I am not sure about all the HP devices.  It might be an iodc
> specific call.  I will have to look at the driver again,
> but that might reset the loquix chip *shrug* I'll take
> a look and see what I can find.
> 
> > 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 !
> 
> That is where I am also. We actually read the type SPIFI-3 (SE) for the
> SKUNK card, and SPIFI-3 (DF) for the wizard (16-bit) card.  I have
> tested this on both cards so I know it works.  I am convinced we are
> reading the correct information from the card, but what I am not
> convinced of is that we have it setup properly yet :)  The problem is I
> do not know what I am missing yet :(
> 
> > 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 ... !
> >
> 
> I do not think the fact the interrupt is registered is very infomative,
> I think you can register an interrupt for device even if it doesn't have
> an real irq assocaitated with it (ie... the serial mux).
> 
> Yeah, thanks for looking at it ... we will have to beat on it some more
> and see what we can find.  Hopefully the ESIEE guys will be able to
> provide us with some good information!
> 
> Thanks
> 
> - Ryan
> 
> > Till soon,
> > Christoph P.
> >
> >
> >
> >
> >
> > --
> > -------------------------------------------------------
> > private:      christoph.plattner@gmx.at
> > company:      christoph.plattner@alcatel.at
> >
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

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