All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
To: Leo Li <leoyang.li@nxp.com>
Cc: Netdev <netdev@vger.kernel.org>,
	Madalin-cristian Bucur <madalin.bucur@nxp.com>,
	Roy Pledge <roy.pledge@nxp.com>,
	Camelia Alexandra Groza <camelia.groza@nxp.com>,
	David Miller <davem@davemloft.net>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
	<linux-arm-kernel@lists.infradead.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Date: Mon, 1 Apr 2019 11:15:21 +0000	[thread overview]
Message-ID: <DB7PR04MB513214FB393EF3C514A26F21EC550@DB7PR04MB5132.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CADRPPNTPZ1xhYr_YKZvrXVJhVqhV9RNAu6ekVHDeOudXTZx3=g@mail.gmail.com>

Hi Leo,

> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Friday, March 29, 2019 11:16 PM
> 
> On Fri, Mar 29, 2019 at 9:03 AM <laurentiu.tudor@nxp.com> wrote:
> >
> > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work without faults behind an iommu.
> >
> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > ---
> >  drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index 7c3cc968053c..b209c79511bb 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -29,6 +29,7 @@
> >   */
> >
> >  #include "bman_priv.h"
> > +#include <linux/iommu.h>
> >
> >  u16 bman_ip_rev;
> >  EXPORT_SYMBOL(bman_ip_rev);
> > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >         int ret, err_irq;
> >         struct device *dev = &pdev->dev;
> >         struct device_node *node = dev->of_node;
> > +       struct iommu_domain *domain;
> >         struct resource *res;
> >         u16 id, bm_pool_cnt;
> >         u8 major, minor;
> > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >
> >         dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
> >
> > +       /* Create an 1-to-1 iommu mapping for FBPR area */
> > +       domain = iommu_get_domain_for_dev(dev);
> > +       if (domain) {
> > +               ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > +                               IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > +               if (ret)
> > +                       dev_warn(dev, "failed to iommu_map() %d\n",
> ret);
> > +       }
> 
> Like Robin has pointed out, could you explain why the mapping in this
> patch and other similar patches cannot be dealt with the dma APIs
> automatically?  If the current bqman driver doesn't use the dma APIs
> correctly, we need to fix that instead of doing the mapping
> explicitly.

Please see my reply to Robin.
As a side comment, if we want to convert to dma api it will be interesting to see how we'll deal with the qman portal devices as they require a smmu mapping for an area of their register block (where stashing goes). Problem is they treated as distinct devices, the address where they should dma cannot be configured independently for each one of them. I think I can came up with a proposal but probably will not look very pretty.

---
Best Regards, Laurentiu

> > +
> >         bm_set_memory(fbpr_a, fbpr_sz);
> >
> >         err_irq = platform_get_irq(pdev, 0);
> > --
> > 2.17.1
> >

WARNING: multiple messages have this Message-ID (diff)
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
To: Leo Li <leoyang.li@nxp.com>
Cc: Madalin-cristian Bucur <madalin.bucur@nxp.com>,
	Netdev <netdev@vger.kernel.org>, Roy Pledge <roy.pledge@nxp.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	Camelia Alexandra Groza <camelia.groza@nxp.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	David Miller <davem@davemloft.net>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Date: Mon, 1 Apr 2019 11:15:21 +0000	[thread overview]
Message-ID: <DB7PR04MB513214FB393EF3C514A26F21EC550@DB7PR04MB5132.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CADRPPNTPZ1xhYr_YKZvrXVJhVqhV9RNAu6ekVHDeOudXTZx3=g@mail.gmail.com>

Hi Leo,

> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Friday, March 29, 2019 11:16 PM
> 
> On Fri, Mar 29, 2019 at 9:03 AM <laurentiu.tudor@nxp.com> wrote:
> >
> > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work without faults behind an iommu.
> >
> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > ---
> >  drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index 7c3cc968053c..b209c79511bb 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -29,6 +29,7 @@
> >   */
> >
> >  #include "bman_priv.h"
> > +#include <linux/iommu.h>
> >
> >  u16 bman_ip_rev;
> >  EXPORT_SYMBOL(bman_ip_rev);
> > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >         int ret, err_irq;
> >         struct device *dev = &pdev->dev;
> >         struct device_node *node = dev->of_node;
> > +       struct iommu_domain *domain;
> >         struct resource *res;
> >         u16 id, bm_pool_cnt;
> >         u8 major, minor;
> > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >
> >         dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
> >
> > +       /* Create an 1-to-1 iommu mapping for FBPR area */
> > +       domain = iommu_get_domain_for_dev(dev);
> > +       if (domain) {
> > +               ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > +                               IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > +               if (ret)
> > +                       dev_warn(dev, "failed to iommu_map() %d\n",
> ret);
> > +       }
> 
> Like Robin has pointed out, could you explain why the mapping in this
> patch and other similar patches cannot be dealt with the dma APIs
> automatically?  If the current bqman driver doesn't use the dma APIs
> correctly, we need to fix that instead of doing the mapping
> explicitly.

