Subject: [PATCH] WD33C93: let platform stub override no_sync/fast/dma_mode

From: Thomas Bogendoerfer <[email-masked]>
Date: Fri, 21 Mar 2008 22:25:43 +0100 (CET)

SGI machines with WD33C93 allow usage of burst mode DMA, which increases
performance noticable. To make this selectable by the sgiwd93 stub,
setting the values for no_sync, fast and dma_mode has been moved to the
individual platform stubs.

Signed-off-by: Thomas Bogendoerfer <[email-masked]>
---

Please apply for 2.6.26

 drivers/scsi/a2091.c   |    3 +++
 drivers/scsi/a3000.c   |    3 +++
 drivers/scsi/gvp11.c   |    3 +++
 drivers/scsi/mvme147.c |    3 +++
 drivers/scsi/sgiwd93.c |    7 ++++---
 drivers/scsi/wd33c93.c |    3 ---
 6 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/a2091.c b/drivers/scsi/a2091.c
index 5ac3a3e..1d1bb25 100644
--- a/drivers/scsi/a2091.c
+++ b/drivers/scsi/a2091.c
@@ -179,6 +179,9 @@ int __init a2091_detect(struct scsi_host_template *tpnt)
 	DMA(instance)->DAWR = DAWR_A2091;
 	regs.SASR = &(DMA(instance)->SASR);
 	regs.SCMD = &(DMA(instance)->SCMD);
+	HDATA(a3000_host)->no_sync = 0xff;
+	HDATA(a3000_host)->fast = 0;
+	HDATA(a3000_host)->dma_mode = CTRL_DMA;
 	wd33c93_init(instance, regs, dma_setup, dma_stop, WD33C93_FS_8_10);
 	request_irq(IRQ_AMIGA_PORTS, a2091_intr, IRQF_SHARED, "A2091 SCSI",
 		    instance);
diff --git a/drivers/scsi/a3000.c b/drivers/scsi/a3000.c
index 3aeec96..8b449d8 100644
--- a/drivers/scsi/a3000.c
+++ b/drivers/scsi/a3000.c
@@ -178,6 +178,9 @@ int __init a3000_detect(struct scsi_host_template *tpnt)
     DMA(a3000_host)->DAWR = DAWR_A3000;
     regs.SASR = &(DMA(a3000_host)->SASR);
     regs.SCMD = &(DMA(a3000_host)->SCMD);
+    HDATA(a3000_host)->no_sync = 0xff;
+    HDATA(a3000_host)->fast = 0;
+    HDATA(a3000_host)->dma_mode = CTRL_DMA;
     wd33c93_init(a3000_host, regs, dma_setup, dma_stop, WD33C93_FS_12_15);
     if (request_irq(IRQ_AMIGA_PORTS, a3000_intr, IRQF_SHARED, "A3000 SCSI",
 		    a3000_intr))
diff --git a/drivers/scsi/gvp11.c b/drivers/scsi/gvp11.c
index 91f8522..e75a7ba 100644
--- a/drivers/scsi/gvp11.c
+++ b/drivers/scsi/gvp11.c
@@ -322,6 +322,9 @@ int __init gvp11_detect(struct scsi_host_template *tpnt)
 	 */
 	regs.SASR = &(DMA(instance)->SASR);
 	regs.SCMD = &(DMA(instance)->SCMD);
+	HDATA(a3000_host)->no_sync = 0xff;
+	HDATA(a3000_host)->fast = 0;
+	HDATA(a3000_host)->dma_mode = CTRL_DMA;
 	wd33c93_init(instance, regs, dma_setup, dma_stop,
 		     (epc & GVP_SCSICLKMASK) ? WD33C93_FS_8_10
 					     : WD33C93_FS_12_15);
diff --git a/drivers/scsi/mvme147.c b/drivers/scsi/mvme147.c
index be41aad..6a8cf17 100644
--- a/drivers/scsi/mvme147.c
+++ b/drivers/scsi/mvme147.c
@@ -82,6 +82,9 @@ int mvme147_detect(struct scsi_host_template *tpnt)
     mvme147_host->irq = MVME147_IRQ_SCSI_PORT;
     regs.SASR = (volatile unsigned char *)0xfffe4000;
     regs.SCMD = (volatile unsigned char *)0xfffe4001;
+    HDATA(a3000_host)->no_sync = 0xff;
+    HDATA(a3000_host)->fast = 0;
+    HDATA(a3000_host)->dma_mode = CTRL_DMA;
     wd33c93_init(mvme147_host, regs, dma_setup, dma_stop, WD33C93_FS_8_10);
 
     if (request_irq(MVME147_IRQ_SCSI_PORT, mvme147_intr, 0, "MVME147 SCSI PORT", mvme147_intr))
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index 26cfc56..03e3596 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -263,10 +263,11 @@ static int __init sgiwd93_probe(struct platform_device *pdev)
 	regs.SASR = wdregs + 3;
 	regs.SCMD = wdregs + 7;
 
-	wd33c93_init(host, regs, dma_setup, dma_stop, WD33C93_FS_MHZ(20));
+	hdata->wh.no_sync = 0;
+	hdata->wh.fast = 1;
+	hdata->wh.dma_mode = CTRL_BURST;
 
