From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Sun, 8 Jan 2012 03:42:01 -0500 Subject: [U-Boot] [PATCH] tegra: mmc: Support operation with dcache enabled In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF176BE9309F@HQMAIL01.nvidia.com> References: <1324497752-27002-1-git-send-email-sjg@chromium.org> <74CDBE0F657A3D45AFBB94109FB122FF176BE9309F@HQMAIL01.nvidia.com> Message-ID: <201201080342.02878.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 Wednesday 21 December 2011 16:10:16 Stephen Warren wrote: > Simon Glass wrote at Wednesday, December 21, 2011 1:03 PM: > > When the data cache is enabled we must flush on write and invalidate > > on read. We also check that buffers are aligned to data cache lines > > boundaries. With recent work in U-Boot this should generally be the case > > but the warnings will catch problems. > > Conceptually this seems fine, but shouldn't the MMC driver core be doing > the cache management, so all platforms without cache coherency can > benefit from it? if the driver bitbangs things out (like SPI/MMC), then the core doing it would be a waste wouldn't it ? a better question might be how does Linux handle it ? does it force the drivers to do it, or does the core take care of things ? -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: