Mark Johnson writes: > > > Andrew Gallatin wrote: > > I was just reading up on mmap in Solaris drivers, and I'm > > afraid I may have a problem...: > > > > I need to allocate and map into userspace a bunch of 128KB buffers. > > The buffers need to be physically contiguous in DMA space, and > > virtually contiguous in userspace. This has to run on amd64, so I > > can't use an IOMMU to make discontiguous 4KB pages contiguous. > > > > According to devmap_umemem_setup(9f), I'm supposed to use > > devmap_umem_setup() for kernel memory, and I need to pass a > > ddi_umem_cookie_t. The ddi_umem_cookie_t means (I think) that I must > > allocate the memory via ddi_umem_alloc(), and I don't think that will > > allocate anything larger than a single page physically contiguous. > > > > Is there any way I can use ddi_dma_alloc_mem_alloc() (or something > > else) to get 128KB physically contiguous and map that out? > > > > Or.... Is it still acceptable to supply a cb_mmap() and use the nice, > > simple, straightforward old way of returning a page frame number? > > Unfortunately, there isn't a way to do this with the DDI > today. We have an RFE out there to fix it... > > You can do something similar to xsvc_umem_cookie_alloc()/ > xsvc_umem_cookie_free(). e.g. pass in a kva returned > from ddi_dma_mem_alloc(). > > The RFE will probably create ddi_umem_cookie_alloc()/ddi_umem_cookie_free(). > > disclaimers: doing this is totally unsupported, could > break in a new solaris revision, or even patch.
Thanks, but the disclaimer is kind of scary :) Will the old hat_getkpfnum based mmap entry point still work? Drew _______________________________________________ driver-discuss mailing list driver-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/driver-discuss
