All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Rob Herring <robh@kernel.org>,
	Thierry Reding <treding@nvidia.com>,
	Shaik Ameer Basha <shaik.ameer@samsung.com>,
	Arnd Bergmann <arnd@arndb.de>, Inki Dae <inki.dae@samsung.com>,
	Joerg Roedel <joro@8bytes.org>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	"linaro-mm-sig@lists.linaro.org" <linaro-mm-sig@lists.linaro.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Olof Johansson <olof@lixom.net>,
	Cho KyongHo <pullip.cho@samsung.com>,
	David Wodhouse <dwmw2@infradead.org>
Subject: Re: [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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2014-12-15 18:19 UTC|newest]

Thread overview: 126+ 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 ` Marek Szyprowski
     [not found] ` <1416395748-10731-1-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
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     ` 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   ` 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   ` 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   ` 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   ` Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 06/19] ARM: dts: exynos4: add sysmmu nodes Marek Szyprowski
2014-11-19 11:15   ` 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   ` Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 08/19] iommu: exynos: remove unused functions Marek Szyprowski
2014-11-19 11:15   ` Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 09/19] iommu: exynos: remove useless spinlock Marek Szyprowski
2014-11-19 11:15   ` 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   ` 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   ` 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   ` 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   ` 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   ` 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   ` Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 16/19] iommu: exynos: document internal structures Marek Szyprowski
2014-11-19 11:15   ` 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   ` Marek Szyprowski
2014-11-19 11:15 ` [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall Marek Szyprowski
2014-11-19 11:15   ` Marek Szyprowski
2014-12-14 12:45   ` Laurent Pinchart
2014-12-14 12:45     ` Laurent Pinchart
2014-12-15  9:47     ` Thierry Reding
2014-12-15  9:47       ` Thierry Reding
2014-12-15 17:17     ` Will Deacon
2014-12-15 17:17       ` Will Deacon
     [not found]       ` <20141215171700.GP20738-5wv7dgnIgG8@public.gmane.org>
2014-12-15 17:27         ` Laurent Pinchart
2014-12-15 17:27           ` Laurent Pinchart
2014-12-15 17:43           ` Will Deacon
2014-12-15 17:43             ` Will Deacon
2014-12-15 17:53             ` Laurent Pinchart
2014-12-15 17:53               ` Laurent Pinchart
2014-12-15 18:13               ` Will Deacon
2014-12-15 18:13                 ` Will Deacon
2014-12-15 18:19                 ` Laurent Pinchart [this message]
2014-12-15 18:19                   ` Laurent Pinchart
2014-12-16 10:58                   ` Marek Szyprowski
2014-12-16 10:58                     ` Marek Szyprowski
2014-12-16 11:40                 ` Arnd Bergmann
2014-12-16 11:40                   ` Arnd Bergmann
2014-12-16 12:07                   ` Laurent Pinchart
2014-12-16 12:07                     ` Laurent Pinchart
2014-12-16 12:10                     ` [Linaro-mm-sig] " Arnd Bergmann
2014-12-16 12:10                       ` Arnd Bergmann
2014-12-16 23:24                       ` Laurent Pinchart
2014-12-16 23:24                         ` Laurent Pinchart
2014-12-17 14:27                         ` Arnd Bergmann
2014-12-17 14:27                           ` Arnd Bergmann
2014-12-17 14:39                           ` Laurent Pinchart
2014-12-17 14:39                             ` Laurent Pinchart
2014-12-17 15:41                             ` Arnd Bergmann
2014-12-17 15:41                               ` Arnd Bergmann
2014-12-17 16:02                               ` Laurent Pinchart
2014-12-17 16:02                                 ` Laurent Pinchart
2014-12-17 21:58                                 ` Arnd Bergmann
2014-12-17 21:58                                   ` Arnd Bergmann
2014-12-17 22:38                                   ` Laurent Pinchart
2014-12-17 22:38                                     ` Laurent Pinchart
2014-12-17 14:53                           ` Lucas Stach
2014-12-17 14:53                             ` Lucas Stach
     [not found]                             ` <1418828005.3347.7.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-12-17 15:56                               ` Arnd Bergmann
2014-12-17 15:56                                 ` Arnd Bergmann
2014-12-18 20:36                                 ` Laurent Pinchart
2014-12-18 20:36                                   ` Laurent Pinchart
2014-12-18 23:21                                   ` Arnd Bergmann
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-11-19 11:15   ` 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-02  9:59   ` Sjoerd Simons
2014-12-05 10:22   ` Marek Szyprowski
2014-12-05 10:22     ` Marek Szyprowski
2015-01-06  9:49     ` Javier Martinez Canillas
2015-01-06  9:49       ` Javier Martinez Canillas
2015-01-07  2:03       ` Joonyoung Shim
2015-01-07  2:03         ` Joonyoung Shim
2015-01-07  9:33         ` Javier Martinez Canillas
2015-01-07  9:33           ` Javier Martinez Canillas
2015-01-07  9:55           ` Joonyoung Shim
2015-01-07  9:55             ` Joonyoung Shim
     [not found]             ` <54AD0293.70909-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-08 16:42               ` Javier Martinez Canillas
2015-01-08 16:42                 ` Javier Martinez Canillas
     [not found]                 ` <54AEB384.2040005-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2015-01-12  6:40                   ` Joonyoung Shim
2015-01-12  6:40                     ` Joonyoung Shim
2015-01-12  9:43                     ` Joonyoung Shim
2015-01-12  9:43                       ` Joonyoung Shim
     [not found]                     ` <54B36C5A.6050109-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-12 16:09                       ` Javier Martinez Canillas
2015-01-12 16:09                         ` Javier Martinez Canillas
2015-01-13  5:24                         ` Joonyoung Shim
2015-01-13  5:24                           ` Joonyoung Shim
2015-01-13  8:40                           ` Joonyoung Shim
2015-01-13  8:40                             ` Joonyoung Shim
     [not found]                             ` <54B4D9E1.10400-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-13  9:43                               ` Javier Martinez Canillas
2015-01-13  9:43                                 ` Javier Martinez Canillas
2015-01-13  9:21                           ` Javier Martinez Canillas
2015-01-13  9:21                             ` Javier Martinez Canillas
2015-01-14  0:19                           ` Javier Martinez Canillas
2015-01-14  0:19                             ` Javier Martinez Canillas
     [not found]                             ` <54B5B5F6.3030607-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2015-01-14  0:24                               ` Javier Martinez Canillas
2015-01-14  0:24                                 ` Javier Martinez Canillas
2015-01-20 11:12                                 ` Joonyoung Shim
2015-01-20 11:12                                   ` Joonyoung Shim
     [not found]                                   ` <54BE383B.5030505-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-20 14:05                                     ` Javier Martinez Canillas
2015-01-20 14:05                                       ` Javier Martinez Canillas
     [not found]   ` <1417514366.21830.22.camel-ZGY8ohtN/8pPYcu2f3hruQ@public.gmane.org>
2015-01-16 10:33     ` Marek Szyprowski
2015-01-16 10:33       ` Marek Szyprowski
     [not found]       ` <54B8E904.6090107-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-16 15:44         ` Sjoerd Simons
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=arnd@arndb.de \
    --cc=dwmw2@infradead.org \
    --cc=inki.dae@samsung.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=olof@lixom.net \
    --cc=pullip.cho@samsung.com \
    --cc=robh@kernel.org \
    --cc=shaik.ameer@samsung.com \
    --cc=tomasz.figa@gmail.com \
    --cc=treding@nvidia.com \
    --cc=will.deacon@arm.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.