[lkml]   [2003]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: *dma_sync_single API change to support non-coherent cpus
On Mon, Mar 03, 2003 at 07:58:25PM +0000, Russell King wrote:
> On Mon, Mar 03, 2003 at 11:18:48AM -0700, Matt Porter wrote:
> > On non cache coherent processors, it is necessary to perform
> > cache operations on the virtual address associated with the
> > buffer to ensure consistency. There is one problem, however,
> > the current API does not provide the virtual address for the
> > buffer. It only provides the bus address in the dma_addr_t.
> > On arm and mips, this is dealt with by simply doing bus_to_virt().
> > However, bus_to_virt() isn't valid for all addresses that could
> > have been passed into *map_single().
> I find myself thinking, in passing, why we don't have these
> architectures define something like the following in architecture
> specific code:
> struct dma_addr {
> unsigned long cpu;
> unsigned long bus;
> unsigned long size;
> };


> Architectures which only need the CPU address can place only that in
> their structure definition, and make dma_map_single and friends no-ops.
> I feel that this would get rid of all the shouting DMA_* macros found
> in various pci.h header files.
> This may be something considering for 2.7 though.

I like this abstraction of dma_addr. As you suggest, it's probably
significant enough to be only considered for 2.7. I was shooting
for the minimal API change for 2.5/2.6 to make non-coherent
processors functional. I seriously don't want to submit a
documentation patch clarifying that this API is only valid for
certain addresses. :)

Matt Porter
This is Linux Country. On a quiet night, you can hear Windows reboot.
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.033 / U:10.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site