From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Mon, 22 Aug 2011 13:17:34 -0400 Subject: [U-Boot] [PATCH] mmc:dcache: Cache line size aligned internal MMC buffers In-Reply-To: References: <1313745913-28672-1-git-send-email-l.majewski@samsung.com> <201108221208.43852.vapier@gentoo.org> Message-ID: <201108221317.36786.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Monday, August 22, 2011 12:42:06 Anton Staaf wrote: > On Mon, Aug 22, 2011 at 9:08 AM, Mike Frysinger wrote: > > On Monday, August 22, 2011 03:29:52 Lukasz Majewski wrote: > >> 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. > > No, this isn't something that can be fixed in the controller driver > code. This is a fundamental problem with buffers in U-Boot that needs > to be resolved by aligning all buffers used for DMA. The main problem > is that invalidating a non-cache line aligned buffer is not a safe > operation. There have been a number of threads discussing this. The > general consensus was to make attempting to invalidate an unaligned > buffer an error and then to clean up the unaligned buffers as we find > them. Linux has taken the approach of the callers providing dma safe buffers instead of having lower layers trying to fix things up all the time. and for obvious reasons: you avoid the double allocation, the memcpy, and you avoid unclear documentation between layers where multiple layers attempt to fixup the callers thus futher multiplying the duplicated allocations/copies/etc... so in this case, why not fix the caller that is passing a dma unaligned buffer down to the mmc code ? -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/20110822/fc8a2c9e/attachment.pgp