Skip to contentSkip to conversation

sh: use declared coherent memory for dreamcast pci ethernet adapter

PATCH In review Magnus Damm 3 participants 11 messages Jan 24, 2008 – Feb 4, 2008

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sh: use declared coherent memory for dreamcast pci ethernet adapter

sh: use declared coherent memory for dreamcast pci ethernet adapter

This patch makes the dreamcast use the recently added declared coherent memory functions to point out the memory window suitable for dma.

Apart from cleaning up, this gives the dreamcast a proper memory allocator for pci dma memory.

---

 arch/sh/boards/dreamcast/setup.c       |    8 ---
 arch/sh/drivers/pci/Makefile           |    3 -
 arch/sh/drivers/pci/dma-dreamcast.c    |   70 --------------------------------
 arch/sh/drivers/pci/fixups-dreamcast.c |   10 ++++
 4 files changed, 11 insertions(+), 80 deletions(-)
arch/sh/boards/dreamcast/setup.c +0 -8
@@ -33,9 +33,6 @@ extern void aica_time_init(void);
 extern int gapspci_init(void);
 extern int systemasic_irq_demux(int);
 
-void *dreamcast_consistent_alloc(struct device *, size_t, dma_addr_t *, gfp_t);
-int dreamcast_consistent_free(struct device *, size_t, void *, dma_addr_t);
-
 static void __init dreamcast_setup(char **cmdline_p)
 {
 	int i;
@@ -64,9 +61,4 @@ static struct sh_machine_vector mv_dream
 	.mv_name		= "Sega Dreamcast",
 	.mv_setup		= dreamcast_setup,
 	.mv_irq_demux		= systemasic_irq_demux,
-
-#ifdef CONFIG_PCI
-	.mv_consistent_alloc	= dreamcast_consistent_alloc,
-	.mv_consistent_free	= dreamcast_consistent_free,
-#endif
 };
arch/sh/drivers/pci/Makefile +1 -2
@@ -12,8 +12,7 @@ obj-$(CONFIG_CPU_SUBTYPE_SH7780)	+= pci-
 obj-$(CONFIG_CPU_SUBTYPE_SH7785)	+= pci-sh7780.o ops-sh4.o
 obj-$(CONFIG_CPU_SH5)			+= pci-sh5.o ops-sh5.o
 
-obj-$(CONFIG_SH_DREAMCAST)		+= ops-dreamcast.o fixups-dreamcast.o \
-					   dma-dreamcast.o
+obj-$(CONFIG_SH_DREAMCAST)		+= ops-dreamcast.o fixups-dreamcast.o
 obj-$(CONFIG_SH_SECUREEDGE5410)		+= ops-snapgear.o
 obj-$(CONFIG_SH_RTS7751R2D)		+= ops-rts7751r2d.o fixups-rts7751r2d.o
 obj-$(CONFIG_SH_SH03)			+= ops-sh03.o fixups-sh03.o
arch/sh/drivers/pci/dma-dreamcast.c deleted +0 -70

70 lines not on this page · raw message

arch/sh/drivers/pci/fixups-dreamcast.c +10 -0
@@ -22,6 +22,7 @@
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/pci.h>
+#include <linux/dma-mapping.h>
 
 #include <asm/io.h>
 #include <asm/irq.h>
@@ -40,6 +41,15 @@ static void __init gapspci_fixup_resourc
 		 */
 		dev->resource[1].start	= p->io_resource->start  + 0x100;
 		dev->resource[1].end	= dev->resource[1].start + 0x200 - 1;
+		/*
+		 * Redirect dma memory allocations to special memory window.
+		 */
+		BUG_ON(!dma_declare_coherent_memory(&dev->dev,
+						GAPSPCI_DMA_BASE,
+						GAPSPCI_DMA_BASE,
+						GAPSPCI_DMA_SIZE,
+						DMA_MEMORY_MAP |
+						DMA_MEMORY_EXCLUSIVE));
 		break;
 	default:
 		printk("PCI: Failed resource fixup\n");
#1 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

Quoted 9 lines · Magnus Damm

sh: use declared coherent memory for dreamcast pci ethernet adapter

This patch makes the dreamcast use the recently added declared coherent memory functions to point out the memory window suitable for dma.

Apart from cleaning up, this gives the dreamcast a proper memory allocator for pci dma memory.

I get this now:

