CACHE: Finishing touches
cover CACHE: Finishing touches
Add a few finishing touches for the cache support. Then ultimately enable cache support on m28.
BIG FAT NOTE: This is for -next. This may break something.
Compile testing IS STILL IN PROGRESS!
Marek Vasut (9):
COMMON: Add __stringify() function
CACHE: Add cache_aligned() macro
CACHE: ext2load: Test if start address is aligned
CACHE: fatload: Test if start address is aligned
CACHE: mmc read/write: Test if start address is aligned
CACHE: nand read/write: Test if start address is aligned
CACHE: net: Test if start address is aligned
CACHE: net: asix: Fix asix driver to work with data cache on
M28EVK: Enable instruction and data cache
common/cmd_ext2.c | 3 +++ common/cmd_fat.c | 4 ++++ common/cmd_mmc.c | 2 ++ common/cmd_nand.c | 9 +++++++++ common/cmd_net.c | 4 ++++ drivers/usb/eth/asix.c | 29 ++++++++++++++++------------- include/common.h | 25 +++++++++++++++++++++++++ include/configs/m28evk.h | 2 -- 8 files changed, 63 insertions(+), 15 deletions(-)
Signature · 1 line
1.7.10
PATCH 1/9 COMMON: Add __stringify() function
This function converts static number to string in preprocessor. This is useful as it allows higher usage of puts() in favour of printf()
--- include/common.h | 7 +++++++ 1 file changed, 7 insertions(+)
include/common.h +7 -0
@@ -268,6 +268,13 @@ typedef void (interrupt_handler_t)(void *); const typeof( ((type *)0)->member ) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );}) +/** +* __stringify - preprocessor magic to return string from number +* @x: constant number +*/ +#define __stringify_1(x...) #x +#define __stringify(x...) __stringify_1(x) +/* * Function Prototypes */
Signature · 1 line
1.7.10
PATCH 2/9 CACHE: Add cache_aligned() macro
In reply to Marek VasutThis macro returns 1 if the argument (address) is aligned, returns zero otherwise. This will be used to test user-supplied address to various commands to prevent user from loading data to/from unaligned address when using caches.
This is made as a macro, because macros are expanded where they are used. Therefore it can be easily instrumented to report position of the fault.
--- include/common.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
include/common.h +18 -0
@@ -730,6 +730,24 @@ void invalidate_dcache_range(unsigned long start, unsigned long stop);void invalidate_dcache_all (void );void invalidate_icache_all (void ); +/* Test if address is cache-aligned. Returns 0 if it is, 1 otherwise. */ +#define cacheline_aligned (addr) \ + ({ \ + int __ret; \ + if (!dcache_status()) { \ + __ret = 1; \ + } else if ((addr) & (ARCH_DMA_MINALIGN - 1)) { \ + puts("Align load address to " \ + __stringify(ARCH_DMA_MINALIGN) \ + " bytes when using caches!\n"); \ + __ret = 0; \ + } else { \ + __ret = 1; \ + } \ + __ret; \ + }) + +/* arch/$(ARCH)/lib/ticks.S */ unsigned long long get_ticks (void );void wait_ticks (unsigned long );
Signature · 1 line
1.7.10
PATCH 2/9 CACHE: Add cache_aligned() macro
Quoted 29 lines · Marek Vasut
This macro returns 1 if the argument (address) is aligned, returns zero otherwise. This will be used to test user-supplied address to various commands to prevent user from loading data to/from unaligned address when using caches.
This is made as a macro, because macros are expanded where they are used. Therefore it can be easily instrumented to report position of the fault.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>--- include/common.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)include/common.h +6
-0@@ -730,6 +730,24 @@ void invalidate_dcache_range(unsigned long start, unsigned long stop);void invalidate_dcache_all (void );void invalidate_icache_all (void ); +/* Test if address is cache-aligned. Returns 0 if it is, 1 otherwise. */ +#define cacheline_aligned (addr) \ + ({ \ + int __ret; \ + if (!dcache_status()) { \ + __ret = 1; \
include/common.h void invalidate_dcache_range(unsigned long start, unsigned long stop); · line 748
Quoted 10 lines
include/common.h +10
-0+ }else if ((addr) & (ARCH_DMA_MINALIGN -1 )) { \ + puts("Align load address to " \ + __stringify(ARCH_DMA_MINALIGN) \ +" bytes when using caches!\n" ); \ + __ret =0 ; \ + }else { \ + __ret =1 ; \ + } \ + __ret; \ + })
What if it's a store rather than a load? If this is only supposed to be used for loads (because on a store you can flush the cache rather than invalidate), it's not labelled that way, the changelog says "to/from unaligned address", and the caller might be common code that doesn't know which direction the transfer is in. Besides, it would be awkward user interface to allow an address to be used in one direction but not the other.
What if the caller wants to try a different strategy if this returns 0, rather than print an error?
Why should the success of a command depend on whether caches are enabled? If we're going to forbid unaligned addresses in certain contexts, shouldn't it always be forbidden to ensure consistent user experience? Or if we're going to be picky about when we reject it, why don't we care whether the device in question does DMA, and whether that DMA is coherent?
-Scott
PATCH 2/9 CACHE: Add cache_aligned() macro
Dear Scott Wood,
Quoted 24 lines · Marek Vasut
Quoted 23 lines
This macro returns 1 if the argument (address) is aligned, returns zero otherwise. This will be used to test user-supplied address to various commands to prevent user from loading data to/from unaligned address when using caches.
This is made as a macro, because macros are expanded where they are used. Therefore it can be easily instrumented to report position of the fault.
Signed-off-by Marek Vasut <[email protected]>Cc Wolfgang Denk <[email protected]>---
include/common.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)include/common.h +0
-0@@ -730,6 +730,24 @@ void invalidate_dcache_range(unsigned long start, unsigned long stop);
Quoted 5 lines
include/common.h void invalidate_dcache_range(unsigned long start, unsigned long stop);
Quoted 5 lines
include/common.h +2
-0void invalidate_dcache_all (void );void invalidate_icache_all (void ); +/* Test if address is cache-aligned. Returns 0 if it is, 1 otherwise. */ +#define cacheline_aligned (addr)
\
Quoted 8 lines
Quoted 8 lines
include/common.h +8
-0+ ({ \ + int __ret; \ + if (!dcache_status()) { \ + __ret = 1; \ + } else if ((addr) & (ARCH_DMA_MINALIGN - 1)) { \ + puts("Align load address to " \ + __stringify(ARCH_DMA_MINALIGN) \ + " bytes when using caches!\n"); \
Quoted 8 lines
include/common.h void invalidate_dcache_range(unsigned long start, unsigned long stop); · line 748
Quoted 6 lines
include/common.h +6
-0+ __ret =0 ; \ + }else { \ + __ret =1 ; \ + } \ + __ret; \ + })What if it's a store rather than a load?
Goot point #1
Quoted 5 lines
If this is only supposed to be
used for loads (because on a store you can flush the cache rather than invalidate), it's not labelled that way, the changelog says "to/from unaligned address", and the caller might be common code that doesn't know which direction the transfer is in.
And we're back at the flush/invalidate thing. This is what I'd really love to understand once and for all:
1) We must prevent user from loading to address 0x.......1 (unaligned), I'll get back to this later on.
2) If the user had address that starts at aligned location but ends at unaligned:
Terminology:
va -- unrelated variable
[****] -- aligned range
2a) LOAD from external source to local address:
The cache must be invalidated over that area. I see the following issue:
[---------buffer---------][va]
[********][********][********]
So consider the scenario where
i) va is written in u-boot
ii) data arrive into the buffer via DMA at the same time iii) cache is invalidated over whole buffer
This will cause variable "va" to be lost forever. The "va" variable might as well be user data, therefore in order to protect those, we should first flush the user-supplied area.
2b) STORE from local address to external source:
Basically the inverted problem as in 2a), but if the driver is written properly, shouldn't be any issue.
Quoted 3 lines
Besides, it would be awkward
user interface to allow an address to be used in one direction but not the other.
Correct, it should be possible to adjust the message.
Quoted 2 lines
What if the caller wants to try a different strategy if this returns 0, rather than print an error?
Good point.
Quoted 2 lines
Why should the success of a command depend on whether caches are enabled?
On less capable architectures, flushing caches over unaligned area causes real mayhem (and DMA depends on this) and it's really tough to debug. If the caches are off, it's all good.
Good point is, that this code should be enabled on per-CPU-model basis probably? Or entirely configurable in the include/configs/....
Quoted 3 lines
If we're going to forbid unaligned addresses in certain contexts, shouldn't it always be forbidden to ensure consistent user experience?
This is a good argument ... I wonder, let's hear others opinions.
Quoted 3 lines
Or if we're going to be picky about when we reject it, why don't we care whether the device in question does DMA, and whether that DMA is coherent?
Correct, good point. But then this is something that should be added into the upcomming uboot driver model!
Quoted 1 line
-Scott
Best regards,
Marek Vasut
PATCH 2/9 CACHE: Add cache_aligned() macro
Hi Marek,
Quoted 80 lines · Marek Vasut
Dear Scott Wood,
Quoted 24 lines · Marek Vasut
Quoted 23 lines
This macro returns 1 if the argument (address) is aligned, returns zero otherwise. This will be used to test user-supplied address to various commands to prevent user from loading data to/from unaligned address when using caches.
This is made as a macro, because macros are expanded where they are used. Therefore it can be easily instrumented to report position of the fault.
Signed-off-by Marek Vasut<[email protected]>Cc Wolfgang Denk<[email protected]>---
include/common.h | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)include/common.h +0
-0@@ -730,6 +730,24 @@ void invalidate_dcache_range(unsigned long start, unsigned long stop);Quoted 5 lines
include/common.h void invalidate_dcache_range(unsigned long start, unsigned long stop);
Quoted 5 lines
include/common.h +2
-0void invalidate_dcache_all (void );void invalidate_icache_all (void ); +/* Test if address is cache-aligned. Returns 0 if it is, 1 otherwise. */ +#define cacheline_aligned (addr)\
Quoted 8 lines
Quoted 8 lines
include/common.h +8
-0+ ({ \ + int __ret; \ + if (!dcache_status()) { \ + __ret = 1; \ + } else if ((addr)& (ARCH_DMA_MINALIGN - 1)) { \ + puts("Align load address to " \ + __stringify(ARCH_DMA_MINALIGN) \ + " bytes when using caches!\n"); \Quoted 8 lines
include/common.h void invalidate_dcache_range(unsigned long start, unsigned long stop); · line 748
Quoted 6 lines
include/common.h +6
-0+ __ret =0 ; \ + }else { \ + __ret =1 ; \ + } \ + __ret; \ + })What if it's a store rather than a load?
Goot point #1
Quoted 5 lines
If this is only supposed to be
used for loads (because on a store you can flush the cache rather than invalidate), it's not labelled that way, the changelog says "to/from unaligned address", and the caller might be common code that doesn't know which direction the transfer is in.And we're back at the flush/invalidate thing. This is what I'd really love to understand once and for all:
1) We must prevent user from loading to address 0x.......1 (unaligned), I'll get back to this later on.
2) If the user had address that starts at aligned location but ends at unaligned:
Terminology:
va -- unrelated variable
[****] -- aligned range2a) LOAD from external source to local address:
The cache must be invalidated over that area. I see the following issue:[---------buffer---------][va] [********][********][********]
So consider the scenario where
i) va is written in u-boot
ii) data arrive into the buffer via DMA at the same time iii) cache is invalidated over whole buffer
Quoted 3 lines
This will cause variable "va" to be lost forever. The "va" variable might as well be user data, therefore in order to protect those, we should first flush the user-supplied area.
Flushing the last cache line may corrupt the data you just DMAed in. The current implementation after a lot of discussions [1] with Albert is this:
Invalidate only the aligned part of the buffer. So, in the above case the first two [********] will get invalidated not the last one. The last un-aligned cache line will result in a warning.
[1] http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/105113
Quoted 4 lines
2b) STORE from local address to external source:
Basically the inverted problem as in 2a), but if the driver is written properly, shouldn't be any issue.
No. Store doesn't have any problem because flush doesn't harm anything.
I have laid down the invalidate/flush requirements for DMA buffers in:
doc/README.arm-caches
best regards,
Aneesh
PATCH 3/9 CACHE: ext2load: Test if start address is aligned
In reply to Marek VasutThis prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
--- common/cmd_ext2.c | 3 +++ 1 file changed, 3 insertions(+)
common/cmd_ext2.c +3 -0
@@ -166,6 +166,9 @@ int do_ext2load (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])return CMD_RET_USAGE ; } +if (!cacheline_aligned (addr)) +return 1 ; +if (!filename) {puts ("** No boot file defined **\n" );return 1 ;
Signature · 1 line
1.7.10
PATCH 4/9 CACHE: fatload: Test if start address is aligned
In reply to Marek VasutThis prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
--- common/cmd_fat.c | 4 ++++ 1 file changed, 4 insertions(+)
common/cmd_fat.c +4 -0
@@ -68,7 +68,11 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) argv[1], dev, part);return 1 ; } + offset =simple_strtoul (argv[3 ],NULL ,16 ); +if (!cacheline_aligned (offset)) +return 1 ; +if (argc ==6 ) count =simple_strtoul (argv[5 ],NULL ,16 );else
Signature · 1 line
1.7.10
PATCH 5/9 CACHE: mmc read/write: Test if start address is aligned
In reply to Marek VasutThis prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
--- common/cmd_mmc.c | 2 ++ 1 file changed, 2 insertions(+)
common/cmd_mmc.c +2 -0
@@ -268,6 +268,8 @@ int do_mmcops(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])if (state !=MMC_ERASE ) { addr = (void *)simple_strtoul (argv[idx],NULL ,16 ); +if (!cacheline_aligned ((ulong )addr)) +return 1 ; ++idx; }else addr =0 ;
Signature · 1 line
1.7.10
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
In reply to Marek VasutThis prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
--- common/cmd_nand.c | 9 +++++++++ 1 file changed, 9 insertions(+)
common/cmd_nand.c +9 -0
@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage; addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 ); +if (!cacheline_aligned (addr)) +return 1 ; read =strncmp (cmd,"read" ,4 ) ==0 ;/* 1 = read, 0 = write */ printf ("\nNAND %s: " , read ?"read" :"write" );
@@ -924,6 +926,9 @@ int do_nandboot(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) addr =simple_strtoul (argv[1 ],NULL ,16 ); else addr =CONFIG_SYS_LOAD_ADDR ; +if (!cacheline_aligned (addr)) +return 1 ; +return nand_load_image (cmdtp, &nand_info[dev->id->num], part->offset, addr, argv[0 ]); }
@@ -956,6 +961,10 @@ usage:bootstage_error (BOOTSTAGE_ID_NAND_SUFFIX );return CMD_RET_USAGE ; } + +if (!cacheline_aligned (addr)) +return 1 ; +bootstage_mark (BOOTSTAGE_ID_NAND_SUFFIX );if (!boot_device) {
Signature · 1 line
1.7.10
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the read() and write() system calls to require cacheline alignment. :-P
Quoted 11 lines
Signed-off-by Marek Vasut <[email protected]>Cc Scott Wood <[email protected]>--- common/cmd_nand.c | 9 +++++++++ 1 file changed, 9 insertions(+)common/cmd_nand.c +0
-0
common/cmd_nand.c int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) · line 613
Quoted 5 lines
common/cmd_nand.c +2
-0@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage; addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 ); +if (!cacheline_aligned (addr)) +return 1 ;
There's no way you can just return like this without printing an error that lets the user know that the operation wasn't performed, and why.
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 12 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 5 lines
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
We would need to architect things such that any 'load' command would be routed through this logic. A solvable problem for sure, but a little bit larger than just for NAND :)
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-P
I don't want to get into an ARM vs PowerPC argument. I think the best answer is that I'm not sure having things unaligned works totally right today as I did a silly test of loading a uImage to 0x82000001 and bootm hung inside of U-Boot not long ago. Can you try that on some cache coherent hardware and see if that works?
[snip]
Quoted 9 lines
common/cmd_nand.c int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) · line 613
Quoted 6 lines
common/cmd_nand.c +2
-0@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage; addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 ); +if (!cacheline_aligned (addr)) +return 1 ;There's no way you can just return like this without printing an error that lets the user know that the operation wasn't performed, and why.
Note that cacheline_aligned does the error print (patch 2 of 9).
Signature · 8 lines
Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120625/d9f9ea2b/attachment.pgp>
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 13 lines · Tom Rini
Quoted 12 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 8 lines
Quoted 5 lines
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
We would need to architect things such that any 'load' command would be routed through this logic.
It's something the driver backend should handle (possibly via a common helper library). The fact that you can't do a DMA transfer to an unaligned buffer is a hardware-specific detail, just as is the fact that you're setting up a DMA buffer in the first place.
Quoted 10 lines
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-PI don't want to get into an ARM vs PowerPC argument. I think the best answer is that I'm not sure having things unaligned works totally right today as I did a silly test of loading a uImage to
0x82000001and bootm hung inside of U-Boot not long ago. Can you try that on some cache coherent hardware and see if that works?
I'm not sure what bootm has to do with nand (and the fact that some ppc is cache coherent actually doesn't matter, since we don't do DMA for NAND), but I was able to bootm from an odd RAM address, and "nand read" to an odd RAM address, on p5020ds.
Quoted 4 lines
[snip]
Quoted 3 lines
Quoted 3 lines
common/cmd_nand.c +0
-0@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage;
Quoted 8 lines
Quoted 6 lines
common/cmd_nand.c int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) · line 613
Quoted 3 lines
common/cmd_nand.c +2
-0addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 ); +if (!cacheline_aligned (addr)) +return 1 ;There's no way you can just return like this without printing an error that lets the user know that the operation wasn't performed, and why.
Note that
cacheline_aligneddoes the error print (patch 2 of 9).
Ah. I saw this patch first since it was CCed to me. :-)
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 21 lines · Scott Wood
Quoted 20 lines · Tom Rini
Quoted 18 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
Quoted 7 lines
Quoted 2 lines
We would need to architect things such that any 'load' command would be routed through this logic.
It's something the driver backend should handle (possibly via a common helper library). The fact that you can't do a DMA transfer to an unaligned buffer is a hardware-specific detail, just as is the fact that you're setting up a DMA buffer in the first place.
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
Quoted 12 lines
Quoted 11 lines
Quoted 5 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-PI don't want to get into an ARM vs PowerPC argument. I think the best answer is that I'm not sure having things unaligned works totally right today as I did a silly test of loading a uImage to
0x82000001and bootm hung inside of U-Boot not long ago. Can you try that on some cache coherent hardware and see if that works?
Quoted 4 lines
I'm not sure what bootm has to do with nand (and the fact that some ppc is cache coherent actually doesn't matter, since we don't do DMA for NAND), but I was able to bootm from an odd RAM address, and "nand read" to an odd RAM address, on p5020ds.
On ARM-land we have a lot of problems with unaligned addresses, even with cache off. I went to reproduce the original bootm problem and ran into fatload hanging. tftp didn't fail but bootm hangs.
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP6M6BAAoJENk4IS6UOR1WQXkP/1L0lbnKcpJ5jY9oCyIA29zE r2eNVmsetudSTVC1rbQsmr5qd15xmzdqIi4yGVxOQIj6rj5eAhwRt8W6vRplNlSy zRSFcZTh8YGdmNyLeiSiXFj/sxppIeSwPJqm1b17U7O43W8G4OVh73Ox1s7/YVB+ ag49VFokK0RBjgY8vux3YeJtpbDVTS0ZAmOXkoxLpvQgctttpnyDjoz9nbhfLA9d BjmpVHKKkwKChhIuNyexMXregkZzfVAw9hJ9N3SCv0/x4VylRQBq3QNroHQJdGGq 0H0FRjAz9iLFu/EsHjmvzPgpCWeWgFLeGh1YLWORSZD3M8YlQvj5j6mSUsZjr8Ab DJOyvZRsYgOK+h/+CIPdbGufY0yQfBPJPvzYkhxPAvs8zKkSwVYRm7xqPbSQNxYt uBJh7Xw3M+rGVmqGmd6bERgeFOiL7BV3Jtfd3YaDQmJqiPS4r2nqwAjiDNaVUYlu 9TaxkbyTQl5PyCA+hkiwO4ebnSRgaGLrgnNZfkIuZD0qcpJ3A/Zldos2YXherwPc /azJiitQvRrxxRU8RHEg1vkTOnX4urQi2cfPap+QiTb5KT+Gxrg6UPwBWvsOmDmY MqIsHwgdpZflOOOX9Vco8ViSE44ePYaQDRLNhHbrdCAYEIEOxRIReAHs9YVVO2my 6OzYbd4sBdJDe/wl8s8X
=7znQ
-----END PGP SIGNATURE-----
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 28 lines · Tom Rini
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 24 lines · Scott Wood
Quoted 22 lines · Tom Rini
Quoted 12 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 6 lines
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
We would need to architect things such that any 'load' command would be routed through this logic.
Quoted 8 lines
Quoted 4 lines
It's something the driver backend should handle (possibly via a common helper library). The fact that you can't do a DMA transfer to an unaligned buffer is a hardware-specific detail, just as is the fact that you're setting up a DMA buffer in the first place.
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
OK, so fix it in each driver that has this issue. A lot of drivers are probably not so performance critical that you can't just always use a bounce buffer. A static buffer plus memcpy isn't that burdensome -- it's close to what the drivers for non-DMA hardware do. For higher performance peripherals, throw in an if-statement or two. It doesn't seem like something that needs a U-Boot-wide change.
In the specific case of NAND, how many NAND drivers use DMA at all?
Quoted 8 lines
Quoted 4 lines
I'm not sure what bootm has to do with nand (and the fact that some ppc is cache coherent actually doesn't matter, since we don't do DMA for NAND), but I was able to bootm from an odd RAM address, and "nand read" to an odd RAM address, on p5020ds.
On ARM-land we have a lot of problems with unaligned addresses, even with cache off. I went to reproduce the original bootm problem and ran into fatload hanging. tftp didn't fail but bootm hangs.
Maybe you can't take alignment exceptions during bootm? PPC doesn't normally take alignment checks, but we would have trouble with this scenario if it did, since bootm clobbers the exception vectors.
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 47 lines · Scott Wood
Quoted 34 lines · Tom Rini
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Quoted 22 lines · Scott Wood
Quoted 21 lines · Tom Rini
Quoted 19 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the
device uses DMA to deploy data. In that case, it might
not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,Or get cache coherent hardware. :-)
Quoted 4 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
Quoted 8 lines
Quoted 2 lines
We would need to architect things such that any 'load' command would be routed through this logic.
It's something the driver backend should handle (possibly via a common helper library). The fact that you can't do a DMA transfer to an unaligned buffer is a hardware-specific detail, just as is the fact that you're setting up a DMA buffer in the first place.
Quoted 3 lines
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
OK, so fix it in each driver that has this issue. A lot of drivers are probably not so performance critical that you can't just always use a bounce buffer. A static buffer plus memcpy isn't that burdensome -- it's close to what the drivers for non-DMA hardware do. For higher performance peripherals, throw in an if-statement or two. It doesn't seem like something that needs a U-Boot-wide change.
Quoted 2 lines
In the specific case of NAND, how many NAND drivers use DMA at all?
Off hand I'm not sure. I know there've been patches for OMAP parts before but they had some unaddressed feedback and aren't in mainline.
Quoted 10 lines
Quoted 9 lines
Quoted 4 lines
I'm not sure what bootm has to do with nand (and the fact that some ppc is cache coherent actually doesn't matter, since we don't do DMA for NAND), but I was able to bootm from an odd RAM address, and "nand read" to an odd RAM address, on p5020ds.
On ARM-land we have a lot of problems with unaligned addresses, even with cache off. I went to reproduce the original bootm problem and ran into fatload hanging. tftp didn't fail but bootm hangs.
Quoted 4 lines
Maybe you can't take alignment exceptions during bootm? PPC doesn't normally take alignment checks, but we would have trouble with this scenario if it did, since bootm clobbers the exception vectors.
Could be it. But again, fatload via mmc also chokes, so there's a few and quite long-standing problems. What Marek and I are arguing for I believe is to say it's not worth the effort to enable this corner case. Since it works on other arches, we shouldn't make this a silent change that slips in, certainly, but at the end of the day it's highly unlikely someone is using this in the wild and won't be able to work around it in their next design or field upgrade. I would hope at least.
- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJP6NaYAAoJENk4IS6UOR1WSogP/RX/VzrN0NzhApkVg38Bal7M zgbjYS/Mub12oJmzU+iDosVC/HS6RqZb+LoLRlXROLAUka6SxUub/DtJATQ5ivRd Y+x17Z7rdu4Q3dIcYV27RkJOCiXCRkUVFvulZEfzXlsLpoTC3PbiAA06xDuxHePJ 85liIhxMfTvwUGH0b4umtvy5vrlgop/K6Vdba9SPJwiS/pfW6hIj9ZnnFmJYY6aN e1IqYjcQtDpxBttdy4PPZr4l0Qx+cYonHs9oFpgnibMsgr7FilqM8fVMq7iHGPYU acX1YpvOZCWQsv3HcQdq/SrjnRJSDdcySV5q1xEZbpgw0iYbkT9lBb5GX4QcXr43 3zuvLlcvdPz1NzFp4v5gRWUnGaKvCUN5rQHT4UFQDfUErAHuA4q6xjnCe6bYD/EF kETrAc8pN3sKwJTMJyE1LU2fFfaUirtggT3gWljfgKkfWmbbLnPRTUSkTFWRwu3S QEcsGD8X+XUsiW9h/mZOlAuspzd6oxOOUCy54NfxkMQZy6YDGFFkPrzme6ztxIlz O2oSSUSmsWFZbWHVxX/YejZta/RNp+3R9c37J8qFhDku19gMDo+RVn49vKW3dBxp yb62WkxgO20990kAi7yDfy0XUlJR0WYdiUFiG273TFxNLcanHyct1JELf6zckxju gBKoz+Ddlqtc7v5AWsuK
=Pyx6
-----END PGP SIGNATURE-----
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
In reply to Scott WoodDear Scott Wood,
Quoted 38 lines · Tom Rini
Quoted 28 lines
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 24 lines · Scott Wood
Quoted 22 lines · Tom Rini
Quoted 12 lines · Scott Wood
Quoted 4 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 6 lines
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
We would need to architect things such that any 'load' command would be routed through this logic.
Quoted 8 lines
Quoted 4 lines
It's something the driver backend should handle (possibly via a common helper library). The fact that you can't do a DMA transfer to an unaligned buffer is a hardware-specific detail, just as is the fact that you're setting up a DMA buffer in the first place.
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
Quoted 6 lines
OK, so fix it in each driver that has this issue. A lot of drivers are probably not so performance critical that you can't just always use a bounce buffer. A static buffer plus memcpy isn't that burdensome -- it's close to what the drivers for non-DMA hardware do. For higher performance peripherals, throw in an if-statement or two. It doesn't seem like something that needs a U-Boot-wide change.
This is flat bull. I don't want bounce buffers growing all around uboot, see my previous email. I'm 120% firm in that.
And btw it's not about bounce buffers, it's also about other code (like FS code) which does unaligned accesses and we're fixing it.
Quoted 2 lines
In the specific case of NAND, how many NAND drivers use DMA at all?
Many do, it's not only nand, it's all over the place.
SPI, NAND, MMC etc.
Quoted 9 lines
Quoted 8 lines
Quoted 4 lines
I'm not sure what bootm has to do with nand (and the fact that some ppc is cache coherent actually doesn't matter, since we don't do DMA for NAND), but I was able to bootm from an odd RAM address, and "nand read" to an odd RAM address, on p5020ds.
On ARM-land we have a lot of problems with unaligned addresses, even with cache off. I went to reproduce the original bootm problem and ran into fatload hanging. tftp didn't fail but bootm hangs.
Quoted 5 lines
Maybe you can't take alignment exceptions during bootm? PPC doesn't normally take alignment checks, but we would have trouble with this scenario if it did, since bootm clobbers the exception vectors.
-Scott
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 14 lines · Marek Vasut
Dear Scott Wood,
Quoted 11 lines · Tom Rini
Quoted 3 lines
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
OK, so fix it in each driver that has this issue. A lot of drivers are probably not so performance critical that you can't just always use a bounce buffer. A static buffer plus memcpy isn't that burdensome -- it's close to what the drivers for non-DMA hardware do. For higher performance peripherals, throw in an if-statement or two. It doesn't seem like something that needs a U-Boot-wide change.
Quoted 2 lines
This is flat bull. I don't want bounce buffers growing all around uboot, see my previous email. I'm 120% firm in that.
I'm 150% firm that you're going to need a better justification to change the user interface for everybody.
What's next, restricting "cp" (or even "cp.b") in case someone wants to use a DMA engine to copy the bits?
Note that in the case of "nand read.oob", depending on NAND page size and platform, there's a good chance that you're imposing an alignment restriction that is larger than the data being transferred even if the user asks to read the entire OOB.
What about "nand write.yaffs2" or multi-page "nand read.raw", which deal with arrays of interleaved main+spare? With a small page NAND chip, you'll need cache lines that are 16 bytes or smaller to avoid unaligned transactions -- and those will bypass your front-end check (unless the user is so "stupid" as to want to modify the data after a raw-read, and do a raw-write of a particular page).
Quoted 2 lines
And btw it's not about bounce buffers, it's also about other code (like FS code) which does unaligned accesses and we're fixing it.
Fixing the alignment of U-Boot-generated buffers is good. That doesn't affect the user interface. This is different.
Quoted 3 lines
Quoted 1 line
In the specific case of NAND, how many NAND drivers use DMA at all?
Many do,
How many? Specifically, how many that have alignment restrictions, that would need to be fixed?
Quoted 1 line
it's not only nand, it's all over the place.
This patch is about NAND.
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Dear Scott Wood,
Quoted 15 lines · Marek Vasut
Quoted 14 lines
Dear Scott Wood,
Quoted 11 lines · Tom Rini
Quoted 3 lines
Right. What I'm trying to say is it's not a NAND problem it's an unaligned addresses problem so the solution needs to be easily used everywhere.
OK, so fix it in each driver that has this issue. A lot of drivers are probably not so performance critical that you can't just always use a bounce buffer. A static buffer plus memcpy isn't that burdensome -- it's close to what the drivers for non-DMA hardware do. For higher performance peripherals, throw in an if-statement or two. It doesn't seem like something that needs a U-Boot-wide change.
Quoted 5 lines
Quoted 2 lines
This is flat bull. I don't want bounce buffers growing all around uboot, see my previous email. I'm 120% firm in that.
I'm 150% firm that you're going to need a better justification to change the user interface for everybody.
I'm trying to make it user-proof. Honestly, loading to some bullshit unaligned address is a corner case, so it won't affect many people. And that minority who'll be affected will adjust their stuff by a few bytes, no problem there.
Quoted 2 lines
What's next, restricting "cp" (or even "cp.b") in case someone wants to use a DMA engine to copy the bits?
Ad absurdum indeed, but it's partly valid point. You'd need to restrict it somehow if that'd be the case, therefore I'll add it to the DM. Drivers should be able to specify their requirements.
Quoted 4 lines
Note that in the case of "nand read.oob", depending on NAND page size and platform, there's a good chance that you're imposing an alignment restriction that is larger than the data being transferred even if the user asks to read the entire OOB.
I don't think I completely follow here.
Quoted 6 lines
What about "nand write.yaffs2" or multi-page "nand read.raw", which deal with arrays of interleaved main+spare? With a small page NAND chip, you'll need cache lines that are 16 bytes or smaller to avoid unaligned transactions -- and those will bypass your front-end check (unless the user is so "stupid" as to want to modify the data after a raw-read, and do a raw-write of a particular page).
Ok, I think I'm very stupid now, probably since I have high fever. I'll read this after I sleep. Sorry Scott, I'm sure you're rolling out a valid point, it's just that I'm incapable of understanding it right now.
Quoted 5 lines
Quoted 2 lines
And btw it's not about bounce buffers, it's also about other code (like FS code) which does unaligned accesses and we're fixing it.
Fixing the alignment of U-Boot-generated buffers is good. That doesn't affect the user interface. This is different.
And it's the easy part.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
In the specific case of NAND, how many NAND drivers use DMA at all?
Many do,
How many? Specifically, how many that have alignment restrictions, that would need to be fixed?
At least all on the ARM architecture. And more will come, since ARM is on the rise.
Quoted 3 lines
Quoted 1 line
it's not only nand, it's all over the place.
This patch is about NAND.
Check the whole patchset ... and that still only covers a small part of it all.
Quoted 1 line
-Scott
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 7 lines · Marek Vasut
Dear Scott Wood,
Quoted 4 lines
Note that in the case of "nand read.oob", depending on NAND page size and platform, there's a good chance that you're imposing an alignment restriction that is larger than the data being transferred even if the user asks to read the entire OOB.
I don't think I completely follow here.
Why should I need to have 64-byte alignment for transfering a 16-byte OOB?
Quoted 10 lines
Quoted 6 lines
What about "nand write.yaffs2" or multi-page "nand read.raw", which deal with arrays of interleaved main+spare? With a small page NAND chip, you'll need cache lines that are 16 bytes or smaller to avoid unaligned transactions -- and those will bypass your front-end check (unless the user is so "stupid" as to want to modify the data after a raw-read, and do a raw-write of a particular page).
Ok, I think I'm very stupid now, probably since I have high fever. I'll read this after I sleep. Sorry Scott, I'm sure you're rolling out a valid point, it's just that I'm incapable of understanding it right now.
Probably best to wait until you're feeling better for the rest of it, too. Hope you get well soon.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
In the specific case of NAND, how many NAND drivers use DMA at all?
Many do,
How many? Specifically, how many that have alignment restrictions, that would need to be fixed?
At least all on the ARM architecture. And more will come, since ARM is on the rise.
atmel: no, doesn't use DMA
davinci: no, doesn't use DMA
kb9202: no, doesn't use DMA
kirkwood: no, doesn't use DMA
mxc: I don't think this uses DMA, but this driver scares me. :-)
mxs: Even scarier. Looks like this one does use DMA.omap_gpmc: no, doesn't use DMA
s3c64xx: no, doesn't use DMA
spr: no, doesn't use DMA
s3c2410: no, doesn't use DMA
If this is about not wanting to touch the mxs_nand driver again, I sympathize. :-)
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
it's not only nand, it's all over the place.
This patch is about NAND.
Check the whole patchset ... and that still only covers a small part of it all.
Right, I think it's wrong elsewhere too when it's user interface, but I'll let the relevant custodians argue those cases.
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
In reply to Tom RiniDear Tom Rini,
Quoted 19 lines · Scott Wood
Quoted 12 lines · Marek Vasut
Quoted 4 lines
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 5 lines
How about use the bounce buffer only if the address is misaligned? The corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty. How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
Quoted 3 lines
We would need to architect things such that any 'load' command would be routed through this logic. A solvable problem for sure, but a little bit larger than just for NAND :)
It's not only NAND, it's the whole user interface that's broken right now.
Quoted 6 lines
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-PI don't want to get into an ARM vs PowerPC argument.
ARM is better anyway :-D
Quoted 5 lines
I think the best
answer is that I'm not sure having things unaligned works totally right today as I did a silly test of loading a uImage to0x82000001and bootm hung inside of U-Boot not long ago. Can you try that on some cache coherent hardware and see if that works?
+1
[...]
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
In reply to Scott WoodDear Scott Wood,
Quoted 7 lines · Marek Vasut
Quoted 4 lines
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Or get cache coherent hardware. :-)
Oh ... you mean powerpc? Or rather something like this
http://cache.freescale.com/files/32bit/doc/fact_sheet/QORIQLS2FAMILYFS.pdf ? :-D
Quoted 5 lines
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned?
Not happening, bounce buffer is bullshit, especially if we can prevent it by teaching user not to do retarded things.
It's like driving a car in the wrong lane. Sure, you can do it, but it'll eventually have some consequences. And using a bounce buffer is like driving a tank in the wrong lane ...
Quoted 4 lines
The
corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty.
Slight is very weak word here.
Quoted 2 lines
How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
If the user is dumb, always. But if you tell the user how to milk the most of the hardware, he'll be happier.
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-P
That's actually almost right, we're doing a bootloader here, it might have limitations. We're not writing yet another operating system with no bounds on possibilities!
Quoted 18 lines
Quoted 18 lines
Signed-off-by Marek Vasut <[email protected]>Cc Scott Wood <[email protected]>---
common/cmd_nand.c | 9 +++++++++ 1 file changed, 9 insertions(+)common/cmd_nand.c +0
-0@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage; addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 );
Quoted 7 lines
common/cmd_nand.c int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, · line 616
Quoted 2 lines
common/cmd_nand.c +2
-0+if (!cacheline_aligned (addr)) +return 1 ;There's no way you can just return like this without printing an error that lets the user know that the operation wasn't performed, and why.
-Scott
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 8 lines · Marek Vasut
Dear Scott Wood,
Quoted 6 lines · Marek Vasut
Quoted 4 lines
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Quoted 4 lines
Quoted 1 line
Or get cache coherent hardware. :-)
Oh ... you mean powerpc? Or rather something like this
http://cache.freescale.com/files/32bit/doc/fact_sheet/QORIQLS2FAMILYFS.pdf ? :-D
The word "coherent/coherency" appears 5 times in that document by my count. :-)
I hope that applies to DMA, not just core-to-core.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned?
Not happening, bounce buffer is bullshit,
Hacking up the common frontend with a new limitation because you can't be bothered to fix your drivers is bullshit.
Quoted 3 lines
It's like driving a car in the wrong lane. Sure, you can do it, but it'll eventually have some consequences. And using a bounce buffer is like driving a tank in the wrong lane ...
Using a bounce buffer is like parking your car before going into the building, rather than insisting the building's hallways be paved.
Quoted 6 lines
Quoted 4 lines
The
corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty.Slight is very weak word here.
Prove me wrong with benchmarks.
Quoted 5 lines
Quoted 2 lines
How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
If the user is dumb, always. But if you tell the user how to milk the most of the hardware, he'll be happier.
So, if you use bounce buffers conditionally (based on whether the address is misaligned), there's no impact except to "dumb" users, and for those users they would merely get a performance degradation rather than breakage. How is this "bullshit"?
Quoted 8 lines
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-PThat's actually almost right, we're doing a bootloader here, it might have limitations. We're not writing yet another operating system with no bounds on possibilities!
We also don't need to bend over backwards to squeeze every last cycle out of the boot process, at the expense of a stable user interface (not to mention requiring the user to know the system's cache line size).
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Dear Scott Wood,
Quoted 24 lines · Marek Vasut
Quoted 8 lines
Dear Scott Wood,
Quoted 6 lines · Marek Vasut
Quoted 4 lines
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer,
Quoted 5 lines
Quoted 1 line
Or get cache coherent hardware. :-)
Oh ... you mean powerpc? Or rather something like this
http://cache.freescale.com/files/32bit/doc/fact_sheet/QORIQLS2FAMILYFS.pd
f ? :-DThe word "coherent/coherency" appears 5 times in that document by my count. :-)
I hope that applies to DMA, not just core-to-core.
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
How about use the bounce buffer only if the address is misaligned?
Not happening, bounce buffer is bullshit,
Hacking up the common frontend with a new limitation because you can't be bothered to fix your drivers is bullshit.
The drivers are not broken, they have hardware limitations. And checking for those has to be done as early as possible. And it's not a new common frontend!
Quoted 6 lines
Quoted 3 lines
It's like driving a car in the wrong lane. Sure, you can do it, but it'll eventually have some consequences. And using a bounce buffer is like driving a tank in the wrong lane ...
Using a bounce buffer is like parking your car before going into the building, rather than insisting the building's hallways be paved.
The other is obviously faster, more comfortable and lets you carry more stuff at once. And if you drive a truck, you can dump a lot of payload instead of carrying it back and forth from the building. That's why there's a special garage for trucks possibly with cargo elevators etc.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
The
corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty.Slight is very weak word here.
Prove me wrong with benchmarks.
Well, copying data back and forth is tremendous overhead. You don't need a benchmark to calculate something like this:
133MHz SDRAM (pumped) gives you what ... 133 Mb/s throughput
(now if it's DDR, dual/quad pumped, that doesn't give you any more advantage since you have to: send address, read the data, send address, write the data ... this is expensive ... without data cache on, even more so)
Now consider you do it via really dump memcpy, what happens:
1) You need to read the data into register
1a) Send address
1b) Read the data into register
2) You need to write the data to a new location 2a) Send address
2b) Write the data into the memory
In the meantime, you get some refresh cycles etc. Now, if you take read and write in 1 time unit and "send address" in 0.5 time unit (this gives total 3 time units per one loop) and consider you're not doing sustained read/write, you should see you'll be able to copy at speed of about 133/3 ~= 40Mb/s
If you want to load 3MB kernel at 40Mb/s onto an unaligned address via DMA, the DMA will deploy it via sustained write, that'll be at 10MB/s, therefore in 300ms. But the subsequent copy will take another 600ms.
And now, I need someone to recalculate it. Also, read up here, it is _VERY_ good and it is certainly more accurate than my previous delirious attempt:
http://www.akkadia.org/drepper/cpumemory.pdf
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
If the user is dumb, always. But if you tell the user how to milk the most of the hardware, he'll be happier.
So, if you use bounce buffers conditionally (based on whether the address is misaligned), there's no impact except to "dumb" users, and for those users they would merely get a performance degradation rather than breakage. How is this "bullshit"?
Correct, but users will complain if they get a subpar performance.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
I'm hesitant to break something -- even if it's odd (literally in this case) -- that currently works on most hardware, just because one or two drivers can't handle it. It feels kind of like changing the
read()andwrite()system calls to require cacheline alignment. :-P
Quoted 7 lines
Quoted 3 lines
That's actually almost right, we're doing a bootloader here, it might have limitations. We're not writing yet another operating system with no bounds on possibilities!
We also don't need to bend over backwards to squeeze every last cycle out of the boot process, at the expense of a stable user interface (not to mention requiring the user to know the system's cache line size).
But that's reported in my patch ;-)
And yes, we want to make the boot process as blazing fast as possible. Imagine you fire a rocket into the deep space and it gets broken and needs reboot, will you enjoy the waiting ? ;-)
Quoted 1 line
-Scott
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Quoted 10 lines · Marek Vasut
Dear Scott Wood,
Quoted 8 lines · Marek Vasut
Quoted 7 lines
Dear Scott Wood,
Quoted 5 lines · Marek Vasut
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
How about use the bounce buffer only if the address is misaligned?
Not happening, bounce buffer is bullshit,
Hacking up the common frontend with a new limitation because you can't be bothered to fix your drivers is bullshit.
The drivers are not broken, they have hardware limitations.
They're broken because they ignore those limitations.
Quoted 2 lines
And checking for
those has to be done as early as possible.
Why?
Quoted 1 line
And it's not a new common frontend!
No, it's a compatibility-breaking change to the existing common frontend.
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
It's like driving a car in the wrong lane. Sure, you can do it, but it'll eventually have some consequences. And using a bounce buffer is like driving a tank in the wrong lane ...
Using a bounce buffer is like parking your car before going into the building, rather than insisting the building's hallways be paved.
The other is obviously faster, more comfortable and lets you carry more stuff at once.
Then you end up needing buildings to be many times as large to give every cubicle an adjacent parking spot, maneuvering room, etc. You'll be breathing fumes all day, and it'll be a lot less comfortable to get even across the hallway without using a car, etc. Communication between coworkers would be limited to horns and obscene gestures. :-)
Quoted 3 lines
And if you drive a truck, you can dump a lot of payload instead of carrying it back and forth from the building. That's why there's a special garage for trucks possibly with cargo elevators etc.
Yes, it's called targeted optimization rather than premature optimization.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
The
corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Slight is very weak word here.
Prove me wrong with benchmarks.
Well, copying data back and forth is tremendous overhead. You don't need a benchmark to calculate something like this:
133MHz SDRAM (pumped) gives you what ... 133 Mb/s throughput
You're saying you get only a little more bandwidth from memory than you'd get from a 100 Mb/s ethernet port? Come on. Data buses are not one bit wide.
And how fast can you pull data out of a NAND chip, even with DMA?
Quoted 1 line
(now if it's DDR, dual/quad pumped, that doesn't give you any more advantage
So such things were implemented for fun?
Quoted 1 line
since you have to: send address, read the data, send address, write the data ...
What about bursts? I'm pretty sure you don't have to send the address separately for every single byte.
Quoted 1 line
this is expensive ... without data cache on, even more so)
Why do we care about "without data cache"? You don't need the bounce buffer in that case.
Quoted 1 line
Now consider you do it via really dump memcpy, what happens:
It looks like ARM U-Boot has an optimized memcpy.
Quoted 7 lines
1) You need to read the data into register
1a) Send address
1b) Read the data into register
2) You need to write the data to a new location
2a) Send address
2b) Write the data into the memory
Quoted 8 lines
In the meantime, you get some refresh cycles etc. Now, if you take read and write in 1 time unit and "send address" in 0.5 time unit (this gives total 3 time units per one loop) and consider you're not doing sustained read/write, you should see you'll be able to copy at speed of about 133/3 ~= 40Mb/s
If you want to load 3MB kernel at 40Mb/s onto an unaligned address via DMA, the DMA will deploy it via sustained write, that'll be at 10MB/s, therefore in 300ms. But the subsequent copy will take another 600ms.
On a p5020ds, using NAND hardware that doesn't do DMA at all, I'm able to load a 3MiB image from NAND in around 300-400 ms. This is with using memcpy_fromio() on an uncached hardware buffer.
Again, I'm not saying that bounce buffers are always negligible overhead -- just that I doubt NAND is fast enough that it makes a huge difference in this specific case.
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
If the user is dumb, always. But if you tell the user how to milk the most of the hardware, he'll be happier.
Quoted 6 lines
Quoted 4 lines
So, if you use bounce buffers conditionally (based on whether the address is misaligned), there's no impact except to "dumb" users, and for those users they would merely get a performance degradation rather than breakage. How is this "bullshit"?
Correct, but users will complain if they get a subpar performance.
If you expend the minimal effort required to make the bounce buffer usage conditional on the address actually being misaligned, the only users that will see subpar performance are those who would see breakage with your approach. Users will complain if they see breakage even more than when the see subpar performance.
If the issue is educating the user to avoid the performance hit (regardless of magnitude), and you care enough, have the driver print a warning (not error) message the first time it needs to use a bounce buffer.
-Scott
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
Dear Scott Wood,
Quoted 18 lines · Marek Vasut
Quoted 17 lines
Dear Scott Wood,
Quoted 14 lines · Marek Vasut
Quoted 10 lines
Dear Scott Wood,
Quoted 6 lines · Marek Vasut
Quoted 3 lines
but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
How about use the bounce buffer only if the address is misaligned?
Not happening, bounce buffer is bullshit,
Hacking up the common frontend with a new limitation because you can't be bothered to fix your drivers is bullshit.
Quoted 8 lines
Quoted 1 line
The drivers are not broken, they have hardware limitations.
They're broken because they ignore those limitations.
Quoted 2 lines
And checking for
those has to be done as early as possible.Why?
Why keep an overhead.
Quoted 3 lines
Quoted 1 line
And it's not a new common frontend!
No, it's a compatibility-breaking change to the existing common frontend.
Well, those are corner cases, it's not like the people will start hitting it en- masse.
I agree it should be somehow platform or even CPU specific.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
It's like driving a car in the wrong lane. Sure, you can do it, but it'll eventually have some consequences. And using a bounce buffer is like driving a tank in the wrong lane ...
Using a bounce buffer is like parking your car before going into the building, rather than insisting the building's hallways be paved.
Quoted 8 lines
Quoted 2 lines
The other is obviously faster, more comfortable and lets you carry more stuff at once.
Then you end up needing buildings to be many times as large to give every cubicle an adjacent parking spot, maneuvering room, etc. You'll be breathing fumes all day, and it'll be a lot less comfortable to get even across the hallway without using a car, etc. Communication between coworkers would be limited to horns and obscene gestures. :-)
Ok, this has gone waaay out of hand here :-)
Quoted 15 lines
Quoted 3 lines
And if you drive a truck, you can dump a lot of payload instead of carrying it back and forth from the building. That's why there's a special garage for trucks possibly with cargo elevators etc.
Yes, it's called targeted optimization rather than premature optimization.
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
The
corrective action a user has to take is the same as with this patch, except for an additional option of living with the slight performance penalty.Slight is very weak word here.
Prove me wrong with benchmarks.
Quoted 8 lines
Quoted 4 lines
Well, copying data back and forth is tremendous overhead. You don't need a benchmark to calculate something like this:
133MHz SDRAM (pumped) gives you what ... 133 Mb/s throughput
You're saying you get only a little more bandwidth from memory than you'd get from a 100 Mb/s ethernet port? Come on. Data buses are not one bit wide.
Good point, it was too late and I forgot to count that in.
Quoted 5 lines
And how fast can you pull data out of a NAND chip, even with DMA?
Quoted 2 lines
(now if it's DDR, dual/quad pumped, that doesn't give you any more advantage
Quoted 7 lines
So such things were implemented for fun?
Quoted 2 lines
since you have to: send address, read the data, send address, write the data ...
What about bursts? I'm pretty sure you don't have to send the address separately for every single byte.
If you do memcpy? You only have registers, sure, you can optimize it, but on intel for example, you don't have many of those.
Quoted 4 lines
Quoted 1 line
this is expensive ... without data cache on, even more so)
Why do we care about "without data cache"? You don't need the bounce buffer in that case.
Correct, it's expensive in both cases though.
Quoted 16 lines
Quoted 1 line
Now consider you do it via really dump memcpy, what happens:
It looks like ARM U-Boot has an optimized memcpy.
Quoted 13 lines
1) You need to read the data into register
1a) Send address
1b) Read the data into register
2) You need to write the data to a new location
2a) Send address
2b) Write the data into the memoryIn the meantime, you get some refresh cycles etc. Now, if you take read and write in 1 time unit and "send address" in 0.5 time unit (this gives total 3 time units per one loop) and consider you're not doing sustained read/write, you should see you'll be able to copy at speed of about 133/3 ~= 40Mb/s
Quoted 7 lines
Quoted 3 lines
If you want to load 3MB kernel at 40Mb/s onto an unaligned address via DMA, the DMA will deploy it via sustained write, that'll be at 10MB/s, therefore in 300ms. But the subsequent copy will take another 600ms.
On a p5020ds, using NAND hardware that doesn't do DMA at all, I'm able to load a 3MiB image from NAND in around 300-400 ms. This is with using
memcpy_fromio()on an uncached hardware buffer.
blazing almost half a second ... but everyone these days wants a faster boot, without memcpy, it can go down to 100ms or even less! And this kind of limitation is not something that'd inconvenience anyone.
Quoted 3 lines
Again, I'm not saying that bounce buffers are always negligible overhead -- just that I doubt NAND is fast enough that it makes a huge difference in this specific case.
It does make a difference. Correct, thinking about it -- implementing a generic bounce buffer for cache-impotent hardware might be a better way to go.
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
How often does this actually happen? How much does it actually slow things down compared to the speed of the NAND chip?
If the user is dumb, always. But if you tell the user how to milk the most of the hardware, he'll be happier.
Quoted 6 lines
Quoted 4 lines
So, if you use bounce buffers conditionally (based on whether the address is misaligned), there's no impact except to "dumb" users, and for those users they would merely get a performance degradation rather than breakage. How is this "bullshit"?
Correct, but users will complain if they get a subpar performance.
If you expend the minimal effort required to make the bounce buffer usage conditional on the address actually being misaligned, the only users that will see subpar performance are those who would see breakage with your approach. Users will complain if they see breakage even more than when the see subpar performance.
Quoted 3 lines
If the issue is educating the user to avoid the performance hit (regardless of magnitude), and you care enough, have the driver print a warning (not error) message the first time it needs to use a bounce buffer.
Ok, on a second thought, you're right. Let's do it the same way we did it with mmc.
Quoted 1 line
-Scott
Best regards,
Marek Vasut
PATCH 6/9 CACHE: nand read/write: Test if start address is aligned
In reply to Marek VasutQuoted 19 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Signed-off-by Marek Vasut<[email protected]>Cc Scott Wood<[email protected]>--- common/cmd_nand.c | 9 +++++++++ 1 file changed, 9 insertions(+)common/cmd_nand.c +0
-0
common/cmd_nand.c int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) · line 613
Quoted 5 lines
common/cmd_nand.c +2
-0@@ -609,6 +609,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) goto usage; addr = (ulong )simple_strtoul (argv[2 ],NULL ,16 ); +if (!cacheline_aligned (addr)) +return 1 ;
You need to check the end address too. Also, I agree with Scott that that this is an un-justifiable restriction on cache-coherent architectures. IMO, such checks should be done in platform specific code where the DMA is being attempted.
best regards,
Aneesh
PATCH 7/9 CACHE: net: Test if start address is aligned
In reply to Marek VasutThis prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
--- common/cmd_net.c | 4 ++++ 1 file changed, 4 insertions(+)
common/cmd_net.c +4 -0
@@ -242,6 +242,10 @@ static int netboot_common(enum proto_t proto, cmd_tbl_t *cmdtp, int argc,bootstage_error (BOOTSTAGE_ID_NET_START );return CMD_RET_USAGE ; } + +if (!cacheline_aligned (load_addr)) +return 1 ; +bootstage_mark (BOOTSTAGE_ID_NET_START );if ((size =NetLoop (proto)) <0 ) {
Signature · 1 line
1.7.10
PATCH 7/9 CACHE: net: Test if start address is aligned
Hi Marek,
Quoted 11 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
Marek Vasut
NAKPATCH 7/9 CACHE: net: Test if start address is aligned
Dear Joe Hershberger,
Quoted 11 lines
Hi Marek,
Quoted 8 lines · Marek Vasut
This prevents the scenario where data cache is on and the device uses DMA to deploy data. In that case, it might not be possible to flush/invalidate data to RAM properly. The other option is to use bounce buffer, but that involves a lot of copying and therefore degrades performance rapidly. Therefore disallow this possibility of unaligned load address altogether if data cache is on.
Quoted 5 lines
Quoted 3 lines
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
Acked-by Joe Hershberger <[email protected]>
NAK, actually ... let's wait until the discussion is settled ;-)
Best regards,
Marek Vasut
PATCH 8/9 CACHE: net: asix: Fix asix driver to work with data cache on
In reply to Marek VasutThe asix driver did not align buffers, therefore it didn't work with data cache enabled. Fix this.
--- drivers/usb/eth/asix.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-)
drivers/usb/eth/asix.c +16 -13
@@ -168,27 +168,28 @@ static inline int asix_set_hw_mii(struct ueth_data *dev)static int asix_mdio_read (struct ueth_data *dev,int phy_id,int loc) { -__le16 res; +ALLOC_CACHE_ALIGN_BUFFER (__le16, res,1 );asix_set_sw_mii (dev); -asix_read_cmd (dev,AX_CMD_READ_MII_REG , phy_id, (__u16 )loc,2 , &res); +asix_read_cmd (dev,AX_CMD_READ_MII_REG , phy_id, (__u16 )loc,2 , res);asix_set_hw_mii (dev);debug ("asix_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n" , - phy_id, loc,le16_to_cpu (res)); + phy_id, loc,le16_to_cpu (*res)); -return le16_to_cpu (res); +return le16_to_cpu (*res); }static void asix_mdio_write (struct ueth_data *dev,int phy_id,int loc,int val) { -__le16 res =cpu_to_le16 (val); +ALLOC_CACHE_ALIGN_BUFFER (__le16, res,1 ); + *res =cpu_to_le16 (val);debug ("asix_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x\n" , phy_id, loc, val);asix_set_sw_mii (dev); -asix_write_cmd (dev,AX_CMD_WRITE_MII_REG , phy_id, (__u16 )loc,2 , &res); +asix_write_cmd (dev,AX_CMD_WRITE_MII_REG , phy_id, (__u16 )loc,2 , res);asix_set_hw_mii (dev); }
@@ -210,7 +211,8 @@ static int asix_sw_reset(struct ueth_data *dev, u8 flags)static inline int asix_get_phy_addr (struct ueth_data *dev) { -u8 buf[2 ]; +ALLOC_CACHE_ALIGN_BUFFER (u8, buf,2 ); +int ret =asix_read_cmd (dev,AX_CMD_READ_PHY_ID ,0 ,0 ,2 , buf);debug ("asix_get_phy_addr()\n" );
@@ -242,13 +244,14 @@ static int asix_write_medium_mode(struct ueth_data *dev, u16 mode)static u16 asix_read_rx_ctl (struct ueth_data *dev) { -__le16 v; -int ret =asix_read_cmd (dev,AX_CMD_READ_RX_CTL ,0 ,0 ,2 , &v); +ALLOC_CACHE_ALIGN_BUFFER (__le16, v,1 ); + +int ret =asix_read_cmd (dev,AX_CMD_READ_RX_CTL ,0 ,0 ,2 , v);if (ret <0 )debug ("Error reading RX_CTL register: %02x\n" , ret);else - ret =le16_to_cpu (v); + ret =le16_to_cpu (*v);return ret; }
@@ -313,7 +316,7 @@ static int mii_nway_restart(struct ueth_data *dev)static int asix_init (struct eth_device *eth,bd_t *bd) {int embd_phy; -unsigned char buf[ETH_ALEN ]; + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buf, ETH_ALEN);u16 rx_ctl;struct ueth_data *dev = (struct ueth_data *)eth->priv;int timeout =0 ;
@@ -425,7 +428,7 @@ static int asix_send(struct eth_device *eth, void *packet, int length)int err;u32 packet_len;int actual_len; -unsigned char msg[PKTSIZE +sizeof (packet_len)]; + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, msg, PKTSIZE + sizeof(packet_len));debug ("** %s(), len %d\n" , __func__, length);
@@ -452,7 +455,7 @@ static int asix_send(struct eth_device *eth, void *packet, int length)static int asix_recv (struct eth_device *eth) {struct ueth_data *dev = (struct ueth_data *)eth->priv; -static unsigned char recv_buf[AX_RX_URB_SIZE ]; + ALLOC_CACHE_ALIGN_BUFFER(unsigned char, recv_buf, AX_RX_URB_SIZE);unsigned char *buf_ptr;int err;int actual_len;
Signature · 1 line
1.7.10
PATCH 8/9 CACHE: net: asix: Fix asix driver to work with data cache on
Hi Marex,
Quoted 6 lines · Marek Vasut
The asix driver did not align buffers, therefore it didn't work with data cache enabled. Fix this.
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
PATCH 8/9 CACHE: net: asix: Fix asix driver to work with data cache on
Dear Joe Hershberger,
Quoted 11 lines
Hi Marex,
Quoted 6 lines · Marek Vasut
The asix driver did not align buffers, therefore it didn't work with data cache enabled. Fix this.
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
Acked-by Joe Hershberger <[email protected]>
Yes, this one is good, can you pick it up please?
Best regards,
Marek Vasut
PATCH 8/9 CACHE: net: asix: Fix asix driver to work with data cache on
In reply to Joe HershbergerDear Joe Hershberger,
Quoted 11 lines
Hi Marex,
Quoted 6 lines · Marek Vasut
The asix driver did not align buffers, therefore it didn't work with data cache enabled. Fix this.
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
Acked-by Joe Hershberger <[email protected]>
Joe, don't apply this one, I'll send updated one.
Best regards,
Marek Vasut
PATCH 8/9 CACHE: net: asix: Fix asix driver to work with data cache on
Dear Joe Hershberger,
Quoted 6 lines
Quoted 6 lines
Hi Marex,
Quoted 3 lines · Marek Vasut
The asix driver did not align buffers, therefore it didn't work with data cache enabled. Fix this.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Signed-off-by Marek Vasut <[email protected]>Cc Joe Hershberger <[email protected]>---
Acked-by Joe Hershberger <[email protected]>Joe, don't apply this one, I'll send updated one.
Stupid me, this can be safely applied.
Quoted 2 lines
Best regards,
Marek Vasut
Best regards,
Marek Vasut
PATCH 9/9 M28EVK: Enable instruction and data cache
In reply to Marek Vasut--- include/configs/m28evk.h | 2 -- 1 file changed, 2 deletions(-)
include/configs/m28evk.h +0 -2
@@ -37,8 +37,6 @@#define CONFIG_MACH_TYPE MACH_TYPE_M28EVK#define CONFIG_SYS_NO_FLASH -#define CONFIG_SYS_ICACHE_OFF -#define CONFIG_SYS_DCACHE_OFF #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_ARCH_CPU_INIT #define CONFIG_ARCH_MISC_INIT
Signature · 1 line
1.7.10