Skip to contentSkip to conversation

net: force PKTALIGN to ARCH_DMA_MINALIGN

PATCH New Eric Nelson 3 participants 7 messages Mar 14, 2012 – Mar 16, 2012 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): http://lists.denx.de/pipermail/u-boot/2012-March/120205.html

Eric Nelson

author
#1 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers.

Signed-off-by Eric Nelson <[email protected]>
---
 include/net.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
include/net.h +2 -1
index e4d42c2..ff428d0 100644
@@ -16,6 +16,7 @@
 #include <commproc.h>
 #endif	/* CONFIG_8xx */
 
+#include <asm/cache.h>
 #include <asm/byteorder.h>	/* for nton* / ntoh* stuff */
 
 

@@ -31,7 +32,7 @@
 # define PKTBUFSRX	4
 #endif
 
-#define PKTALIGN	32
+#define PKTALIGN	ARCH_DMA_MINALIGN
 
 /* IPv4 addresses are always 32 bits in size */
 typedef u32		IPaddr_t;
Signature · 1 line
1.7.9
#3 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

In reply to Eric Nelson

Dear Eric Nelson,

Quoted 21 lines

This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers.

Signed-off-by Eric Nelson <[email protected]>
---
 include/net.h |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
include/net.h +1 -0
index e4d42c2..ff428d0 100644
@@ -16,6 +16,7 @@
 #include <commproc.h>
 #endif	/* CONFIG_8xx */
 
+#include <asm/cache.h>
 #include <asm/byteorder.h>	/* for nton* / ntoh* stuff */

include/net.h line 38

Quoted 8 lines
include/net.h +1 -1
@@ -31,7 +32,7 @@
 # define PKTBUFSRX	4
 #endif
 
-#define PKTALIGN	32
+#define PKTALIGN	ARCH_DMA_MINALIGN
 
 /* IPv4 addresses are always 32 bits in size */
 typedef u32		IPaddr_t;

Won't this break retarded hardware that has ARCH_DMA_MINALIGN smaller than 32 ?

Best regards,
Marek Vasut

#4 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

Quoted 4 lines · On Thursday 15 March 2012 22:50:08 Marek Vasut wrote:

Dear Eric Nelson,

Quoted 3 lines

This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers.

Quoted 8 lines

include/net.h line 35

Quoted 5 lines
include/net.h +1 -1
 
-#define PKTALIGN	32
+#define PKTALIGN	ARCH_DMA_MINALIGN

Won't this break retarded hardware that has ARCH_DMA_MINALIGN smaller than 32 ?

why would it ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120315/6f794f64/attachment.pgp>

#5 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

Dear Mike Frysinger,

Quoted 9 lines · On Thursday 15 March 2012 22:50:08 Marek Vasut wrote:
Quoted 8 lines

Dear Eric Nelson,

Quoted 6 lines

This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers.

include/net.h +0 -0
Quoted 7 lines
Quoted 5 lines

include/net.h line 35

Quoted 2 lines
include/net.h +1 -1
-#define PKTALIGN	32
+#define PKTALIGN	ARCH_DMA_MINALIGN

Won't this break retarded hardware that has ARCH_DMA_MINALIGN smaller than 32 ?

why would it ?

Nevermind.

Best regards,
Marek Vasut

author
#6 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

In reply to Marek Vasut
Quoted 26 lines · Marek Vasut

Dear Eric Nelson,

Quoted 24 lines

This will prevent the need for architectures whose DMA alignment is greater than 32 to have bounce buffers.

Signed-off-by Eric Nelson<[email protected]>
---
  include/net.h |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
include/net.h +1 -0
index e4d42c2..ff428d0 100644
@@ -16,6 +16,7 @@
  #include<commproc.h>
  #endif	/* CONFIG_8xx */
 
+#include<asm/cache.h>
  #include<asm/byteorder.h>	/* for nton* / ntoh* stuff */
 
 

@@ -31,7 +32,7 @@
  # define PKTBUFSRX	4
  #endif
Quoted 8 lines

include/net.h line 38

Quoted 5 lines
include/net.h +1 -1
-#define PKTALIGN	32
+#define PKTALIGN	ARCH_DMA_MINALIGN
 
  /* IPv4 addresses are always 32 bits in size */
  typedef u32		IPaddr_t;

Won't this break retarded hardware that has ARCH_DMA_MINALIGN smaller than 32 ?

I can't see how it would.

This macro is only used for alignment and the PKTSIZE_ALIGN variable should be safe on any architecture at 1536 (0x600) bytes.

I do see a potential problem with eth.c iff CONFIG_API is set, but I'm unfamiliar with this API. It appears to me that this declaration needs to be aligned, with or without the PKTALIGN change or it won't be usable with DMA since PKTSIZE is unlikely to be cache line or DMA friendly at 1518 (0x5EE) bytes.

	static struct {
		uchar data[PKTSIZE];
		int length;
	} eth_rcv_bufs[PKTBUFSRX];

It appears that the CONFIG_API macro is only defined for PMC440. Is this supported for other machines?

Is there some test code available?

Please advise,

Eric

#7 lore raw

PATCH 1/1 net: force PKTALIGN to ARCH_DMA_MINALIGN

Quoted 6 lines · On Thursday 15 March 2012 23:36:34 Eric Nelson wrote:

I do see a potential problem with eth.c iff CONFIG_API is set, but I'm unfamiliar with this API. It appears to me that this declaration needs to be aligned, with or without the PKTALIGN change or it won't be usable with DMA since PKTSIZE is unlikely to be cache line or DMA friendly at 1518 (0x5EE) bytes.

Quoted 7 lines
	static struct {
		uchar data[PKTSIZE];
		int length;
	} eth_rcv_bufs[PKTBUFSRX];

It appears that the CONFIG_API macro is only defined for PMC440. Is this supported for other machines?

CONFIG_API is the new standalone api. it uses a syscall-like approach to maintaining compatibility unlike the current standalone api which breaks easily.

however, this struct is used only internally. the exposed function calls are unchanged. so changing the size of the buffer is OK generally speaking.

there is a slight behavior change though. if you look at the funcs, they only accept buffers that are smaller than PKTSIZE bytes. i'm not sure we care about this detail though. i think the max size you can send is arbitrary and was designed just so you could get a frame's worth of data at a time, so as long as that ceiling isn't violated, it's OK.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120316/d9268c5d/attachment.pgp>