| Message ID | 4C03C728.9080107@kernel.org |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On 05/31/2010 10:26 AM, Tejun Heo wrote: > vt6421 has problems talking to recent WD drives. It causes a lot of > transmission errors while high bandwidth transfer as reported in the > following bugzilla entry. > > https://bugzilla.kernel.org/show_bug.cgi?id=15173 > > Joseph Chan provided the following fix. I don't have any idea what it > does but I can verify the issue is gone with the patch applied. > > Signed-off-by: Tejun Heo<tj@kernel.org> > Originally-from: Joseph Chan<JosephChan@via.com.tw> > Reported-by: Jorrit Tijben<sjorrit@gmail.com> > Cc: stable@kernel.org > --- > Joseph, can you please add some documentation of what it does and why? > > Thanks. > > drivers/ata/sata_via.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) applied -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Sorry for the delay to respond. -----Original Message----- From: Jeff Garzik [mailto:jgpobox@gmail.com] On Behalf Of Jeff Garzik > https://bugzilla.kernel.org/show_bug.cgi?id=15173 > > Joseph Chan provided the following fix. I don't have any idea what it > does but I can verify the issue is gone with the patch applied. After analysis, we found when host issued HOLD, device still send some extra DW data before it issues HOLDA. According SPEC, device can send data out up to 20DW. If the host issue HOLD and then the FIFO is full, host will issue R_ERR for device to notice data can't be received. For some device, it will enter 3G/1.5G protocol hand-shake from 3G protocol. According our FIFO default value for two WDC HDDs, it will encounter many time FIFO full case during DMA Read because these two WDC devices will issues 20DW *2 =40DW and the host will be trigged to issue R_ERR to device if the Host side computer consumes data lower than the coming DMA read data from device. Rx52[2] is the Internal 128DW FIFO Flow control water-mark adjusting mechanism enable bit of VT6421 and the default value is 0 to mean host will issue HOLD to device when the leaved FIFO size is always set as 32DW. So, we set the Rx52[2] to 1 to enable FIFO water-mark adjusting mechanism and then adjust our leaved FIFO size from 32 DW to 64 DW (128*1/2) through RX43 FIFO water-mark FIFO size control registers.
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c index 101d8c2..0ecd0f6 100644 --- a/drivers/ata/sata_via.c +++ b/drivers/ata/sata_via.c @@ -575,6 +575,19 @@ static void svia_configure(struct pci_dev *pdev) tmp8 |= NATIVE_MODE_ALL; pci_write_config_byte(pdev, SATA_NATIVE_MODE, tmp8); } + + /* + * vt6421 has problems talking to some drives. The following + * is the magic fix from Joseph Chan <JosephChan@via.com.tw>. + * Please add proper documentation if possible. + * + * https://bugzilla.kernel.org/show_bug.cgi?id=15173 + */ + if (pdev->device == 0x3249) { + pci_read_config_byte(pdev, 0x52, &tmp8); + tmp8 |= 1 << 2; + pci_write_config_byte(pdev, 0x52, tmp8); + } } static int svia_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
vt6421 has problems talking to recent WD drives. It causes a lot of transmission errors while high bandwidth transfer as reported in the following bugzilla entry. https://bugzilla.kernel.org/show_bug.cgi?id=15173 Joseph Chan provided the following fix. I don't have any idea what it does but I can verify the issue is gone with the patch applied. Signed-off-by: Tejun Heo <tj@kernel.org> Originally-from: Joseph Chan <JosephChan@via.com.tw> Reported-by: Jorrit Tijben <sjorrit@gmail.com> Cc: stable@kernel.org --- Joseph, can you please add some documentation of what it does and why? Thanks. drivers/ata/sata_via.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html