From: laurent.pinchart@ideasonboard.com (Laurent Pinchart)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall
Date: Mon, 15 Dec 2014 20:19:57 +0200 [thread overview]
Message-ID: <1582013.9WDR2r2f3r@avalon> (raw)
In-Reply-To: <20141215181323.GX20738@arm.com>
On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> On Mon, Dec 15, 2014 at 05:53:48PM +0000, Laurent Pinchart wrote:
> > Hi Will,
>
> Hello again :)
>
> > On Monday 15 December 2014 17:43:02 Will Deacon wrote:
> > > On Mon, Dec 15, 2014 at 05:27:30PM +0000, Laurent Pinchart wrote:
> > > > On Monday 15 December 2014 17:17:00 Will Deacon wrote:
> > > > > Creating the platform device manually for the IOMMU is indeed
> > > > > grotty, but I don't really understand why it's needed. Interrupt
> > > > > controllers, for example, seem to get by without one.
> > > >
> > > > There's several reasons, one of the most compelling ones I can think
> > > > of at the moment is runtime PM. IRQ controllers close to the CPU use
> > > > CPU PM notifiers instead. Note that IRQ controllers that are further
> > > > away from the CPU (such as GPIO-based IRQ controllers) are real
> > > > platform devices and use runtime PM.
> > >
> > > Ok, that's a good point, but the IOMMU will still probe later anyway,
> > > right?
> >
> > That depends on the driver implementation, using OF node match an IOMMU
> > driver doesn't have to register a struct driver. Assuming we require
> > IOMMU drivers to register a struct driver, a platform device should then
> > be probed at a later time.
> >
> > However, if we wait until the IOMMU gets probed to initialize runtime PM
> > and make it functional, we'll be back in square one if the IOMMU gets
> > probed after the bus master, as the bus master could start issuing bus
> > requests at probe time with the IOMMU not powered yet.
>
> True, but couldn't the early init code do enough to get the thing
> functional? That said, I'm showing my ignorance here as I'm not familiar
> with the PM code (and the software models I have for the SMMU clearly don't
> implement anything in this regard).
We're reaching the limits of my knowledge as well. If the IOMMU is in a power
domain different than the bus masters the driver would at least need to ensure
that the power domain is turned on, which might be a bit hackish without
runtime PM.
> > > > IOMMUs are not as low-level as system interrupt controllers or system
> > > > clocks. I'm beginning to agree with Thierry that they should be
> > > > treated as normal platform devices as they're not required earlier
> > > > than probe time of their bus master devices.
> > >
> > > Well, I think you'd have to propose patches for discussion since I'm
> > > certainly not wed to the current approach; I just want something that
> > > allows of_{dma,iommu}_configure to run with the information it needs.
> >
> > Do we need of_dma_configure() to run when the device is created, or could
> > we postpone it to just before probe time ?
>
> I'm not sure I can answer that one... Arnd?
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2014-12-15 18:19 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 [this message]
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
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=1582013.9WDR2r2f3r@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