Hi,
On Fri, Jul 29, 2011 at 2:50 AM, Marek Szyprowski m.szyprowski@samsung.com wrote:
- 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.
- 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