Hello,
On 7/17/2013 4:20 PM, Ricardo Ribalda Delgado wrote:
Hello again Marek
In my system I am doing the scatter gather compaction on device
driver... But I agree that it would be better done on the vb2 layer.
For the oversize sglist we could do one of this two things.
If we want to have a simple pass processing we have to allocate an
structure A for the worts case, work on that structure. then allocate
a structure B for the exact size that we need, memcpy A to B, and
free(A).
Otherwise we need two passes. One to allocate the pages, and another
one to allocate the pages and find out the amount of sg, and another
to greate the sg structure.
What do you prefer?
I would prefer two passes approach. In the first pass you just fill the
buf->pages array with order 0 entries and count the total number of memory
chunks (adding support for max dma segment size at this point should be
quite easy). In the second pass you just allocate the scatter list and
fill it with previously allocated pages.
I have also the following changes on my TODO list for vb2-dma-sg:
- remove custom vb2_dma_sg_desc structure and replace it with common
sg_table structure
- move mapping of the scatter list from device driver to vb2-dma-sg module
to simplify driver code and unify memory management across devices (so the
driver just gets correctly mapped scatter list and only reads dma addresses
of each memory chunk, no longer needs to track buffer state/ownership).
The correct flow is to call dma_map_sg() at buffer allocation,
dma_unmap_sg() at free and dma_sync_for_{device,cpu} in prepare/finish
callbacks. The only problem here is the need to convert all existing users
of vb2-dma-sg (marvell-ccic and solo6x10) to the new interface.
However I have completely no time atm to do any of the above changes. Would
You like to take any of the above tasks while playing with vb2-dma-sg?
Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
