Support for LSI 53C1010R

Support for LSI 53C1010R

[Phil Thompson]

I'm having problems with the Linux sym53c8xx_2 (sym-2.1.17a) driver on an
embedded system with an LSI 53C1010R. Are there any issues with the driver
and that revision of the chip - specifically the R suffix?

The driver tries to do some things with the chip which (according to the
datasheet) aren't supported. For example, the first problem is that it fails
to determine the PCI clock frequency - it times out in sym_hipd.c:getfreq()
waiting for the GEN flag (almost as if there is no SCSI clock). Just prior
to this (in sym_getpciclock()) it tries to set the SCLK bit of STEST1 in
order to use the PCI clock as the SCSI clock - but that bit is reserved
according to the datasheet.

The same hardware seems to work with a much simpler, internally written,
driver.

Any insights very welcome.

Thanks,
Phil

Re: Support for LSI 53C1010R

[Matthew Wilcox]

On Tue, Apr 13, 2004 at 02:21:13PM +0100, Phil Thompson wrote:
> I'm having problems with the Linux sym53c8xx_2 (sym-2.1.17a) driver on an
> embedded system with an LSI 53C1010R. Are there any issues with the driver
> and that revision of the chip - specifically the R suffix?

I don't have a 1010R myself, only the data sheet.

> The driver tries to do some things with the chip which (according to the
> datasheet) aren't supported. For example, the first problem is that it fails
> to determine the PCI clock frequency - it times out in sym_hipd.c:getfreq()
> waiting for the GEN flag (almost as if there is no SCSI clock). Just prior
> to this (in sym_getpciclock()) it tries to set the SCLK bit of STEST1 in
> order to use the PCI clock as the SCSI clock - but that bit is reserved
> according to the datasheet.

Yes.  It's reserved for the 1010 too, and this problem doesn't occur
there.  Does the problem go away if you stop setting that bit?  If so it
would be straightforward to conditionalise this setting on a feature bit.
My guess is that it's something else though.

> The same hardware seems to work with a much simpler, internally written,
> driver.

I'd like to simplify the sym2 driver; it's far too complicated.  It'll
take a while though.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

RE: Support for LSI 53C1010R

[Phil Thompson]

> -----Original Message-----
> From: Matthew Wilcox [mailto:willy@debian.org] 
> Sent: 13 April 2004 16:09
> To: Phil Thompson
> Cc: 'linux-scsi@vger.kernel.org'
> Subject: Re: Support for LSI 53C1010R
> 
> 
> On Tue, Apr 13, 2004 at 02:21:13PM +0100, Phil Thompson wrote:
> > I'm having problems with the Linux sym53c8xx_2 
> (sym-2.1.17a) driver on 
> > an embedded system with an LSI 53C1010R. Are there any 
> issues with the 
> > driver and that revision of the chip - specifically the R suffix?
> 
> I don't have a 1010R myself, only the data sheet.
> 
> > The driver tries to do some things with the chip which 
> (according to 
> > the
> > datasheet) aren't supported. For example, the first problem 
> is that it fails
> > to determine the PCI clock frequency - it times out in 
> sym_hipd.c:getfreq()
> > waiting for the GEN flag (almost as if there is no SCSI 
> clock). Just prior
> > to this (in sym_getpciclock()) it tries to set the SCLK bit 
> of STEST1 in
> > order to use the PCI clock as the SCSI clock - but that bit 
> is reserved
> > according to the datasheet.
> 
> Yes.  It's reserved for the 1010 too, and this problem 
> doesn't occur there.  Does the problem go away if you stop 
> setting that bit?  If so it would be straightforward to 
> conditionalise this setting on a feature bit. My guess is 
> that it's something else though.

It doesn't make any difference if I skip the calls and hardwire the PCI
frequency to 66000. The next problem is that sym_snooptest() fails - also
with a timeout.

I've gone through the datasheet and the driver to check for any other
reserved bits/registers that are being used - SCLK is the only one.

I agree that it's looking like something else.

> > The same hardware seems to work with a much simpler, internally 
> > written, driver.
> 
> I'd like to simplify the sym2 driver; it's far too 
> complicated.  It'll take a while though.

Either the simple driver isn't using as much of the hardware (and there is a
hardware bug), or the bootloader isn't setting something up that the Linux
driver is expecting.

Thanks,
Phil

Re: Support for LSI 53C1010R

[Matthew Dharm]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Tue, Apr 13, 2004 at 02:21:13PM +0100, Phil Thompson wrote:
> I'm having problems with the Linux sym53c8xx_2 (sym-2.1.17a) driver on an
> embedded system with an LSI 53C1010R. Are there any issues with the driver
> and that revision of the chip - specifically the R suffix?

At my day job, we make boards with the 1010R on them that run Linux just
fine.  No problems at all.  It's even running big-endian.

Matt

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

C:  They kicked your ass, didn't they?
S:  They were cheating!
					-- The Chief and Stef
User Friendly, 11/19/1997

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]