From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Linux ARM Kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
Ian Campbell
<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Device Tree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Scott Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Vikram Prakash <vikramp-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
Linux Kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
BCM Kernel Feedback
<bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Subject: Re: [RFC PATCH 4/6] iommu/arm-smmu: Add support for IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver
Date: Thu, 28 Jan 2016 17:28:30 +0000 [thread overview]
Message-ID: <56AA4FBE.6090702@arm.com> (raw)
In-Reply-To: <1453872079-27140-5-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 27/01/16 05:21, Anup Patel wrote:
> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> some kind of iommu for such 32bit devices.
>
> This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
> in-turn will allows us to use iommu based DMA mappings for 32bit devices.
>
> Signed-off-by: Anup Patel <anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> drivers/iommu/arm-smmu.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9bdf6b2..43424fe 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -29,6 +29,7 @@
> #define pr_fmt(fmt) "arm-smmu: " fmt
>
> #include <linux/delay.h>
> +#include <linux/dma-iommu.h>
> #include <linux/dma-mapping.h>
> #include <linux/err.h>
> #include <linux/interrupt.h>
> @@ -967,7 +968,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> {
> struct arm_smmu_domain *smmu_domain;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
> return NULL;
> /*
> * Allocate the domain and initialise some of its data structures.
> @@ -978,6 +979,12 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> if (!smmu_domain)
> return NULL;
>
> + if (type == IOMMU_DOMAIN_DMA &&
> + iommu_get_dma_cookie(&smmu_domain->domain)) {
> + kfree(smmu_domain);
> + return NULL;
> + }
> +
> mutex_init(&smmu_domain->init_mutex);
> spin_lock_init(&smmu_domain->pgtbl_lock);
>
> @@ -992,6 +999,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
> * Free the domain resources. We assume that all devices have
> * already been detached.
> */
> + iommu_put_dma_cookie(domain);
> arm_smmu_destroy_domain_context(domain);
> kfree(smmu_domain);
> }
> @@ -1361,6 +1369,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
> return 0;
> }
>
> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> +{
> + /*
> + * Nothing to do here because SMMU is already aware of all
> + * MMU masters and their stream IDs using mmu-master attibute
> + * SMMU DT node.
> + */
...but on the same hand this will also never get called if there's no
"iommus" property on the master. Maintaining support for existing users
of the "mmu-masters" binding is one thing (namely the thing that's been
slowing down my efforts to clean up the really hacky generic binding
support I did all the DMA stuff with), but having _both_ bindings in a
single DT is something I don't think anybody wants to see - is that how
you've tested this?
Robin.
> + return 0;
> +}
> +
> static int arm_smmu_add_device(struct device *dev)
> {
> struct iommu_group *group;
> @@ -1458,6 +1476,7 @@ static struct iommu_ops arm_smmu_ops = {
> .unmap = arm_smmu_unmap,
> .map_sg = default_iommu_map_sg,
> .iova_to_phys = arm_smmu_iova_to_phys,
> + .of_xlate = arm_smmu_of_xlate,
> .add_device = arm_smmu_add_device,
> .remove_device = arm_smmu_remove_device,
> .device_group = arm_smmu_device_group,
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: robin.murphy@arm.com (Robin Murphy)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 4/6] iommu/arm-smmu: Add support for IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver
Date: Thu, 28 Jan 2016 17:28:30 +0000 [thread overview]
Message-ID: <56AA4FBE.6090702@arm.com> (raw)
In-Reply-To: <1453872079-27140-5-git-send-email-anup.patel@broadcom.com>
On 27/01/16 05:21, Anup Patel wrote:
> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> some kind of iommu for such 32bit devices.
>
> This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
> in-turn will allows us to use iommu based DMA mappings for 32bit devices.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
> drivers/iommu/arm-smmu.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9bdf6b2..43424fe 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -29,6 +29,7 @@
> #define pr_fmt(fmt) "arm-smmu: " fmt
>
> #include <linux/delay.h>
> +#include <linux/dma-iommu.h>
> #include <linux/dma-mapping.h>
> #include <linux/err.h>
> #include <linux/interrupt.h>
> @@ -967,7 +968,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> {
> struct arm_smmu_domain *smmu_domain;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
> return NULL;
> /*
> * Allocate the domain and initialise some of its data structures.
> @@ -978,6 +979,12 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> if (!smmu_domain)
> return NULL;
>
> + if (type == IOMMU_DOMAIN_DMA &&
> + iommu_get_dma_cookie(&smmu_domain->domain)) {
> + kfree(smmu_domain);
> + return NULL;
> + }
> +
> mutex_init(&smmu_domain->init_mutex);
> spin_lock_init(&smmu_domain->pgtbl_lock);
>
> @@ -992,6 +999,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
> * Free the domain resources. We assume that all devices have
> * already been detached.
> */
> + iommu_put_dma_cookie(domain);
> arm_smmu_destroy_domain_context(domain);
> kfree(smmu_domain);
> }
> @@ -1361,6 +1369,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
> return 0;
> }
>
> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> +{
> + /*
> + * Nothing to do here because SMMU is already aware of all
> + * MMU masters and their stream IDs using mmu-master attibute
> + * SMMU DT node.
> + */
...but on the same hand this will also never get called if there's no
"iommus" property on the master. Maintaining support for existing users
of the "mmu-masters" binding is one thing (namely the thing that's been
slowing down my efforts to clean up the really hacky generic binding
support I did all the DMA stuff with), but having _both_ bindings in a
single DT is something I don't think anybody wants to see - is that how
you've tested this?
Robin.
> + return 0;
> +}
> +
> static int arm_smmu_add_device(struct device *dev)
> {
> struct iommu_group *group;
> @@ -1458,6 +1476,7 @@ static struct iommu_ops arm_smmu_ops = {
> .unmap = arm_smmu_unmap,
> .map_sg = default_iommu_map_sg,
> .iova_to_phys = arm_smmu_iova_to_phys,
> + .of_xlate = arm_smmu_of_xlate,
> .add_device = arm_smmu_add_device,
> .remove_device = arm_smmu_remove_device,
> .device_group = arm_smmu_device_group,
>
WARNING: multiple messages have this Message-ID (diff)
From: Robin Murphy <robin.murphy@arm.com>
To: Anup Patel <anup.patel@broadcom.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Joerg Roedel <joro@8bytes.org>, Will Deacon <will.deacon@arm.com>,
Sricharan R <sricharan@codeaurora.org>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>
Cc: Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Device Tree <devicetree@vger.kernel.org>,
Ray Jui <rjui@broadcom.com>,
Scott Branden <sbranden@broadcom.com>,
Vikram Prakash <vikramp@broadcom.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>
Subject: Re: [RFC PATCH 4/6] iommu/arm-smmu: Add support for IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver
Date: Thu, 28 Jan 2016 17:28:30 +0000 [thread overview]
Message-ID: <56AA4FBE.6090702@arm.com> (raw)
In-Reply-To: <1453872079-27140-5-git-send-email-anup.patel@broadcom.com>
On 27/01/16 05:21, Anup Patel wrote:
> To allow use of large memory (> 4Gb) with 32bit devices we need to use
> some kind of iommu for such 32bit devices.
>
> This patch extends SMMUv1/SMMUv2 driver to support DMA domains which
> in-turn will allows us to use iommu based DMA mappings for 32bit devices.
>
> Signed-off-by: Anup Patel <anup.patel@broadcom.com>
> Reviewed-by: Ray Jui <rjui@broadcom.com>
> Reviewed-by: Scott Branden <sbranden@broadcom.com>
> ---
> drivers/iommu/arm-smmu.c | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 9bdf6b2..43424fe 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -29,6 +29,7 @@
> #define pr_fmt(fmt) "arm-smmu: " fmt
>
> #include <linux/delay.h>
> +#include <linux/dma-iommu.h>
> #include <linux/dma-mapping.h>
> #include <linux/err.h>
> #include <linux/interrupt.h>
> @@ -967,7 +968,7 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> {
> struct arm_smmu_domain *smmu_domain;
>
> - if (type != IOMMU_DOMAIN_UNMANAGED)
> + if (type != IOMMU_DOMAIN_UNMANAGED && type != IOMMU_DOMAIN_DMA)
> return NULL;
> /*
> * Allocate the domain and initialise some of its data structures.
> @@ -978,6 +979,12 @@ static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
> if (!smmu_domain)
> return NULL;
>
> + if (type == IOMMU_DOMAIN_DMA &&
> + iommu_get_dma_cookie(&smmu_domain->domain)) {
> + kfree(smmu_domain);
> + return NULL;
> + }
> +
> mutex_init(&smmu_domain->init_mutex);
> spin_lock_init(&smmu_domain->pgtbl_lock);
>
> @@ -992,6 +999,7 @@ static void arm_smmu_domain_free(struct iommu_domain *domain)
> * Free the domain resources. We assume that all devices have
> * already been detached.
> */
> + iommu_put_dma_cookie(domain);
> arm_smmu_destroy_domain_context(domain);
> kfree(smmu_domain);
> }
> @@ -1361,6 +1369,16 @@ static int arm_smmu_init_platform_device(struct device *dev,
> return 0;
> }
>
> +int arm_smmu_of_xlate(struct device *dev, struct of_phandle_args *args)
> +{
> + /*
> + * Nothing to do here because SMMU is already aware of all
> + * MMU masters and their stream IDs using mmu-master attibute
> + * SMMU DT node.
> + */
...but on the same hand this will also never get called if there's no
"iommus" property on the master. Maintaining support for existing users
of the "mmu-masters" binding is one thing (namely the thing that's been
slowing down my efforts to clean up the really hacky generic binding
support I did all the DMA stuff with), but having _both_ bindings in a
single DT is something I don't think anybody wants to see - is that how
you've tested this?
Robin.
> + return 0;
> +}
> +
> static int arm_smmu_add_device(struct device *dev)
> {
> struct iommu_group *group;
> @@ -1458,6 +1476,7 @@ static struct iommu_ops arm_smmu_ops = {
> .unmap = arm_smmu_unmap,
> .map_sg = default_iommu_map_sg,
> .iova_to_phys = arm_smmu_iova_to_phys,
> + .of_xlate = arm_smmu_of_xlate,
> .add_device = arm_smmu_add_device,
> .remove_device = arm_smmu_remove_device,
> .device_group = arm_smmu_device_group,
>
next prev parent reply other threads:[~2016-01-28 17:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 5:21 [RFC PATCH 0/6] iommu/arm-smmu: Add support for DMA domains and instruction fetch Anup Patel
2016-01-27 5:21 ` Anup Patel
[not found] ` <1453872079-27140-1-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2016-01-27 5:21 ` [RFC PATCH 1/6] iommu/arm-smmu: Init driver using IOMMU_OF_DECLARE Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` [RFC PATCH 2/6] iommu/arm-smmu: Invoke DT probe from arm_smmu_of_setup() Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` [RFC PATCH 3/6] of: iommu: Increment DT node refcount in of_iommu_set_ops() Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-28 17:15 ` Robin Murphy
2016-01-28 17:15 ` Robin Murphy
2016-01-27 5:21 ` [RFC PATCH 4/6] iommu/arm-smmu: Add support for IOMMU_DOMAIN_DMA in SMMUv1/SMMUv2 driver Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
[not found] ` <1453872079-27140-5-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2016-01-28 17:28 ` Robin Murphy [this message]
2016-01-28 17:28 ` Robin Murphy
2016-01-28 17:28 ` Robin Murphy
2016-01-28 17:48 ` Mark Rutland
2016-01-28 17:48 ` Mark Rutland
[not found] ` <56AA4FBE.6090702-5wv7dgnIgG8@public.gmane.org>
2016-01-29 3:58 ` Anup Patel
2016-01-29 3:58 ` Anup Patel
2016-01-29 3:58 ` Anup Patel
2016-01-27 5:21 ` [RFC PATCH 5/6] iommu/arm-smmu: Option to treat instruction fetch as data read for SMMUv2 Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
[not found] ` <1453872079-27140-6-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2016-01-28 17:10 ` Robin Murphy
2016-01-28 17:10 ` Robin Murphy
2016-01-28 17:10 ` Robin Murphy
[not found] ` <56AA4B89.3040400-5wv7dgnIgG8@public.gmane.org>
2016-01-29 3:42 ` Anup Patel
2016-01-29 3:42 ` Anup Patel
2016-01-29 3:42 ` Anup Patel
2016-01-27 5:21 ` [RFC PATCH 6/6] iommu/arm-smmu: Update bindings document for smmu-inst-as-data DT option Anup Patel
2016-01-27 5:21 ` Anup Patel
2016-01-27 5:21 ` Anup Patel
[not found] ` <1453872079-27140-7-git-send-email-anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2016-01-27 12:28 ` Mark Rutland
2016-01-27 12:28 ` Mark Rutland
2016-01-27 12:28 ` Mark Rutland
2016-01-27 14:22 ` Anup Patel
2016-01-27 14:22 ` Anup Patel
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=56AA4FBE.6090702@arm.com \
--to=robin.murphy-5wv7dgnigg8@public.gmane.org \
--cc=anup.patel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=pawel.moll-5wv7dgnIgG8@public.gmane.org \
--cc=rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=vikramp-dY08KVG/lbpWk0Htik3J/w@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.