[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140704134709.GA4203@ulmo>
Date: Fri, 4 Jul 2014 15:47:10 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Joerg Roedel <joro@...tes.org>
Cc: Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Stephen Warren <swarren@...dotorg.org>,
Arnd Bergmann <arnd@...db.de>,
Will Deacon <will.deacon@....com>,
Cho KyongHo <pullip.cho@...sung.com>,
Grant Grundler <grundler@...omium.org>,
Dave Martin <Dave.Martin@....com>,
Marc Zyngier <marc.zyngier@....com>,
Hiroshi Doyu <hdoyu@...dia.com>,
Olav Haugan <ohaugan@...eaurora.org>,
Paul Walmsley <pwalmsley@...dia.com>,
Rhyland Klein <rklein@...dia.com>,
Allen Martin <amartin@...dia.com>, devicetree@...r.kernel.org,
iommu@...ts.linux-foundation.org,
linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 01/10] iommu: Add IOMMU device registry
On Fri, Jul 04, 2014 at 01:05:30PM +0200, Joerg Roedel wrote:
> On Thu, Jun 26, 2014 at 10:49:41PM +0200, Thierry Reding wrote:
> > Add an IOMMU device registry for drivers to register with and implement
> > a method for users of the IOMMU API to attach to an IOMMU device. This
> > allows to support deferred probing and gives the IOMMU API a convenient
> > hook to perform early initialization of a device if necessary.
>
> Can you elaborate on why exactly you need this? The IOMMU-API is
> designed to hide any details from the user about the available IOMMUs in
> the system and which IOMMU handles which device. This looks like it is
> going in a completly different direction from that.
I need this primarily to properly serialize device probing order.
Without it the IOMMU may be probed later than its clients, in which case
the client drivers will assume that there is no IOMMU (iommu_present()
for the parent bus fails).
There are other ways around this, but I think we'll need to eventually
come up with something like this anyway. Consider for example what
happens when a device has master interfaces on two different IOMMUs. Not
only does the current model of having one and one only IOMMU per struct
bus_type break down, but also IOMMU masters will need a way to specify
which IOMMU they're talking to.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists