All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: "thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "mark.rutland-5wv7dgnIgG8@public.gmane.org"
	<mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org"
	<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
	Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	"swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org"
	<swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	"will.deacon-5wv7dgnIgG8@public.gmane.org"
	<will.deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
	<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Tue, 19 Nov 2013 13:03:51 +0100	[thread overview]
Message-ID: <20131119.140351.1342214267287135109.hdoyu@nvidia.com> (raw)
In-Reply-To: <20131119102506.GG31504-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>

Hi Thierry,

Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote @ Tue, 19 Nov 2013 11:25:07 +0100:

> From earlier discussions I thought the goal was to actually defer this
> until all nodes referred to by the iommus property were actually
> registered. The above only checks that the phandles can be resolved to
> valid struct device_node:s. That doesn't mean that an actual IOMMU has
> been registered for it, only that the devices have been created.

Currently "bus->iommu_ops" is set at the end of tegra_smmu_probe(). So
if "bus->iommu_ops" is set, it means that an iommu instance is
populated at that time.

> If you really only rely on dev->bus->iommu_ops to be present, then there
> is no need to go through the loop in the first place, since you have
> access to it immediately through the struct device that's passed into
> the function.

As mentioned in the above, "bus->iommu_ops" is set when an iommu
instance is populated. "iommus=" is used only to defer a device probe
until an iommu instance shows up although multiple IOMMUs are not
supported yet correctly as you pointed out.

> Furthermore, relying on dev->bus->iommu_ops will prevent multiple IOMMUs
> from being used at all, since only one IOMMU can register iommu_ops with
> the bus, right? So I think what we really need here is a way to resolve
> the IOMMU using a phandle and return the associated struct
> iommu_ops.

Multiple IOMMU support doesn't work right now. It needs to be
discussed a bit more.

> I also have some trouble understanding how the current IOMMU framework
> is supposed to work together with multiple IOMMUs for one device. The
> .add_device() callback seems to be missing crucial information to help
> decide whether the device to be added is actually one that it covers.
> Also with an of_iommu_attach() function, doesn't that become more or
> less redundant?

I understand what you meant. In the current tegra SMMU implementation,
iommu_ops is set when an iommu is populated so that we cannot use
iommu_ops before that time. That's why of_iommu_attach() was
introduced here. I couldn't set iommu_ops at drvier init yet because
we support SMMU and GART with a single image and the current IOMMU
framework assume that there's one IOMMU on the bus. If we set
iommu_ops at driver init, the latter one would overwrite it.

WARNING: multiple messages have this Message-ID (diff)
From: Hiroshi Doyu <hdoyu@nvidia.com>
To: "thierry.reding@gmail.com" <thierry.reding@gmail.com>
Cc: Stephen Warren <swarren@nvidia.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Tue, 19 Nov 2013 13:03:51 +0100	[thread overview]
Message-ID: <20131119.140351.1342214267287135109.hdoyu@nvidia.com> (raw)
In-Reply-To: <20131119102506.GG31504@ulmo.nvidia.com>

Hi Thierry,

Thierry Reding <thierry.reding@gmail.com> wrote @ Tue, 19 Nov 2013 11:25:07 +0100:

> From earlier discussions I thought the goal was to actually defer this
> until all nodes referred to by the iommus property were actually
> registered. The above only checks that the phandles can be resolved to
> valid struct device_node:s. That doesn't mean that an actual IOMMU has
> been registered for it, only that the devices have been created.

Currently "bus->iommu_ops" is set at the end of tegra_smmu_probe(). So
if "bus->iommu_ops" is set, it means that an iommu instance is
populated at that time.

> If you really only rely on dev->bus->iommu_ops to be present, then there
> is no need to go through the loop in the first place, since you have
> access to it immediately through the struct device that's passed into
> the function.

As mentioned in the above, "bus->iommu_ops" is set when an iommu
instance is populated. "iommus=" is used only to defer a device probe
until an iommu instance shows up although multiple IOMMUs are not
supported yet correctly as you pointed out.

> Furthermore, relying on dev->bus->iommu_ops will prevent multiple IOMMUs
> from being used at all, since only one IOMMU can register iommu_ops with
> the bus, right? So I think what we really need here is a way to resolve
> the IOMMU using a phandle and return the associated struct
> iommu_ops.

Multiple IOMMU support doesn't work right now. It needs to be
discussed a bit more.

> I also have some trouble understanding how the current IOMMU framework
> is supposed to work together with multiple IOMMUs for one device. The
> .add_device() callback seems to be missing crucial information to help
> decide whether the device to be added is actually one that it covers.
> Also with an of_iommu_attach() function, doesn't that become more or
> less redundant?

I understand what you meant. In the current tegra SMMU implementation,
iommu_ops is set when an iommu is populated so that we cannot use
iommu_ops before that time. That's why of_iommu_attach() was
introduced here. I couldn't set iommu_ops at drvier init yet because
we support SMMU and GART with a single image and the current IOMMU
framework assume that there's one IOMMU on the bus. If we set
iommu_ops at driver init, the latter one would overwrite it.

