Hi Marek,
The patches for "CMA and get_user_pages" seems to be year old as per the
mailing list link
http://lists.linaro.org/pipermail/linaro-mm-sig/2013-March/003090.html
Is there any latest patch-set for this feature and any updates whether
these patches are to be pushed into main stream kernel sooner.
Thanks!!!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
The following series implements small updates to the fence api.
I've found them useful when implementing the fence API in ttm and i915.
The last patch enables RCU on top of the api. I've found this less
useful, but it was the condition on which Thomas Hellstrom was ok
with converting TTM to fence, so I had to keep it in.
If nobody objects I'll probably merge that patch through drm, because
some care is needed in ttm before it can flip the switch on rcu.
---
Maarten Lankhorst (2):
reservation: update api and add some helpers
[RFC] reservation: add suppport for read-only access using rcu
On Wed, 14 May 2014 10:15:38 +0100, "Jon Medhurst (Tixy)" <tixy(a)linaro.org> wrote:
> On Sun, 2014-03-02 at 13:40 +0800, Grant Likely wrote:
> > On Fri, 28 Feb 2014 14:42:50 +0100, Marek Szyprowski <m.szyprowski(a)samsung.com> wrote:
> > > This patch adds code for automated assignment of reserved memory regions
> > > to struct device. reserved_mem->ops->device_init()/device_cleanup()
> > > callbacks are called to perform reserved memory driver specific
> > > initialization and cleanup
> > >
> > > Based on previous code provided by Josh Cartwright <joshc(a)codeaurora.org>
> > >
> > > Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com>
> >
> > Hi Marek,
> >
> > I've not applied this one yet, only because there is still the open
> > issue of whether or not these functions should be called from drivers or
> > from core code. I don't actually have any problems with the content of
> > this patch. Once the user is sorted out I'll merge it.
>
> Has anything more come of these patches? I see some of the series is now
> in Linux 3.15, but the actual patches to let people use the feature
> aren't there yet, namely patches 5 though 8.
>
> My personal immediate interest in these is as a mechanism on arm64 to
> limit CMA to a region of memory that is actually DMA-able devices (e.g.
> below 4GB for 32-bit devices without an iommu).
>
> For reference, the mail archives for this series is at
> http://lkml.org/lkml/2014/2/28/237
IIRC, the issue I have with patch 5-8 is that I don't like the driver core
going off and doing automagical things to attach regions to devices.
I've not seen any more discussion on this topic since I merged the
patches I was okay with, but I may have missed something.
g.
On 5/12/2014 7:37 AM, Pintu Kumar wrote:
> Hi,
> Thanks for the reply.
>
> ----------------------------------------
>> From: arnd(a)arndb.de
>> To: linux-arm-kernel(a)lists.infradead.org
>> CC: pintu.k(a)outlook.com; linux-mm(a)kvack.org; linux-kernel(a)vger.kernel.org; linaro-mm-sig(a)lists.linaro.org
>> Subject: Re: Questions regarding DMA buffer sharing using IOMMU
>> Date: Mon, 12 May 2014 14:00:57 +0200
>>
>> On Monday 12 May 2014 15:12:41 Pintu Kumar wrote:
>>> Hi,
>>> I have some queries regarding IOMMU and CMA buffer sharing.
>>> We have an embedded linux device (kernel 3.10, RAM: 256Mb) in
>>> which camera and codec supports IOMMU but the display does not support IOMMU.
>>> Thus for camera capture we are using iommu buffers using
>>> ION/DMABUF. But for all display rendering we are using CMA buffers.
>>> So, the question is how to achieve buffer sharing (zero-copy)
>>> between Camera and Display using only IOMMU?
>>> Currently we are achieving zero-copy using CMA. And we are
>>> exploring options to use IOMMU.
>>> Now we wanted to know which option is better? To use IOMMU or CMA?
>>> If anybody have come across these design please share your thoughts and results.
>>
>> There is a slight performance overhead in using the IOMMU in general,
>> because the IOMMU has to fetch the page table entries from memory
>> at least some of the time.
>
> Ok, we need to check performance later
>
>>
>> If that overhead is within the constraints you have for transfers between
>> camera and codec, you are always better off using IOMMU since that
>> means you don't have to do memory migration.
>
> Transfer between camera is codec is fine. But our major concern is single buffer
> sharing between camera & display. Here camera supports iommu but display does not support iommu.
> Is it possible to render camera preview (iommu buffers) on display (not iommu and required physical contiguous overlay memory)?
>
I'm pretty sure the answer is no for zero copy IOMMU buffers if one of your
devices does not support IOMMU. If the data is coming in as individual pages
and the hardware does not support scattered pages there isn't much you can
do except copy to a contiguous buffer. At least with Ion, the heap types can
be set up in a particular way such that the client need never know about the
existence of an IOMMU or not.
> Also is it possible to buffer sharing between 2 iommu supported devices?
>
I don't see why not but there isn't a lot of information to go on here.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
On Monday 12 May 2014 15:12:41 Pintu Kumar wrote:
> Hi,
> I have some queries regarding IOMMU and CMA buffer sharing.
> We have an embedded linux device (kernel 3.10, RAM: 256Mb) in
> which camera and codec supports IOMMU but the display does not support IOMMU.
> Thus for camera capture we are using iommu buffers using
> ION/DMABUF. But for all display rendering we are using CMA buffers.
> So, the question is how to achieve buffer sharing (zero-copy)
> between Camera and Display using only IOMMU?
> Currently we are achieving zero-copy using CMA. And we are
> exploring options to use IOMMU.
> Now we wanted to know which option is better? To use IOMMU or CMA?
> If anybody have come across these design please share your thoughts and results.
There is a slight performance overhead in using the IOMMU in general,
because the IOMMU has to fetch the page table entries from memory
at least some of the time.
If that overhead is within the constraints you have for transfers between
camera and codec, you are always better off using IOMMU since that
means you don't have to do memory migration.
Note however, that we don't have a way to describe IOMMU relations
to devices in DT, so whatever you come up with to do this will most
likely be incompatible with what we do in future kernel versions.
Arnd