From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from beavis.ybsoft.com (bradetich.net [209.161.7.161]) by dsl2.external.hp.com (Postfix) with ESMTP id 9591C4829 for ; Mon, 16 Sep 2002 20:25:03 -0600 (MDT) From: Ryan Bradetich To: Christoph Plattner Cc: "parisc-linux@lists.parisc-linux.org" In-Reply-To: <3D8516EF.7A7D8206@gmx.at> References: <3D8516EF.7A7D8206@gmx.at> Content-Type: text/plain Date: 16 Sep 2002 20:25:01 -0600 Message-Id: <1032229501.930.45.camel@beavis> Mime-Version: 1.0 Subject: [parisc-linux] Re: Status SPIFI SCSI Sender: parisc-linux-admin@lists.parisc-linux.org Errors-To: parisc-linux-admin@lists.parisc-linux.org List-Help: List-Post: List-Subscribe: , List-Id: parisc-linux developers list List-Unsubscribe: , List-Archive: 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 >