> -----Original Message----- > From: John Williams [mailto:john.williams@xxxxxxxxxxxxx] > Sent: Monday, May 05, 2008 3:57 PM > To: Stephen Neuendorffer > Cc: arnd@xxxxxxxx; linux-arch@xxxxxxxxxxxxxxx; John Linn; matthew@xxxxxx; will.newton@xxxxxxxxx; > drepper@xxxxxxxxxx; microblaze-uclinux@xxxxxxxxxxxxxx; grant.likely@xxxxxxxxxxxx; Michal Simek; > linux-kernel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH] Microblaze: implement dma-coherent API and refactorcache flush code. > > Hi Steve, > > On Mon, 2008-05-05 at 15:37 -0700, Stephen Neuendorffer wrote: > > > In particular, the dcache in the microblaze is write through, so the > > existing code is more easily thought of as 'invalidation' than > > 'flushing'. In addition, some of the flush_* methods were old, and > > some shouldn't need to be implemented (since currently no mmu is > > supported). > > I agree - this renaming is a long time coming. > > [snip] > > Does the DMA API insist upon the dma_cache_sync call to guarantee > sensible results? If so, your implementation looks fine. If not, then > the results will clearly be bogus as there's nothing magical about the > memory being allocated in dma_alloc. Yes, in fact this is one of the keys to getting the lltemac driver to work right. see Documentation/DMA-API.txt > To that end, can it just call kmalloc(), and similarly kfree() for > dma_free? My understanding is that on other architectures (x86, for instance) 'dma' memory ensures other things, like it's accessible in PCI memory space. On microblaze, there's nothing really special about dma memory, but you get the API as a chunk. > I'd still like to see the uncached shadow stuff make a return one day, > it is an effective way of solving the problem, we'll just need to find a > cleaner way to implement it. A linear walk through the cache to > invalidate is so slow, it destroys any benefit gained from DMA in the > first place. I think it's definitely a simple way of solving the problem (in fact, the version of the code that's currently at git.xilinx.com includes it). Would it be better dealt with at the page level, rather than at the address level, then one of the architecture-reserved flags could be used for it? If it really does have value, then I want to make sure it goes in, along with bits in EDK that make it straightforward to use. For me, the biggest barrier to using it is understanding exactly what assumptions it is making on the hardware, and making those assumptions bulletproof. Steve -- 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
