summaryrefslogtreecommitdiffstats
path: root/drivers/scsi/wd33c93.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Spelling fix: explicitlyJean Delvare2007-10-191-1/+1
| | | | | | | From: Jean Delvare <khali@linux-fr.org> Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Adrian Bunk <bunk@kernel.org>
* [SCSI] wd33c93: Fast SCSI with WD33C93Bpeter fuerst2007-02-161-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Attached are patches, which help to utilize more of the WD33C93B SCSI controller's capabilities. 1) Added/changed all the necessary code to enable Burst Mode DMA. Only Single Byte DMA was used before. 2) Added/changed all the necessary code to enable Fast-10 SCSI transfers. 3) The original driver inadvertently used a transfer period of 1000-800ns (the lowest possible transfer rate) for asynchronous data transfers, instead of the (configurable) default period intended for this purpose, if the target responded to a SDTR not with a Reject-message, but with a zero-SDTR. This issue was fixed. Moreover, in case of a Reject the driver used the default-period's initialization-value instead of its (maybe smaller) current value. The missing assignment was added. 4) The driver's commandline- and proc-file-interface was augmented to handle the new options properly. The WD33C93 manual, found at http://www.datasheet.in/datasheet-html/W/D/3/WD33C93B_WesternDigital.pdf.html, was very helpful. Signed-off-by: peter fuerst <post@pfrst.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
* Remove obsolete #include <linux/config.h>Jörn Engel2006-06-301-1/+0
| | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-171-0/+348
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!