> On Sun, 12 Dec 1999, Terence Ripperda wrote:
> >
> > One of the things I'd like to be able to do is allocate DMA buffers in the
> > kernel and remap those to user space. remap_page_range looks like it
> > provides the functionality I need, but of course only works on non-RAM
> > memory addresses and "reserved" pages.
>
> Check out Alan Cox's 2.3.18ac patch series. It includes a dmaram driver
> which does exactly what you describe here, if I'm not mistaken.
close, but there's still some issues I'm not quite clear on.
In the dmaram patch, Alan uses set_bit() to set the reserved bit on the
memory pages so that remap_page_range() can remap the pages to user space.
In the bttv driver the same thing is done, with the mem_map_reserve()
wrapper.
My question is, is this clean? Is it ok for a driver to fiddle with kernel
mm details like that? What happens if drivers forget to unreserve() the
pages when done, are they kernel memory leaks? (shades of windows
"resources" depleting over time)
Would it be cleaner for a remappable_malloc() function that hides these
details from a module? (perhaps the aforementioned memory leaks are
unavoidable, even in this case?)
> > Would such code likely be accepted into the kernel, or are there
> > reasons for avoiding such functionality?
>
> There is ioremap_nocache and io_remap_page_range, but I don't think
> those are applicable to your situation.
correct. AGP is non-cache-coherent. So, say I fill a DMA buffer, and
signal the hardware to start pulling. Unlike PCI, there's no snoop to make
sure all data is indeed flushed from the buffers and in RAM. So, I either
need to mark the memory uncacheable, or issue a cache flush between
filling the buffer and signaling the hardware.
Although PATs for marking memory uncacheable/etc are relatively new, cache
flushes aren't, so I was surprised to not see them (actually, the macros
are there, just defined to nothing).
I just wanted to probe the waters and see if there was a reason to
avoiding that functionality.
Terence
-
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/