WARNING: multiple messages have this Message-ID (diff)
From: hdoyu@nvidia.com (Hiroshi Doyu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs
Date: Tue, 19 Nov 2013 13:03:51 +0100	[thread overview]
Message-ID: <20131119.140351.1342214267287135109.hdoyu@nvidia.com> (raw)
In-Reply-To: <20131119102506.GG31504@ulmo.nvidia.com>

Hi Thierry,

Thierry Reding <thierry.reding@gmail.com> wrote @ Tue, 19 Nov 2013 11:25:07 +0100:

> From earlier discussions I thought the goal was to actually defer this
> until all nodes referred to by the iommus property were actually
> registered. The above only checks that the phandles can be resolved to
> valid struct device_node:s. That doesn't mean that an actual IOMMU has
> been registered for it, only that the devices have been created.

Currently "bus->iommu_ops" is set at the end of tegra_smmu_probe(). So
if "bus->iommu_ops" is set, it means that an iommu instance is
populated at that time.

> If you really only rely on dev->bus->iommu_ops to be present, then there
> is no need to go through the loop in the first place, since you have
> access to it immediately through the struct device that's passed into
> the function.

As mentioned in the above, "bus->iommu_ops" is set when an iommu
instance is populated. "iommus=" is used only to defer a device probe
until an iommu instance shows up although multiple IOMMUs are not
supported yet correctly as you pointed out.

> Furthermore, relying on dev->bus->iommu_ops will prevent multiple IOMMUs
> from being used at all, since only one IOMMU can register iommu_ops with
> the bus, right? So I think what we really need here is a way to resolve
> the IOMMU using a phandle and return the associated struct
> iommu_ops.

Multiple IOMMU support doesn't work right now. It needs to be
discussed a bit more.

> I also have some trouble understanding how the current IOMMU framework
> is supposed to work together with multiple IOMMUs for one device. The
> .add_device() callback seems to be missing crucial information to help
> decide whether the device to be added is actually one that it covers.
> Also with an of_iommu_attach() function, doesn't that become more or
> less redundant?

I understand what you meant. In the current tegra SMMU implementation,
iommu_ops is set when an iommu is populated so that we cannot use
iommu_ops before that time. That's why of_iommu_attach() was
introduced here. I couldn't set iommu_ops at drvier init yet because
we support SMMU and GART with a single image and the current IOMMU
framework assume that there's one IOMMU on the bus. If we set
iommu_ops at driver init, the latter one would overwrite it.

  parent reply	other threads:[~2013-11-19 12:03 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-19  9:33 [PATCHv5 0/9] Unifying Tegra IOMMU(SMMU) driver among Tegra SoCs Hiroshi Doyu
2013-11-19  9:33 ` Hiroshi Doyu
2013-11-19  9:33 ` Hiroshi Doyu
     [not found] ` < 1384853593-32202-3-git-send-email-hdoyu@nvidia.com>
     [not found] ` <1384853593-32202-1-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19  9:33   ` [PATCHv5 1/9] of: introduce of_property_for_earch_phandle_with_args() Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 2/9] driver/core: populate devices in order for IOMMUs Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-3-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 10:25       ` Thierry Reding
2013-11-19 10:25         ` Thierry Reding
2013-11-19 10:25         ` Thierry Reding
     [not found]         ` <20131119102506.GG31504-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-11-19 12:03           ` Hiroshi Doyu [this message]
2013-11-19 12:03             ` Hiroshi Doyu
2013-11-19 12:03             ` Hiroshi Doyu
     [not found]             ` <20131119.140351.1342214267287135109.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:22               ` Stephen Warren
2013-11-19 21:22                 ` Stephen Warren
2013-11-19 21:22                 ` Stephen Warren
     [not found]                 ` <528BD6A7.3030908-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-20  3:17                   ` Hiroshi Doyu
2013-11-20  3:17                     ` Hiroshi Doyu
2013-11-20  3:17                     ` Hiroshi Doyu
     [not found]                     ` <20131120.051708.396722414386125310.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-20 13:14                       ` Thierry Reding
2013-11-20 13:14                         ` Thierry Reding
2013-11-20 13:14                         ` Thierry Reding
     [not found]                         ` <20131120131447.GA8279-AwZRO8vwLAwmlAP/+Wk3EA@public.gmane.org>
2013-11-20 14:03                           ` Hiroshi Doyu
2013-11-20 14:03                             ` Hiroshi Doyu
2013-11-20 14:03                             ` Hiroshi Doyu
     [not found]                             ` <20131120.160359.1043627108929095327.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-20 16:30                               ` Stephen Warren
2013-11-20 16:30                                 ` Stephen Warren
2013-11-20 16:30                                 ` Stephen Warren
     [not found]                                 ` <528CE3AB.60806-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-21  9:01                                   ` Hiroshi Doyu
2013-11-21  9:01                                     ` Hiroshi Doyu
2013-11-21  9:01                                     ` Hiroshi Doyu
2013-11-21 13:15       ` Grant Likely
2013-11-21 13:15         ` Grant Likely
2013-11-21 13:15         ` Grant Likely
     [not found]         ` <20131121131558.E5B82C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 19:04           ` Stephen Warren
2013-11-21 19:04             ` Stephen Warren
2013-11-21 19:04             ` Stephen Warren
     [not found]             ` <528E5932.1070105-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-22  7:41               ` Grant Likely
2013-11-22  7:41                 ` Grant Likely
2013-11-22  7:41                 ` Grant Likely
     [not found]                 ` <20131122074111.155E2C40753-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-22 17:35                   ` Stephen Warren
2013-11-22 17:35                     ` Stephen Warren
2013-11-22 17:35                     ` Stephen Warren
     [not found]                     ` <528F95FE.7080406-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-25 17:39                       ` Will Deacon
2013-11-25 17:39                         ` Will Deacon
2013-11-25 17:39                         ` Will Deacon
2013-11-19  9:33   ` [PATCHv5 3/9] ARM: tegra: create a DT header defining SWGROUP ID Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-4-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:36       ` Stephen Warren
2013-11-19 21:36         ` Stephen Warren
2013-11-19 21:36         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 4/9] iommu/tegra: smmu: register device to iommu dynamically Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-5-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:39       ` Stephen Warren
2013-11-19 21:39         ` Stephen Warren
2013-11-19 21:39         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 5/9] iommu/tegra: smmu: calculate ASID register offset by ID Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 6/9] iommu/tegra: smmu: get swgroups from DT "iommus=" Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found]     ` <1384853593-32202-7-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-19 21:52       ` Stephen Warren
2013-11-19 21:52         ` Stephen Warren
2013-11-19 21:52         ` Stephen Warren
2013-11-19  9:33   ` [PATCHv5 7/9] iommu/tegra: smmu: allow duplicate ASID wirte Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 8/9] iommu/tegra: smmu: Rename hwgrp -> swgroups Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33   ` [PATCHv5 9/9] [FOR TEST] ARM: dt: tegra30: add "iommus" binding Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
2013-11-19  9:33     ` Hiroshi Doyu
     [not found] ` < 1384853593-32202-2-git-send-email-hdoyu@nvidia.com>
     [not found]   ` <1384853593-32202-2-git-send-email-hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 12:43     ` [PATCHv5 1/9] of: introduce of_property_for_earch_phandle_with_args() Grant Likely