[    2.894858] IP-Config: Failed to open eth0
[    2.898395] IP-Config: No network devices available.

So it appears, on first blush, that the patch breaks the driver. I'll test further to confirm.

#2 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

In reply to Magnus Damm
Quoted 12 lines · Adrian McMenamin
Quoted 9 lines · Magnus Damm

sh: use declared coherent memory for dreamcast pci ethernet adapter

This patch makes the dreamcast use the recently added declared coherent memory functions to point out the memory window suitable for dma.

Apart from cleaning up, this gives the dreamcast a proper memory allocator for pci dma memory.

Quoted 8 lines

I get this now:

[    2.894858] IP-Config: Failed to open eth0
[    2.898395] IP-Config: No network devices available.

So it appears, on first blush, that the patch breaks the driver. I'll test further to confirm.

I can confirm that the patches:

f838a96ef5cdc261cb458b154e79b259688008b8
b82c3460d4a2d86cdac80e178a76f3833f1aecba
1b0a4750bf70d0e6f1b4ef573b1231530b9891be

all need to be reverted as they break the Dreamcast network driver

#3 lore raw
In reply to Magnus Damm
Quoted 22 lines · Adrian McMenamin
Quoted 12 lines · Adrian McMenamin
Quoted 9 lines · Magnus Damm

sh: use declared coherent memory for dreamcast pci ethernet adapter

This patch makes the dreamcast use the recently added declared coherent memory functions to point out the memory window suitable for dma.

Apart from cleaning up, this gives the dreamcast a proper memory allocator for pci dma memory.

Quoted 8 lines

I get this now:

[    2.894858] IP-Config: Failed to open eth0
[    2.898395] IP-Config: No network devices available.

So it appears, on first blush, that the patch breaks the driver. I'll test further to confirm.

Quoted 7 lines

I can confirm that the patches:

f838a96ef5cdc261cb458b154e79b259688008b8
b82c3460d4a2d86cdac80e178a76f3833f1aecba
1b0a4750bf70d0e6f1b4ef573b1231530b9891be

all need to be reverted as they break the Dreamcast network driver

Hi Adrian,

Thanks for testing and sorry about breaking the dreamcast ethernet driver. We do need declared coherent memory support for the sm501 chip and there shouldn't be any problems with using that interface for the dreamcast. At least in theory. =)

I did unfortunately introduce a generic bug with the declared coherent memory V2 patch yesterday, but I've posted a fix for that earlier today. I don't however think that fix will help you. What you're seeing seems to be that IP-config doesn't work which hints that packet data isn't transferred as it should. And in your case it's most likely because some virtual address or dma handle isn't setup properly.

The main thing here is that dma_alloc_coherent() should return the same virtual address and dma handle regardless if my coherent patches are applied. Or the values should at least be sane.

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

drivers/net/8139too.c +9 -0
@@ -1311,6 +1311,15 @@ static int rtl8139_open (struct net_devi
 					   &tp->tx_bufs_dma, GFP_KERNEL);
 	tp->rx_ring = dma_alloc_coherent(&tp->pci_dev->dev, RX_BUF_TOT_LEN,
 					   &tp->rx_ring_dma, GFP_KERNEL);
+
+	printk("zzzzzzzz:"
+	       "tx_bufs = 0x%08lx/0x%08lx, "
+	       "rx_ring = 0x%08lx/0x%08lx, "
+	       "(0x%08lx)\n",
+	       (unsigned long)tp->tx_bufs, (unsigned long)tp->tx_bufs_dma,
+	       (unsigned long)tp->rx_ring, (unsigned long)tp->rx_ring_dma,
+	       (unsigned long)tp->pci_dev->dev.dma_mem);
+
 	if (tp->tx_bufs == NULL || tp->rx_ring == NULL) {
 		free_irq(dev->irq, dev);
 
#4 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

In reply to Magnus Damm
Quoted 7 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring 0xa1842000/0x01842000, (0x00000000)
[    0.000000] Linux version 2.6.24-rc8-g96010b55-dirty (adrian@bossclass) (gcc version 3.4.6) #325 PREEMPT Fri Jan 25 20:55:23 GMT 2008
[    0.000000] console [sercon0] enabled
[    0.000000] Booting machvec: Sega Dreamcast
[    0.000000] Node 0: start_pfn = 0xc000, low = 0xd000
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal      49152 ->    53248
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:    49152 ->    53248
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 4064
[    0.000000] Kernel command line: root=/dev/nfs rw nfsroot2.168.61.50:/home/adrian/debdist ip=dhcp earlyprintk=serial video=pvr2fb:640x480-32@60 consol7
[    0.000000] PID hash table entries: 64 (order: 6, 256 bytes)
[    0.000000] Using tmu for system timer
[    0.004322] Using 12.469 MHz high precision timer.
[    0.010042] Console: colour dummy device 80x25
[    0.015260] Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.023141] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.032852] Memory: 13492k/16384k available (1907k kernel code, 632k data, 96k init)
[    0.041763] PVR0205c1 CVR000000 PRR000000
[    0.047277] I-cache : n_ways=1 n_sets%6 way_incr�92
[    0.053284] I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
[    0.061475] D-cache : n_ways=1 n_setsQ2 way_incr384
[    0.067580] D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
[    0.075997] SLUB: Genslabs=9, HWalign2, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
[    0.175560] Mount-cache hash table entries: 512
[    0.181822] CPU: SH7750
[    0.188425] net_namespace: 64 bytes
[    0.195981] NET: Registered protocol family 16
[    0.218402] Maple bus core now registered.
[    0.223419] DMA: Registering DMA API.
[    0.227713] DMA: Registering sh_dmac handler (4 channels).
[    0.237179] DMA: Registering pvr2_dmac handler (1 channel).
[    0.245030] DMA: Registering g2_dmac handler (4 channels).
[    0.254340] Autoconfig PCI channel 0x8c278530
[    0.259497] Scanning bus 00, I/O 0x01001600:0x01003600, Mem 0x01840000:0x01848000
[    0.268201] 00:00.0 Class 0200: 11db:1234 (rev 10)
[    0.273749]         I/O at 0x01001600 [size=0x100]
[    0.279483]         Mem at 0x01840000 [size=0x100]
[    0.285923] PCI: Fixing up device 0000:00:00.0
[    0.310760] Time: SuperH clocksource has been installed.
[    0.321218] NET: Registered protocol family 2
[    0.363178] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.373744] TCP established hash table entries: 512 (order: 0, 4096 bytes)
[    0.381772] TCP bind hash table entries: 512 (order: -1, 2048 bytes)
[    0.389184] TCP: Hash tables configured (established 512 bind 512)
[    0.396293] TCP reno registered
[    0.411663] sq: Registering store queue API.
[    0.418456] cpufreq: SuperH CPU frequency driver.
[    0.423949] cpufreq: clock framework rate rounding not supported on this CPU.
[    0.435453] Total HugeTLB memory allocated, 0
[    0.442081] io scheduler noop registered
[    0.446662] io scheduler anticipatory registered (default)
[    1.578357] Console: switching to colour frame buffer device 80x30
[    1.637402] fb0: NEC PowerVR2 (rev 1.1) frame buffer device, using 1200k/8192k of video memory
[    1.647303] fb0: Mode 640x480-32 pitch = 2560 cable: VGA video output: VGA
[    1.655257] fb0: registering with SQ API
[    1.660102] sqremap:    NEC PowerVR2  [2048 pages]  va 0xe0000000   pa 0xa5000000
[    1.668709] fb0: Mapped video memory to SQ addr 0xe0000000
[    2.232603] SuperH SCI(F) driver initialized
[    2.238353] sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
[    2.246417] sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
�k�  2.253707] console handover: boot [sercon0] -> real [ttySC1]
[    2.261322] sh-sci sh-sci: CPU frequency notifier registered
[    2.267290] 8139too Fast Ethernet driver 0.9.28
[    2.274966] eth0: RealTek RTL8139 at 0xa1001700, 00:d0:f1:03:12:b9, IRQ 83
[    2.282232] Dreamcast_keyboard: probe of 0:0.port failed with error -22
[    2.288540] Dreamcast_keyboard: probe of 1:0.port failed with error -22
[    2.295327] Dreamcast_keyboard: probe of 2:0.port failed with error -22
[    2.302148] Dreamcast_keyboard: probe of 3:0.port failed with error -22
[    2.308991] TCP cubic registered
[    2.312239] NET: Registered protocol family 1
[    2.316745] NET: Registered protocol family 17
[    2.322042] RPC: Registered udp transport module.
[    2.326201] RPC: Registered tcp transport module.
[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0xa1842000/0x01842000, (0x00000000)
[    2.842145] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[    3.848013] Sending DHCP requests ., OK
[    3.867949] IP-Config: Got DHCP answer from 192.168.61.50, my address is 192.168.61.55
[    3.876893] IP-Config: Complete:
[    3.879289]       device=eth0, addr2.168.61.55, mask%5.255.255.224, gw2.168.61.50,
[    3.887844]      host2.168.61.55, domain=, nis-domain=(none),
[    3.893976]      bootserver2.168.61.50, rootserver2.168.61.50, rootpath[    3.902331] Looking up port of RPC 100003/2 on 192.168.61.50
[    3.912680] Looking up port of RPC 100005/1 on 192.168.61.50
[    3.953472] VFS: Mounted root (nfs filesystem).
[    3.958001] Freeing unused kernel memory: 96k freed

-
To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#5 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

In reply to Magnus Damm
Quoted 6 lines · Adrian McMenamin
Quoted 4 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Quoted 7 lines
Quoted 3 lines

Thank you.

/ magnus

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

dreamy login: �[ 0.000000] Linux version 2.6.24-rc8-g3f58465d-dirty (adrian@bossclass) (gcc version 3.4.6) #326 PREEMPT Fri Jan 25 21:43:31 GMT 2008

[    0.000000] console [sercon0] enabled
[    0.000000] Booting machvec: Sega Dreamcast
[    0.000000] Node 0: start_pfn = 0xc000, low = 0xd000
[    0.000000] Zone PFN ranges:
[    0.000000]   Normal      49152 ->    53248
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:    49152 ->    53248
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 4064
[    0.000000] Kernel command line: root=/dev/nfs rw nfsroot2.168.61.50:/home/adrian/debdist ip=dhcp earlyprintk=serial video=pvr2fb:640x480-32@60 consol7
[    0.000000] PID hash table entries: 64 (order: 6, 256 bytes)
[    0.000000] Using tmu for system timer
[    0.004317] Using 12.469 MHz high precision timer.
[    0.010038] Console: colour dummy device 80x25
[    0.015264] Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.023145] Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.032828] Memory: 13492k/16384k available (1907k kernel code, 632k data, 96k init)
[    0.041737] PVR0205c1 CVR000000 PRR000000
[    0.047252] I-cache : n_ways=1 n_sets%6 way_incr�92
[    0.053261] I-cache : entry_mask=0x00001fe0 alias_mask=0x00001000 n_aliases=2
[    0.061449] D-cache : n_ways=1 n_setsQ2 way_incr384
[    0.067556] D-cache : entry_mask=0x00003fe0 alias_mask=0x00003000 n_aliases=4
[    0.075993] SLUB: Genslabs=9, HWalign2, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
[    0.175612] Mount-cache hash table entries: 512
[    0.181888] CPU: SH7750
[    0.188400] net_namespace: 64 bytes
[    0.195963] NET: Registered protocol family 16
[    0.218251] Maple bus core now registered.
[    0.223390] DMA: Registering DMA API.
[    0.227711] DMA: Registering sh_dmac handler (4 channels).
[    0.234246] Maple bus at (0, 0): Connected function 0x1
[    0.240286] No maple driver found for this device
[    0.246516] Maple bus at (1, 0): Connected function 0x40
[    0.252651] No maple driver found for this device
[    0.259225] No maple devices attached to port 2
[    0.264485] No maple devices attached to port 3
[    0.271997] DMA: Registering pvr2_dmac handler (1 channel).
[    0.279888] DMA: Registering g2_dmac handler (4 channels).
[    0.289247] Autoconfig PCI channel 0x8c278530
[    0.294387] Scanning bus 00, I/O 0x01001600:0x01003600, Mem 0x01840000:0x01848000
[    0.303027] Maple bus at (0, 1): Connected function 0xE
[    0.309065] No maple driver found for this device
[    0.314888] 00:00.0 Class 0200: 11db:1234 (rev 10)
[    0.320438]         I/O at 0x01001600 [size=0x100]
[    0.325984]         Mem at 0x01840000 [size=0x100]
[    0.332308] Maple bus at (0, 2): Connected function 0x10
[    0.338442] No maple driver found for this device
[    0.344736] PCI: Fixing up device 0000:00:00.0
[    0.366638] Time: SuperH clocksource has been installed.
[    0.376928] NET: Registered protocol family 2
[    0.419080] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.429569] TCP established hash table entries: 512 (order: 0, 4096 bytes)
[    0.437609] TCP bind hash table entries: 512 (order: -1, 2048 bytes)
[    0.445045] TCP: Hash tables configured (established 512 bind 512)
[    0.452150] TCP reno registered
[    0.467588] sq: Registering store queue API.
[    0.474363] cpufreq: SuperH CPU frequency driver.
[    0.479926] cpufreq: clock framework rate rounding not supported on this CPU.
[    0.491474] Total HugeTLB memory allocated, 0
[    0.498290] io scheduler noop registered
[    0.502845] io scheduler anticipatory registered (default)
[    1.640505] Console: switching to colour frame buffer device 80x30
[    1.700596] fb0: NEC PowerVR2 (rev 1.1) frame buffer device, using 1200k/8192k of video memory
[    1.710566] fb0: Mode 640x480-32 pitch = 2560 cable: VGA video output: VGA
[    1.718540] fb0: registering with SQ API
[    1.723397] sqremap:    NEC PowerVR2  [2048 pages]  va 0xe0000000   pa 0xa5000000
[    1.732097] fb0: Mapped video memory to SQ addr 0xe0000000
[    2.296084] SuperH SCI(F) driver initialized
[    2.301844] sh-sci: ttySC0 at MMIO 0xffe00000 (irq = 25) is a sci
[    2.309935] sh-sci: ttySC1 at MMIO 0xffe80000 (irq = 43) is a scif
�k�  2.317207] console handover: boot [sercon0] -> real [ttySC1]
[    2.324926] sh-sci sh-sci: CPU frequency notifier registered
[    2.330778] 8139too Fast Ethernet driver 0.9.28
[    2.338340] eth0: RealTek RTL8139 at 0xa1001700, 00:d0:f1:03:12:b9, IRQ 83
[    2.346804] input: Keyboard as /devices/maple/1:00.40/input/input0
[    2.367072] TCP cubic registered
[    2.369682] NET: Registered protocol family 1
[    2.374272] NET: Registered protocol family 17
[    2.379687] RPC: Registered udp transport module.
[    2.383910] RPC: Registered tcp transport module.
[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)
[    2.899672] IP-Config: Failed to open eth0
[    2.903757] IP-Config: No network devices available.
[    2.909606] Looking up port of RPC 100003/2 on 192.168.61.50

