From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Date: Wed, 17 Dec 2014 18:02:51 +0200 [thread overview]
Message-ID: <3147207.bM49L5sBIQ@avalon> (raw)
In-Reply-To: <2560037.PCKFDiopkL@wuerfel>
Hi Arnd,
On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
> > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > > > If we forbid the IOMMU driver from being compiled as a module can't we
> > > > just rely on deferred probing ? The bus master driver will just be
> > > > reprobed after the IOMMU gets probed, like for other devices.
> > > >
> > > > This could fail in case the IOMMU device permanently fails to probe.
> > > > There
> > > > would be something very wrong in the system in that case, Enabling the
> > > > bus
> > > > masters totally transparently without IOMMU support could not be such
> > > > a
> > > > good idea.
> > >
> > > I believe in the majority of cases today, the IOMMU is entirely
> > > optional.
> > > There are valid reasons for not including the IOMMU driver in the
> > > kernel,
> > > e.g. when you know that all the machines with that driver can DMA to
> > > all of their RAM and you want to avoid the overhead of IOTLB misses.
> >
> > Should that really be controlled by compiling the IOMMU driver out,
> > wouldn't it be better to disable the IOMMU devices in DT in that case ?
>
> It's a policy decision that should only depend on the user. Modifying the
> DT is wrong here IMHO because the device is still connected to the IOMMU
> in hardware and we should correctly represent that.
I was thinking about setting status = "disabled" on the IOMMU nodes, not
removing the IOMMU references in the bus master nodes.
> You can normally set 'iommu=off' or 'iommu=force' on the command line
> to force it on or off rather than letting the IOMMU driver decide whether
> the device turns it on. Not enabling the IOMMU at all should really just
> behave the same way as 'iommu=off', anything else would be very confusing.
Setting iommu=off sounds fine to me. The IOMMU core would then return a "no
IOMMU present" error instead of -EPROBE_DEFER, and probing of the bus masters
would continue without IOMMU support.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-12-17 16:02 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 11:15 [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 01/19] iommu: fix const qualifier in of_iommu_set_ops Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 02/19] iommu: fix initialization without 'add_device' callback Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 03/19] arm: dma-mapping: add missing check for iommu Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 04/19] drm: exynos: detach from default dma-mapping domain on init Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 05/19] arm: exynos: pm_domains: add support for devices registered before arch_initcall Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 06/19] ARM: dts: exynos4: add sysmmu nodes Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 07/19] iommu: exynos: don't read version register on every tlb operation Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 08/19] iommu: exynos: remove unused functions Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 09/19] iommu: exynos: remove useless spinlock Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 10/19] iommu: exynos: refactor function parameters to simplify code Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 11/19] iommu: exynos: remove unused functions, part 2 Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 12/19] iommu: exynos: remove useless device_add/remove callbacks Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 13/19] iommu: exynos: add support for binding more than one sysmmu to master device Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 14/19] iommu: exynos: add support for runtime_pm Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 15/19] iommu: exynos: rename variables to reflect their purpose Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 16/19] iommu: exynos: document internal structures Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 17/19] iommu: exynos: remove excessive includes and sort others alphabetically Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall Marek Szyprowski
2014-12-14 12:45 ` Laurent Pinchart
2014-12-15 9:47 ` Thierry Reding
2014-12-15 17:17 ` Will Deacon
2014-12-15 17:27 ` Laurent Pinchart
2014-12-15 17:43 ` Will Deacon
2014-12-15 17:53 ` Laurent Pinchart
2014-12-15 18:13 ` Will Deacon
2014-12-15 18:19 ` Laurent Pinchart
2014-12-16 10:58 ` Marek Szyprowski
2014-12-16 11:40 ` Arnd Bergmann
2014-12-16 12:07 ` Laurent Pinchart
2014-12-16 12:10 ` [Linaro-mm-sig] " Arnd Bergmann
2014-12-16 23:24 ` Laurent Pinchart
2014-12-17 14:27 ` Arnd Bergmann
2014-12-17 14:39 ` Laurent Pinchart
2014-12-17 15:41 ` Arnd Bergmann
2014-12-17 16:02 ` Laurent Pinchart [this message]
2014-12-17 21:58 ` Arnd Bergmann
2014-12-17 22:38 ` Laurent Pinchart
2014-12-17 14:53 ` Lucas Stach
2014-12-17 15:56 ` Arnd Bergmann
2014-12-18 20:36 ` Laurent Pinchart
2014-12-18 23:21 ` Arnd Bergmann
2014-11-19 11:15 ` [PATCH v3 19/19] iommu: exynos: add callback for initializing devices from device tree Marek Szyprowski
2014-12-02 9:59 ` [PATCH v3 00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem Sjoerd Simons
2014-12-05 10:22 ` Marek Szyprowski
2015-01-06 9:49 ` Javier Martinez Canillas
2015-01-07 2:03 ` Joonyoung Shim
2015-01-07 9:33 ` Javier Martinez Canillas
2015-01-07 9:55 ` Joonyoung Shim
2015-01-08 16:42 ` Javier Martinez Canillas
2015-01-12 6:40 ` Joonyoung Shim
2015-01-12 9:43 ` Joonyoung Shim
2015-01-12 16:09 ` Javier Martinez Canillas
2015-01-13 5:24 ` Joonyoung Shim
2015-01-13 8:40 ` Joonyoung Shim
2015-01-13 9:43 ` Javier Martinez Canillas
2015-01-13 9:21 ` Javier Martinez Canillas
2015-01-14 0:19 ` Javier Martinez Canillas
2015-01-14 0:24 ` Javier Martinez Canillas
2015-01-20 11:12 ` Joonyoung Shim
2015-01-20 14:05 ` Javier Martinez Canillas
2015-01-16 10:33 ` Marek Szyprowski
2015-01-16 15:44 ` Sjoerd Simons
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=3147207.bM49L5sBIQ@avalon \
--to=laurent.pinchart@ideasonboard.com \
--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