* Simon Glass wrote: > Hi Thierry, > > On Thu, Apr 26, 2012 at 6:18 PM, Thierry Reding < > thierry.red...@avionic-design.de> wrote: > > > * Mike Frysinger wrote: > > > On Tuesday 24 April 2012 03:53:44 Thierry Reding wrote: > > > > The MMC core sometimes reads buffers that are smaller than a complete > > > > cacheline, for example when reading the SCR. In order to avoid a > > warning > > > > from the ARM v7 cache handling code, this patch makes sure that > > complete > > > > cachelines are flushed. > > > > > > this is still wrong. all you've done is bypass the error message without > > > addressing the underlying problem -- you're invalidating too much. > > > > Reading 8 bytes is always less than a cacheline, so we don't have much > > choice, do we? We could of course always read a whole cacheline even if > > only > > 8 bytes are requested, but does that have any advantage over reading 8 > > bytes > > and then invalidating the cacheline? > > > > Or maybe I'm missing the point. > > > > Well the point is that you can read 8 bytes but you still must use a buffer > that is large enough for DMA activity. So the caller must allocate a buffer > larger than 8 bytes.
The buffer used in this case is allocated with the ALLOC_CACHE_ALIGN_BUFFER() macro, so the buffer size is not an issue. However, the mmc_data structure's blocksize field is set to 8, which is the value that will eventually end up in invalidate_dcache_range(). For reference, see sd_change_freq() in drivers/mmc/mmc.c. > I worry that what you have done will just introduce obscure bugs, since we > will potentially invalidate stack variants (for example) and lose their > values. > > With the case problems, we are trying to fix them at source (i.e. at the > higher level). I understand. The question then becomes how to best fix the passed in size. Always passing the size of a complete cacheline in the SEND_SCR command doesn't seem like a better option because it may have other implications on other hardware. Thierry
pgpaTrmn3In8t.pgp
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot