* Simon Glass wrote:
Hi Thierry,
On Thu, Apr 26, 2012 at 6:18 PM, Thierry Reding < thierry.reding@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