2013-11-21 12:43       ` Grant Likely
2013-11-21 12:43       ` Grant Likely
     [not found]       ` <20131121124328.46BC1C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 13:12         ` Hiroshi Doyu
2013-11-21 13:12           ` Hiroshi Doyu
2013-11-21 13:12           ` Hiroshi Doyu
     [not found]   ` <20131121124328. 46BC1C40A2C@trevor.secretlab.ca>
     [not found]     ` <20131121151218.befbb483c0cf09cdcd4cd4dd@ nvidia.com>
     [not found]       ` <20131121151218.befbb483c0cf09cdcd4cd4dd-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 15:56         ` Grant Likely
2013-11-21 15:56           ` Grant Likely
2013-11-21 15:56           ` Grant Likely
     [not found]           ` <20131121155649.48C96C406A3-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 17:20             ` Hiroshi Doyu
2013-11-21 17:20               ` Hiroshi Doyu
2013-11-21 17:20               ` Hiroshi Doyu
     [not found]               ` <20131121.192051.747601347584525020.hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-11-21 18:52                 ` Stephen Warren
2013-11-21 18:52                   ` Stephen Warren
2013-11-21 18:52                   ` Stephen Warren
2013-11-21 21:36                 ` Rob Herring
2013-11-21 21:36                   ` Rob Herring
2013-11-21 21:36                   ` Rob Herring
     [not found] ` < 1384853593-32202-5-git-send-email-hdoyu@nvidia.com>
     [not found]   ` <528BDAAA.4000203@ wwwdotorg.org>
     [not found]     ` <528BDAAA.4000203-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-11-21 13:23       ` [PATCHv5 4/9] iommu/tegra: smmu: register device to iommu dynamically Grant Likely
2013-11-21 13:23         ` Grant Likely
2013-11-21 13:23         ` Grant Likely
     [not found]         ` <20131121132322.EFDD1C40A2C-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-21 13:38           ` Hiroshi Doyu
2013-11-21 13:38             ` Hiroshi Doyu
2013-11-21 13:38             ` Hiroshi Doyu

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=20131119.140351.1342214267287135109.hdoyu@nvidia.com \
    --to=hdoyu-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
    --cc=swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.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 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.