Please see my reply to Robin.
As a side comment, if we want to convert to dma api it will be interesting to see how we'll deal with the qman portal devices as they require a smmu mapping for an area of their register block (where stashing goes). Problem is they treated as distinct devices, the address where they should dma cannot be configured independently for each one of them. I think I can came up with a proposal but probably will not look very pretty.

---
Best Regards, Laurentiu

> > +
> >         bm_set_memory(fbpr_a, fbpr_sz);
> >
> >         err_irq = platform_get_irq(pdev, 0);
> > --
> > 2.17.1
> >

WARNING: multiple messages have this Message-ID (diff)
From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
To: Leo Li <leoyang.li@nxp.com>
Cc: Madalin-cristian Bucur <madalin.bucur@nxp.com>,
	Netdev <netdev@vger.kernel.org>, Roy Pledge <roy.pledge@nxp.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	Camelia Alexandra Groza <camelia.groza@nxp.com>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
	David Miller <davem@davemloft.net>,
	"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>
Subject: RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu
Date: Mon, 1 Apr 2019 11:15:21 +0000	[thread overview]
Message-ID: <DB7PR04MB513214FB393EF3C514A26F21EC550@DB7PR04MB5132.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CADRPPNTPZ1xhYr_YKZvrXVJhVqhV9RNAu6ekVHDeOudXTZx3=g@mail.gmail.com>

Hi Leo,

> -----Original Message-----
> From: Li Yang [mailto:leoyang.li@nxp.com]
> Sent: Friday, March 29, 2019 11:16 PM
> 
> On Fri, Mar 29, 2019 at 9:03 AM <laurentiu.tudor@nxp.com> wrote:
> >
> > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> >
> > Add a one-to-one iommu mapping for bman private data memory (FBPR).
> > This is required for BMAN to work without faults behind an iommu.
> >
> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > ---
> >  drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/soc/fsl/qbman/bman_ccsr.c
> b/drivers/soc/fsl/qbman/bman_ccsr.c
> > index 7c3cc968053c..b209c79511bb 100644
> > --- a/drivers/soc/fsl/qbman/bman_ccsr.c
> > +++ b/drivers/soc/fsl/qbman/bman_ccsr.c
> > @@ -29,6 +29,7 @@
> >   */
> >
> >  #include "bman_priv.h"
> > +#include <linux/iommu.h>
> >
> >  u16 bman_ip_rev;
> >  EXPORT_SYMBOL(bman_ip_rev);
> > @@ -178,6 +179,7 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >         int ret, err_irq;
> >         struct device *dev = &pdev->dev;
> >         struct device_node *node = dev->of_node;
> > +       struct iommu_domain *domain;
> >         struct resource *res;
> >         u16 id, bm_pool_cnt;
> >         u8 major, minor;
> > @@ -225,6 +227,15 @@ static int fsl_bman_probe(struct platform_device
> *pdev)
> >
> >         dev_dbg(dev, "Allocated FBPR 0x%llx 0x%zx\n", fbpr_a, fbpr_sz);
> >
> > +       /* Create an 1-to-1 iommu mapping for FBPR area */
> > +       domain = iommu_get_domain_for_dev(dev);
> > +       if (domain) {
> > +               ret = iommu_map(domain, fbpr_a, fbpr_a, fbpr_sz,
> > +                               IOMMU_READ | IOMMU_WRITE | IOMMU_CACHE);
> > +               if (ret)
> > +                       dev_warn(dev, "failed to iommu_map() %d\n",
> ret);
> > +       }
> 
> Like Robin has pointed out, could you explain why the mapping in this
> patch and other similar patches cannot be dealt with the dma APIs
> automatically?  If the current bqman driver doesn't use the dma APIs
> correctly, we need to fix that instead of doing the mapping
> explicitly.

Please see my reply to Robin.
As a side comment, if we want to convert to dma api it will be interesting to see how we'll deal with the qman portal devices as they require a smmu mapping for an area of their register block (where stashing goes). Problem is they treated as distinct devices, the address where they should dma cannot be configured independently for each one of them. I think I can came up with a proposal but probably will not look very pretty.

