Hi Mike,
On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger vapier@gentoo.org wrote:
On Friday, August 19, 2011 11:28:18 Lukasz Majewski wrote:
On Fri, 19 Aug 2011 09:57:10 -0400 Mike Frysinger wrote:
On Friday, August 19, 2011 05:25:13 Lukasz Majewski wrote:
- cache_align_buf = memalign(get_dcache_line_size(),
nowhere do i see get_dcache_line_size() defined
Please look to the following post: http://patchwork.ozlabs.org/patch/110501/
and another related with this issue: http://patchwork.ozlabs.org/patch/110300/
if you're posting patches with dependencies, you need to mention them explicitly (below the "---" area), or send proper patch series ([PATCH N/M]).
ignoring that, this patch will break all arches except arm. that's bad mmmkay. you probably need to move that weak def out of arm's cache.c and into like lib/cache.c.
Yes, I will prepare two patch series: One addressing the get_dcache_line_size function for all u-boot architectures.
Another patch series will address changes to the drivers/mmc.c file.
also, what is the code size increase with your patch ?
Code size overhead (s5p_goni target): Without proposed changes: 167928 B (u-boot.bin) With changes: 168208 B (u-boot.bin)
Delta: 280 B
np if it gives significant (more than system noise) speedups. any details on that ? -mike
No tests performed yet. The goal of those patches is to preserve the MMC subsystem functionality when dcache is enabled (the ext_csd[512] corruption is observed with d-cache enabled).
I'm particularly interested if the approach with memalign and get_dcache_line_size is the preferred way to go.
I will think about some reliable ways to measure the MMC performance with enabled and disabled MMC subsystem.