On Wednesday 01 March 2006 22:18, Jonathan Stone wrote:
> In message <200602191932.39840.hselasky@c2i.net>Hans Petter Selasky writes
>
> >Hi,
> >
> >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()":
>
> [...]
>
> >u_int32_t
> >usb_vtophys(void *ptr, u_int32_t size)
> >{
> >    struct usb_dma *arg = (void *)(((u_int8_t *)ptr) + size);
> >    return arg->seg.ds_addr;
> >}
>
> Hans Petter,
>
> 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?

Currently all PCI USB controllers use 32-bit physical addresses, so there is 
no need for anything more than 32-bits. Maybe I should use u_int64_t. It is 
not a big deal to change it.

> 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?

Yes, it is just for convenience. The function should return the physical 
address relative to the parenting PCI bus, which the hardware is on, which 
should be programmed into the hardware.

>
> 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???)

Yes, right, but changing it to 64-bits is not a big deal. Maybe I should use 
bus_addr_t like you suggest.

> ... 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?

Sure, but what name is appropriate for the function ?

--HPS