From: Arnd Bergmann <arnd@arndb.de>
To: "Roedel, Joerg" <Joerg.Roedel@amd.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
'Kyungmin Park' <kyungmin.park@samsung.com>,
'Kukjin Kim' <kgene.kim@samsung.com>,
'Sylwester Nawrocki' <s.nawrocki@samsung.com>,
'Andrzej Pietrasiewicz' <andrzej.p@samsung.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Date: Tue, 19 Apr 2011 17:37:30 +0200 [thread overview]
Message-ID: <201104191737.30916.arnd@arndb.de> (raw)
In-Reply-To: <20110419150018.GV2192@amd.com>
On Tuesday 19 April 2011, Roedel, Joerg wrote:
> > Getting back to our video codec - it has 2 IOMMU controllers. The codec
> > hardware is able to address only 256MiB of space. Do you have an idea how
> > this can be handled with dma-mapping API? The only idea that comes to my
> > mind is to provide a second, fake 'struct device' and use it for allocations
> > for the second IOMMU controller.
>
> The GPU IOMMUs can probably be handled in the GPU driver if they are
> that different. Recent PCIe GPUs on x86 have their own IOMMUs too which
> are very device specific and are handled in the device driver.
I tend to disagree with this one, and would suggest that the GPUs should
actually provide their own iommu_ops, even if they are the only users
of these.
However, this is a minor point that we don't need to worry about today.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver
Date: Tue, 19 Apr 2011 17:37:30 +0200 [thread overview]
Message-ID: <201104191737.30916.arnd@arndb.de> (raw)
In-Reply-To: <20110419150018.GV2192@amd.com>
On Tuesday 19 April 2011, Roedel, Joerg wrote:
> > Getting back to our video codec - it has 2 IOMMU controllers. The codec
> > hardware is able to address only 256MiB of space. Do you have an idea how
> > this can be handled with dma-mapping API? The only idea that comes to my
> > mind is to provide a second, fake 'struct device' and use it for allocations
> > for the second IOMMU controller.
>
> The GPU IOMMUs can probably be handled in the GPU driver if they are
> that different. Recent PCIe GPUs on x86 have their own IOMMUs too which
> are very device specific and are handled in the device driver.
I tend to disagree with this one, and would suggest that the GPUs should
actually provide their own iommu_ops, even if they are the only users
of these.
However, this is a minor point that we don't need to worry about today.
Arnd
next prev parent reply other threads:[~2011-04-19 15:37 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-18 9:26 [RFC/PATCH v3 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 9:26 ` [PATCH 1/7] ARM: EXYNOS4: power domains: fixes and code cleanup Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 9:26 ` [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 14:12 ` Arnd Bergmann
2011-04-18 14:12 ` Arnd Bergmann
2011-04-19 8:23 ` Marek Szyprowski
2011-04-19 8:23 ` Marek Szyprowski
2011-04-19 12:49 ` Arnd Bergmann
2011-04-19 12:49 ` Arnd Bergmann
2011-04-19 13:50 ` Roedel, Joerg
2011-04-19 13:50 ` Roedel, Joerg
2011-04-19 14:28 ` Arnd Bergmann
2011-04-19 14:28 ` Arnd Bergmann
2011-04-19 14:51 ` Roedel, Joerg
2011-04-19 14:51 ` Roedel, Joerg
2011-04-19 14:03 ` Marek Szyprowski
2011-04-19 14:03 ` Marek Szyprowski
2011-04-19 14:29 ` Arnd Bergmann
2011-04-19 14:29 ` Arnd Bergmann
2011-04-20 14:55 ` Marek Szyprowski
2011-04-20 14:55 ` Marek Szyprowski
2011-04-20 16:07 ` Arnd Bergmann
2011-04-20 16:07 ` Arnd Bergmann
2011-04-21 11:32 ` Marek Szyprowski
2011-04-21 11:32 ` Marek Szyprowski
2011-04-21 12:00 ` Arnd Bergmann
2011-04-21 12:00 ` Arnd Bergmann
2011-04-21 14:03 ` Marek Szyprowski
2011-04-21 14:03 ` Marek Szyprowski
2011-04-21 14:18 ` Arnd Bergmann
2011-04-21 14:18 ` Arnd Bergmann
2011-04-22 7:33 ` Marek Szyprowski
2011-04-22 7:33 ` Marek Szyprowski
2011-04-26 14:10 ` Arnd Bergmann
2011-04-26 14:10 ` Arnd Bergmann
2011-04-26 14:23 ` Marek Szyprowski
2011-04-26 14:23 ` Marek Szyprowski
2011-04-19 15:00 ` Roedel, Joerg
2011-04-19 15:00 ` Roedel, Joerg
2011-04-19 15:37 ` Arnd Bergmann [this message]
2011-04-19 15:37 ` Arnd Bergmann
2011-04-18 9:26 ` [PATCH 3/7] v4l: videobuf2: dma-sg: move some generic functions to memops Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 9:26 ` [PATCH 4/7] v4l: videobuf2: add IOMMU based DMA memory allocator Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 14:15 ` Arnd Bergmann
2011-04-18 14:15 ` Arnd Bergmann
2011-04-19 9:02 ` Marek Szyprowski
2011-04-19 9:02 ` Marek Szyprowski
2011-04-19 9:21 ` Russell King - ARM Linux
2011-04-19 9:21 ` Russell King - ARM Linux
2011-04-19 12:00 ` Arnd Bergmann
2011-04-19 12:00 ` Arnd Bergmann
2011-04-18 9:26 ` [PATCH 5/7] v4l: s5p-fimc: add pm_runtime support Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 9:26 ` [PATCH 6/7] v4l: s5p-fimc: Add support for vb2-dma-iommu allocator Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 9:26 ` [PATCH 7/7] ARM: EXYNOS4: enable FIMC on Universal_C210 Marek Szyprowski
2011-04-18 9:26 ` Marek Szyprowski
2011-04-18 13:24 ` [RFC/PATCH v3 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update Marek Szyprowski
2011-04-18 13:24 ` Marek Szyprowski
-- strict thread matches above, loose matches on Subject: below --
2011-04-05 14:06 [RFC/PATCH v2 " Marek Szyprowski
2011-04-05 14:06 ` [PATCH 2/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver Marek Szyprowski
2011-04-05 14:06 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201104191737.30916.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=Joerg.Roedel@amd.com \
--cc=andrzej.p@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=s.nawrocki@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.