On Thu, 2009-12-10 at 07:40 +0300, Ilya Loginov wrote: > On Wed, 09 Dec 2009 18:19:55 -0600 > James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > OK, but the point I'm making is that it's a very heavyweight function on > > a lot of architectures. It sounds like mips should just have a > > flush_kernel_dcache_page() ... has anyone tested fuse on mips; if that > > fails, then it's a must. > > Yes, it works. There are many embedded systems which are based on MIPS. > For example, there is MIPS in my router. I use fuse on it(it is required > by ntfs-3g). OpenWRT. Yes ... apparently mips implements flush_anon_page(); I'm misremembering how fuse got fixed. > > The problem seems to be defined as one of ensuring coherency on PIO > > block devices in the most efficient manner possible. > > > Like I said previously, I still think some extension to the DMA API to > > map the areas correctly might be the best way forwards. > > What do you mean under DMA API? Do you mean that we should fix memcpy? The DMA API prepares user pages to send to physical devices via MMIO. It's an abstraction to prevent device driver writers having to remember complex (and architecture specific) rules about page flushing. For PIO we have this kmap/operate/flush_kernel_dcache_page()/kunmap complexity (see for example drivers/mmc/mmc_spi.c). However, it could all be taken care of in a similar way to the DMA API via an abstraction ... although I suspect the best abstraction is to pull the flush into kunmap. What MTD device is this? The subsystem is very complex, but I suppose I could trace the read path in a single device to see what the actual problem is. 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