-
To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#6 lore raw
In reply to Magnus Damm

Adrian,

Thanks for testing and posting the results.

Quoted 12 lines · Adrian McMenamin
Quoted 10 lines · Adrian McMenamin
Quoted 7 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

Quoted 7 lines
Quoted 3 lines

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

Ok, it looks like i got the dma values right at least, but that the rx ring allocation fails.

The amount of dma memory for the dreamcast ethernet adapter seems to be 8 pages (32k), and for dreamcast the 8139too driver allocates 2 pages (4*1536) for tx and 5 pages (16k+16+2048) for rx. It all adds up to 7 pages (tx+rx) which in theory should fit within 8 pages of available dma memory.

It does however look like the bitmap code operates on order granularity both when it comes to size and alignment which means that the rx allocation of 5 pages becomes an order 3 allocation - 8 pages aligned to 8 pages - which in turn results in that we can't fulfill the allocation request. At least that's my theory. =)

As a test and/or workaround, can you try changing RX_BUF_IDX in 8139too.c from 1 in the dreamcast case to 0? That should result in 3 pages for the rx buffer which should lead to an order 2 allocation unless I'm mistaken. And we should be able to fulfill that request without problems.

Does the RX_BUF_IDX change make the declared coherent patches work?

Thank you!

/ magnus

#7 lore raw
In reply to Magnus Damm
Quoted 37 lines · Magnus Damm
Quoted 12 lines · Adrian McMenamin
Quoted 10 lines · Adrian McMenamin
Quoted 7 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

Quoted 7 lines
Quoted 3 lines

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > > > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

Ok, it looks like i got the dma values right at least, but that the rx ring allocation fails.

The amount of dma memory for the dreamcast ethernet adapter seems to be 8 pages (32k), and for dreamcast the 8139too driver allocates 2 pages (4*1536) for tx and 5 pages (16k+16+2048) for rx. It all adds up to 7 pages (tx+rx) which in theory should fit within 8 pages of available dma memory.

It does however look like the bitmap code operates on order granularity both when it comes to size and alignment which means that the rx allocation of 5 pages becomes an order 3 allocation - 8 pages aligned to 8 pages - which in turn results in that we can't fulfill the allocation request. At least that's my theory. =)

Quoted 8 lines

As a test and/or workaround, can you try changing RX_BUF_IDX in 8139too.c from 1 in the dreamcast case to 0? That should result in 3 pages for the rx buffer which should lead to an order 2 allocation unless I'm mistaken. And we should be able to fulfill that request without problems.

Does the RX_BUF_IDX change make the declared coherent patches work?

Adrian? It would be nice to know if dropping RX_BUF_IDX works for you. The other alternative is to break this down on to a single page boundary, but that requires that we change the bitmap management approach away from order-granularity. I've hacked together some changes in the bitmap API to handle this as a proof of concept, so at least it's doable, and it may make sense to try and extend the API in this way in the future.

