The intention behind this patchset is to allow usage of IOMMU based
DMA mappings for 32bit devices. It is based on '4.5-rc3' tag of linux
mainline tree and Robin's SMMU patchset "[PATCH 0/4] Miscellaneous
ARM SMMU patches".
This patchset and its dependent patches are available in smmu_v2
branch of https://github.com/Broadcom/arm64-linux.git
All patches have been tested on Broadcom SoCs having SMMU-500.
Anup Patel (3):
iommu/arm-smmu: Invoke DT probe from arm_smmu_of_setup()
of: iommu: Increment DT node refcount in of_iommu_set_ops()
iommu/arm-smmu: Add stub of_xlate() operation in SMMUv1/SMMUv2 driver
Sricharan R (1):
iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE
drivers/iommu/arm-smmu.c | 52 ++++++++++++++++++++++++++++++++++++------------
drivers/iommu/of_iommu.c | 1 +
2 files changed, 40 insertions(+), 13 deletions(-)
--
1.9.1
The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed
via normal DT probing.
This patch uses of_platform_device_create() from arm_smmu_of_setup()
to ensure that SMMU platform device is probed immediately.
Signed-off-by: Anup Patel <redacted>
---
drivers/iommu/arm-smmu.c | 6 ++++++
1 file changed, 6 insertions(+)
-----Original Message-----
From: linux-arm-kernel [mailto:linux-arm-kernel-
bounces at lists.infradead.org] On Behalf Of Anup Patel
Sent: Monday, February 08, 2016 10:48 AM
To: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
Linux IOMMU; Linux ARM Kernel
Cc: Mark Rutland; Device Tree; Scott Branden; Pawel Moll; Ian Campbell;
Ray
quoted hunk
Jui; Linux Kernel; Vikram Prakash; Rob Herring; BCM Kernel Feedback; Kumar
Gala; Anup Patel
Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
arm_smmu_of_setup()
The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed via normal
DT probing.
This patch uses of_platform_device_create() from arm_smmu_of_setup() to
ensure that SMMU platform device is probed immediately.
Signed-off-by: Anup Patel <redacted>
---
drivers/iommu/arm-smmu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
@@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)staticint__initarm_smmu_of_setup(structdevice_node*np){+structplatform_device*pdev;if(!init_done)arm_smmu_init();+pdev=of_platform_device_create(np,NULL,NULL);+if(IS_ERR(pdev))+returnPTR_ERR(pdev);+of_iommu_set_ops(np,&arm_smmu_ops);
A question here is, There was a probe deferral series [1], to take care of
deferred
probing of devices behind iommus. With that this sort of early device
probing during setup
should not be required and also it clears other dependencies of iommus on
clocks, etc, if any.
My intention was to check whats the right way to do this ? (or) point me
to any updates
on the probe deferral series that I miss ?
[1] http://lkml.iu.edu/hypermail/linux/kernel/1505.3/03280.html
Regards,
Sricharan
On Thu, Feb 18, 2016 at 5:30 PM, Sricharan [off-list ref] wrote:
Hi,
quoted
-----Original Message-----
From: linux-arm-kernel [mailto:linux-arm-kernel-
bounces at lists.infradead.org] On Behalf Of Anup Patel
Sent: Monday, February 08, 2016 10:48 AM
To: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
Linux IOMMU; Linux ARM Kernel
Cc: Mark Rutland; Device Tree; Scott Branden; Pawel Moll; Ian Campbell;
Ray
quoted
Jui; Linux Kernel; Vikram Prakash; Rob Herring; BCM Kernel Feedback; Kumar
Gala; Anup Patel
Subject: [PATCH v2 2/4] iommu/arm-smmu: Invoke DT probe from
arm_smmu_of_setup()
The SMMUv1/SMMUv2 driver is initialized very early using the
IOMMU_OF_DECLARE() but the actual platform device is probed via normal
DT probing.
This patch uses of_platform_device_create() from arm_smmu_of_setup() to
ensure that SMMU platform device is probed immediately.
Signed-off-by: Anup Patel <redacted>
---
drivers/iommu/arm-smmu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index
@@ -1956,10 +1957,15 @@ static int __init arm_smmu_init(void)staticint__initarm_smmu_of_setup(structdevice_node*np){+structplatform_device*pdev;if(!init_done)arm_smmu_init();+pdev=of_platform_device_create(np,NULL,NULL);+if(IS_ERR(pdev))+returnPTR_ERR(pdev);+of_iommu_set_ops(np,&arm_smmu_ops);
A question here is, There was a probe deferral series [1], to take care of
deferred
probing of devices behind iommus. With that this sort of early device
probing during setup
should not be required and also it clears other dependencies of iommus on
clocks, etc, if any.
My intention was to check whats the right way to do this ? (or) point me
to any updates
on the probe deferral series that I miss ?
[1] http://lkml.iu.edu/hypermail/linux/kernel/1505.3/03280.html
I think probe deferral is better way of handling this. I will drop this
patch.
Thanks,
Anup
To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.
This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.
Signed-off-by: Anup Patel <redacted>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/iommu/arm-smmu.c | 11 +++++++++++
1 file changed, 11 insertions(+)
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-02-08 11:19:06
On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
quoted hunk
To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.
This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.
Signed-off-by: Anup Patel <redacted>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/iommu/arm-smmu.c | 11 +++++++++++
1 file changed, 11 insertions(+)
@@ -1398,6 +1398,16 @@ static int arm_smmu_init_platform_device(struct device *dev,return0;}+intarm_smmu_of_xlate(structdevice*dev,structof_phandle_args*args)+{+/*+*NothingtodoherebecauseSMMUisalreadyawareofall+*MMUmastersandtheirstreamIDsusingmmu-masterattibute+*SMMUDTnode.+*/+return0;+}
NAK to this.
As previously mentioned by others [1], this is an abuse of the generic
iommu binding support code.
The SMMU binding currently does not define its implementation of the
generic IOMMU binding. This series did not define what an SMMU's
#iommu-cells would be nor what the contained values would represent.
Therefore it is not valid to use an SMMU node with an iommus property as
the SMMu doesn't follwo the generic IOMMU binding.
There is ongoing work to have generic iommu binding support for the
SMMU. In the absence of documentation for what this means for the
binding, I am worried that this hack harms that effort.
To use features of the generic IOMMU binding, we must properly implement
the generic IOMMU binding for the SMMU rather than bodging it onto the
side of the existing binding.
Thanks,
Mark.
quoted hunk
+
static int arm_smmu_add_device(struct device *dev)
{
struct iommu_group *group;
On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland [off-list ref] wrote:
On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
quoted
To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.
This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.
Signed-off-by: Anup Patel <redacted>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/iommu/arm-smmu.c | 11 +++++++++++
1 file changed, 11 insertions(+)
As previously mentioned by others [1], this is an abuse of the generic
iommu binding support code.
The SMMU binding currently does not define its implementation of the
generic IOMMU binding. This series did not define what an SMMU's
#iommu-cells would be nor what the contained values would represent.
Therefore it is not valid to use an SMMU node with an iommus property as
the SMMu doesn't follwo the generic IOMMU binding.
There is ongoing work to have generic iommu binding support for the
SMMU. In the absence of documentation for what this means for the
binding, I am worried that this hack harms that effort.
Thanks for the info, I would like to try this on Broadcom SoCs.
Whats the ETA of patches for generic IOMMU binding for SMMU?
To use features of the generic IOMMU binding, we must properly implement
the generic IOMMU binding for the SMMU rather than bodging it onto the
side of the existing binding.
Thanks,
Mark.
From: Mark Rutland <mark.rutland@arm.com> Date: 2016-02-08 13:42:59
On Mon, Feb 08, 2016 at 06:13:11PM +0530, Anup Patel wrote:
On Mon, Feb 8, 2016 at 4:48 PM, Mark Rutland [off-list ref] wrote:
quoted
On Mon, Feb 08, 2016 at 10:47:32AM +0530, Anup Patel wrote:
quoted
To allow use of large memory (> 4Gb) with 32bit devices we need to use
IOMMU based DMA mappings for such 32bit devices. The IOMMU dt-bindings
allows us do this by specifying 'iommus' attribute in 32bit device DT
node. Unfortunately, specifying 'iommus' attribute does not work with
current SMMUv1/SMMUv2 driver because it requires of_xlate() operation
to be implemented by the driver.
This patch adds a stub implementation of of_xlate() in SMMUv1/SMMUv2
driver to allow usage of 'iommus' attribute in DT for 32bit devices.
Signed-off-by: Anup Patel <redacted>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
---
drivers/iommu/arm-smmu.c | 11 +++++++++++
1 file changed, 11 insertions(+)
Ok.
To be clear, I expect the generic binding alone to be used for the case
you described, regardless of who implements that or how long it takes to
appear.
quoted
As previously mentioned by others [1], this is an abuse of the generic
iommu binding support code.
The SMMU binding currently does not define its implementation of the
generic IOMMU binding. This series did not define what an SMMU's
#iommu-cells would be nor what the contained values would represent.
Therefore it is not valid to use an SMMU node with an iommus property as
the SMMu doesn't follwo the generic IOMMU binding.
There is ongoing work to have generic iommu binding support for the
SMMU. In the absence of documentation for what this means for the
binding, I am worried that this hack harms that effort.
Thanks for the info, I would like to try this on Broadcom SoCs.
Whats the ETA of patches for generic IOMMU binding for SMMU?
That I do not know.
Robin, what's the state of the generic IOMMU binding support?
Thanks,
Mark.
We are saving pointer to iommu DT node in of_iommu_set_ops()
hence we should increment DT node ref count.
Signed-off-by: Anup Patel <redacted>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
Reviewed-by: Robin Murphy <Robin.Murphy@arm.com>
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1 insertion(+)
From: Sricharan R <redacted>
This patch uses IOMMU_OF_DECLARE to register the driver
and the iommu_ops. So when master devices of the iommu are
registered, of_xlate callback can be used to add the master
configurations to the smmu driver.
Signed-off-by: Sricharan R <redacted>
Signed-off-by: Anup Patel <redacted>
Tested-by: Anup Patel <redacted>
---
drivers/iommu/arm-smmu.c | 35 ++++++++++++++++++++++-------------
1 file changed, 22 insertions(+), 13 deletions(-)
@@ -265,6 +266,8 @@#define FSYNR0_WNR (1 << 4)staticintforce_stage;+staticboolinit_done;+module_param_named(force_stage,force_stage,int,S_IRUGO);MODULE_PARM_DESC(force_stage,"Force SMMU mappings to be installed@a particular stage of translation. A value of '1' or '2' forces the corresponding stage. All other values are ignored (i.e. no stage is forced). Note that selecting a specific stage will disable support for nested translation.");
@@ -1958,15 +1949,33 @@ static int __init arm_smmu_init(void)bus_set_iommu(&pci_bus_type,&arm_smmu_ops);#endif+init_done=true;+return0;}+staticint__initarm_smmu_of_setup(structdevice_node*np)+{++if(!init_done)+arm_smmu_init();++of_iommu_set_ops(np,&arm_smmu_ops);++return0;+}++IOMMU_OF_DECLARE(arm_smmu_v1,"arm,smmu-v1",arm_smmu_of_setup);+IOMMU_OF_DECLARE(arm_smmu_v2,"arm,smmu-v2",arm_smmu_of_setup);+IOMMU_OF_DECLARE(arm_smmu_400,"arm,mmu-400",arm_smmu_of_setup);+IOMMU_OF_DECLARE(arm_smmu_401,"arm,mmu-401",arm_smmu_of_setup);+IOMMU_OF_DECLARE(arm_smmu_500,"arm,mmu-500",arm_smmu_of_setup);+staticvoid__exitarm_smmu_exit(void){returnplatform_driver_unregister(&arm_smmu_driver);}-subsys_initcall(arm_smmu_init);module_exit(arm_smmu_exit);MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");