On Thu, Aug 13, 2009 at 11:18 AM, San Mehat<s...@google.com> wrote: > On Thu, Aug 13, 2009 at 10:16 AM, Seth Forshee <seth.fors...@gmail.com> > wrote: >> >> On Wed, Aug 12, 2009 at 09:14:36AM -0700, San Mehat wrote: >> > On Tue, Jul 28, 2009 at 7:59 AM, Seth Forshee >> > <seth.fors...@gmail.com>wrote: >> > >> > > >> > > On Tue, Jul 28, 2009 at 07:34:14AM -0700, San Mehat wrote: >> > > > I'll try your test code when I have a chance. >> > > >> > > Thanks. >> > > >> > > > > I'm in a difficult debugging sitation for this issue. I can't >> > > > > build >> > > the >> > > > > kernel for the device (I'm working on getting the source to allow >> > > > > me to >> > > > > do this), and I don't have documentation for the processor. I >> > > > > also >> > > > > don't know whether the msm_sdcc driver is using DMA or PIO for the >> > > > > transfer, although in my tracing of the code paths it doesn't look >> > > > > like >> > > > > it should matter because in either case the cache lines for the >> > > > > userspace mapping should be cleaned and invalidated before the >> > > > > transfer >> > > > > starts. Are there any peculiarities of Android kernel >> > > > > modifications or >> > > > > of the MSM7k that could be causing this sort of behavior? >> > > > > >> > > > >> > > >> > >> > Just an update on this, I've run your test program on a number of >> > devices >> > with a few different brands of sdcards and haven't had a single failure. >> > Perhaps your unit is somehow faulty? >> >> Interesting. I'll see if I can get another board to test with. >> >> I haven't been involved with kernel development on this device, but >> looking now it's pretty obvious that some changes have been made to the >> MSM MMC driver. Maybe I'll see exactly what changes were made. >> >> I also noticed that CONFIG_MMC_BLOCK_BOUNCE is enabled in the kernel >> config for this device. Was that enabled during your tests? I haven't >> had time to look in detail, but it looks like the end result is that the >> data is copied to a kmalloc-ed buffer, and I/O is done from there. That >> adds more opportunity for aliasing, I suppose. > > Ahhh yes, that could explain the differences - we're running with > BLOCK_BOUNCE disabled. I'll try it that way in a few days
I've seen something like this with the block bounce enabled on another processor on 2.6.29. Problem is it doesn't flush when copying to/from the bounce buffer. This patch from 2.6.31 seems to fix it, might be worth a try: The only thing that might be worth adding is cache_is_vipt_nonaliasing() if you're running an arm11 with 16K cache. For the purposes of icache coherency at least it'd be required for pretty much all cache variants. commit 73be1591579084a8103a7005dd3172f3e9dd7362 Author: Nicolas Pitre <n...@cam.org> Date: Fri Jun 12 03:09:29 2009 +0100 [ARM] 5545/2: add flush_kernel_dcache_page() for ARM Without this, the default implementation is a no op which is completely wrong with a VIVT cache, and usage of sg_copy_buffer() produces unpredictable results. Tested-by: Sebastian Andrzej Siewior <bige...@breakpoint.cc> CC: sta...@kernel.org Signed-off-by: Nicolas Pitre <n...@marvell.com> Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk> diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index bb7d695..1a711ea 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -429,6 +429,14 @@ static inline void flush_anon_page(struct vm_area_struct *vma, __flush_anon_page(vma, page, vmaddr); } +#define ARCH_HAS_FLUSH_KERNEL_DCACHE_PAGE +static inline void flush_kernel_dcache_page(struct page *page) +{ + /* highmem pages are always flushed upon kunmap already */ + if ((cache_is_vivt() || cache_is_vipt_aliasing()) && !PageHighMem(page)) + __cpuc_flush_dcache_page(page_address(page)); +} + #define flush_dcache_mmap_lock(mapping) \ spin_lock_irq(&(mapping)->tree_lock) #define flush_dcache_mmap_unlock(mapping) \ --~--~---------~--~----~------------~-------~--~----~ unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel -~----------~----~----~----~------~----~------~--~---