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.
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
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 the
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.
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
