Subject: floppy DMA

From: Philip Blundell <[email-masked]>
Date: Mon, 08 Feb 1999 20:25:21 +0000

Hi,

It seems to me that the code we use for floppy pseudo-DMA at the moment is 
unnecessarily complicated.  Although I don't claim to be an expert in these 
matters it appears that something like the attached patch might be better.  
I've tested this briefly on my A5000 and it doesn't seem to have any 
detrimental effects.

What do you think?

p.

--- clean/linux/arch/arm/lib/floppydma.S	Mon Feb  8 19:09:15 1999
+++ linux/arch/arm/lib/floppydma.S	Mon Feb  8 19:10:42 1999
@@ -2,6 +2,7 @@
  * linux/arch/arm/lib/floppydma.S
  *
  * Copyright (C) 1995, 1996 Russell King
+ * Copyright (C) 1999 Philip Blundell
  */
 #include <linux/linkage.h>
 #include <asm/assembler.h>
@@ -9,20 +10,14 @@
 
 		.global	SYMBOL_NAME(floppy_fiqin_end)
 ENTRY(floppy_fiqin_start)
-		subs	r9, r9, #1
-		ldrgtb	r12, [r11, #-4]
-		ldrleb	r12, [r11], #0
+		ldrb	r12, [r11], #4
 		strb	r12, [r10], #1
 		subs	pc, lr, #4
 SYMBOL_NAME(floppy_fiqin_end):
 
 		.global	SYMBOL_NAME(floppy_fiqout_end)
 ENTRY(floppy_fiqout_start)
-		subs	r9, r9, #1
-		ldrgeb	r12, [r10], #1
-		movlt	r12, #0
-		strleb	r12, [r11], #0
-		subles	pc, lr, #4
-		strb	r12, [r11, #-4]
+		ldrb	r12, [r10], #1
+		strb	r12, [r11], #4
 		subs	pc, lr, #4
 SYMBOL_NAME(floppy_fiqout_end):
--- clean/linux/arch/arm/kernel/dma-a5k.c	Mon Feb  8 19:09:14 1999
+++ linux/arch/arm/kernel/dma-a5k.c	Mon Feb  8 19:14:30 1999
@@ -39,7 +40,7 @@
 	else {
 		struct pt_regs regs;
 		get_fiq_regs(&regs);
-		return regs.ARM_r9;
+		return ((int)PCIO_FLOPPYDMABASE + 4 - regs.ARM_fp) / 4;
 	}
 	return 0;
 }
@@ -69,9 +70,9 @@
 			return;
 		}
 		memcpy((void *)0x1c, fiqhandler_start, fiqhandler_length);
-		regs.ARM_r9 = dma->buf.length;
 		regs.ARM_r10 = __bus_to_virt(dma->buf.address);
-		regs.ARM_fp = (int)PCIO_FLOPPYDMABASE;
+		regs.ARM_fp = (int)PCIO_FLOPPYDMABASE + 4 
+			- (dma->buf.length * 4);
 		set_fiq_regs(&regs);
 		enable_irq(dma->dma_irq);
 	}
--- clean/linux/arch/arm/kernel/dma-rpc.c	Mon Feb  8 19:09:14 1999
+++ linux/arch/arm/kernel/dma-rpc.c	Mon Feb  8 19:18:08 1999
@@ -226,7 +226,7 @@
 	case DMA_VIRTUAL_FLOPPY: {
 		struct pt_regs regs;
 		get_fiq_regs(&regs);
-		return regs.ARM_r9;
+		return ((int)PCIO_FLOPPYDMABASE + 4 - regs.ARM_fp) / 4;
 		}
 		break;
 	}
@@ -276,9 +276,9 @@
 			fiqhandler_length = &floppy_fiqout_end - &floppy_fiqout_start;
 		}
 
-		regs.ARM_r9  = dma->buf.length;
 		regs.ARM_r10 = __bus_to_virt(dma->buf.address);
-		regs.ARM_fp  = (int)PCIO_FLOPPYDMABASE;
+		regs.ARM_fp = (int)PCIO_FLOPPYDMABASE + 4 
+			- (dma->buf.length * 4);
 
 		if (claim_fiq(&fh)) {
 			printk("floppydma: couldn't claim FIQ.\n");

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 8 Feb 1999 23:11:39 +0000 (GMT)

> I've tested this briefly on my A5000 and it doesn't seem to have any 

Interesting, but can it cope with a complete track of the disk?  I seem to
remember that the floppy driver does do this from time to time, and this
is larger than the DMA area.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 09 Feb 1999 09:18:24 +0000

>is larger than the DMA area.

Ah, I didn't realise that.  I imagine that's not the common case though, and 
we could handle it differently in the last resort.  Or maybe the floppy driver 
can be prevented from doing this.  I'll take a look when I have time.

p.

---

From: "Dr . David Alan Gilbert" <[email-masked]>
Date: Tue, 09 Feb 1999 11:15:04 +0000

>can be prevented from doing this.  I'll take a look when I have time.

I'm not sure - but on Linux/x86 the floppy driver reads a whole track
and buffers it - I can't remember if thats still in there or was removed
to save RAM on ARM.

Dave

---

From: Paul Koning <[email-masked]>
Date: Tue, 9 Feb 1999 10:46:05 -0500

>>>>> "Philip" == Philip Blundell <[email-masked]> writes:

 >> Interesting, but can it cope with a complete track of the disk?  I
 >> seem to remember that the floppy driver does do this from time to
 >> time, and this is larger than the DMA area.

 Philip> Ah, I didn't realise that.  I imagine that's not the common
 Philip> case though, and we could handle it differently in the last
 Philip> resort.  Or maybe the floppy driver can be prevented from
 Philip> doing this.  I'll take a look when I have time.

Don't know about common, but applications that want to do high speed
floppy I/O are likely to do such a thing.  I have one that hasn't yet
been upgraded to do this, but will be when I can.

	paul

---

From: "Dr . David Alan Gilbert" <[email-masked]>
Date: Tue, 09 Feb 1999 16:27:43 +0000

>been upgraded to do this, but will be when I can.

Hmm - 'floppy' and 'high speed' in the same sentance - can someone note
that down - it may be a once only occurrence.....

Dave

---

From: Paul Koning <[email-masked]>
Date: Tue, 9 Feb 1999 11:30:49 -0500

>>>>> "David" == David Alan Gilbert <[email-masked]> writes:

 David> At 10:46 AM 2/9/99 -0500, Paul Koning wrote:
 >> Don't know about common, but applications that want to do high
 >> speed floppy I/O are likely to do such a thing.  I have one that
 >> hasn't yet been upgraded to do this, but will be when I can.

 David> Hmm - 'floppy' and 'high speed' in the same sentance - can
 David> someone note that down - it may be a once only occurrence.....

Ok ok... :-)

But if you ever tried block at a time processing vs. track at a time
processing, you'd know.  Perhaps you might use "slow" vs "absurdly
unbelievably slow".

	paul