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
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
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
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
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
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-
>>>>
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;
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.
>
>
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
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
+---
> 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
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
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,
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
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
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
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
>
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
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
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
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
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
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
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
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.
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
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
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
[ +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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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.
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
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
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
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
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
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
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
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
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
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
>>
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
> -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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
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
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
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
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
> -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
> -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
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_
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.
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
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
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
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
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
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
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
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(
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
> -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
> -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
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
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
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
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
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
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
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
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
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
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
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
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
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 - 100 of 132 matches
Mail list logo