#8 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

In reply to Magnus Damm
Quoted 41 lines · Magnus Damm

Adrian,

Thanks for testing and posting the results.

Quoted 12 lines · Adrian McMenamin
Quoted 10 lines · Adrian McMenamin
Quoted 7 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

Quoted 7 lines
Quoted 3 lines

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > > > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

Ok, it looks like i got the dma values right at least, but that the rx ring allocation fails.

The amount of dma memory for the dreamcast ethernet adapter seems to be 8 pages (32k), and for dreamcast the 8139too driver allocates 2 pages (4*1536) for tx and 5 pages (16k+16+2048) for rx. It all adds up to 7 pages (tx+rx) which in theory should fit within 8 pages of available dma memory.

It does however look like the bitmap code operates on order granularity both when it comes to size and alignment which means that the rx allocation of 5 pages becomes an order 3 allocation - 8 pages aligned to 8 pages - which in turn results in that we can't fulfill the allocation request. At least that's my theory. =)

Quoted 8 lines

As a test and/or workaround, can you try changing RX_BUF_IDX in 8139too.c from 1 in the dreamcast case to 0? That should result in 3 pages for the rx buffer which should lead to an order 2 allocation unless I'm mistaken. And we should be able to fulfill that request without problems.

Does the RX_BUF_IDX change make the declared coherent patches work?

I am afraid the short answer is "no".

[    2.749341] eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
[    3.756113] Sending DHCP requests .<3>eth0: PCI Bus error 2200.
[    3.760108] eth0: PCI Bus error 2200.
[    3.764106] eth0: PCI Bus error 2200.
[    3.768130] eth0: PCI Bus error 2200.
[    3.772120] eth0: PCI Bus error 2200.
[    3.776112] eth0: PCI Bus error 2200.
[    3.780113] eth0: PCI Bus error 2200.
[    3.784113] eth0: PCI Bus error 2200.
[    3.788090] eth0: PCI Bus error 2200.
[    3.791806] eth0: PCI Bus error 2200.
[    3.792113] eth0: PCI Bus error 2200.
[    3.796113] eth0: PCI Bus error 2200.
[    3.800118] eth0: PCI Bus error 2200.
[    3.804117] eth0: PCI Bus error 2200.
[    3.808113] eth0: PCI Bus error 2200.
[    3.812113] eth0: PCI Bus error 2200.
[    3.816113] eth0: PCI Bus error 2200.
[    3.820122] eth0: PCI Bus error 2200.
[    3.824113] eth0: PCI Bus error 2200.
[    3.828113] eth0: PCI Bus error 2200.
[    3.832113] eth0: PCI Bus error 2200.
[    3.836118] eth0: PCI Bus error 2200.
[    3.840117] eth0: PCI Bus error 2200.
[    3.844114] eth0: PCI Bus error 2200.
[    3.848113] eth0: PCI Bus error 2200.
[    3.852113] eth0: PCI Bus error 2200.
[    3.856122] eth0: PCI Bus error 2200.
[    3.859835] eth0: PCI Bus error 2200.
[    3.860114] eth0: PCI Bus error 2200.
[    3.864114] eth0: PCI Bus error 2200.
[    3.868122] eth0: PCI Bus error 2200.
[    3.872114] eth0: PCI Bus error 2200.
[    3.876114] eth0: PCI Bus error 2200.
[    3.880114] eth0: PCI Bus error 2200.
[    3.884119] eth0: PCI Bus error 2200.
[    3.888118] eth0: PCI Bus error 2200.
[    3.892114] eth0: PCI Bus error 2200.
[    3.896114] eth0: PCI Bus error 2200.
[    3.900114] eth0: PCI Bus error 2200.
[    3.904123] eth0: PCI Bus error 2200.
[    3.908114] eth0: PCI Bus error 2200.
[    3.912115] eth0: PCI Bus error 2200.
[    3.916115] eth0: PCI Bus error 2200.
[    3.920120] eth0: PCI Bus error 2200.
[    3.924119] eth0: PCI Bus error 2200.
[    3.928114] eth0: PCI Bus error 2200.