-	if (hdata->wh.no_sync == 0xff)
-		hdata->wh.no_sync = 0;
+	wd33c93_init(host, regs, dma_setup, dma_stop, WD33C93_FS_MHZ(20));
 
 	err = request_irq(irq, sgiwd93_intr, 0, "SGI WD93", host);
 	if (err) {
diff --git a/drivers/scsi/wd33c93.c b/drivers/scsi/wd33c93.c
index f286c37..5fda881 100644
--- a/drivers/scsi/wd33c93.c
+++ b/drivers/scsi/wd33c93.c
@@ -1973,10 +1973,7 @@ wd33c93_init(struct Scsi_Host *instance, const wd33c93_regs regs,
 	hostdata->incoming_ptr = 0;
 	hostdata->outgoing_len = 0;
 	hostdata->default_sx_per = DEFAULT_SX_PER;
-	hostdata->no_sync = 0xff;	/* sync defaults to off */
 	hostdata->no_dma = 0;	/* default is DMA enabled */
-	hostdata->fast = 0;	/* default is Fast SCSI transfers disabled */
-	hostdata->dma_mode = CTRL_DMA;	/* default is Single Byte DMA */
 
 #ifdef PROC_INTERFACE
 	hostdata->proc = PR_VERSION | PR_INFO | PR_STATISTICS |

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 21 Mar 2008 22:12:30 +0000

> Signed-off-by: Thomas Bogendoerfer <[email-masked]>

Acked-by: Ralf Baechle <[email-masked]>

This is one of the things on my list of things to be fixed for IP22 for
even longer than I can recall.  Thanks Thomas!

  Ralf

---

From: peter fuerst <[email-masked]>
Date: Fri, 21 Mar 2008 23:20:07 +0100 (CET)

Hi Thomas,

the code-sequence

	wd33c93_init(...
	if (hdata->wh.no_sync == 0xff)
		hdata->wh.no_sync = 0;

was put/kept there intentionally - in this very order - to enable
"nosync" from the command-line!

	Date: Mon, 12 Feb 2007 15:27:17 +0100 (CET)
	From: peter fuerst <[email-masked]>
	To: [email-masked], [email-masked]
	Cc: Ralf Baechle <[email-masked]>, Kumba <[email-masked]>,
	     Thiemo Seufer <[email-masked]>, Tim Yamin <[email-masked]>
	Subject: [PATCH][SCSI] sgiwd93.c: interfacing to wd33c93

	1) sgiwd93 used to switch off asynchronous mode on the wd33c93, discarding
	   any "nosync"-requests from the commandline.
	   But we need to allow "nosync"-requests for selected devices, for example
	   the Pioneer DVD305S.
	   (For the curious: this device accepts the SDTR from wd33c93 and success-
	   fully sends inquiry data in sync mode, but after the data phase in the
	   inquiry command does an unexpected disconnect, seemingly sending no
	   "status" or "command complete". Forcing async transfers makes it work
	   together flawlessly with the wd33c93. Of course, preferable would be, to
	   implement wd33c93's "resume command" stuff, but that probably will not
	   come soon.)
	2) ...
	...

	========================================================================
	--- dc7bdc97927ea1c519f0d8bd3133739600c841d4/drivers/scsi/sgiwd93.c	Sat Oct  7 00:00:00 2006
	+++ new/drivers/scsi/sgiwd93.c	Sun Feb 11 22:10:06 2007
	@@ -250,3 +250,3 @@

	-	hdata->wh.no_sync = 0;
	+	if (0xff == hdata->wh.no_sync) hdata->wh.no_sync = 0;

	========================================================================
	...

On Fri, 21 Mar 2008, Thomas Bogendoerfer wrote:

> Date: Fri, 21 Mar 2008 22:25:43 +0100 (CET)
> From: Thomas Bogendoerfer <[email-masked]>
> To: [email-masked], [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: [PATCH] WD33C93: let platform stub override no_sync/fast/dma_mode
>
> ...
> ...

---

From: peter fuerst <[email-masked]>
Date: Fri, 21 Mar 2008 23:28:59 +0100 (CET)

Oops, forget it, i just missed the change in wd33c93.c, sorry.

kind regrads

peter

On Fri, 21 Mar 2008, peter fuerst wrote:

> Date: Fri, 21 Mar 2008 23:20:07 +0100 (CET)
> To: Thomas Bogendoerfer <[email-masked]>
> Cc: [email-masked], [email-masked],
>      [email-masked], [email-masked]
> Subject: Re: [PATCH] WD33C93: let platform stub override
>     no_sync/fast/dma_mode
>
>
> Hi Thomas,
>
> the code-sequence
> ...

---

From: [email-masked] (Thomas Bogendoerfer)
Date: Sat, 22 Mar 2008 00:04:24 +0100

> "nosync" from the command-line!

this hack is IMHO no longer needed. If the user wants to override no_sync
via kernel command line, it works as before. If the user doesn't no_sync
will be 0 (now set in sgiwd93.c before calling wd33c93_init()) and the
driver will try to do sync transfers for all devices. It works like before.
Or did I miss something ?

Thomas

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

---

From: peter fuerst <[email-masked]>
Date: Sat, 22 Mar 2008 00:45:03 +0100 (CET)

On Sat, 22 Mar 2008, Thomas Bogendoerfer wrote:

> Date: Sat, 22 Mar 2008 00:04:24 +0100
> To: peter fuerst <[email-masked]>

It works cleaner than before :-)

> Or did I miss something ?

No. As already said, just forget it, i missed to look at the whole patch in time.