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
-~----------~----~----~----~------~----~------~--~---
