On Fri, 2009-12-11 at 00:27 +0300, Ilya Loginov wrote: > On Thu, 10 Dec 2009 14:59:36 -0600 > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > To fix mips, you just need a > > flush_kernel_dcache_page() in slram_read so that the alias is updated > > after the memcpy. > > I think you right. But! If we choose this way: > > First. We need to realize flush_kernel_dcache_page() for many > architectures. Am I right? Actually, I think only sparc and mips need it. It's only needed for an aliasing architecture. Next, it's only used for pio drivers, so if the platform never uses a pio driver, it can get away without having this (that's the sparc case, I think). > Second. What difference will be between flush_kernel_dcache_page and > flush_dcache_page on MIPS? In common, flush_dcache_page in MIPS set > bit dirty on page. You already replied to this. > > I would also expect this driver not to work on any > > highmem system without additional kmap/kunmap(_atomic) pairs in the read > > and write routines. > > > How many other mtd drivers are affected, I'm not sure ... any that do > > PIO are wrong ... those that do MMIO should be right (that looks to be > > just the omap driver). > > Third. We should fix all other PIO drivers with problem and patch > aoe: switch to the new bio_flush_dcache_pages() interface in -mm tree > (i can't find this commit in the Linus tree). There is same problem. Unfortunately, you can't do it at the bio level. The reason is the kmap/kunmap. On a highmem system the mapping disappears after kunmap, so you have to flush before you lose the mapping ... that means right in the guts of the driver where it's doing the kmap/copy/kunmap. Sounds like aio does have the issue, yes. If you grep the kernel for flush_kernel_dcache_pages(), you'll see that a lot of PIO drivers are already using this, so there's not a lot of conversion to be done. > May be I wrong. And we have much less work. James -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
