Hi, On 10-2-13 上午3:29, olafbuddenha...@gmx.net wrote: > >> antrik said this implementation isn't consistent with Mach's memory >> management and I should make it work like device_map, so there will be >> a pager in the kernel. I basically agree with that. What should the >> interface be? any suggestions? > > It should be something along these lines I think: > > kern_return_t mach_get_dma_pages ( > host_priv_t host_priv, > vm_size_t size, > mach_port_t *pager, > vm_offset_t *phys_addr, > mach_dma_flags_t flags > ) > > The last parameter would contain various options, like restricting to > first 32 MiB of RAM (for ISA DMA) or first 4 GiB (for many other > devices). Not sure whether we actually need any other options -- > otherwise, perhaps this should get a more specific name. > > "pager" returns a memory object, which can then be used in a vm_map() > call. "phys_addr" returns the physical address of the allocated region, > used to program the DMA hardware. OK. > > BTW, I'm not sure about handling scatter-gather DMA. This still needs > the physical addresses to be stable during the transfer, and available > to the driver; but the region needn't be contiguous... So I guess we > could just use "normal" memory (ideally passed directly from/to the > clients); wire it; and use some other special function to obtain the > physical addresses of each page. Maybe it can work, but I'm still far from that right now:-) > >> + kfree (pages, npages * sizeof (vm_page_t)); >> + vm_pages_release (npages, pages, TRUE); > > This looks wrong -- freeing the "pages" array before using it to free > the actual pages... But I doubt it is related to the problem you are > experiencing, considering that this is just an error path. Right, it's a bug. > > (Also, I don't think the extra vm_pages_release() function is really > useful, considering that it's just a very simple loop, and used only in > a single place... But here I am nitpicking again :-) ) I don't know why I did it. I cannot give a reason myself:-)
Zheng Da
