Hi Rebecca, From: Rebecca Schultz Zavin <rebecca@xxxxxxxxxxx> Subject: Re: [RFC][PATCH 1/1] gpu: ion: Add IOMMU heap allocator with IOMMU API Date: Wed, 18 Jan 2012 22:58:47 +0100 Message-ID: <CALJcvx58x60HvHMCLkR48rHuZWTYL-aYc43hmW7Kk8=qYC1Jgw@xxxxxxxxxxxxxx> > Hi, > > I'm just ramping back up after being on maternity leave so I'm > pretty buried under on the lists. Please do continue to CC me > directly on ION related work. Congrats! and I'll put you on Cc:. >> On Tue, Jan 17, 2012 at 11:40 PM, Hiroshi Doyu <hdoyu@xxxxxxxxxx<mailto:hdoyu@xxxxxxxxxx>> wrote: >> Hi, >> >> Recently we've implemented IOMMU heap as an attachment which is one of >> the ION memory manager(*1) heap/backend. This implementation is >> completely independent of any SoC, and this can be used for other SoC >> as well. If our implementation is not totally wrong, it would be nice >> to share some experience/code here since Ion is still not so clear to >> me yet. > > I will take a look at your review this code as soon as I can. The > intention is to take contributions like these so keep them coming. Thanks. >> I found that Linaro also seems to have started some ION work(*2). I >> think that some of Ion feature could be supported/replaced with Linaro >> UMM. For example, presently "ion_iommu_heap" is implemented with the >> standard IOMMU API, but it could be also implemented with the coming >> DMA API? Also DMABUF can be used in Ion core part as well, I guess. > > It is my intention to leverage the DMABUF api as much as I can. > I'll be going back over the work on the DMA api over the next few > weeks and thinking about how to integrate the two solutions. Good. >> Currently there's no Ion memmgr code in the upstream >> "drivers/staging/android"(*3). Is there any plan to support this? Or >> is this something considered as a completely _temporary_ solution, and >> never going to be added? > > I expect this is an oversight that occurred when the android drivers > were added back to staging. It's not intended to be a temporary > solution. That being said, I'm not sure I want to push for it in > staging. I'd rather give it a little more time to bake and then at > some post it as a patch set. > > >> It would be nice if we can share some of our effort here since not >> small Android users need Ion, even temporary. > > Agreed! Keep sending things my way and I'll get feedback to you as > quickly as I can. The following patch may be helpful for this review. This Ion IOMMU heap patch depends on the following iommu_ops, "GART" and "SMMU" patches, which is the IOMMU API backend for Tegra20/30. https://lkml.org/lkml/2012/1/5/25 So currently as long as the standard IOMMU API is usable in any SoC, this Ion IOMMU heap could work. I think that DMA API could replace this eventually. > > > Any comment would be really appreciated. > > Hiroshi DOYU > > *1: https://android.googlesource.com/kernel/common.git > $ git clone https://android.googlesource.com/kernel/common.git > $ cd common > $ git checkout -b android origin/android-3.0 > $ git grep -e "<linux/ion.h>" drivers/ > > drivers/gpu/ion/ion.c:#include <linux/ion.h> > drivers/gpu/ion/ion_carveout_heap.c:#include <linux/ion.h> > drivers/gpu/ion/ion_heap.c:#include <linux/ion.h> > drivers/gpu/ion/ion_priv.h:#include <linux/ion.h> > drivers/gpu/ion/ion_system_heap.c:#include <linux/ion.h> > drivers/gpu/ion/ion_system_mapper.c:#include <linux/ion.h> > drivers/gpu/ion/tegra/tegra_ion.c:#include <linux/ion.h> > > *2: https://blueprints.launchpad.net/linaro-mm-sig/+spec/linaro-mmwg-cma-ion > *3: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=tree;f=drivers/staging/android;h=4a70996505b423f12e2ea61d0aad3d9b0cc7a5c0;hb=HEAD > -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
