Commit Graph

21 Commits

Author SHA1 Message Date
Tejun Heo e4e10e3e79 [PATCH] sata_sil: implement R_ERR on DMA activate FIS errata fix
Silicon Image has disclosed a new sil3114/3152 errata and workaround
which causes the controller to return R_ERR on DMA activate FIS if the
FIS is received while the next PRD is being fetched.  This patch
implements the workaround.

This errata results in lock up and doesn't trigger if m15w workaround
is in effect.  We stopped applying m15w to 3512 and 3114 in 2.6.14-rc1
which makes 3512/3114 lock up with some drives on all kernel versions
since 2.6.14-rc1 upto now (2.6.16-rc4).  This patch should fix the
regression.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-02-25 16:52:31 -05:00
Tejun Heo 0ee304d580 [PATCH] sata_sil: add board ID for 3512
3512 is slightly different from 3112 errata-wise.  Differentiate it.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2006-02-25 16:52:31 -05:00
Jeff Garzik 51e9f2ff83 [libata sata_sil] implement 'slow_down' module parameter
On occasion, a user will submit a patch that enables the "mod15write"
quirk for their device.  Enabling this quirk has the effect of clamping
all ATA commands to no more than 15 sectors.  The intended use of this
quirk is to stop the controller from generating FIS's of unusual size
("but Wesley, what about the FOUS's?"), which in turn works around
problems in a <list> of hard drives.

One side effect of this quirk is greatly decreased performance.  Users
often enable the mod15write quirk to fix various system, power, chip,
and/or driver problems.  For a few rare problematic cases, enabling this
has cured lockups or data corruption.

Rather than add bogus listings to the mod15write quirk list (I get a
patch every month doing such), we add a 'slow_down' module parameter.
This allows users to employ a performance sledgehammer in the hopes
of curing a problem.  It defaults to off (0), of course.
2006-01-27 16:50:27 -05:00
Tejun Heo 93c9338713 [BLOCK] update libata to use new blk_ordered for barriers
Reflect changes in SCSI midlayer and updated to use new
ordered request implementation

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jens Axboe <axboe@suse.de>
2006-01-06 09:55:00 +01:00
Arjan van de Ven 98ac62defe [PATCH] mark several libata datastructures const
Hi,

the patch below marks several libata (and libata-driver) structures
const so that they end up in the .rodata segment and don't false-share
cachelines with things that get dirtied often.

Signed-off-by: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-12-01 02:29:35 -05:00
Jeff Garzik 3b7d697dfb [libata] constify PCI ID table in several drivers 2005-11-10 11:04:11 -05:00
Jeff Garzik 193515d51c [libata] eliminate use of drivers/scsi/scsi.h compatibility header/defines 2005-11-07 00:59:37 -05:00
Jeff Garzik a9524a76f7 [libata] use dev_printk() throughout drivers
A few drivers were not following the standard meme of printing out
their driver name and version at module load time; this is fixed
as well.
2005-10-30 14:39:11 -05:00
Jeff Garzik 057ace5e79 libata: const-ification bombing run
Enforce access rules where appropriate.

If the compiler is smart enough, this may buy us an optimization or two
as a side effect.
2005-10-22 14:27:05 -04:00
Al Viro 9aa36e89b5 [PATCH] iomem annotations (sata_sil)
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-10-21 02:05:31 -04:00
Jeff Garzik 374b187357 [libata] update several drivers to use pci_iomap()/pci_iounmap() 2005-08-30 05:42:52 -04:00
Jeff Garzik ea6ba10bbb [libata] __iomem annotations for various drivers 2005-08-30 05:18:18 -04:00
Jeff Garzik 70d374ea99 Merge /spare/repo/linux-2.6/ 2005-08-29 15:59:42 -04:00
Jeff Garzik af36d7f0df [libata] license change, other bits
- changes license of all code from OSL+GPL to plain ole GPL
  - except for NVIDIA, who hasn't yet responded about sata_nv
  - copyright holders were already contacted privately

- adds info in each driver about where hardware/protocol docs may be
  obtained

- where I have made major contributions, updated copyright dates
2005-08-28 20:18:39 -04:00
Jeff Garzik 953d1137fc [libata sata_sil] list documentation URL, since its public 2005-08-26 19:46:24 -04:00
Tejun Heo e4deec6304 [PATCH] sil: apply M15W quirk selectively (take 2)
As SII reports that only original 3112's are affected by M15W quirk,
This patch adds SIL_FLAG_MOD15WRITE to selectively apply M15W quirk
depending on chipsets.  As of yet, we don't know exactly which PCI IDs
are for original 3112, so M15W quirk is applied to all except for 3512
and 3124.  Once more info is avaliable, we can change some of these
sil_3112_m15w's to sil_3112.

Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
2005-08-23 01:05:55 -04:00
Jeff Garzik 8a60a07129 libata: trim trailing whitespace.
Also, fixup a tabs-to-spaces block of code in ata_piix.
2005-07-31 13:13:24 -04:00
Jens Axboe e1dd23a001 [PATCH] sata_sil: Fix FIFO PCI Bus Arbitration kernel oops
Correct this.

diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
2005-06-09 03:06:22 -04:00
Jeff Garzik aa8f0dc6c3 libata: Fix use-after-iounmap
Jens Axboe pointed out that the iounmap() call in libata was occurring
too early, and some drivers (ahci, probably others) were using ioremap'd
memory after it had been unmapped.

The patch should address that problem by way of improving the libata
driver API:

* move ->host_stop() call after all ->port_stop() calls have occurred.

* create default helper function ata_host_stop(), and move iounmap()
call there.

* add ->host_stop_prewalk() hook, use it in sata_qstor.c (hi Mark).
sata_qstor appears to require the host-stop-before-port-stop ordering
that existed prior to applying the attached patch.
2005-05-26 21:54:27 -04:00
NAKAMURA Kenta 525a099771 [PATCH] sata_sil: new ID 1002:437A for ATI IXP400 2005-05-25 19:28:38 -04:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00