From: Tejun Heo <htejun@gmail.com>
To: jgarzik@pobox.com, linux-ide@vger.kernel.org, hellan@acm.org,
Carlos.Pardo@siliconimage.com, Raymond.Liu@siliconimage.com
Cc: Tejun Heo <htejun@gmail.com>
Subject: [PATCH 3/3] sata_sil: clean up and add errata/workaround documentation
Date: Sat, 25 Feb 2006 13:30:46 +0900 [thread overview]
Message-ID: <11408418462821-git-send-email-htejun@gmail.com> (raw)
In-Reply-To: <1140841846157-git-send-email-htejun@gmail.com>
This patch collects into one place/update errata documentattion and
adds description of 3114 R_ERR on DMA activate FIS errata.
Signed-off-by: Tejun Heo <htejun@gmail.com>
---
drivers/scsi/sata_sil.c | 97 ++++++++++++++++++++++++++++++++++++-----------
1 files changed, 75 insertions(+), 22 deletions(-)
eb8c1c7aadc83423d03a46ec3ac806452e9d2cfe
diff --git a/drivers/scsi/sata_sil.c b/drivers/scsi/sata_sil.c
index 9face3c..75784cd 100644
--- a/drivers/scsi/sata_sil.c
+++ b/drivers/scsi/sata_sil.c
@@ -30,8 +30,79 @@
* Documentation for SiI 3112:
* http://gkernel.sourceforge.net/specs/sii/3112A_SiI-DS-0095-B2.pdf.bz2
*
+ * Documentation for SiI 3114:
+ * http://gkernel.sourceforge.net/specs/sii/sii-0680a-v1.31.pdf.bz2
+ *
* Other errata and documentation available under NDA.
*
+ * Currently implemented workarounds are...
+ *
+ * 1. Mod15Write errata workaround
+ *
+ * Errata:
+ * The Mod15Write bug is caused by the SiI3112 controller splitting
+ * data FIS in the middle of a 512 byte block when transferring
+ * data equal to or larger than 8k (not prohibited by the standard
+ * but still a bit peculiar) and some Seagate drives locking up on
+ * receiving such data FIS.
+ *
+ * Workaround:
+ * This is worked around by limiting max_sectors to 15 such that
+ * write data is always smaller than 8k. This slows down IO
+ * severely.
+ *
+ * This workaround is applied during sil_dev_config() and the
+ * affected drives are marked with SIL_QUIRK_MOD15WRITE in
+ * sil_blacklist.
+ *
+ * The workaround slows down everything considerably and tends to
+ * hide other problems when applied. Due to lack of information,
+ * this workaround had been applied when some drives show similar
+ * symptoms (e.g. errata #3). It seems that the blacklist
+ * currently contains some number of unaffected drives.
+ *
+ * As we don't know exactly which drives are affected, slow_down
+ * module parameter is implemented which turns on this workaround
+ * manually.
+ *
+ * 2. Maxtor udma5 max errata
+ *
+ * Errata:
+ * For certain Maxtor devices, we must not program the drive be
+ * beyond udma5.
+ *
+ * Workaround:
+ * Limit max transfer mode to udma5.
+ *
+ * This workaround is applied during sli_dev_config() and the
+ * affected drives are marked with SIL_QUIRK_UDMA5MAX in
+ * sil_blacklist.
+ *
+ * Note that udma5 is 100Mbytes/s which is more than sufficient, so
+ * this workaround doesn't really affect performance.
+ *
+ * 3. SiI 3512/3114 R_ERR on DMA activate FIS errta workaround
+ *
+ * Errata:
+ * During DMA write operations with a data length greater than 8
+ * Kbytes, a PRD entry fetch that occurs at the same time that a
+ * DMA Activate FIS is received may cause the controller to falsely
+ * indicate that the DMA Activate FIS has an illegal FIS Type.
+ * This may cause the controller to send an R_EER in response to
+ * the DMA Active FIS.
+ *
+ * Workaround:
+ * By configuring bit[1:0] of the SFISCfg register to accept FIS
+ * types other than the standard SATA defined FIS types, the
+ * controller is prevented from falsely setting the illegal FIS
+ * Type indicator, thus preventing the improper RERR response. The
+ * default value of the SFISCfg register is 0x1040_1555. To
+ * implement this workaround, the SFISCfg register should be set to
+ * a value of 0x1040_1554.
+ *
+ * This workaround is applied during controller initialization in
+ * sil_init_one().
+ *
*/
#include <linux/kernel.h>
@@ -328,28 +399,10 @@ static void sil_scr_write (struct ata_po
* @dev: Device to be examined
*
* After the IDENTIFY [PACKET] DEVICE step is complete, and a
- * device is known to be present, this function is called.
- * We apply two errata fixups which are specific to Silicon Image,
- * a Seagate and a Maxtor fixup.
- *
- * For certain Seagate devices, we must limit the maximum sectors
- * to under 8K.
- *
- * For certain Maxtor devices, we must not program the drive
- * beyond udma5.
- *
- * Both fixups are unfairly pessimistic. As soon as I get more
- * information on these errata, I will create a more exhaustive
- * list, and apply the fixups to only the specific
- * devices/hosts/firmwares that need it.
- *
- * 20040111 - Seagate drives affected by the Mod15Write bug are blacklisted
- * The Maxtor quirk is in the blacklist, but I'm keeping the original
- * pessimistic fix for the following reasons...
- * - There seems to be less info on it, only one device gleaned off the
- * Windows driver, maybe only one is affected. More info would be greatly
- * appreciated.
- * - But then again UDMA5 is hardly anything to complain about
+ * device is known to be present, this function is called. This
+ * function also applies controller/device specific erratas,
+ * please see the comment at the top of this file for more
+ * information.
*/
static void sil_dev_config(struct ata_port *ap, struct ata_device *dev)
{
--
1.2.1
next prev parent reply other threads:[~2006-02-25 4:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-25 4:30 [PATCHSET] sata_sil: R_ERR on DMA activate FIS errata workaround Tejun Heo
2006-02-25 4:30 ` Tejun Heo [this message]
2006-02-25 4:30 ` [PATCH 2/3] sata_sil: implement R_ERR on DMA activate FIS errata fix Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2006-02-25 4:52 [PATCHSET, RESEND] sata_sil: R_ERR on DMA activate FIS errata workaround Tejun Heo
2006-02-25 4:52 ` [PATCH 3/3] sata_sil: clean up and add errata/workaround documentation Tejun Heo
2006-02-25 7:29 ` Jeff Garzik
2006-02-25 7:36 ` Tejun Heo
2006-02-25 22:07 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11408418462821-git-send-email-htejun@gmail.com \
--to=htejun@gmail.com \
--cc=Carlos.Pardo@siliconimage.com \
--cc=Raymond.Liu@siliconimage.com \
--cc=hellan@acm.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).