lkml.org 
[lkml]   [2001]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
Date
From
Andries.Brouwer@cwi.nl said:
> If I am not mistaken, Richard Hirst has also done work on this thing.
> The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now
> works under both 2.2 and 2.4. It also has on-board SCSI (NCR
> 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the
> addresses. It would be somewhat interesting to get that thing to work
> as well.

You're likely to trip across the part of the driver I skimped on: The clock divider section. Usually you want the async core to run just under 25Mhz and the sync core to run just under 50Mhz. Therefore, you ususally clock the 700-66 chip at 50Mhz and put 1 into the sync and 2 into the async divider (which is all I do---although you probably clock a non -66 chip at 25Mhz). However, a combo card may have a rather different clock speed. I can work on this some more if you want to try to get the card running. Do you know what the clock speed is?

alan@lxorguk.ukuu.org.uk said:
> According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the
> NCR 53c700/66 is mapped at 0xCC0-0xCFF.

That would be io mapped? then the 53c700.c chip driver should plug almost straight in.

Andries.Brouwer@cwi.nl said:
> Yes. But long ago he wrote:
> ---
> You need quite a different driver from the 53c710 drivers that exist,
> because 53c700 doesn't have DSA register. I've attached a diff for
> 2.4.0-test9 which adds sim700.{c,h,scr}. That driver is supposed to
> handle 53c700 and 53c710 and be a replacement for sim710.c.

There are several other differences, although the lack of DSA register is the most annoying:

- They can't manipulate the chip registers in the script.
- Their SCSI-DMA fifo core is only 32 bits (you need to compute the datapath residue differently)
- The selection model is completely different. You can put the 710 into 700 compatibility mode and run the same selection model, but that's probably not what you want: the 700 needs two interrupts to resume after a reselection, one to see the selection and the other to collect the lun and tag. The 710 can wait for the reselection grab the lun and tag and then interrupt. You can also dispense with the elaborate selection interrupt section I have to have. I thought of doing a probabalistic selection for the 700: given the PUN, you guess the lun and tag (probably use the oldest) and set the script up for these. You take a "wrong guess" interrupt if you got it incorrect. However, with 8 tags outstanding per device, you'd probably only see a 13% correct guess, which didn't seem worth it.

I thought, based on these differences, that it made more sense to keep the 700 driver separate from the 710 one.

The next chip core I'm considering is the 720/770 (I have a nice microchannel card with 4 of these and 2MB of onboard memory), unless you know of someone who has already done the extra work (the 53c7xx and 53c7,8xx don't do the wide/ultra features).

James


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.034 / U:1.548 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site