Hi Mike,
On Mon, 22 Aug 2011 12:08:42 -0400 Mike Frysinger vapier@gentoo.org wrote:
On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote:
On Fri, 19 Aug 2011 11:35:50 -0400 Mike Frysinger 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: 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 ?
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).
so you're papering over a bug in some controller's cache handling ? shouldnt you fix the controller in question by having it flush its caches ? aligning random buffers to make cache issues "go away" isnt the right way for anything. -mike
Please look into the following patch: http://patchwork.ozlabs.org/patch/110576/
It seems that only flushing/invalidating buffers is not enough.