[git patches] atang tree: fix UDMA mode for older Promise controllers

[git patches] atang tree: fix UDMA mode for older Promise controllers

[Bartlomiej Zolnierkiewicz]

DISCLAIMER: the fact of getting patches merged into atang tree means
that from now on they will be getting updates for changes happening
in atang tree and it should not be treated as an indication regarding
decisions taken by 'upstream' kernel trees


Russell King did some great debugging work last month on the root
source of UDMA problems that have been consistenly reported against
pata_pdc202xx_old driver for the last couple of years which should
allow us to hopefully fix them all in atang tree.


On top of atang-v4.4.

The following changes since commit bcf33ade797072b4dcd51dd13b353a6e052036c6:
  Thomas Chou (1):
        drivers/staging: New PATA driver for Altera CompactFlash.

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git atang-v4.5

Bartlomiej Zolnierkiewicz (3):
      pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards
      pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets
      pata_pdc202xx_old: update documentation

 drivers/ata/Kconfig             |    1 -
 drivers/ata/pata_pdc202xx_old.c |   13 ++++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

[PATCH 1/3] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

On Monday 04 January 2010 02:30:24 pm Russell King wrote:

> Found the problem - getting rid of the read of the alt status register
> after the command has been written fixes the UDMA CRC errors on write:
> 
> @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
> ata_taskfile *tf)
>         DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
> 
>         iowrite8(tf->command, ap->ioaddr.command_addr);
> -       ata_sff_pause(ap);
> +       ndelay(400);
> +//     ata_sff_pause(ap);
>  }
>  EXPORT_SYMBOL_GPL(ata_sff_exec_command);
> 
> 
> This rather makes sense.  The PDC20247 handles the UDMA part of the
> protocol.  It has no way to tell the PDC20246 to wait while it suspends
> UDMA, so that a normal register access can take place - the 246 ploughs
> on with the register access without any regard to the state of the 247.
> 
> If the drive immediately starts the UDMA protocol after a write to the
> command register (as it probably will for the DMA WRITE command), then
> we'll be accessing the taskfile in the middle of the UDMA setup, which
> can't be good.  It's certainly a violation of the ATA specs.

Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.

Debugged-by: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc202xx_old.c |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -2,7 +2,7 @@
  * pata_pdc202xx_old.c 	- Promise PDC202xx PATA for new ATA layer
  *			  (C) 2005 Red Hat Inc
  *			  Alan Cox <alan@lxorguk.ukuu.org.uk>
- *			  (C) 2007,2009 Bartlomiej Zolnierkiewicz
+ *			  (C) 2007,2009,2010 Bartlomiej Zolnierkiewicz
  *
  * Based in part on linux/drivers/ide/pci/pdc202xx_old.c
  *
@@ -26,6 +26,15 @@
 
 #include "pata_pdc202xx_old.h"
 
