Re: [PATCH V2 2/6] iommu: iova: properly handle 0 as a valid IOVA address

2022-05-30 Thread Ajay Kumar
Hi Robin On Mon, May 23, 2022 at 11:00 PM Robin Murphy wrote: > > On 2022-05-11 13:15, Ajay Kumar wrote: > > From: Marek Szyprowski > > > > Zero is a valid DMA and IOVA address on many architectures, so adjust the > > IOVA management code to properly handle

Re: [PATCH V2 0/6] IOMMU-DMA - support DMA_ATTR_LOW_ADDRESS attribute

2022-05-23 Thread Ajay Kumar
Ping! On Thu, May 12, 2022 at 9:09 AM Ajay Kumar wrote: > > This patchset is a rebase of original patches from Marek Szyprowski: > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2321261.html > > The patches have been rebased on Joro's IOMMU tree "n

[PATCH V2 6/6] media: platform: s5p-mfc: use DMA_ATTR_LOW_ADDRESS

2022-05-11 Thread Ajay Kumar
that will be used for ARM architecture soon, so limit the dma_mask to size of the DMA window the hardware can use and add the needed DMA attribute to force proper IOVA allocation of the firmware buffer. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar --- drivers/media/platform/samsung/s5p-mfc

[PATCH V2 5/6] iommu: dma-iommu: add support for DMA_ATTR_LOW_ADDRESS

2022-05-11 Thread Ajay Kumar
From: Marek Szyprowski Implement support for the DMA_ATTR_LOW_ADDRESS DMA attribute. If it has been set, call alloc_iova_first_fit() instead of the alloc_iova_fast() to allocate the new IOVA from the beginning of the address space. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar

[PATCH V2 4/6] iommu: dma-iommu: refactor iommu_dma_alloc_iova()

2022-05-11 Thread Ajay Kumar
. While touching the parameter list, move struct device to the second position to better match the convention of the DMA-mapping related functions. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar --- drivers/iommu/dma-iommu.c | 25 ++--- 1 file changed, 14 insertions

[PATCH V2 3/6] iommu: iova: add support for 'first-fit' algorithm

2022-05-11 Thread Ajay Kumar
From: Marek Szyprowski Add support for the 'first-fit' allocation algorithm. It will be used for the special case of implementing DMA_ATTR_LOW_ADDRESS, so this path doesn't use IOVA cache. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar --- drivers/iommu/iova.c | 78

[PATCH V2 2/6] iommu: iova: properly handle 0 as a valid IOVA address

2022-05-11 Thread Ajay Kumar
return value. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar --- drivers/iommu/dma-iommu.c | 16 +--- drivers/iommu/iova.c | 13 + include/linux/iova.h | 1 + 3 files changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/iommu/dma-iommu.c b

[PATCH V2 1/6] dma-mapping: add DMA_ATTR_LOW_ADDRESS attribute

2022-05-11 Thread Ajay Kumar
space, such requirement can be easily fulfilled, simply by enforcing the 'first-fit' IOVA allocation algorithm. This patch adds a DMA attribute for such case. Signed-off-by: Marek Szyprowski Signed-off-by: Ajay Kumar --- include/linux/dma-mapping.h | 6 ++ 1 file changed, 6 insertions

[PATCH V2 0/6] IOMMU-DMA - support DMA_ATTR_LOW_ADDRESS attribute

2022-05-11 Thread Ajay Kumar
This patchset is a rebase of original patches from Marek Szyprowski: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2321261.html The patches have been rebased on Joro's IOMMU tree "next" branch: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git This patchset is needed

Re: [PATCH] iommu/arm-smmu-v3: Handle duplicated Stream IDs from other masters

2021-01-12 Thread Ajay Kumar
On Tue, Jan 12, 2021 at 12:57 AM Robin Murphy wrote: > > On 2021-01-07 13:03, Will Deacon wrote: > > On Thu, Jan 07, 2021 at 03:03:40PM +0530, Ajay Kumar wrote: > >> When PCI function drivers(ex:pci-endpoint-test) are probed for already > >> initialized PCIe

[PATCH] iommu/arm-smmu-v3: Handle duplicated Stream IDs from other masters

2021-01-07 Thread Ajay Kumar
-id. Signed-off-by: Ajay Kumar --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c index e634bbe60573..a91c3c0e9ee8 100644

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-09-23 Thread Ajay kumar
Hello all, We pretty much tried to solve the same issue here with a new API in DMA-IOMMU: https://lore.kernel.org/linux-iommu/20200811054912.ga...@infradead.org/T/ Christopher- the user part would be MFC devices on exynos platforms Thanks, Ajay On 9/23/20, Christoph Hellwig wrote: > On Wed,

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-09-23 Thread Ajay Kumar
Hello all, We pretty much tried to solve the same issue here with a new API in DMA-IOMMU: https://lore.kernel.org/linux-iommu/20200811054912.ga...@infradead.org/T/ Christoph - the user part would be MFC devices on exynos platforms Thanks, Ajay On Wed, Sep 23, 2020 at 12:28 PM Christoph

[RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically

2020-08-10 Thread Ajay Kumar
); When they want to limit IOVA for allocated buffers in range 0x100 to 0xC000: iommu_set_iova_range(dev, 0x100, 0xC000 - 0x100); = Signed-off-by: Ajay Kumar --- drivers/iommu/dma-iommu.c | 73

[RFC PATCH] dma-iommu: allow devices to set IOVA range dynamically

2020-08-03 Thread Ajay Kumar
current cached node, we do a reset of current cached nodes as well. Signed-off-by: Ajay Kumar --- drivers/iommu/dma-iommu.c | 73 +++ drivers/iommu/iommu.c | 16 + include/linux/iommu.h | 6 include/linux/iova.h | 6 4 files changed

Re: [PATCH] iommu/iova: Retry from last rb tree node if iova search fails

2020-05-07 Thread Ajay kumar
On 5/7/20, Robin Murphy wrote: > On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote: >> From: Vijayanand Jitta >> >> When ever a new iova alloc request comes iova is always searched >> from the cached node and the nodes which are previous to cached >> node. So, even if there is free iova space

Re: [RFC PATCH] drivers: iommu: reset cached node if dma_mask is changed

2020-05-07 Thread Ajay kumar
Hi Robin, On 5/7/20, Robin Murphy wrote: > On 2020-05-04 7:37 pm, Ajay Kumar wrote: >> The current IOVA allocation code stores a cached copy of the >> first allocated IOVA address node, and all the subsequent allocations >> have no way to get past(higher than) the first

[RFC PATCH] drivers: iommu: reset cached node if dma_mask is changed

2020-05-04 Thread Ajay Kumar
: This patch is needed to address the issue discussed in below thread: https://www.spinics.net/lists/iommu/msg43586.html Signed-off-by: Ajay Kumar Signed-off-by: Sathyam Panda --- drivers/iommu/iova.c | 17 - include/linux/iova.h | 1 + 2 files changed, 17 insertions(+), 1

Re: IOVA allocation dependency between firmware buffer and remaining buffers

2020-04-24 Thread Ajay kumar
Can someone check this? On Mon, Apr 20, 2020 at 9:24 PM Ajay kumar wrote: > > Hi All, > > I have an IOMMU master which has limitations as mentioned below: > 1) The IOMMU master internally executes a firmware, and the firmware memory > is allocated by the same master driver. >

IOVA allocation dependency between firmware buffer and remaining buffers

2020-04-20 Thread Ajay kumar
using DMA API limit_iova_alloc_range(dev, 0x1000_, 0xC000_); /* via helpers */ alloc( ) other buffers using DMA API Thanks, Ajay Kumar ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu