Garrett D'Amore wrote: > Christian Kaiser wrote: >> Lu Baolu wrote: >> >>> On Wed, Dec 3, 2008 at 1:48 AM, Christian Kaiser >>> <[EMAIL PROTECTED]> wrote: >>> >>>> Hi all, >>>> >>>> I am currently porting a driver from Linux to Solaris. >>>> >>>> The Linux driver uses amongst others the following functions: >>>> >>>> virt_to_phys() >>>> virt_to_bus() >>>> phys_to_virt() >>>> bus_to_virt() >>>> >>>> As you can see, these functions translate virtual into physical or bus >>>> addresses and vice versa. >>>> Is there something similar available on Solaris? I am currently >>>> developing on SXCE b103. >>>> >>> Hi, >>> >>> You may refer to the code in rootnex_get_sgl(). You can find samples >>> there, but they are non-ddi. >>> >>> usr/src/uts/i86pc/io/rootnex.c, line 2393 >>> >>> 2387 /* >>> 2388 * rootnex_get_sgl() >>> 2389 * Called in bind fastpath to get the sgl. Most of this will >>> be replaced >>> 2390 * with a call to the vm layer when vm2.0 comes around... >>> 2391 */ >>> 2392 static void >>> 2393 rootnex_get_sgl(ddi_dma_obj_t *dmar_object, ddi_dma_cookie_t *sgl, >>> 2394 rootnex_sglinfo_t *sglinfo) >>> >> >> Thanks! >> >> I found out that hat_getpfnum() is used in rootnex_get_sgl(). I assume >> that since hat_getkpfnum() (the k makes the difference!) is not >> available on amd64, hat_getpfnum() (without k!) is the only way to >> find out the page frame number? Is that correct? >> >> Unfortunately, I don't know how the get the "hat" out of a virtual >> address that would be the first parameter to hat_getpfnum(). In the >> example it is taken from 'dmar_object' but I don't have such an object >> in my code. What else can I do? >> > > If you are writing a device driver, or porting one, then you're going > about this entirely the wrong way. These APIs should only be used by low > level platform code, not from within device drivers. In fact, > hat_getkpfnum generates warnings if you use it!
Thanks Garrett, but I am aware of this. I am using this internal functions just as a workaround until we have our driver ready that it does not need this conversion anymore. And this is a high priority on my todo-list. > Assuming that this is an ordinary device driver, and not something > really unusual (really unusual would mean something like a new MMU layer > or somesuch), then you need to use the Solaris DDI DMA interfaces. > > ddi_dma_alloc_handle() to get a handle. > ddi_dma_mem_alloc() to allocate memory (unless you already have memory). > ddi_dma_addr_bind_handle() to bind DMA addresses, and get the "cookie" > for the corresponding physical address. > ddi_dma_buf_bind_handle() if you're working buf(9S) structures instead > of arbitrary memory > > This may sound like more work, but the end result is portable and safe, > and will even work on amd64 and SPARC systems. Yes, and I am using them. In fact, I strictly use the DDI Interface with two exceptions that I am aware of. And my goal is to remove these two exceptions asap to have a clean driver! Christian -- Christian Kaiser, Software Engineer, Dolphin Interconnect Solutions http//www.dolphinics.com _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
