[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAPybu_1px6n4=bcF0=KyBVR4NR=ihrnDQTdfTH+wuWJ8UaZCHg@mail.gmail.com>
Date: Fri, 19 Jul 2013 10:03:12 +0200
From: Ricardo Ribalda Delgado <ricardo.ribalda@...il.com>
To: Marek Szyprowski <m.szyprowski@...sung.com>
Cc: Pawel Osciak <pawel@...iak.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
linux-media@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] videobuf2-dma-sg: Minimize the number of dma segments
Hello Marek
I have prepared a new set of patches, please take a look to them. The
series implements the coherent allocation, segments compaction and use
of sg_table, it does not implement the dma_map/dma_unmap/dma_sync, I
rather work on that one when you are back.
Thanks for your help
On Thu, Jul 18, 2013 at 3:34 PM, Marek Szyprowski
<m.szyprowski@...sung.com> wrote:
> Hello,
>
>
> On 7/18/2013 9:39 AM, Ricardo Ribalda Delgado wrote:
>>
>> Hello again:
>>
>> I have started to implemt it, but I think there is more hidden work in
>> this task as it seems. In order to call dma_map_sg and
>> max_dma_segment_size I need acess to the struct device, but (correct
>> me if I am wrong), vb2 is device agnostic. Adding the above
>> functionality will mean not only updating marvell-ccic and solo6x10,
>> but updating all the vb2 buffers.
>
>
> For getting device pointer, vb2-dma-sg need to be extended with so called
> 'allocator context'. Please check how it is done in vb2-dma-contig
> (vb2_dma_contig_init_ctx() function).
>
>
>
>> Also after some readings, maybe the sg compactation should not be done
>> here, but in dma_map_sg. According to the doc:
>>
>> """
>> The implementation is free to merge several consecutive sglist entries
>> into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
>> consecutive sglist entries can be merged into one provided the first one
>> ends and the second one starts on a page boundary - in fact this is a huge
>> advantage for cards which either cannot do scatter-gather or have very
>> limited number of scatter-gather entries) and returns the actual number
>> of sg entries it mapped them to. On failure 0 is returned.
>> """
>>
>> So, my proposal would be to alloc with alloc_pages to try to get
>> memory as coherent as possible, then split the page, set the sg in
>> PAGE_SIZE lenghts, and then let the dma_map_sg do its magic. if it
>> doesnt do compactation, fix dma_map_sg, so more driver could take
>> advantage of it.
>
>
> Right, this approach is probably the best one, but this way you would need
> to do the compaction in every dma-mapping implementation for every supported
> architecture. IMHO vb2-dma-sg can help dma-mapping by at least by allocating
> memory in larger chunks and constructing shorter scatter list. Updating
> dma-mapping functions across all architectures is a lot of work and testing,
> so for initial version we should focus on vb2-dma-sg. Memory allocators
> already do some work to ease mapping a buffer to dma space.
>
>
>> I could also of course fix marvell-ccic and solo6x10 to use sg_table.
>>
>> Does anything of this make sense?
>
>
> I would also like to help you as much as possible, but for the next 10 days
> I will be not available for both personal reasons and holidays. If you have
> any questions, feel free to leave them on my mail, I will reply asap I get
> back.
>
>
> Best regards
> --
> Marek Szyprowski
> Samsung R&D Institute Poland
>
>
--
Ricardo Ribalda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists