[lkml]   [2003]   [Feb]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposal: Eliminate GFP_DMA
On Fri, Feb 28, 2003 at 11:17:29AM -0700, Deepak Saxena wrote:
> This discussion raises an issue that I've been meaning to bring up for
> a bit. Currently, the DMA-API is defined as returning a cpu physical
> address [1]

The DMA-API should reflect the same as the PCI-DMA API, namely:

| pci_alloc_consistent returns two values: the virtual address which you
| can use to access it from the CPU and dma_handle which you pass to the
| card.

Translated: not a physical address. "Physical" address to me means
the address that appears on the outside of the CPU after it has passed
through the MMU and is heading for the local CPUs system RAM.

So yes, I think this is a bug that exists in the DMA-API document.

It must be an offsetable cookie that the card on its own bus knows how
to deal with to access the memory associated with the mapping. In plain
speak, the bus address for that device.

> One easy answer is to provide bus-specific bus_map/unmap/etc functions
> such as is done with PCI, but this seems rather ugly to me as now every
> custom bus needs a new set of functions which IMNHO defeats the purpose
> of a Generic DMA API.

You can do this today with the API - test dev->bus_type to determine
the type of the bus, convert to the correct device type and grab the
bus information.

The API hasn't really changed - its just that bugs exist in the
documentation that need fixing before 2.6 comes out. Submit a
patch. 8)

Russell King ( The developer of ARM Linux

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:33    [W:0.071 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site