[U-Boot] [PATCH 2/2] mmc: tegra: invalidate complete cachelines

[Thierry Reding]

* Simon Glass wrote:
> Hi Thierry,
> 
> On Thu, Apr 26, 2012 at 6:18 PM, Thierry Reding <
> thierry.reding at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120426/778720f5/attachment.pgp>