New dma-noncoherent code, looking for comment and people to test

[Remi Machet]

I agree. Is someone already working on that or should I do it ?

Remi


On Mon, 2008-09-29 at 13:03 -0500, Kumar Gala wrote:
> On Sep 29, 2008, at 12:26 PM, Remi Machet wrote:
> 
> > Hi,
> >
> > I rewrote dma-noncoherent.c and I am looking for people to review  
> > and test it
> > on various platforms that use it to make sure I did not introduce  
> > any bug.
> > The platforms affected by this change are those that define
> > CONFIG_NOT_COHERENT_CACHE:
> > ppc44x
> > walnut
> > makalu
> > kilauea
> > ep405
> > adder875
> > ep88xc
> > taishan
> > warp
> > sam440ep
> > sequoia
> > bamboo
> > canyonlands
> > rainier
> > katmai
> > ebony
> > mpc885_ads
> > mpc866_ads
> > ppc40x
> > c2k (already tested)
> > prpmc2800
> >
> > The old code in dma-noncoherent.c uses a memory pool at a hard coded
> > virtual address set by CONFIG_CONSISTENT_START (typically  
> > 0xFF100000). If not
> > set carefully this address can conflict with early ioremap in systems
> > that enable HIGHMEM, on top of that the code is overly complex  
> > because it
> > needs to have its own memory manager.
> > This is why I tried to re-implement the code using standard memory
> > management APIs. The new code does not require the user to set
> > CONFIG_CONSISTENT_START or CONFIG_CONSISTENT_SIZE, is much smaller and
> > simplier. It also can allocate as much memory as available in ZONE_DMA
> > (instead of being limited by CONFIG_CONSISTENT_SIZE).
> >
> > I also removed the HIGHMEM support in dma_sync since memory  
> > allocated for
> > DMA transfer should always be in ZONE_DMA (ie not in ZONE_HIGHMEM).
> >
> > Looking forward to any comment about why this code may not work or  
> > is not
> > as good as the original. If you do test this code on your platform,  
> > let me
> > know how it goes ... if no-one object and no bug is found I will  
> > submit
> > this patch in a month or so.
> >
> > Thanks !
> >
> > Remi
> 
> We really should change this code over to the new dma changes Becky's  
> introduced so we just have a non-coherent set of DMA ops (thus we can  
> do both non-coherent and coherent in the same system).
> 
> - k
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev