Re: [PATCH 1/2] staging: fsl-dpaa2/eth: Fix address translations

Hi Ioana, Debatable nit inline. On 05/24/2017 03:13 PM, Ioana Radulescu wrote: > Use the correct mechanisms for translating a DMA-mapped IOVA > address into a virtual one. Without this fix, once SMMU is > enabled on Layerscape platforms, the Ethernet driver throws > IOMMU translation faults. > >

Re: [PATCH 1/2] staging: fsl-dpaa2/eth: Fix address translations

On 05/25/2017 03:31 PM, Ruxandra Ioana Radulescu wrote: >> -Original Message- >> From: Laurentiu Tudor >> Sent: Wednesday, May 24, 2017 3:34 PM >> To: Ruxandra Ioana Radulescu <ruxandra.radule...@nxp.com>; >> gre...@linuxfoundation.org >>

Re: [PATCH 5/6 v3] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

Hi Nipun, On 04/27/2018 01:27 PM, Nipun Gupta wrote: > Signed-off-by: Nipun Gupta > --- > drivers/bus/fsl-mc/fsl-mc-bus.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c

Re: [PATCH 6/7 v5] bus: fsl-mc: set coherent dma mask for devices on fsl-mc bus

On 05/20/2018 04:49 PM, Nipun Gupta wrote: > of_dma_configure() API expects coherent_dma_mask to be correctly > set in the devices. This patch does the needful. > > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com> Acked-by: Laurentiu Tudor <laurentiu.tu...@nxp.com> ---

Re: [PATCH v4 6/6] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Hi Nipun, On 04/30/2018 09:27 AM, Nipun Gupta wrote: > fsl-mc bus support the new iommu-map property. Comply to this binding > for fsl_mc bus. > > Signed-off-by: Nipun Gupta <nipun.gu...@nxp.com> This looks good to me, so: Reviewed-By: Laurentiu Tudor <laurentiu.tu...@nxp.c

Re: [PATCH v4 5/6] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

s good to me, so Reviewed-by: Laurentiu Tudor <laurentiu.tu...@nxp.com> --- Best Regards, Laurentiu > drivers/bus/fsl-mc/fsl-mc-bus.c | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-m

Re: [PATCH 1/3] iommu: Add fast hook for getting DMA domains

Hi Robin, On 14.08.2018 16:04, Robin Murphy wrote: > While iommu_get_domain_for_dev() is the robust way for arbitrary IOMMU > API callers to retrieve the domain pointer, for DMA ops domains it > doesn't scale well for large systems and multi-queue devices, since the > momentary refcount

[RFC PATCH] i2c: imx: dma map the i2c data i/o register

: Unhandled context fault: fsr=0x402, iova=0x02180004, fsynr=0x150021, cb=7 Signed-off-by: Laurentiu Tudor --- drivers/i2c/busses/i2c-imx.c | 57 +--- 1 file changed, 47 insertions(+), 10 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c

Re: [RFC PATCH] i2c: imx: dma map the i2c data i/o register

Hi Robin, On 16.01.2019 19:55, Robin Murphy wrote: > On 16/01/2019 16:17, Laurentiu Tudor wrote: >> This is an attempt to fix an iommu exception when doing dma to the >> i2c controller with EDMA. Without these mappings the smmu raises a >> context fault [1] exactly with t

[PATCH] dmaengine: fsl-edma: dma map slave device address

This mapping needs to be created in order for slave dma transfers to work on systems with SMMU. The implementation mostly mimics the one in pl330 dma driver, authored by Robin Murphy. Signed-off-by: Laurentiu Tudor Suggested-by: Robin Murphy --- Original approach was to add the missing mappings

Re: [PATCH] dmaengine: fsl-edma: dma map slave device address

Hi Angelo, On 18.01.2019 23:50, Angelo Dureghello wrote: > Hi Laurentiu, > > On Fri, Jan 18, 2019 at 12:06:23PM +0200, Laurentiu Tudor wrote: >> This mapping needs to be created in order for slave dma transfers >> to work on systems with SMMU. The implementation mostly mimic

[PATCH 11/13] dpaa_eth: fix iova handling for contiguous frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this by adding a function that does proper iova -> phys conversions using the iom

[PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu

From: Laurentiu Tudor 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 --- drivers/soc/fsl/qbman/bman_ccsr.c | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH 06/13] soc/fsl/qbman_portals: add APIs to retrieve the probing status

From: Laurentiu Tudor Add a couple of new APIs to check the probing status of the required cpu bound qman and bman portals: 'int bman_portals_probed()' and 'int qman_portals_probed()'. They return the following values. * 1 if qman/bman portals were all probed correctly * 0 if qman/bman

[PATCH 12/13] dpaa_eth: fix iova handling for sg frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this also for scatter-gather frames using the iova -> phys conversion function

[PATCH 08/13] fsl/fman: add API to get the device behind a fman port

From: Laurentiu Tudor Add an API that retrieves the 'struct device' that the specified fman port probed against. The new API will be used in a subsequent iommu enablement related patch. Signed-off-by: Laurentiu Tudor Acked-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/fman_port.c

[PATCH 07/13] fsl/fman: backup and restore ICID registers

From: Laurentiu Tudor During probing, FMAN is reset thus losing all its register settings. Backup port ICID registers before reset and restore them after, similarly to how it's done on powerpc / PAMU based platforms. This also has the side effect of disabling the old code path (liodn backup

[PATCH 13/13] dpaa_eth: fix SG frame cleanup

From: Laurentiu Tudor Fix issue with the entry indexing in the sg frame cleanup code being off-by-1. This problem showed up when doing some basic iperf tests and manifested in traffic coming to a halt. Signed-off-by: Laurentiu Tudor Acked-by: Madalin Bucur --- drivers/net/ethernet/freescale

[PATCH 00/13] Prerequisites for NXP LS104xA SMMU enablement

From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part

[PATCH 10/13] dpaa_eth: base dma mappings on the fman rx port

From: Laurentiu Tudor The dma transactions initiator is the rx fman port so that's the device that the dma mappings should be done. Previously the mappings were done through the MAC device which makes no sense because it's neither dma-able nor connected in any way to smmu. Signed-off

[PATCH 04/13] soc/fsl/qman-portal: map CENA area in the iommu

From: Laurentiu Tudor Add a one-to-one iommu mapping for qman portal CENA register area. This is required for QMAN stashing to work without faults behind an iommu. Signed-off-by: Laurentiu Tudor --- drivers/soc/fsl/qbman/qman_portal.c | 17 + 1 file changed, 17 insertions

[PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets

From: Laurentiu Tudor ARM SoCs use SMMU so the liodn fixup done in the qman driver is no longer making sense and it also breaks the ICID settings inherited from u-boot. Do the fixups only for PPC targets. Signed-off-by: Laurentiu Tudor --- drivers/soc/fsl/qbman/qman_ccsr.c | 2 ++ 1 file

[PATCH 09/13] dpaa_eth: defer probing after qbman

From: Laurentiu Tudor Enabling SMMU altered the order of device probing causing the dpaa1 ethernet driver to get probed before qbman and causing a boot crash. Add predictability in the probing order by deferring the ethernet driver probe after qbman and portals by using the recently introduced

[PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes

From: Laurentiu Tudor Prior to calling iommu_map()/iommu_unmap() page align the size or failures such as below could happen: iommu: unaligned: iova 0x... pa 0x... size 0x4000 min_pagesz 0x1 qman_portal 5.qman-portal: failed to iommu_map() -22 Seen when booted a kernel compiled

[PATCH 03/13] soc/fsl/qman: map FQD and PFDR areas in the iommu

From: Laurentiu Tudor Add a one-to-one iommu mapping for qman private data memory areas (FQD and PFDR). This is required for QMAN to work without faults behind an iommu. Signed-off-by: Laurentiu Tudor --- drivers/soc/fsl/qbman/qman_ccsr.c | 15 +++ 1 file changed, 15 insertions

RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu

Hi Robin, > -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Friday, March 29, 2019 4:51 PM > > On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > Add a one-to-one iommu mapping f

RE: [PATCH 05/13] soc/fsl/bqman: page align iommu mapping sizes

Hi Leo, > -Original Message- > From: Li Yang [mailto:leoyang...@nxp.com] > Sent: Saturday, March 30, 2019 12:07 AM > To: Laurentiu Tudor > Cc: Netdev ; Madalin-cristian Bucur > ; Roy Pledge ; Camelia > Alexandra Groza ; David Miller > ; Linux IOMMU ; > moder

RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu

Hi Leo, > -Original Message- > From: Li Yang [mailto:leoyang...@nxp.com] > Sent: Friday, March 29, 2019 11:16 PM > > On Fri, Mar 29, 2019 at 9:03 AM wrote: > > > > From: Laurentiu Tudor > > > > Add a one-to-one iommu mapping for bman private d

RE: [PATCH 01/13] soc/fsl/qman: fixup liodns only on ppc targets

Hi Leo, > -Original Message- > From: Li Yang [mailto:leoyang...@nxp.com] > Sent: Friday, March 29, 2019 11:50 PM > To: Laurentiu Tudor > Cc: Netdev ; Madalin-cristian Bucur > ; Roy Pledge ; Camelia > Alexandra Groza ; David Miller > ; Linux IOMMU ; > moder

RE: [PATCH 13/13] dpaa_eth: fix SG frame cleanup

t; On Fri, 2019-03-29 at 16:00 +0200, laurentiu.tu...@nxp.com wrote: > > > > From: Laurentiu Tudor > > > > Fix issue with the entry indexing in the sg frame cleanup code being > > off-by-1. This problem showed up when doing some basic iperf tests and > > m

RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement

Hello, > -Original Message- > From: David Miller > Sent: Friday, May 31, 2019 1:09 AM > > From: laurentiu.tu...@nxp.com > Date: Thu, 30 May 2019 17:19:45 +0300 > > > Depends on this pull request: > > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-May/653554.html > >

RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames

> -Original Message- > From: Christoph Hellwig > Sent: Friday, May 31, 2019 7:56 PM > > On Fri, May 31, 2019 at 04:53:16PM +0000, Laurentiu Tudor wrote: > > Unfortunately due to our hardware particularities we do not have > alternatives. This is also the case

RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement

> -Original Message- > From: Andreas Färber > Sent: Friday, May 31, 2019 8:04 PM > > Hello Laurentiu, > > Am 31.05.19 um 18:46 schrieb Laurentiu Tudor: > >> -Original Message- > >> From: Andreas Färber > >> Sent: Friday, May 31, 2

RE: [PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement

Hello Andreas, > -Original Message- > From: Andreas Färber > Sent: Friday, May 31, 2019 7:15 PM > > Hi Laurentiu, > > Am 30.05.19 um 16:19 schrieb laurentiu.tu...@nxp.com: > > This patch series contains several fixes in preparation for SMMU > > support on NXP LS1043A and LS1046A chips.

RE: [PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames

Hi Christoph, > -Original Message- > From: Christoph Hellwig > Sent: Friday, May 31, 2019 7:32 PM > > On Thu, May 30, 2019 at 05:19:50PM +0300, laurentiu.tu...@nxp.com wrote: > > +static phys_addr_t dpaa_iova_to_phys(const struct dpaa_priv *priv, > > +

[PATCH v3 5/6] dpaa_eth: fix iova handling for contiguous frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this by adding a function that does proper iova -> phys conversions using the iom

[PATCH v3 6/6] dpaa_eth: fix iova handling for sg frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this also for scatter-gather frames using the iova -> phys conversion function

[PATCH v3 1/6] fsl/fman: don't touch liodn base regs reserved on non-PAMU SoCs

From: Laurentiu Tudor liodn base registers are specific to PAMU based NXP systems and on SMMU based ones are reserved. Don't access them if PAMU is compiled in. Signed-off-by: Laurentiu Tudor --- drivers/net/ethernet/freescale/fman/fman.c | 6 +- 1 file changed, 5 insertions(+), 1

[PATCH v3 4/6] dpaa_eth: base dma mappings on the fman rx port

From: Laurentiu Tudor The dma transactions initiator is the rx fman port so that's the device that the dma mappings should be done. Previously the mappings were done through the MAC device which makes no sense because it's neither dma-able nor connected in any way to smmu. Signed-off

[PATCH v3 2/6] fsl/fman: add API to get the device behind a fman port

From: Laurentiu Tudor Add an API that retrieves the 'struct device' that the specified fman port probed against. The new API will be used in a subsequent iommu enablement related patch. Signed-off-by: Laurentiu Tudor Acked-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/fman_port.c

[PATCH v3 3/6] dpaa_eth: defer probing after qbman

From: Laurentiu Tudor Enabling SMMU altered the order of device probing causing the dpaa1 ethernet driver to get probed before qbman and causing a boot crash. Add predictability in the probing order by deferring the ethernet driver probe after qbman and portals by using the recently introduced

[PATCH v3 0/6] Prerequisites for NXP LS104xA SMMU enablement

From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part

RE: [ARM SMMU] Dynamic StreamID allocation

Hi Pankaj, > -Original Message- > From: linux-arm-kernel On > Behalf Of Pankaj Bansal > Sent: Friday, May 10, 2019 3:34 PM > > Hi Will/Robin/Joerg, > > I am s/w engineer from NXP India Pvt. Ltd. > We are using SMMU-V3 in one of NXP SOC. > I have a question about the SMMU Stream ID

[PATCH v2 1/9] soc/fsl/qman: fixup liodns only on ppc targets

From: Laurentiu Tudor ARM SoCs use SMMU so the liodn fixup done in the qman driver is no longer making sense and it also breaks the ICID settings inherited from u-boot. Do the fixups only for PPC targets. Signed-off-by: Laurentiu Tudor --- drivers/soc/fsl/qbman/qman_ccsr.c | 2 +- drivers/soc

[PATCH v2 2/9] soc/fsl/qbman_portals: add APIs to retrieve the probing status

From: Laurentiu Tudor Add a couple of new APIs to check the probing status of the required cpu bound qman and bman portals: 'int bman_portals_probed()' and 'int qman_portals_probed()'. They return the following values. * 1 if qman/bman portals were all probed correctly * 0 if qman/bman

[PATCH v2 5/9] dpaa_eth: defer probing after qbman

From: Laurentiu Tudor Enabling SMMU altered the order of device probing causing the dpaa1 ethernet driver to get probed before qbman and causing a boot crash. Add predictability in the probing order by deferring the ethernet driver probe after qbman and portals by using the recently introduced

[PATCH v2 0/9] Prerequisites for NXP LS104xA SMMU enablement

From: Laurentiu Tudor This patch series contains several fixes in preparation for SMMU support on NXP LS1043A and LS1046A chips. Once these get picked up, I'll submit the actual SMMU enablement patches consisting in the required device tree changes. This patch series contains only part

[PATCH v2 7/9] dpaa_eth: fix iova handling for contiguous frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this by adding a function that does proper iova -> phys conversions using the iom

[PATCH v2 6/9] dpaa_eth: base dma mappings on the fman rx port

From: Laurentiu Tudor The dma transactions initiator is the rx fman port so that's the device that the dma mappings should be done. Previously the mappings were done through the MAC device which makes no sense because it's neither dma-able nor connected in any way to smmu. Signed-off

[PATCH v2 3/9] fsl/fman: backup and restore ICID registers

From: Laurentiu Tudor During probing, FMAN is reset thus losing all its register settings. Backup port ICID registers before reset and restore them after, similarly to how it's done on powerpc / PAMU based platforms. This also has the side effect of disabling the old code path (liodn backup

[PATCH v2 9/9] dpaa_eth: fix SG frame cleanup

From: Laurentiu Tudor Fix issue with the entry indexing in the sg frame cleanup code being off-by-1. This problem showed up when doing some basic iperf tests and manifested in traffic coming to a halt. Signed-off-by: Laurentiu Tudor Acked-by: Madalin Bucur --- drivers/net/ethernet/freescale

[PATCH v2 4/9] fsl/fman: add API to get the device behind a fman port

From: Laurentiu Tudor Add an API that retrieves the 'struct device' that the specified fman port probed against. The new API will be used in a subsequent iommu enablement related patch. Signed-off-by: Laurentiu Tudor Acked-by: Madalin Bucur --- drivers/net/ethernet/freescale/fman/fman_port.c

[PATCH v2 8/9] dpaa_eth: fix iova handling for sg frames

From: Laurentiu Tudor The driver relies on the no longer valid assumption that dma addresses (iovas) are identical to physical addressees and uses phys_to_virt() to make iova -> vaddr conversions. Fix this also for scatter-gather frames using the iova -> phys conversion function

RE: [PATCH 02/13] soc/fsl/bman: map FBPR area in the iommu

Hi Robin, > -Original Message- > From: Robin Murphy > Sent: Friday, March 29, 2019 4:51 PM > > On 29/03/2019 14:00, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > Add a one-to-one iommu mapping for bman private data memory (FBPR). >

RE: [PATCH v2 9/9] dpaa_eth: fix SG frame cleanup

> -Original Message- > From: Joakim Tjernlund > Sent: Thursday, May 2, 2019 1:37 PM > > On Thu, 2019-05-02 at 09:05 +0000, Laurentiu Tudor wrote: > > Hi Joakim, > > > > > -Original Message- > > > From: Joakim Tjernlund

RE: [PATCH v2 9/9] dpaa_eth: fix SG frame cleanup

Hi Joakim, > -Original Message- > From: Joakim Tjernlund > Sent: Saturday, April 27, 2019 8:11 PM > > On Sat, 2019-04-27 at 10:10 +0300, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > Fix issue with the entry indexing in the sg fram

RE: [PATCH v2 7/9] dpaa_eth: fix iova handling for contiguous frames

> -Original Message- > From: Christoph Hellwig > Sent: Saturday, April 27, 2019 7:46 PM > > On Sat, Apr 27, 2019 at 10:10:29AM +0300, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > The driver relies on the no longer valid assumpt

Re: [RFC PATCH] dma-mapping: create iommu mapping for newly allocated dma coherent mem

Hi Christoph, On 24.04.2019 17:57, Christoph Hellwig wrote: > I'd be happy to offload all of the mentioned tasks to you if you > volunteer. Alright, I think I mostly got it and can start with the two usb drivers you mentioned. Just need a few clarifications, please see inline. > I think the

RE: [RFC PATCH] dma-mapping: create iommu mapping for newly allocated dma coherent mem

Hello, > -Original Message- > From: Christoph Hellwig > Sent: Monday, April 22, 2019 9:11 PM > > On Mon, Apr 22, 2019 at 07:51:25PM +0300, laurentiu.tu...@nxp.com wrote: > > From: Laurentiu Tudor > > > > If possible / available call into the DMA API

[RFC PATCH] dma-mapping: create iommu mapping for newly allocated dma coherent mem

From: Laurentiu Tudor If possible / available call into the DMA API to get a proper iommu mapping and a dma address for the newly allocated coherent dma memory. Signed-off-by: Laurentiu Tudor --- arch/arm/mm/dma-mapping-nommu.c | 3 ++- include/linux/dma-mapping.h | 12 ++--- kernel

Re: [PATCH v2 3/3] dpaa2_eth: use new unmap and sync dma api variants

On 28.10.2019 13:38, h...@lst.de wrote: > On Mon, Oct 28, 2019 at 10:55:05AM +0000, Laurentiu Tudor wrote: >>>> @@ -85,9 +75,10 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv, >>>> sgt = vaddr + dpaa2_fd_get_offset(fd); >>>> for

Re: [PATCH v2 1/3] dma-mapping: introduce new dma unmap and sync api variants

On 28.10.2019 15:42, Robin Murphy wrote: > On 24/10/2019 13:41, Laurentiu Tudor wrote: >> From: Laurentiu Tudor >> >> Introduce a few new dma unmap and sync variants that, on top of the >> original variants, return the virtual address corresponding to the >&g

Re: [PATCH v2 1/3] dma-mapping: introduce new dma unmap and sync api variants

Hi Robin, On 28.10.2019 15:42, Robin Murphy wrote: > On 24/10/2019 13:41, Laurentiu Tudor wrote: >> From: Laurentiu Tudor >> >> Introduce a few new dma unmap and sync variants that, on top of the >> original variants, return the virtual address corresponding

[PATCH v3 2/4] iommu/dma: wire-up new dma map op .get_virt_addr

From: Laurentiu Tudor Add an implementation of the newly introduced dma map op in the generic DMA IOMMU generic glue layer and wire it up. Signed-off-by: Laurentiu Tudor --- drivers/iommu/dma-iommu.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/iommu/dma-iommu.c

[PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants

From: Laurentiu Tudor This series introduces a few new dma unmap and sync api variants that, on top of what the originals do, return the virtual address corresponding to the input dma address. In order to do that a new dma map op is added, .get_virt_addr that takes the input dma address

[PATCH v3 3/4] swiotlb: make new {unmap, sync}_desc dma apis work with swiotlb

From: Laurentiu Tudor Add a new swiotlb helper to retrieve the original physical address given a swiotlb physical address and use it in the new dma_unmap_single_attrs_desc(), dma_sync_single_for_cpu_desc() and dma_unmap_page_attrs_desc() APIs to make them work with swiotlb. Signed-off

[PATCH v3 4/4] dpaa2_eth: use new unmap and sync dma api variants

From: Laurentiu Tudor Convert this driver to usage of the newly introduced dma unmap and sync DMA APIs. This will get rid of the unsupported direct usage of iommu_iova_to_phys() API. Signed-off-by: Laurentiu Tudor --- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 43

[PATCH v3 1/4] dma-mapping: introduce new dma unmap and sync api variants

From: Laurentiu Tudor Introduce a few new dma unmap and sync variants that, on top of the original variants, return the virtual address corresponding to the input dma address. Additionally, provide an api that can be used to check at runtime if these variants are actually available. In order

Re: [PATCH v2 3/3] dpaa2_eth: use new unmap and sync dma api variants

Hi Jonathan, On 25.10.2019 19:12, Jonathan Lemon wrote: > > > On 24 Oct 2019, at 5:41, Laurentiu Tudor wrote: > >> From: Laurentiu Tudor >> >> Convert this driver to usage of the newly introduced dma unmap and >> sync DMA APIs. This will get

Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

On 24.10.2019 05:01, h...@lst.de wrote: > On Wed, Oct 23, 2019 at 11:53:41AM +0000, Laurentiu Tudor wrote: >> We had an internal discussion over these points you are raising and >> Madalin (cc-ed) came up with another idea: instead of adding this prone >> to misuse api ho

[PATCH 0/3] dma-mapping: introduce new dma unmap and sync variants

From: Laurentiu Tudor This series introduces a few new dma unmap and sync api variants that, on top of what the originals do, return the physical address corresponding to the input dma address. In order to do that a new dma map op is added, .get_phys_addr that takes the input dma address

[PATCH v2 3/3] dpaa2_eth: use new unmap and sync dma api variants

From: Laurentiu Tudor Convert this driver to usage of the newly introduced dma unmap and sync DMA APIs. This will get rid of the unsupported direct usage of iommu_iova_to_phys() API. Signed-off-by: Laurentiu Tudor --- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 40

[PATCH v2 2/3] iommu/dma: wire-up new dma map op .get_virt_addr

From: Laurentiu Tudor Add an implementation of the newly introduced dma map op in the generic DMA IOMMU generic glue layer and wire it up. Signed-off-by: Laurentiu Tudor --- drivers/iommu/dma-iommu.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/iommu/dma

[PATCH v2 1/3] dma-mapping: introduce new dma unmap and sync api variants

From: Laurentiu Tudor Introduce a few new dma unmap and sync variants that, on top of the original variants, return the virtual address corresponding to the input dma address. In order to implement this a new dma map op is added and used: void *get_virt_addr(dev, dma_handle); It does

[PATCH v2 0/3] dma-mapping: introduce new dma unmap and sync variants

From: Laurentiu Tudor This series introduces a few new dma unmap and sync api variants that, on top of what the originals do, return the virtual address corresponding to the input dma address. In order to do that a new dma map op is added, .get_virt_addr that takes the input dma address

[PATCH 3/3] dpaa2_eth: use new unmap and sync dma api variants

From: Laurentiu Tudor Convert this driver to usage of the newly introduced dma unmap and sync DMA APIs. This will get rid of the unsupported direct usage of iommu_iova_to_phys() API. Signed-off-by: Laurentiu Tudor --- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 43

[PATCH 1/3] dma-mapping: introduce new dma unmap and sync api variants

From: Laurentiu Tudor Introduce a few new dma unmap and sync variants that, on top of the original variants, return the physical address corresponding to the input dma address. In order to implement this a new dma map op is added and used: phys_addr_t get_phys_addr(dev, dma_handle); It does

[PATCH 2/3] iommu/dma: wire-up new dma map op .get_phys_addr

From: Laurentiu Tudor Add an implementation of the newly introduced dma map op in the generic DMA IOMMU generic glue layer and wire it up. Signed-off-by: Laurentiu Tudor --- drivers/iommu/dma-iommu.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/iommu/dma-iommu.c b

Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

On 24.10.2019 14:04, Robin Murphy wrote: > On 2019-10-24 8:49 am, Laurentiu Tudor wrote: >> >> >> On 24.10.2019 05:01, h...@lst.de wrote: >>> On Wed, Oct 23, 2019 at 11:53:41AM +, Laurentiu Tudor wrote: >>>> We had an internal discussion over these p

RE: [PATCH v2 1/3] dma-mapping: introduce new dma unmap and sync api variants

> -Original Message- > From: h...@lst.de > Sent: Monday, October 28, 2019 2:38 PM > > On Thu, Oct 24, 2019 at 12:41:41PM +0000, Laurentiu Tudor wrote: > > From: Laurentiu Tudor > > > > Introduce a few new dma unmap and sync variants that, on top of

Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

On 22.10.2019 16:25, Robin Murphy wrote: > On 22/10/2019 13:55, Laurentiu Tudor wrote: >> From: Laurentiu Tudor >> >> Introduce a new dma map op called dma_addr_to_phys_addr() that converts >> a dma address to the physical address backing it up and add wrapper for

[RFC PATCH 3/3] dpaa2_eth: use dma_addr_to_phys_addr() new dma api

From: Laurentiu Tudor Convert this driver to usage of the newly introduced dma_addr_to_phys_addr() DMA API. This will get rid of the unsupported direct usage of iommu_iova_to_phys() API. Signed-off-by: Laurentiu Tudor --- .../net/ethernet/freescale/dpaa2/dpaa2-eth.c | 21

[RFC PATCH 0/3] dma-mapping: introduce a new dma api

From: Laurentiu Tudor This series introduces a new dma api called dma_addr_to_phys_addr() that converts a dma address to the corresponding physical address. It consists in a new dma map op and the wrapper api, both added in the first patch. The second patch adds an implementation in the iommu

[RFC PATCH 2/3] iommu/dma: wire-up new dma op dma_addr_to_phys_addr()

From: Laurentiu Tudor Add an implementation of the newly introduced dma map op in the generic DMA IOMMU generic glue layer and wire it up. Signed-off-by: Laurentiu Tudor --- drivers/iommu/dma-iommu.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/iommu/dma-iommu.c b

[RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

From: Laurentiu Tudor Introduce a new dma map op called dma_addr_to_phys_addr() that converts a dma address to the physical address backing it up and add wrapper for it. Signed-off-by: Laurentiu Tudor --- include/linux/dma-mapping.h | 21 + 1 file changed, 21 insertions

Re: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

Hi Robin, On 22.10.2019 16:25, Robin Murphy wrote: > On 22/10/2019 13:55, Laurentiu Tudor wrote: >> From: Laurentiu Tudor >> >> Introduce a new dma map op called dma_addr_to_phys_addr() that converts >> a dma address to the physical address backing it up and add

Re: [PATCH v3 0/4] dma-mapping: introduce new dma unmap and sync variants

On 13.11.2019 22:11, David Miller wrote: > From: Laurentiu Tudor > Date: Wed, 13 Nov 2019 12:24:17 + > >> From: Laurentiu Tudor >> >> This series introduces a few new dma unmap and sync api variants that, >> on top of what the originals do, return the

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

Hello, On 28.02.2020 04:57, Bjorn Andersson wrote: On Mon 09 Dec 07:07 PST 2019, Thierry Reding wrote: From: Thierry Reding Sorry for the slow response on this, finally got the time to go through this in detail and try it out on some Qualcomm boards. On some platforms, the firmware will

Re: [PATCH] iommu: silence iommu group prints

On 04.03.2020 12:07, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 11:56:53AM +0200, Laurentiu Tudor wrote: From 44ae46501b5379bd0890df87fd3827248626ed03 Mon Sep 17 00:00:00 2001 From: Laurentiu Tudor Date: Tue, 1 Oct 2019 16:22:48 +0300 Subject: [PATCH 1/6] bus: fsl-mc

Re: [PATCH] iommu: silence iommu group prints

On 04.03.2020 12:52, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 12:33:14PM +0200, Laurentiu Tudor wrote: On 04.03.2020 12:07, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 11:56:53AM +0200, Laurentiu Tudor wrote: From

RE: [PATCH] iommu: silence iommu group prints

Hi Robin, > -Original Message- > From: Robin Murphy > Sent: Friday, February 28, 2020 8:32 PM > > [ +Laurentiu ] > > Hi Russell, > > Thanks for sharing a log, now I properly understand what's up... further > comments at the end (for context). > > On 28/02/2020 10:06 am, Russell King

Re: [PATCH] iommu: silence iommu group prints

Hi Russell, On 03.03.2020 17:49, Russell King - ARM Linux admin wrote: On Tue, Mar 03, 2020 at 04:18:57PM +0200, Laurentiu Tudor wrote: On 28.02.2020 20:32, Robin Murphy wrote: [ +Laurentiu ] Hi Russell, Thanks for sharing a log, now I properly understand what's up... further comments

Re: [PATCH] iommu: silence iommu group prints

On 28.02.2020 20:32, Robin Murphy wrote: [ +Laurentiu ] Hi Russell, Thanks for sharing a log, now I properly understand what's up... further comments at the end (for context). On 28/02/2020 10:06 am, Russell King - ARM Linux admin wrote: On Fri, Feb 28, 2020 at 09:33:40AM +, John

Re: [PATCH] iommu: silence iommu group prints

On 04.03.2020 00:17, Russell King - ARM Linux admin wrote: On Tue, Mar 03, 2020 at 05:55:05PM +0200, Laurentiu Tudor wrote: From c98dc05cdd45ae923654f2427985bd28bcde4bb2 Mon Sep 17 00:00:00 2001 From: Laurentiu Tudor Date: Thu, 13 Feb 2020 11:59:12 +0200 Subject: [PATCH 1/4] bus: fsl-mc: add

Re: [PATCH] iommu: silence iommu group prints

On 04.03.2020 11:51, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 11:42:16AM +0200, Laurentiu Tudor wrote: On 04.03.2020 11:33, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 10:56:06AM +0200, Laurentiu Tudor wrote: On 04.03.2020 00:17, Russell King - ARM

Re: [PATCH] iommu: silence iommu group prints

On 04.03.2020 11:33, Russell King - ARM Linux admin wrote: On Wed, Mar 04, 2020 at 10:56:06AM +0200, Laurentiu Tudor wrote: On 04.03.2020 00:17, Russell King - ARM Linux admin wrote: On Tue, Mar 03, 2020 at 05:55:05PM +0200, Laurentiu Tudor wrote: From

[RFC PATCH 2/4] irqchip/fsl-mc: Change the way the IRQ domain is set for MC devices

From: Diana Craciun In ACPI the MC bus is represented as a platform device and a named component in the IORT table. The mc-bus devices are discovered dynamically at runtime but they share the same fwnode with the parent platfom device. This patch changes the way the IRQ domain is searched for

[RFC PATCH 3/4] bus: fsl-mc: Add ACPI support for fsl-mc

From: Makarand Pawagi ACPI support is added in the fsl-mc driver. Driver will parse MC DSDT table to extract memory and other resorces. Interrupt (GIC ITS) information will be extracted from MADT table by drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c. IORT table will be parsed to configure DMA.

[RFC PATCH 4/4] iommu/of: get rid of fsl-mc specific code

From: Laurentiu Tudor Changing the way we configure dma for fsl-mc devices allows us to get rid of our fsl-mc specific code in the generic of iommu code. Signed-off-by: Laurentiu Tudor --- drivers/iommu/of_iommu.c | 20 1 file changed, 20 deletions(-) diff --git

[RFC PATCH 1/4] bus: fsl-mc: add custom .dma_configure implementation

From: Laurentiu Tudor The devices on this bus are not discovered by way of device tree but by queries to the firmware. It makes little sense to trick the generic of layer into thinking that these devices are of related so that we can get our dma configuration. Instead of doing that, add our

  1   2   >