On May 28, 2008, at 8:53 PM, Mark Nelson wrote:
On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote:
On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
I essentially adopt the 64-bit dma code, with some changes to
support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
in
On May 23, 2008, at 4:51 AM, Christoph Hellwig wrote:
On Wed, Apr 30, 2008 at 06:36:43PM -0500, Becky Bruce wrote:
In addition, the dma_map/unmap_page functions are added to dma_ops on
HIGHMEM-enabled configs because we can't just fall back on map/
unmap_single
when HIGHMEM is enabled. Addi
On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote:
> On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
> >
> > I essentially adopt the 64-bit dma code, with some changes to support
> > 32-bit systems, including HIGHMEM. dma functions on 32-bit are now
> > invoked via accessor functions which call
On Wed, Apr 30, 2008 at 06:36:43PM -0500, Becky Bruce wrote:
> In addition, the dma_map/unmap_page functions are added to dma_ops on
> HIGHMEM-enabled configs because we can't just fall back on map/unmap_single
> when HIGHMEM is enabled. Adding these to dma_ops makes it cleaner to
> substitute dif
On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
>
> I essentially adopt the 64-bit dma code, with some changes to support
> 32-bit systems, including HIGHMEM. dma functions on 32-bit are now
> invoked via accessor functions which call the correct op for a device based
> on archdata dma_ops. Cu
I essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a device based
on archdata dma_ops. Currently, this defaults to dma_direct_ops, but this
structure
