Subject: Re: bus_dmamem question
To: Hans Petter Selasky <email@example.com>
From: Jonathan Stone <jonathan@Pescadero.dsg.stanford.edu>
Date: 03/01/2006 13:18:58
In message <firstname.lastname@example.org>Hans Petter Selasky writes
>Can someone here help get the following BUS-DMA code right? Currently
>"usb_alloc_mem()" works, but "usb_free_mem()" will cause a "uvm_fault()":
>usb_vtophys(void *ptr, u_int32_t size)
> struct usb_dma *arg = (void *)(((u_int8_t *)ptr) + size);
> return arg->seg.ds_addr;
Can I ask: what is the semantics of vtophys()? I expect you're already
well aware that exposing real physical addresses (a` la classic
FreeBSD-4 vtophys()) is completely unacceptable for a
machine-independent NetBSD driver. That would defeat the whole
purpose of NetBSD's bus_space(9)/bus_dma(9) APIs.
I don't see usb_vtophys(9) documented anywhere NetBSD-3-stable. Are
there other resources which explain this API which I should be
checking, to help me understand your code-fragment?
Are you really expecting a physical address here, or is this some
convenient way to get at a single bus-dma opaque cookie, in an
already-existing dma_map, corresponding to the given kva?
if the latter, I don't see how a u_int32_t can *ever*, under any
circumstances, be a correct machine-independent type for this
function. (How would it work on a machine where a bus_addr_t is bigger
than 32 bits???)
Is there something else going on here I'm overlooking, or not seeing,
perhaps due to your email showing only part of a larger picture? If
that's so, can that "something else" be clearly documented before this
code becomes a candidate for inclusion in NetBSD?
... If nothing else, and assuming the overall aim of the code you're
working on is a Good Thing: can we at least change the name to remove
the word "vtophys", to avoid any unecessary worry and confusion?