+static void pdc20246_exec_command(struct ata_port *ap,
+				  const struct ata_taskfile *tf)
+{
+	DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
+
+	iowrite8(tf->command, ap->ioaddr.command_addr);
+	ndelay(400);
+}
+
 /**
  *	pdc2026x_bmdma_start		-	DMA engine begin
  *	@qc: ATA command
@@ -171,6 +180,8 @@ static struct ata_port_operations pdc202
 	.cable_detect		= ata_cable_40wire,
 	.set_piomode		= pdc202xx_set_piomode,
 	.set_dmamode		= pdc202xx_set_dmamode,
+
+	.sff_exec_command	= pdc20246_exec_command,
 };
 
 static struct ata_port_operations pdc2026x_port_ops = {

Re: [PATCH 1/3] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

[Jeff Garzik]

On 02/13/2010 08:35 AM, Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> Subject: [PATCH] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards
>
> On Monday 04 January 2010 02:30:24 pm Russell King wrote:
>
>> Found the problem - getting rid of the read of the alt status register
>> after the command has been written fixes the UDMA CRC errors on write:
>>
>> @@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
>> ata_taskfile *tf)
>>          DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
>>
>>          iowrite8(tf->command, ap->ioaddr.command_addr);
>> -       ata_sff_pause(ap);
>> +       ndelay(400);
>> +//     ata_sff_pause(ap);
>>   }
>>   EXPORT_SYMBOL_GPL(ata_sff_exec_command);
>>
>>
>> This rather makes sense.  The PDC20247 handles the UDMA part of the
>> protocol.  It has no way to tell the PDC20246 to wait while it suspends
>> UDMA, so that a normal register access can take place - the 246 ploughs
>> on with the register access without any regard to the state of the 247.
>>
>> If the drive immediately starts the UDMA protocol after a write to the
>> command register (as it probably will for the DMA WRITE command), then
>> we'll be accessing the taskfile in the middle of the UDMA setup, which
>> can't be good.  It's certainly a violation of the ATA specs.
>
> Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.
>
> Debugged-by: Russell King<rmk@arm.linux.org.uk>
> Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@gmail.com>
> ---
>   drivers/ata/pata_pdc202xx_old.c |   13 ++++++++++++-
>   1 file changed, 12 insertions(+), 1 deletion(-)

applied

[PATCH 2/3] pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

PDC2026x chipsets need the same treatment as PDC20246 one.

This is completely untested but will hopefully fix UDMA issues
that people have been reporting against pata_pdc202xx_old for
the last couple of years.

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/pata_pdc202xx_old.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -26,7 +26,7 @@
 
 #include "pata_pdc202xx_old.h"
 
-static void pdc20246_exec_command(struct ata_port *ap,
+static void pdc202xx_exec_command(struct ata_port *ap,
 				  const struct ata_taskfile *tf)
 {
 	DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
@@ -181,7 +181,7 @@ static struct ata_port_operations pdc202
 	.set_piomode		= pdc202xx_set_piomode,
 	.set_dmamode		= pdc202xx_set_dmamode,
 
-	.sff_exec_command	= pdc20246_exec_command,
+	.sff_exec_command	= pdc202xx_exec_command,
 };
 
 static struct ata_port_operations pdc2026x_port_ops = {

Re: [PATCH 2/3] pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

[Bartlomiej Zolnierkiewicz]

On Saturday 13 February 2010 02:35:59 pm Bartlomiej Zolnierkiewicz wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Subject: [PATCH] pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets
> 
> PDC2026x chipsets need the same treatment as PDC20246 one.
> 
> This is completely untested but will hopefully fix UDMA issues
> that people have been reporting against pata_pdc202xx_old for
> the last couple of years.
> 
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> ---
>  drivers/ata/pata_pdc202xx_old.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Index: b/drivers/ata/pata_pdc202xx_old.c
> ===================================================================
> --- a/drivers/ata/pata_pdc202xx_old.c
> +++ b/drivers/ata/pata_pdc202xx_old.c
> @@ -26,7 +26,7 @@
>  
>  #include "pata_pdc202xx_old.h"
>  
> -static void pdc20246_exec_command(struct ata_port *ap,
> +static void pdc202xx_exec_command(struct ata_port *ap,
>  				  const struct ata_taskfile *tf)
>  {
>  	DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);
> @@ -181,7 +181,7 @@ static struct ata_port_operations pdc202
>  	.set_piomode		= pdc202xx_set_piomode,
>  	.set_dmamode		= pdc202xx_set_dmamode,
>  
> -	.sff_exec_command	= pdc20246_exec_command,
> +	.sff_exec_command	= pdc202xx_exec_command,
>  };
>  
>  static struct ata_port_operations pdc2026x_port_ops = {

the missing chunk :)

@@ -195,6 +195,8 @@
 	.dev_config		= pdc2026x_dev_config,
 
 	.port_start		= pdc2026x_port_start,
+
+	.sff_exec_command	= pdc202xx_exec_command,
 };
 
 static int pdc202xx_init_one(struct pci_dev *dev, const struct pci_device_id *id)

Re: [PATCH 2/3] pata_pdc202xx_old: fix UDMA mode for PDC2026x chipsets

[Jeff Garzik]

On 02/13/2010 08:44 AM, Bartlomiej Zolnierkiewicz wrote:
> .sff_exec_command	= pdc202xx_exec_command,

applied patch #2 + this missing chunk

[PATCH 3/3] pata_pdc202xx_old: update documentation

[Bartlomiej Zolnierkiewicz]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Subject: [PATCH] pata_pdc202xx_old: update documentation

Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
---
 drivers/ata/Kconfig |    1 -
 1 file changed, 1 deletion(-)

Index: b/drivers/ata/Kconfig
===================================================================
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -599,7 +599,6 @@ config PATA_PDC_OLD
 	  20265 and 20267 adapters.
 
 	  Known issues:
-	  - UDMA transfers fail mysteriously on some chipsets
 	  - ATAPI DMA is unsupported currently
 
 	  If unsure, say N.