---
Best Regards, Laurentiu

> > +
> >         bm_set_memory(fbpr_a, fbpr_sz);
> >
> >         err_irq = platform_get_irq(pdev, 0);
> > --
> > 2.17.1
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-04-01 11:15 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-29 14:00 [PATCH 00/13] Prerequisites for NXP LS104xA SMMU enablement laurentiu.tudor
2019-03-29 14:00 ` laurentiu.tudor
2019-03-29 14:00 ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 21:50   ` Li Yang
2019-03-29 21:50     ` Li Yang
2019-03-29 21:50     ` Li Yang
2019-03-29 21:50     ` Li Yang
2019-04-01 10:21     ` Laurentiu Tudor
2019-04-01 10:21       ` Laurentiu Tudor
2019-04-01 10:21       ` Laurentiu Tudor
2019-04-01 10:21       ` Laurentiu Tudor
2019-03-29 14:00 ` [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:50   ` Robin Murphy
2019-03-29 14:50     ` Robin Murphy
2019-03-29 14:50     ` Robin Murphy
2019-04-01 11:04     ` Laurentiu Tudor
2019-04-01 11:04       ` Laurentiu Tudor
2019-04-01 11:04       ` Laurentiu Tudor
2019-04-01 11:04       ` Laurentiu Tudor
2019-04-19 13:41     ` Laurentiu Tudor
2019-04-19 13:41       ` Laurentiu Tudor
2019-04-19 13:41       ` Laurentiu Tudor
2019-04-19 13:41       ` Laurentiu Tudor
2019-04-19 13:41       ` Laurentiu Tudor
2019-03-29 21:16   ` Li Yang
2019-03-29 21:16     ` Li Yang
2019-03-29 21:16     ` Li Yang
2019-03-29 21:16     ` Li Yang
2019-04-01 11:15     ` Laurentiu Tudor [this message]
2019-04-01 11:15       ` Laurentiu Tudor
2019-04-01 11:15       ` Laurentiu Tudor
2019-04-01 11:15       ` Laurentiu Tudor
2019-03-29 14:00 ` [PATCH 03/13] soc/fsl/qman: map FQD and PFDR areas " laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 04/13] soc/fsl/qman-portal: map CENA area " laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 22:06   ` Li Yang
2019-03-29 22:06     ` Li Yang
2019-03-29 22:06     ` Li Yang
2019-03-29 22:06     ` Li Yang
2019-04-01 10:18     ` Laurentiu Tudor
2019-04-01 10:18       ` Laurentiu Tudor
2019-04-01 10:18       ` Laurentiu Tudor
2019-04-01 10:18       ` Laurentiu Tudor
2019-03-29 14:00 ` [PATCH 06/13] soc/fsl/qbman_portals: add APIs to retrieve the probing status laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-04-01 22:12   ` Li Yang
2019-04-01 22:12     ` Li Yang
2019-04-01 22:12     ` Li Yang
2019-04-01 22:12     ` Li Yang
2019-03-29 14:00 ` [PATCH 07/13] fsl/fman: backup and restore ICID registers laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 08/13] fsl/fman: add API to get the device behind a fman port laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 09/13] dpaa_eth: defer probing after qbman laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 10/13] dpaa_eth: base dma mappings on the fman rx port laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 11/13] dpaa_eth: fix iova handling for contiguous frames laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 12/13] dpaa_eth: fix iova handling for sg frames laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00 ` [PATCH 13/13] dpaa_eth: fix SG frame cleanup laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 14:00   ` laurentiu.tudor
2019-03-29 15:25   ` Joakim Tjernlund
2019-03-29 15:25     ` Joakim Tjernlund
2019-03-29 15:25     ` Joakim Tjernlund
2019-03-29 15:25     ` Joakim Tjernlund
2019-04-01 10:41     ` Laurentiu Tudor
2019-04-01 10:41       ` Laurentiu Tudor
2019-04-01 10:41       ` Laurentiu Tudor
2019-04-01 10:41       ` Laurentiu Tudor

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=DB7PR04MB513214FB393EF3C514A26F21EC550@DB7PR04MB5132.eurprd04.prod.outlook.com \
    --to=laurentiu.tudor@nxp.com \
    --cc=camelia.groza@nxp.com \
    --cc=davem@davemloft.net \
    --cc=iommu@lists.linux-foundation.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=madalin.bucur@nxp.com \
    --cc=netdev@vger.kernel.org \
    --cc=roy.pledge@nxp.com \
    /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.