Re: [PATCH v12 0/9] ACPI/IORT: Support for IORT RMR node

2022-05-04 Thread Laurentiu Tudor
NXP LX2160A with SMMUv2, so: Tested-by: Laurentiu Tudor --- Thanks & Best Regards, Laurentiu Please note, this series has a dependency on the ACPICA header patch here[1]. Please take a look and let me know. Thanks, Shameer [1] https://eur01.safelinks.protection.outlook.com/?url=http

Re: [PATCH v9 00/11] ACPI/IORT: Support for IORT RMR node

2022-04-19 Thread Laurentiu Tudor
a-iommu.h | 5 + include/linux/iommu.h | 9 + 9 files changed, 505 insertions(+), 45 deletions(-) I've tested the patches on a NXP LX2160A with SMMUv2 and things look fine. Thanks! Tested-by: Laurentiu Tudor --- Best Regards, Laurentiu

Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing

2021-10-05 Thread Laurentiu Tudor
On 9/17/2021 2:26 PM, Shameerali Kolothum Thodi wrote: > > >> -Original Message- >> From: Jon Nettleton [mailto:j...@solid-run.com] >> Sent: 16 September 2021 12:17 >> To: Shameerali Kolothum Thodi >> Cc: Robin Murphy ; Lorenzo Pieralisi >&g

Re: [PATCH v7 2/9] ACPI/IORT: Add support for RMR node parsing

2021-08-05 Thread Laurentiu Tudor
On 8/5/2021 7:03 PM, Lorenzo Pieralisi wrote: > On Thu, Aug 05, 2021 at 09:07:17AM +0100, Shameer Kolothum wrote: > > [...] > >> +static void __init iort_node_get_rmr_info(struct acpi_iort_node *iort_node) >> +{ >> +struct acpi_iort_node *smmu; >> +struct acpi_iort_rmr *rmr; >> +st

Re: [PATCH v6 0/9] ACPI/IORT: Support for IORT RMR node

2021-07-19 Thread Laurentiu Tudor
drivers/iommu/arm/arm-smmu/arm-smmu.c | 48 ++ > drivers/iommu/dma-iommu.c | 89 +- > include/linux/acpi_iort.h | 7 + > include/linux/dma-iommu.h | 13 ++ > include/linux/iommu.h | 11 ++ > 7 files chan

Re: [PATCH v5 3/8] ACPI/IORT: Add a helper to retrieve RMR memory regions

2021-06-03 Thread Laurentiu Tudor
Hi Jon, On 6/3/2021 3:27 PM, Jon Nettleton wrote: > On Wed, May 26, 2021 at 7:11 PM Laurentiu Tudor > wrote: >> >> >> >> On 5/26/2021 7:36 PM, Shameerali Kolothum Thodi wrote: >>> >>> >>>> -Original Message- >>>>

Re: [PATCH v5 3/8] ACPI/IORT: Add a helper to retrieve RMR memory regions

2021-05-26 Thread Laurentiu Tudor
On 5/26/2021 7:36 PM, Shameerali Kolothum Thodi wrote: > > >> -Original Message----- >> From: Laurentiu Tudor [mailto:laurentiu.tu...@nxp.com] >> Sent: 26 May 2021 08:53 >> To: Shameerali Kolothum Thodi ; >> linux-arm-ker...@lists.infradead.org;

Re: [PATCH v5 3/8] ACPI/IORT: Add a helper to retrieve RMR memory regions

2021-05-26 Thread Laurentiu Tudor
Hi Shameer, On 5/24/2021 2:02 PM, Shameer Kolothum wrote: > Add a helper function that retrieves RMR memory descriptors > associated with a given IOMMU. This will be used by IOMMU > drivers to setup necessary mappings. > > Now that we have this, invoke it from the generic helper > interface. > >

Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings

2020-12-02 Thread Laurentiu Tudor
Hi Robin, Sorry for the late reply, we had a few days of over here. Comments inline. On 11/25/2020 8:10 PM, Robin Murphy wrote: > On 2020-11-25 15:50, laurentiu.tu...@nxp.com wrote: >> From: Laurentiu Tudor >> >> Add a NXP specific hook to preserve SMMU mappings present at

[PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings

2020-11-25 Thread laurentiu . tudor
From: Laurentiu Tudor Add a NXP specific hook to preserve SMMU mappings present at boot time (created by the boot loader). These are needed for MC firmware present on some NXP chips to continue working across kernel boot and SMMU initialization. Signed-off-by: Laurentiu Tudor --- drivers

Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings

2020-09-16 Thread Laurentiu Tudor
+--- > drivers/iommu/arm/arm-smmu/arm-smmu.h | 14 ++- > 3 files changed, 205 insertions(+), 42 deletions(-) > Tested on a NXP LX2160A with John's tree [1] and below diff [2], so for the whole series: Tested-by: Laurentiu Tudor [1] https://git.linaro.org/people/john.stu

Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader mappings

2020-09-09 Thread Laurentiu Tudor
Hi Bjorn, On 9/4/2020 6:55 PM, Bjorn Andersson wrote: > Based on previous attempts and discussions this is the latest attempt at > inheriting stream mappings set up by the bootloader, for e.g. boot splash or > efifb. > > Per Will's request this builds on the work by Jordan and Rob for the Adreno

Re: [PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings

2020-07-28 Thread Laurentiu Tudor
On 7/9/2020 10:57 PM, Bjorn Andersson wrote: > On Thu 09 Jul 08:50 PDT 2020, Laurentiu Tudor wrote: > >> >> >> On 7/9/2020 8:01 AM, Bjorn Andersson wrote: >>> With many Qualcomm platforms not having functional S2CR BYPASS a >>> temporary IOMMU domain,

Re: [PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings

2020-07-09 Thread Laurentiu Tudor
on prior work by Thierry Reding and Laurentiu Tudor. > > Signed-off-by: Bjorn Andersson > --- > drivers/iommu/arm-smmu-qcom.c | 11 + > drivers/iommu/arm-smmu.c | 80 +-- > drivers/iommu/arm-smmu.h | 3 ++ > 3 files changed, 90 insertio

Re: [EXT] Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-07-09 Thread Laurentiu Tudor
On 7/9/2020 12:26 PM, Makarand Pawagi wrote: > > >> -Original Message- >> From: Lorenzo Pieralisi >> Sent: Thursday, July 9, 2020 2:50 PM >> To: Laurentiu Tudor >> Cc: linux-arm-ker...@lists.infradead.org; Makarand Pawagi >> ; Diana Mad

Re: [EXT] Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-07-09 Thread Laurentiu Tudor
On 7/9/2020 1:37 PM, Makarand Pawagi wrote: > > >> -Original Message----- >> From: Laurentiu Tudor >> Sent: Thursday, July 9, 2020 3:45 PM >> To: Makarand Pawagi ; Lorenzo Pieralisi >> >> Cc: linux-arm-ker...@lists.infradead.org; Diana Mad

Re: [PATCH v2 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-07-01 Thread Laurentiu Tudor
ip/irq-gic-v3-its-fsl-mc-msi.c. > > IORT table is parsed to configure DMA. > > Signed-off-by: Makarand Pawagi > Signed-off-by: Diana Craciun > Signed-off-by: Laurentiu Tudor > --- > drivers/bus/fsl-mc/fsl-mc-bus.c | 73 >

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

2020-05-27 Thread Laurentiu Tudor
On 5/26/2020 11:34 PM, John Stultz wrote: > On Thu, May 14, 2020 at 12:34 PM wrote: >> >> On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote: >> >> Rob, Will, we're reaching the point where upstream has enough >> functionality that this is becoming a critical issue for us. >> >> E.g. Lenovo Yog

Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus

2020-05-22 Thread Laurentiu Tudor
On 5/22/2020 5:02 PM, Rob Herring wrote: > On Fri, May 22, 2020 at 3:42 AM Robin Murphy wrote: >> >> On 2020-05-22 00:10, Rob Herring wrote: >>> On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi >>> wrote: >>>> >>>> From: Laurentiu Tudor

Re: [PATCH 12/12] bus: fsl-mc: Add ACPI support for fsl-mc

2020-05-21 Thread Laurentiu Tudor
rs/irqchip/irq-gic-v3-its-fsl-mc-msi.c. > > IORT table is parsed to configure DMA. > > Signed-off-by: Makarand Pawagi > Signed-off-by: Diana Craciun > Signed-off-by: Laurentiu Tudor > --- The author of this patch should be Makarand. I think I accidentaly broke it when we

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

2020-04-16 Thread Laurentiu Tudor
On 4/15/2020 7:04 PM, Lorenzo Pieralisi wrote: > On Wed, Apr 15, 2020 at 06:44:37PM +0300, Laurentiu Tudor wrote: >> >> >> On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote: >>> On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote: >>>> Hi Lorenz

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

2020-04-15 Thread Laurentiu Tudor
On 4/14/2020 5:32 PM, Lorenzo Pieralisi wrote: > On Wed, Mar 25, 2020 at 06:48:55PM +0200, Laurentiu Tudor wrote: >> Hi Lorenzo, >> >> On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote: >>> On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wro

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

2020-03-25 Thread Laurentiu Tudor
Hi Lorenzo, On 3/25/2020 2:51 PM, Lorenzo Pieralisi wrote: > On Thu, Feb 27, 2020 at 12:05:39PM +0200, laurentiu.tu...@nxp.com wrote: >> From: Laurentiu Tudor >> >> The devices on this bus are not discovered by way of device tree >> but by queries to the firmware. It

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

2020-03-24 Thread laurentiu . tudor
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 a

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

2020-03-24 Thread laurentiu . tudor
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 v2 0/4] bus: fsl-mc: Add ACPI support for fsl-mc

2020-03-24 Thread laurentiu . tudor
From: Laurentiu Tudor This patch adds ACPI support for the fsl-mc bus driver. First 2 patches are prerequsite that remove dependencies on device tree. Third patch adds the actual ACPI support and the final one drops some fsl-mc specific code in the generic device tree handling code. Changes in

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

2020-03-24 Thread laurentiu . tudor
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 the

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

2020-03-24 Thread laurentiu . tudor
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

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

2020-03-17 Thread Laurentiu Tudor
[ +Russell ] Forgot to Cc: you Russell, sorry about that. This patch series could be an important step towards fixing the MC firmware over smmu issue on nxp layerscape chips. --- Best Regards, Laurentiu On 3/17/2020 4:21 PM, laurentiu.tu...@nxp.com wrote: From: Thierry Reding On some pla

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

2020-03-17 Thread laurentiu . tudor
From: Thierry Reding On some platforms, the firmware will setup hardware to read from a given region of memory. One such example is a display controller that is scanning out a splash screen from physical memory. During Linux' boot process, the ARM SMMU will configure all contexts to fault by def

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

2020-03-17 Thread laurentiu . tudor
1 all of the reserved regions associated with them. This happens before the SMMU is enabled, so that the mappings are already set up before translations begin. Signed-off-by: Thierry Reding Signed-off-by: Laurentiu Tudor --- drivers/iommu/arm-smmu.c

[RFC PATCH v2 1/2] iommu: arm-smmu: Extract arm_smmu_of_parse()

2020-03-17 Thread laurentiu . tudor
From: Thierry Reding This function will be subsequently used to extract stream ID information early, before a struct device is available. Signed-off-by: Thierry Reding --- drivers/iommu/arm-smmu.c | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/dri

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

2020-03-04 Thread Laurentiu Tudor
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

2020-03-04 Thread Laurentiu Tudor
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

2020-03-04 Thread Laurentiu Tudor
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

2020-03-04 Thread Laurentiu Tudor
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

2020-03-04 Thread Laurentiu Tudor
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

Re: [PATCH] iommu: silence iommu group prints

2020-03-04 Thread Laurentiu Tudor
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

2020-03-03 Thread Laurentiu Tudor
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 commen

Re: [PATCH] iommu: silence iommu group prints

2020-03-03 Thread Laurentiu Tudor
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 Garr

RE: [PATCH] iommu: silence iommu group prints

2020-03-02 Thread Laurentiu Tudor
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 -

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

2020-02-27 Thread laurentiu . tudor
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 the

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

2020-02-27 Thread laurentiu . tudor
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

2020-02-27 Thread laurentiu . tudor
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 a

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

2020-02-27 Thread laurentiu . tudor
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

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

2019-11-14 Thread Laurentiu Tudor
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 virtua

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

2019-11-13 Thread Laurentiu Tudor
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 1/4] dma-mapping: introduce new dma unmap and sync api variants

2019-11-13 Thread Laurentiu Tudor
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 to

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

2019-11-13 Thread Laurentiu Tudor
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-by

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

2019-11-13 Thread Laurentiu Tudor
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 0/4] dma-mapping: introduce new dma unmap and sync variants

2019-11-13 Thread Laurentiu Tudor
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 and

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

2019-11-07 Thread Laurentiu Tudor
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 to the

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

2019-11-06 Thread Laurentiu Tudor
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 >>

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

2019-11-06 Thread Laurentiu Tudor
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

2019-10-29 Thread Laurentiu Tudor
> -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: [PATCH v2 3/3] dpaa2_eth: use new unmap and sync dma api variants

2019-10-28 Thread Laurentiu Tudor
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 ri

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

2019-10-24 Thread Laurentiu Tudor
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

2019-10-24 Thread Laurentiu Tudor
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

2019-10-24 Thread Laurentiu Tudor
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 the

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

2019-10-24 Thread Laurentiu Tudor
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 and

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

2019-10-24 Thread Laurentiu Tudor
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

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

2019-10-24 Thread Laurentiu Tudor
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

2019-10-24 Thread Laurentiu Tudor
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

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

2019-10-24 Thread Laurentiu Tudor
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 0/3] dma-mapping: introduce new dma unmap and sync variants

2019-10-24 Thread Laurentiu Tudor
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 and

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

2019-10-24 Thread Laurentiu Tudor
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

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

2019-10-23 Thread Laurentiu Tudor
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: [RFC PATCH 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

2019-10-22 Thread Laurentiu Tudor
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 1/3] dma-mapping: introduce a new dma api dma_addr_to_phys_addr()

2019-10-22 Thread Laurentiu Tudor
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

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

2019-10-22 Thread Laurentiu Tudor
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 0/3] dma-mapping: introduce a new dma api

2019-10-22 Thread Laurentiu Tudor
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 3/3] dpaa2_eth: use dma_addr_to_phys_addr() new dma api

2019-10-22 Thread Laurentiu Tudor
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

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

2019-05-31 Thread Laurentiu Tudor
> -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 5/6] dpaa_eth: fix iova handling for contiguous frames

2019-05-31 Thread Laurentiu Tudor
> -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 fo

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

2019-05-31 Thread Laurentiu Tudor
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, > > +dma_

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

2019-05-31 Thread Laurentiu Tudor
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 0/6] Prerequisites for NXP LS104xA SMMU enablement

2019-05-31 Thread Laurentiu Tudor
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 > > I

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

2019-05-30 Thread laurentiu . tudor
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. Sig

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

2019-05-30 Thread laurentiu . tudor
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 o

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

2019-05-30 Thread laurentiu . tudor
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/f

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

2019-05-30 Thread laurentiu . tudor
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 5/6] dpaa_eth: fix iova handling for contiguous frames

2019-05-30 Thread laurentiu . tudor
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 iommu a

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

2019-05-30 Thread laurentiu . tudor
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 added

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

2019-05-30 Thread laurentiu . tudor
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(

RE: [ARM SMMU] Dynamic StreamID allocation

2019-05-13 Thread Laurentiu Tudor
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 alloc

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

2019-05-02 Thread Laurentiu Tudor
> -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 7/9] dpaa_eth: fix iova handling for contiguous frames

2019-05-02 Thread Laurentiu Tudor
> -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: [PATCH v2 9/9] dpaa_eth: fix SG frame cleanup

2019-05-02 Thread Laurentiu Tudor
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

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

2019-04-27 Thread laurentiu . tudor
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 added

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

2019-04-27 Thread laurentiu . tudor
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. Sig

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

2019-04-27 Thread laurentiu . tudor
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 b

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

2019-04-27 Thread laurentiu . tudor
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 5/9] dpaa_eth: defer probing after qbman

2019-04-27 Thread laurentiu . tudor
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

2019-04-27 Thread laurentiu . tudor
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 o

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

2019-04-27 Thread laurentiu . tudor
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 iommu a

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

2019-04-27 Thread laurentiu . tudor
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 correctl

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

2019-04-27 Thread laurentiu . tudor
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 4/9] fsl/fman: add API to get the device behind a fman port

2019-04-27 Thread laurentiu . tudor
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/f

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

2019-04-25 Thread Laurentiu Tudor
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 fir

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

2019-04-23 Thread Laurentiu Tudor
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

  1   2   >