RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 04, 2012 11:53 PM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Monday, December 03, 2012 10:34 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux- foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Sunday, December 02, 2012 7:33 PM To: Sethi Varun-B16395 Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. Hmm, we need to work out a good abstraction for this. On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote: Added the following domain attributes required by FSL PAMU driver: 1. Subwindows field added to the iommu domain geometry attribute. Are the Subwindows mapped with full size or do you map only parts of the subwindows? [Sethi Varun-B16395] It's possible to map a part of the subwindow i.e. size of the mapping can be less than the sub window size. +* This attribute indicates number of DMA subwindows supported by +* the geometry. If there is a single window that maps the entire +* geometry, attribute must be set to 1. A value of 0 implies +* that this mechanism is not used at all(normal paging is used). +* Value other than* 0 or 1 indicates the actual number of +* subwindows. +*/ This semantic is ugly, how about a feature detection mechanism? [Sethi Varun-B16395] A feature mechanism to query the type of IOMMU? A feature mechanism to determine whether this subwindow mechanism is available, and what the limits are. So, we use the IOMMU capability interface to find out if IOMMU supports sub windows or not, right? But still number of sub windows would be specified as a part of the geometry and the valid value for sub windows would 0,1 or actual number of sub windows. How does a user of the interface find out what values are possible for the actual number of subwindows? How does a user of the interface find out whether there are any limitations on specifying a value of zero (in the case of PAMU, that would be a maximum 1 MiB naturally-aligned aperture to support arbitrary 4KiB mappings)? How about if we say that the default value for subwindows is zero and this what you get when you read the geometry (iommu_get_attr) after initializing the domain? In that case the user would know that implication of setting subwindows to zero with respect to the aperture size. Also, should we introduce an additional API like iommu_check_attr, which the user can use to validate the attribute value. For example in case of geometry, the user can fill up the structure and pass it to the iommu driver in order to verify the aperture and subwindows field. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [v3 1/1] iommu/tegra: smmu: bus_notifier registers platform IOMMU devices
On 12/07/2012 03:12 AM, Hiroshi Doyu wrote:
Stephen Warren swar...@wwwdotorg.org wrote @ Wed, 5 Dec 2012 22:11:40 +0100:
On 12/04/2012 11:37 AM, Hiroshi Doyu wrote:
Most of platform devices are IOMMU'able in Tegra30 SoC. Registering
all IOMMU'able devices manually isn't nice. This patch allows
platform bus_notifier to register IOMMU devices. Map info can be
passed from DT. Info format is:
dma-window = 0 0x4000;
TODO:
A map can be shared with mutiple devices. This info also could be
passed from DT or default map can be set in advance.
+static int tegra_smmu_device_notifier(struct notifier_block *nb,
+ unsigned long event, void *_dev)
+ switch (event) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ err = of_get_dma_window(dev-of_node, NULL, 0, NULL, base,
+ size);
+ if (!err)
+ map = arm_iommu_create_mapping(platform_bus_type,
+ base, size, 0);
So, this ends up attempting to hook up the Tegra SMMU for /any/ node on
a platform bus that has a dma-window property. That seems a little
dangerous. I guess it's not true for Tegra30, but what if there are
multiple buses on the SoC, each with a separate IOMMU - using this
approach would mean the two IOMMU drivers end up fighting to register
mappings for devices on each-others buses.
I think the solution here is one of:
a) Explicitly represent the bus structure in DT (something we don't do
on Tegra at present), and have the bus itself indicate which IOMMU
device is the IOMMU for that bus.
AHB/APB/PPSB bus don't do much currently. New bus drivers for them
would be used just for device registration. I'm not so sure if this
direction is right or not. Could they live with the existing
platfrom_driver? Any example would be appreciated if any.
I wasn't really thinking of creating a whole new driver for the bus; the
existing simple-bus will automatically enumerate/instantiate all its
children, and hence allow describing (at least part of) the SoC bus
structure without writing any additional code. This appears to be used
quite a bit already in arch/arm/boot/dts/*.
...
Probably, devices should not be registered until the IOMMU that serves
them is available. Otherwise, can't a device probe, start making IO
accesses using a physical/bus memory map, and then later have that
yanked out and replaced by the IOMMU'd memory map. How is that
co-ordinated? That somewhat argues for each device explicitly setting up
the IOMMU registration, or the driver core handling the
dependencies.
I think that enabling/disabling IOMMU _tranparently_ to drivers may be
beneficial basically because we don't want to deal with drivers with
IOMMU enabled separately from the normal case.
For dynamic enabling/disabling of IOMMU, *dma_ops in struct
dev_archdata will be overwritten, and there may be inconsistency for
the type of dma allocated buffers. Has there been other arch/platfrom
to handle dynamic enabling/disalbing IOMMU this already, even for each
drivers?
I don't know.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 11, 2012 6:31 AM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/10/2012 04:10:06 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Tuesday, December 04, 2012 11:53 PM To: Sethi Varun-B16395 Cc: Wood Scott-B07421; Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/04/2012 05:53:33 AM, Sethi Varun-B16395 wrote: -Original Message- From: Wood Scott-B07421 Sent: Monday, December 03, 2012 10:34 PM To: Sethi Varun-B16395 Cc: Joerg Roedel; linux-ker...@vger.kernel.org; iommu@lists.linux- foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. On 12/03/2012 10:57:29 AM, Sethi Varun-B16395 wrote: -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Joerg Roedel Sent: Sunday, December 02, 2012 7:33 PM To: Sethi Varun-B16395 Cc: linux-ker...@vger.kernel.org; iommu@lists.linux-foundation.org; Wood Scott-B07421; linuxppc-...@lists.ozlabs.org; Tabi Timur-B04825 Subject: Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver. Hmm, we need to work out a good abstraction for this. On Tue, Nov 20, 2012 at 07:24:56PM +0530, Varun Sethi wrote: Added the following domain attributes required by FSL PAMU driver: 1. Subwindows field added to the iommu domain geometry attribute. Are the Subwindows mapped with full size or do you map only parts of the subwindows? [Sethi Varun-B16395] It's possible to map a part of the subwindow i.e. size of the mapping can be less than the sub window size. +* This attribute indicates number of DMA subwindows supported by +* the geometry. If there is a single window that maps the entire +* geometry, attribute must be set to 1. A value of 0 implies +* that this mechanism is not used at all(normal paging is used). +* Value other than* 0 or 1 indicates the actual number of +* subwindows. +*/ This semantic is ugly, how about a feature detection mechanism? [Sethi Varun-B16395] A feature mechanism to query the type of IOMMU? A feature mechanism to determine whether this subwindow mechanism is available, and what the limits are. So, we use the IOMMU capability interface to find out if IOMMU supports sub windows or not, right? But still number of sub windows would be specified as a part of the geometry and the valid value for sub windows would 0,1 or actual number of sub windows. How does a user of the interface find out what values are possible for the actual number of subwindows? How does a user of the interface find out whether there are any limitations on specifying a value of zero (in the case of PAMU, that would be a maximum 1 MiB naturally-aligned aperture to support arbitrary 4KiB mappings)? How about if we say that the default value for subwindows is zero and this what you get when you read the geometry (iommu_get_attr) after initializing the domain? In that case the user would know that implication of setting subwindows to zero with respect to the aperture size. So it would default to the maximum aperture size possible with no subwindows? That might be OK, though is there a way to reset the domain later on to get back to that informational state? [Sethi Varun-B16395] Yes, that can be done via iommu_set_attr API. How about finding out the maximum number of subwindows? [Sethi Varun-B16395] We can introduce an API to determine the permissible range of values for an attribute, but it may be redundant for other IOMMU implementations. For the IOMMU implementations where geometry is just a read only attribute, iommu_get_attr returns the set of permissible values. I think it would be better if we can add a read only field (for the users) max_subwindows to the geometry. -Varun ___ iommu mailing
