ISA DMA take 2

ISA DMA take 2

[Adrian Cox]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

Attached is an update to my ISA DMA patch. The main change from the
previous patch is that it works, because it now changes MAX_DMA_ADDRESS.
I've tested it on my platform (Via 686 southbridge, ISA DMA for floppy),
and it shouldn't break any others.

Can somebody please apply this one?

--
Adrian Cox   http://www.humboldt.co.uk/

[-- Attachment #2: dma.patch --]
[-- Type: text/plain, Size: 1318 bytes --]

diff --minimal -Nru a/arch/ppc/mm/init.c b/arch/ppc/mm/init.c
--- a/arch/ppc/mm/init.c	Tue Jan  8 14:59:58 2002
+++ b/arch/ppc/mm/init.c	Tue Jan  8 14:59:58 2002
@@ -440,11 +440,18 @@
 	kmap_prot = PAGE_KERNEL;
 #endif /* CONFIG_HIGHMEM */

-	/*
-	 * All pages are DMA-able so we put them all in the DMA zone.
-	 */
-	zones_size[ZONE_DMA] = total_lowmem >> PAGE_SHIFT;
-	for (i = 1; i < MAX_NR_ZONES; i++)
+    	if (ISA_DMA_THRESHOLD && ISA_DMA_THRESHOLD < total_lowmem - 1)
+	{
+		zones_size[ZONE_DMA] = (ISA_DMA_THRESHOLD + 1) >> PAGE_SHIFT;
+		zones_size[ZONE_NORMAL] =
+			(total_lowmem - ISA_DMA_THRESHOLD - 1) >> PAGE_SHIFT;
+	}
+	else
+	{
+	    	zones_size[ZONE_DMA] = total_lowmem >> PAGE_SHIFT;
+	    	zones_size[ZONE_NORMAL] = 0;
+	}
+	for (i = 2; i < MAX_NR_ZONES; i++)
 		zones_size[i] = 0;

 #ifdef CONFIG_HIGHMEM
diff --minimal -Nru a/include/asm-ppc/dma.h b/include/asm-ppc/dma.h
--- a/include/asm-ppc/dma.h	Tue Jan  8 14:59:58 2002
+++ b/include/asm-ppc/dma.h	Tue Jan  8 14:59:58 2002
@@ -37,8 +37,7 @@
 #endif

 /* The maximum address that we can perform a DMA transfer to on this platform */
-/* Doesn't really apply... */
-#define MAX_DMA_ADDRESS		0xFFFFFFFF
+#define MAX_DMA_ADDRESS		ISA_DMA_THRESHOLD

 /* in arch/ppc/kernel/setup.c -- Cort */
 extern unsigned long DMA_MODE_WRITE, DMA_MODE_READ;

Re: ISA DMA take 2

[Michael Sokolov]

Adrian Cox <adrian@humboldt.co.uk> wrote:

> Attached is an update to my ISA DMA patch. The main change from the
> previous patch is that it works, because it now changes MAX_DMA_ADDRESS.
> I've tested it on my platform (Via 686 southbridge, ISA DMA for floppy),
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> and it shouldn't break any others.

What's your memory map? Do you put the bottom 16 MB of main memory in the
bottom 16 MB of the PCI memory space on the PCI segment with the Via without an
I/O hole?

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ISA DMA take 2

[Adrian Cox]

Michael Sokolov wrote:


> What's your memory map? Do you put the bottom 16 MB of main memory in the
> bottom 16 MB of the PCI memory space on the PCI segment with the Via without an
> I/O hole?

Yes - and I set ISA_DMA_THRESHOLD to 0x00ffffff. It's not possible to
use ISA DMA with the Via southbridge unless you have main memory at 0x0
on the PCI bus.

Of course, if anybody knows a cheap southbridge with 32-bit ISA DMA,
UDMA100, and maybe USB, it would be nice to hear of it for future boards.

--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ISA DMA take 2

[Michael Sokolov]

Adrian Cox <adrian@humboldt.co.uk> wrote:

> Yes - and I set ISA_DMA_THRESHOLD to 0x00ffffff. It's not possible to
> use ISA DMA with the Via southbridge unless you have main memory at 0x0
> on the PCI bus.

As I understand it, you also have to have no I/O hole in the mapping of the
bottom 16 MB of memory onto PCI, right? As I understand it, Linux/PPC is a sane
PPC OS and treats all PPC memory as normal, without any special treatment for
0xA0000-0xFFFFF, so your DMA buffer could legitimately end up in that region
and if your memory map has an I/O hole you would be screwed, right? And of
course main memory on PCI at 0 with no I/O hole means you can't have video on
the same PCI bus... !@#$ing pee sea legacy :(

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ISA DMA take 2

[Adrian Cox]

Michael Sokolov wrote:


> As I understand it, you also have to have no I/O hole in the mapping of the
> bottom 16 MB of memory onto PCI, right? As I understand it, Linux/PPC is a sane
> PPC OS and treats all PPC memory as normal, without any special treatment for
> 0xA0000-0xFFFFF, so your DMA buffer could legitimately end up in that region
> and if your memory map has an I/O hole you would be screwed, right? And of
> course main memory on PCI at 0 with no I/O hole means you can't have video on
> the same PCI bus... !@#$ing pee sea legacy :(


I have two CT69030 VGA chips on the same PCI bus, but I only enable
their PCI memory mapped regions, and never use the legacy VGA addresses.

Linux on this board doesn't hand out memory in the 0xa0000 to 0xfffff
region as DMA buffers, because that range is part of the kernel text
segment.  Linux on i386 explicity removes that range from the memory
map, and for completeness I should probably ensure that those pages are
marked reserved in case a minimal kernel comes below the 1MB barrier.

--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ISA DMA take 2

[Michael Sokolov]

Adrian Cox <adrian@humboldt.co.uk> wrote:

> I have two CT69030 VGA chips on the same PCI bus, but I only enable
> their PCI memory mapped regions, and never use the legacy VGA addresses.

Ahh, I didn't know you could disable legacy VGA address decoding.

MS

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ISA DMA take 2

[Adrian Cox]

Michael Sokolov wrote:

> Adrian Cox <adrian@humboldt.co.uk> wrote:
>>I have two CT69030 VGA chips on the same PCI bus, but I only enable
>>their PCI memory mapped regions, and never use the legacy VGA addresses.
>
> Ahh, I didn't know you could disable legacy VGA address decoding.


You don't need to. You just have to make sure that no legacy VGA address
ever appears on the PCI bus for the device to respond to.

This is quite easy - references by the PowerPC to addresses 0xa0000 to
0xfffff will go to RAM, not to PCI. If buffers for bus-mastering
peripherals are never allocated in that range, then those addresses will
never appear on the PCI bus.

--
Adrian Cox   http://www.humboldt.co.uk/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/