And so on, seemingly for ever.

#9 lore raw

Re: [PATCH] sh: use declared coherent memory for dreamcast pci

In reply to Magnus Damm
Quoted 42 lines · Adrian McMenamin
Quoted 41 lines · Magnus Damm

Adrian,

Thanks for testing and posting the results.

Quoted 12 lines · Adrian McMenamin
Quoted 10 lines · Adrian McMenamin
Quoted 7 lines · Magnus Damm

Can you please apply the attached patch and test both with and without the 3 declared coherent patches? I'd like to see the values printed out by printk() both with and without the declared coherent patches.

Thank you.

/ magnus

Quoted 7 lines
Quoted 3 lines

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > > > > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

Ok, it looks like i got the dma values right at least, but that the rx ring allocation fails.

The amount of dma memory for the dreamcast ethernet adapter seems to be 8 pages (32k), and for dreamcast the 8139too driver allocates 2 pages (4*1536) for tx and 5 pages (16k+16+2048) for rx. It all adds up to 7 pages (tx+rx) which in theory should fit within 8 pages of available dma memory.

It does however look like the bitmap code operates on order granularity both when it comes to size and alignment which means that the rx allocation of 5 pages becomes an order 3 allocation - 8 pages aligned to 8 pages - which in turn results in that we can't fulfill the allocation request. At least that's my theory. =)

Quoted 8 lines
Quoted 8 lines

As a test and/or workaround, can you try changing RX_BUF_IDX in 8139too.c from 1 in the dreamcast case to 0? That should result in 3 pages for the rx buffer which should lead to an order 2 allocation unless I'm mistaken. And we should be able to fulfill that request without problems.

Does the RX_BUF_IDX change make the declared coherent patches work?

OK, I redid this with the latest patch - which went into Paul's git repo a couple of days ago and it works. The earlier error was with the patches that were about a fortnight old.

#10 lore raw
In reply to Magnus Damm
Quoted 32 lines · Adrian McMenamin
Quoted 31 lines · Adrian McMenamin
Quoted 30 lines · Magnus Damm
Quoted 7 lines · Adrian McMenamin
Quoted 3 lines · Adrian McMenamin

Without the coherency patches...

[    2.833387] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring > > > > > 0xa1842000/0x01842000, (0x00000000)

With the coherency patches...

[    2.890870] zzzzzzzz:tx_bufs = 0xa1840000/0x01840000, rx_ring = 0x00000000/0x00000000, (0x8cd010e0)

Ok, it looks like i got the dma values right at least, but that the rx ring allocation fails.

The amount of dma memory for the dreamcast ethernet adapter seems to be 8 pages (32k), and for dreamcast the 8139too driver allocates 2 pages (4*1536) for tx and 5 pages (16k+16+2048) for rx. It all adds up to 7 pages (tx+rx) which in theory should fit within 8 pages of available dma memory.

It does however look like the bitmap code operates on order granularity both when it comes to size and alignment which means that the rx allocation of 5 pages becomes an order 3 allocation - 8 pages aligned to 8 pages - which in turn results in that we can't fulfill the allocation request. At least that's my theory. =)

As a test and/or workaround, can you try changing RX_BUF_IDX in 8139too.c from 1 in the dreamcast case to 0? That should result in 3 pages for the rx buffer which should lead to an order 2 allocation unless I'm mistaken. And we should be able to fulfill that request without problems.

Quoted 5 lines
Quoted 1 line
Quoted 1 line

Does the RX_BUF_IDX change make the declared coherent patches work?

OK, I redid this with the latest patch - which went into Paul's git repo a couple of days ago and it works. The earlier error was with the patches that were about a fortnight old.

Thanks for the help with the testing. Feel free to send a fixed version of your patch to the 8139too maintainers!

/ magnus