Changes since v1:
- Updated commit logs of patches 1 and 3.
- Added patches for tw68 and cx23885.
The patch series adds an allocation context to dma-sg and uses that to move
dma_(un)map_sg into the vb2 framework, which is where it belongs.
Related to that is the addition of buf_prepare/finish _for_cpu variants,
where the _for_cpu ops are called when the buffer is synced for the cpu, and
the others are called when it is synced to the device.
DMABUF export support is added to dma-sg and vmalloc, so now all memory
models support DMABUF importing and exporting.
A new flag was added so drivers know when the DMA engine should be
(re)programmed. This is primarily needed for the dma-sg memory model.
Reviews are very welcome.
There is one thing I am not happy about: the addition of the 'new_cookies'
flag. The idea is that if it is set, then the driver has to setup the
DMA engine descriptors in buf_prepare(). This avoids creating the DMA
descriptors in every buf_prepare and deleting them again for every buf_finish.
The problem is that when using the new flag the cleanup of those descriptors
can't be done in buf_finish anymore since when that op is called you do not
yet know if the descriptors need to be updated. Instead the cleanup has to
happen in buf_cleanup(). The tw68 patch is a good example of that.
Unfortunately, this sequence is asymmetrical.
I cannot think of a good alternative. The only slight improvement that might
be worth doing is that the vb2 core also sets new_cookies when buf_cleanup()
needs to cleanup the descriptors. There is a corner case where buf_cleanup
doesn't need to do that (e.g. if buf_prepare returned an error), and right
now drivers need to detect that. It's probably better to move that logic
to the vb2 core.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
