lkml.org 
[lkml]   [1999]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Address spaces on a i386 - Getting Confused (fwd)
Ramakrishna K wrote:
> I am not familiar with Linux code.
>
> But a solution to DMA'ing to user-space will be
> a) lock the relevant user range into memory.
> b) touch them to fault the pages in.
> c) Then trap into the kernel using an ioctl to set up kernel address for this
> range. ( I bet there must be some VM calls to acheive that ). What i mean
> is that get the pages behind the locked user-address behind the kernel address.
> d) Do the DMA to these pages.
> e) Release the kernel-mappings.

You make it sound so simple. Unfortunately it isn't.

c) as you describe not possible: In the kernel, a "kernel address" that
can be DMA'd using the documented method (virt_to_bus) is in the direct
mapped region. On i386, that's the region from 0xc0000000 up.

You can set up a kernel-space mapping (similar to vmalloc), however DMA
using virt_to_bus doesn't work for them.

The device driver must be written to divide its DMA requirements into
regions that don't cross non-contiguous page boundaries. It must look
up the physical address from user-space (an architecture specific thing
for which there is no reliable macro yet). It must translate the
physical address to a bus address. (Possible using
virt_to_bus(phys_to_virt()) for the moment).

As a future problem, some user-space pages will not be reachable by DMA
anyway, because they are outside the bus address range of the device
doing DMA. (cf. 32-bit PCI cards on >4GB memory machines, or
complexities of multi-bus machines).

The kmalloc()/mmap() method, while not as automatic from user-space, is
still by far the easiest method.

Enjoy,
-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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