[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <027701cd81fe$0ed356a0$2c7a03e0$%szyprowski@samsung.com>
Date: Fri, 24 Aug 2012 15:40:38 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: 'Federico Vaga' <federico.vaga@...il.com>
Cc: 'Mauro Carvalho Chehab' <mchehab@...radead.org>,
'Pawel Osciak' <pawel@...iak.com>,
'Hans Verkuil' <hans.verkuil@...co.com>,
'Giancarlo Asnaghi' <giancarlo.asnaghi@...com>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
'Jonathan Corbet' <corbet@....net>,
Tomasz Stanislawski <t.stanislaws@...sung.com>
Subject: RE: [PATCH 2/3] [media] videobuf2-dma-streaming: new videobuf2 memory
allocator
Hello,
On Friday, August 24, 2012 3:23 PM Federico Vaga wrote:
> > Getting back to your patch - in your approach cpu cache handling is
> > missing. I suspect that it worked fine only because it has been
> > tested on some simple platform without any cpu caches (or with very
> > small ones).
>
> Is missing from the memory allocator because I do it on the device
> driver. The current operations don't allow me to do that in the memory
> allocator.
Memory allocator module is much more appropriate place for it. dma-sg
allocator also needs a huge cleanup in this area...
> > Please check the following thread:
> > http://www.spinics.net/lists/linux-media/msg51768.html where Tomasz
> > has posted his ongoing effort on updating and extending videobuf2 and
> > dma-contig allocator. Especially the patch
> > http://www.spinics.net/lists/linux-media/msg51776.html will be
> > interesting for you, because cpu cache synchronization
> > (dma_sync_single_for_device / dma_sync_single_for_cpu) should be
> > called from prepare/finish callbacks.
>
> You are right, it is interesting because avoid me to use cache sync in
> my driver. Can I work on these patches?
>
> From this page I understand that these patches are not approved yet
> https://patchwork.kernel.org/project/linux-media/list/?page=2
You can take the patch which adds prepare/finish methods to memory
allocators. It should not have any dependency on the other stuff from
that thread. I'm fine with merging it either together with Your patch
or via Tomasz's patchset, whatever comes first.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
--
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