From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Date: Thu, 26 Apr 2012 12:34:43 +0200 Subject: [U-Boot] [PATCH 2/2] mmc: tegra: invalidate complete cachelines In-Reply-To: References: <1335254024-30115-1-git-send-email-thierry.reding@avionic-design.de> <1335254024-30115-2-git-send-email-thierry.reding@avionic-design.de> <201204251854.41947.vapier@gentoo.org> <20120426061831.GB10685@avionic-0098.mockup.avionic-design.de> Message-ID: <20120426103443.GA11972@avionic-0098.mockup.avionic-design.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de * 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: