Hi, On Fri, Jul 29, 2011 at 2:50 AM, Marek Szyprowski <m.szyprowski@xxxxxxxxxxx> wrote: >> 1. There is no way to keep track of what virtual address are being mapped >> in the scatterlist, which we need to propagate to the dsp, in order that it >> knows where does the buffers start and end on its virtual address space. >> I ended up adding an iov_address to scatterlist which if accepted should be >> toggled/affected by the selection of CONFIG_IOMMU_API. > > Sorry, but your patch is completely wrong. You should not add any additional > entries to scatterlist. At the time it was the easiest way for me to keep track of both virtual and physical addresses, without doing a page_to_phys every time on unmap. I understand that it might fall out of the scope of the scatterlist struct. > dma_addr IS the virtual address in the device's io > address space, so the dma_addr is a value that your device should put into > it's own registers to start dma transfer to provided memory pages. I also wanted to keep the same part as the original arm_dma_map_sg: s->dma_address = __dma_map_page... Where the dma_address was the "clean" (from cache) physical address. But if desired, I guess this value can be replaced for the iommu va. >> 2. tidspbridge driver sometimes needs to map a physical address into a >> fixed virtual address (i.e. the start of a firmware section is expected to >> be at dsp va 0x20000000), there is no straight forward way to do this with >> the dma api given that it only expects to receive a cpu_addr, a sg or a >> page, by adding iov_address I could pass phys and iov addresses in a sg >> and overcome this limitation, but, these addresses belong to: > > We also encountered the problem of fixed firmware address. We addressed is by > setting io address space start to this address and letting device driver to > rely on the fact that the first call to dma_alloc() will match this address. Indeed, however in my case, I need sections at (I might have approximated the numbers to the real ones): 0x11000000 for dsp shared memory 0x11800000 for peripherals 0x20000000 for dsp external code 0x21000000 for mapped buffers The end of a section and start of the other usually have a gap, so the exact address needs to be specified by the firmware. So, this won't work with just letting the pool manager to provide the virtual address. >> 2a. Shared memory between ARM and DSP: this memory is allocated through >> memblock API which takes it out of kernel control to be later >> ioremap'd and iommu map'd to the dsp (this because a non-cacheable >> requirement), so, these physical addresses doesn't have a linear >> virtual address translation, which is what dma api expects. > > I hope that the issue with page cache attributes can be resolved if we always > allocate memory from CMA (see the latest CMAv12 patches: > http://www.spinics.net/lists/linux-media/msg35674.html ) I'll take a look more closely and will be trying them if possible. >> 2b. Bus addresses: of dsp peripherals which are also ioremap'd and >> affected by the same thing. > > Right now I have no idea how to handle ioremapped areas in dma-mapping > framework, but do we really need to support them? It would be good to know if this is expected to be handled by dma-mapping, otherwise it can be dealt by iommu api as Joerg pointed out. Thanks for your comments, Omar -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href