public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters
Date: Tue, 02 Sep 2014 14:46:22 +0200	[thread overview]
Message-ID: <4561708.C5IqxBT0S9@wuerfel> (raw)
In-Reply-To: <5405B86C.9010704@samsung.com>

On Tuesday 02 September 2014 14:30:36 Marek Szyprowski wrote:
> >>>> However we also need to figure out how to let drivers to make their own
> >>>> configuration, like it is required by Exynos DRM subsystem, which consist
> >>>> of several devices, each having its own IOMMU controller, but for
> >>>> convenience those drivers assume that they all have been bound to the same,
> >>>> single domain.
> >>> IIRC with the way we ended up putting the mask into the iommu descriptor of
> >>> the ARM SMMU, you can put multiple devices into the same iommu group, and
> >>> have them automatically share a domain.
> >>>
> >>> I don't know if the same would work for the Samsung implementation.
> >> The question is how to transfer such information from the device
> >> drivers, that
> >> need/benefit from such configuration to iommu driver, which does all the
> >> setup?
> >> This is something completely internal to particular drivers and should
> >> not be
> >> exported to device tree or userspace. Thierry suggested to hardcode this
> >> information in the iommu driver, but I'm looking for other approaches.
> >> Maybe simply releasing device from the default dma-mapping domain before
> >> attaching to custom one will be the easiest solution.
> > For the ARM SMMU, the problem is that there is not necessarily a good way
> > to partition the masters into IOMMU groups automatically, therefore we
> > want to provide some hints in DT. On a machine that can have more domains
> > than it has masters, this is not a problem and we can always use an
> > all-ones mask, but for a machine on which this is not the case, the
> > problem is simplified a lot of we hardcode the masks in a way that can
> > always work, putting multiple devices into an iommu group if necessary.
> 
> Well, I was talking about the Exynos IOMMU case, where there are no hw
> restrictions and grouping is done just to make things easier for the Exynos
> DRM drivers (a buffer gets the same DMA address for all devices, which
> are a part of virtual Exynos DRM device).

Does that mean you don't actually need to use multiple contexts here and
could actually just use the normal dma-mapping interface if there is
a way to ensure the mappings are always shared across these masters?

Or do you need this in addition to being able to use multiple masters
so you can have multiple rendering contexts in user space?

	Arnd

  reply	other threads:[~2014-09-02 12:46 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29 15:54 [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Will Deacon
2014-08-29 15:54 ` [RFC PATCH 1/7] iommu: provide early initialisation hook for IOMMU drivers Will Deacon
2014-09-01  7:52   ` Thierry Reding
2014-09-01 14:31     ` Arnd Bergmann
2014-09-01 16:36       ` Will Deacon
2014-09-02  6:56     ` Laurent Pinchart
2014-09-02 14:47   ` Varun Sethi
2014-09-02 15:04     ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 2/7] dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_ops Will Deacon
2014-09-01 14:27   ` Arnd Bergmann
2014-09-01 16:20     ` Will Deacon
2014-08-29 15:54 ` [RFC PATCH 3/7] iommu: add new iommu_ops callback for adding a device with a set of IDs Will Deacon
2014-09-01  8:13   ` Thierry Reding
2014-09-01 14:39     ` Arnd Bergmann
2014-09-01 16:34       ` Will Deacon
2014-09-01 17:18         ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 4/7] iommu: provide helper function to configure an IOMMU for an of master Will Deacon
2014-09-01  8:29   ` Thierry Reding
2014-09-01 14:46     ` Arnd Bergmann
2014-09-01 16:40       ` Will Deacon
2014-09-01 20:18         ` Arnd Bergmann
2014-09-02 10:03           ` Will Deacon
2014-09-02 12:15             ` Arnd Bergmann
2014-09-02 13:05               ` Will Deacon
2014-09-02 14:01                 ` Arnd Bergmann
2014-09-02 20:59                   ` jroedel at suse.de
2014-09-03  9:45                     ` Will Deacon
2014-09-02 15:03               ` Varun Sethi
2014-09-02 15:08                 ` Arnd Bergmann
2014-09-02 10:23       ` Laurent Pinchart
2014-09-02 10:51   ` Laurent Pinchart
2014-09-02 11:03     ` Will Deacon
2014-09-02 19:08       ` Laurent Pinchart
2014-09-02 14:55   ` Varun Sethi
2014-08-29 15:54 ` [RFC PATCH 5/7] dma-mapping: detect and configure IOMMU in of_dma_configure Will Deacon
2014-09-01 14:53   ` Arnd Bergmann
2014-08-29 15:54 ` [RFC PATCH 6/7] arm: call iommu_init before of_platform_populate Will Deacon
2014-08-29 15:54 ` [RFC PATCH 7/7] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops Will Deacon
2014-09-02  6:26 ` [RFC PATCH 0/7] Introduce automatic DMA configuration for IOMMU masters Marek Szyprowski
2014-09-02  8:31   ` Will Deacon
2014-09-02  8:48     ` Marek Szyprowski
2014-09-02  8:56       ` Arnd Bergmann
2014-09-02 10:42         ` Marek Szyprowski
2014-09-02 10:57           ` Will Deacon
2014-09-02 12:24             ` Marek Szyprowski
2014-09-02 12:43               ` Arnd Bergmann
2014-09-02 21:50                 ` Laurent Pinchart
2014-09-02 12:22           ` Arnd Bergmann
2014-09-02 12:30             ` Marek Szyprowski
2014-09-02 12:46               ` Arnd Bergmann [this message]
2014-09-02 13:11                 ` 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=4561708.C5IqxBT0S9@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox