RE: [PATCH] Microblaze: implement dma-coherent API and refactorcache flush code.

[Stephen Neuendorffer]

> -----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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/