[PATCH v3] iommu/dma: Fix IOVA reserve dma ranges

Fix IOVA reserve failure in the case when address of first memory region listed in dma-ranges is equal to 0x0. Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address") Signed-off-by: Srinath Mannam --- Changes from v2: Modify error message with useful information bas

Re: [PATCH v2] iommu/dma: Fix IOVA reserve dma ranges

On Fri, Sep 11, 2020 at 8:47 PM Bjorn Helgaas wrote: > Hi Bjorn, Thanks for review. > On Fri, Sep 11, 2020 at 03:55:34PM +0530, Srinath Mannam wrote: > > Fix IOVA reserve failure in the case when address of first memory region > > listed in dma-ranges is equal to 0x0. > > > > Fixes: aadad097cd46f

[PATCH v2] iommu/dma: Fix IOVA reserve dma ranges

Fix IOVA reserve failure in the case when address of first memory region listed in dma-ranges is equal to 0x0. Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address") Signed-off-by: Srinath Mannam --- Changes from v1: Removed unnecessary changes based on Robin's rev

Re: [PATCH] iommu/dma: Fix IOVA reserve dma ranges

On Wed, Sep 9, 2020 at 5:35 PM Robin Murphy wrote: > Hi Robin, Thanks for review > On 2020-09-09 06:32, Srinath Mannam wrote: > > Fix IOVA reserve failure for memory regions listed in dma-ranges in the > > following cases. > > > > - start address of memory region is 0x0. > > That's fair enough, an

[PATCH] iommu/dma: Fix IOVA reserve dma ranges

Fix IOVA reserve failure for memory regions listed in dma-ranges in the following cases. - start address of memory region is 0x0. - end address of a memory region is equal to start address of next memory region. Fixes: aadad097cd46f ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address")

Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address

On Wed, May 27, 2020 at 11:00 PM Robin Murphy wrote: > Thanks Robin for your quick response. > On 2020-05-27 17:03, Srinath Mannam wrote: > > This patch gives the provision to change default value of MSI IOVA base > > to platform's suitable IOVA using module parameter. The present > > hardcoded MS

[RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address

This patch gives the provision to change default value of MSI IOVA base to platform's suitable IOVA using module parameter. The present hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform. Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible DMA address")

Re: [PATCH v6 3/3] PCI: iproc: Add sorted dma ranges resource entries to host bridge

Hi Bjorn, Thank you. Regards, Srinath. On Tue, May 7, 2019 at 3:11 PM Lorenzo Pieralisi wrote: > > On Mon, May 06, 2019 at 04:12:08PM -0500, Bjorn Helgaas wrote: > > On Fri, May 03, 2019 at 07:35:34PM +0530, Srinath Mannam wrote: > > > The IPROC host controller allows only a subset of physical

Re: [PATCH v6 0/3] PCIe Host request to reserve IOVA

Hi Lorenzo, Thanks a lot. Regards, Srinath. On Fri, May 3, 2019 at 9:23 PM Lorenzo Pieralisi wrote: > > On Fri, May 03, 2019 at 07:35:31PM +0530, Srinath Mannam wrote: > > This patch set will reserve IOVA addresses for DMA memory holes. > > > > The IPROC host controller allows only a few ranges

[PATCH v6 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

The dma_ranges list field of PCI host bridge structure has resource entries in sorted order representing address ranges allowed for DMA transfers. Process the list and reserve IOVA addresses that are not present in its resource entries (ie DMA memory holes) to prevent allocating IOVA addresses tha

[PATCH v6 3/3] PCI: iproc: Add sorted dma ranges resource entries to host bridge

The IPROC host controller allows only a subset of physical address space as target of inbound PCI memory transactions addresses. PCIe devices memory transactions targeting memory regions that are not allowed for inbound transactions in the host controller are rejected by the host controller and ca

[PATCH v6 0/3] PCIe Host request to reserve IOVA

This patch set will reserve IOVA addresses for DMA memory holes. The IPROC host controller allows only a few ranges of physical address as inbound PCI addresses which are listed through dma-ranges DT property. Added dma_ranges list field of PCI host bridge structure to hold these allowed inbound a

[PATCH v6 1/3] PCI: Add dma_ranges window list

Add a dma_ranges field in PCI host bridge structure to hold resource entries list of memory regions in sorted order representing memory ranges that can be accessed through DMA transactions. Based-on-patch-by: Oza Pawandeep Signed-off-by: Srinath Mannam [lorenzo.pieral...@arm.com: updated commit

Re: [PATCH v5 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

Hi Robin, On Fri, May 3, 2019 at 3:58 PM Robin Murphy wrote: > > On 03/05/2019 06:23, Srinath Mannam wrote: > > Hi Robin, Lorenzo, > > > > Thanks for review and guidance. > > AFAIU, conclusion of discussion is, to return error if dma-ranges list > > is not sorted. > > > > So that, Can I send a n

Re: [PATCH v5 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

Hi Lorenzo, Thank you so much, Please see my reply below. On Fri, May 3, 2019 at 3:23 PM Lorenzo Pieralisi wrote: > > On Fri, May 03, 2019 at 10:53:23AM +0530, Srinath Mannam wrote: > > Hi Robin, Lorenzo, > > > > Thanks for review and guidance. > > AFAIU, conclusion of discussion is, to return e

Re: [PATCH v5 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

Hi Robin, Lorenzo, Thanks for review and guidance. AFAIU, conclusion of discussion is, to return error if dma-ranges list is not sorted. So that, Can I send a new patch with below change to return error if dma-ranges list is not sorted? -static void iova_reserve_pci_windows(struct pci_dev *dev,

Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA

Hi David, Thanks for review, I will fix in next version of this patch set. Regards, Srinath. On Thu, May 2, 2019 at 3:24 PM David Laight wrote: > > From: Srinath Mannam > > Sent: 01 May 2019 16:23 > ... > > > > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote: > > > > > Few SOCs h

[PATCH v5 1/3] PCI: Add dma_ranges window list

Add a dma_ranges field in PCI host bridge structure to hold resource entries list of memory regions in sorted order given through dma-ranges DT property. While initializing IOMMU domain of PCI EPs connected to that host bridge, this list of resources will be processed and IOVAs for the address hol

[PATCH v5 3/3] PCI: iproc: Add sorted dma ranges resource entries to host bridge

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. Inbound address of host accessed by PCIe devices will not be translated before it c

[PATCH v5 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

dma_ranges field of PCI host bridge structure has resource entries in sorted order of address range given through dma-ranges DT property. This list is the accessible DMA address range. So that this resource list will be processed and reserve IOVA address to the inaccessible address holes in the lis

[PATCH v5 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

Re: [PATCH v4 3/3] PCI: iproc: Add sorted dma ranges resource entries to host bridge

Hi Lorenzo, Please see my reply below. On Wed, May 1, 2019 at 8:07 PM Lorenzo Pieralisi wrote: > > On Fri, Apr 12, 2019 at 08:43:35AM +0530, Srinath Mannam wrote: > > IPROC host has the limitation that it can use only those address ranges > > given by dma-ranges property as inbound address. So t

Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA

Hi Lorenzo, Thanks a lot. Please see my reply below. On Wed, May 1, 2019 at 7:24 PM Lorenzo Pieralisi wrote: > > On Wed, May 01, 2019 at 02:20:56PM +0100, Robin Murphy wrote: > > On 2019-05-01 1:55 pm, Bjorn Helgaas wrote: > > > On Wed, May 01, 2019 at 12:30:38PM +0100, Lorenzo Pieralisi wrote:

Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA

Hi Robin, Thank you so much for all the information. Regards, Srinath. On Wed, May 1, 2019 at 6:51 PM Robin Murphy wrote: > > On 2019-05-01 1:55 pm, Bjorn Helgaas wrote: > > On Wed, May 01, 2019 at 12:30:38PM +0100, Lorenzo Pieralisi wrote: > >> On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath

Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA

Hi Bjorn, Thank you. Please find my reply below. On Wed, May 1, 2019 at 6:25 PM Bjorn Helgaas wrote: > > On Wed, May 01, 2019 at 12:30:38PM +0100, Lorenzo Pieralisi wrote: > > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote: > > > Few SOCs have limitation that their PCIe host can'

Re: [PATCH v4 0/3] PCIe Host request to reserve IOVA

Hi Bjorn, Thanks for review. Please find my reply below. On Sat, Apr 13, 2019 at 4:04 AM Bjorn Helgaas wrote: > > On Fri, Apr 12, 2019 at 08:43:32AM +0530, Srinath Mannam wrote: > > Few SOCs have limitation that their PCIe host can't allow few inbound > > address ranges. Allowed inbound address

[PATCH v4 3/3] PCI: iproc: Add sorted dma ranges resource entries to host bridge

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. Inbound address of host accessed by PCIe devices will not be translated before it c

[PATCH v4 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

[PATCH v4 1/3] PCI: Add dma_ranges window list

Add a dma_ranges field in PCI host bridge structure to hold resource entries list of memory regions in sorted order given through dma-ranges DT property. While initializing IOMMU domain of PCI EPs connected to that host bridge This list of resources will be processed and IOVAs for the address hole

[PATCH v4 2/3] iommu/dma: Reserve IOVA for PCIe inaccessible DMA address

dma_ranges field of PCI host bridge structure has resource entries in sorted order of address range given through dma-ranges DT property. This list is the accessible DMA address range. So that this resource list will be processed and reserve IOVA address to the inaccessible address holes in the lis

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

Hi Robin, Thanks a lot for detailed clarification. I will send next patch set with the changes you suggested. Regards, Srinath. On Thu, Mar 28, 2019 at 9:17 PM Robin Murphy wrote: > > On 28/03/2019 10:34, Srinath Mannam wrote: > > Hi Robin, > > > > Thanks for your feedback. Please see my reply

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

Hi Robin, Thanks for your feedback. Please see my reply in line. On Wed, Mar 27, 2019 at 8:32 PM Robin Murphy wrote: > > On 25/01/2019 10:13, Srinath Mannam wrote: > > Few SOCs have limitation that their PCIe host can't allow few inbound > > address ranges. Allowed inbound address ranges are lis

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

Hi Bjorn, Could you please help to review the patch series below? Thanks, Srinath. On Thu, Feb 21, 2019 at 2:29 PM Srinath Mannam wrote: > > Hi Bjorn, > > Please help to review this patch series. > Thank you. > > Regards, > Srinath. > On Fri, Jan 25, 2019 at 3:44 PM Srinath Mannam > wrote: > >

Re: [PATCH v3 0/3] PCIe Host request to reserve IOVA

Hi Bjorn, Please help to review this patch series. Thank you. Regards, Srinath. On Fri, Jan 25, 2019 at 3:44 PM Srinath Mannam wrote: > > Few SOCs have limitation that their PCIe host can't allow few inbound > address ranges. Allowed inbound address ranges are listed in dma-ranges > DT property

Re: [PATCH v2 2/2] PCI: iproc: Add PCIe 32bit outbound memory configuration

Hi Lorenzo, Thanks for review, please see my comments below inline. On Wed, Feb 13, 2019 at 12:07 AM Lorenzo Pieralisi wrote: > > On Tue, Feb 05, 2019 at 10:27:01AM +0530, Srinath Mannam wrote: > > Add configuration to support IPROC PCIe host controller outbound memory > > window mapping with SO

Re: [PATCH v2 1/2] PCI: iproc: Add CRS check in config read

Hi Lorenzo, Thanks for review, please see my comments below inline. On Tue, Feb 12, 2019 at 11:42 PM Lorenzo Pieralisi wrote: > > On Tue, Feb 05, 2019 at 10:27:00AM +0530, Srinath Mannam wrote: > > In the current implementation, config read output data 0x0001 is > > assumed as CRS completion

[PATCH v2 0/2] Add IPROC PCIe new features

This patch set extends support of new IPROC PCIe host controller features - Add CRS state check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed s

[PATCH v2 2/2] PCI: iproc: Add PCIe 32bit outbound memory configuration

Add configuration to support IPROC PCIe host controller outbound memory window mapping with SOC address range inside 4GB boundary, which is 32 bit AXI address. Signed-off-by: Srinath Mannam Signed-off-by: Abhishek Shah Signed-off-by: Ray Jui Reviewed-by: Scott Branden Reviewed-by: Vikram Praka

[PATCH v2 1/2] PCI: iproc: Add CRS check in config read

In the current implementation, config read output data 0x0001 is assumed as CRS completion. But sometimes 0x0001 can be a valid data. IPROC PCIe host controller has a register to show config read request status flags like SC, UR, CRS and CA. So that extra check is added to confirm the CRS

[PATCH v2 0/2] Add IPROC PCIe new features

This patch set extends support of new IPROC PCIe host controller features - Add CRS check using controller register status flags - Add 32bit outbound window mapping configuration This patch set is based on Linux-5.0-rc2. Changes from v1: - Addressed Bjorn Helgaas comments. - Removed set ord

[PATCH v3 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

[PATCH v3 3/3] PCI: iproc: Add dma reserve resources to host

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. Inbound address of host accessed by PCIe devices will not be translated before it c

[PATCH v3 1/3] PCI: Add dma-resv window list

Add a dma_resv parameter in PCI host bridge structure to hold resource entries list of memory regions for which IOVAs have to reserve. PCIe host driver will add resource entries to this list based on its requirements. Few inbound address ranges can't be allowed by few PCIe host, so those address r

[PATCH v3 2/3] iommu/dma: Reserve IOVA for PCI host reserve address list

PCI host bridge has list of resource entries contain address ranges for which IOVA address mapping has to be reserve. These address ranges are the address holes in dma-ranges DT property. It is similar to PCI IO resources address ranges reserving in IOMMU for each EP connected to host bridge. Sig

Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode

Hi Bjorn, Thank you, Please see my comments below inline. On Fri, Jan 25, 2019 at 1:01 AM Bjorn Helgaas wrote: > > On Thu, Jan 24, 2019 at 02:10:18PM +0530, Srinath Mannam wrote: > > On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote: > > > On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Man

Re: [PATCH 2/3] PCI: iproc: CRS state check in config request

Hi Bjorn, Thanks for review, please see my comments below inline. On Fri, Jan 18, 2019 at 8:38 PM Bjorn Helgaas wrote: > > On Fri, Jan 18, 2019 at 09:53:22AM +0530, Srinath Mannam wrote: > > In the current implementation, config read of 0x0001 data > > is assumed as CRS completion. but somet

Re: [PATCH 1/3] PCI: iproc: Add feature to set order mode

Hi Bjorn, Thanks for review, please see my comments below inline. On Fri, Jan 18, 2019 at 8:37 PM Bjorn Helgaas wrote: > > On Fri, Jan 18, 2019 at 09:53:21AM +0530, Srinath Mannam wrote: > > Order mode in RX header of incoming pcie packets can be override to > > strict or loose order based on re

Re: [PATCH 0/3] Add IPROC PCIe new features

Hi Bjorn, Thank you for the review. I will address your comments in the next patchset. Regards, Srinath. On Fri, Jan 18, 2019 at 8:11 PM Bjorn Helgaas wrote: > > On Fri, Jan 18, 2019 at 09:53:20AM +0530, Srinath Mannam wrote: > > Add changes related to IPROC PCIe RC IP new features. > > > > Thi

[PATCH 1/3] PCI: iproc: Add feature to set order mode

Order mode in RX header of incoming pcie packets can be override to strict or loose order based on requirement. Sysfs entry is provided to set dynamic and default order modes of upstream traffic. To improve performance in few endpoints we required to modify the ordering attributes. Using this feat

[PATCH 2/3] PCI: iproc: CRS state check in config request

In the current implementation, config read of 0x0001 data is assumed as CRS completion. but sometimes 0x0001 can be a valid data. IPROC PCIe RC has a register to show config request status flags like SC, UR, CRS and CA. So that extra check is added in the code to confirm the CRS state using

[PATCH 0/3] Add IPROC PCIe new features

Add changes related to IPROC PCIe RC IP new features. This patch set is based on Linux-5.0-rc2. Srinath Mannam (3): PCI: iproc: Add feature to set order mode PCI: iproc: CRS state check in config request PCI: iproc: Add PCIe 32bit outbound memory configuration drivers/pci/controller/pcie-

[PATCH 3/3] PCI: iproc: Add PCIe 32bit outbound memory configuration

IPROC PCIe RC supports outbound memory mapping with SOC address inside 4GB address boundary, which is 32 bit AXI address. This patch add the support. Signed-off-by: Srinath Mannam Signed-off-by: Abhishek Shah Signed-off-by: Ray Jui Reviewed-by: Scott Branden Reviewed-by: Vikram Prakash --- d

[PATCH v2 3/3] PCI: iproc: Add dma reserve resources to host

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. Inbound address of host accessed by pcie devices will not be translated before it c

[PATCH v2 1/3] PCI: Add dma-resv window list

Add a dma_resv parameter in pci host bridge structure to hold resource entries list of memory regions for which IOVAs have to reserve. PCIe host driver will add resource entries to this list based on its requirements. Few inbound address ranges can't be allowed by few PCIe host, so those address r

[PATCH v2 2/3] iommu/dma: IOVA reserve for PCI host reserve address list

PCI host bridge has list of resource entries contain address ranges for which IOVA address mapping has to be reserve. These address ranges are the address holes in dma-ranges DT property. It is similar to PCI IO resources address ranges reserving in IOMMU for each EP connected to host bridge. Sig

[PATCH v2 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

Re: [RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host

Hi Oza, Thank you for the review. Please find my comments in lined. On Thu, Dec 13, 2018 at 11:33 AM wrote: > > On 2018-12-12 11:16, Srinath Mannam wrote: > > IPROC host has the limitation that it can use > > only those address ranges given by dma-ranges > > property as inbound address. > > So t

[RFC PATCH 3/3] PCI: iproc: Add dma reserve resources to host

IPROC host has the limitation that it can use only those address ranges given by dma-ranges property as inbound address. So that the memory address holes in dma-ranges should be reserved to allocate as DMA address. All such reserved addresses are created as resource entries and add to dma_resv lis

[RFC PATCH 1/3] PCI: Add dma-resv window list

Add a dma_resv parameter in pci host bridge structure to hold resource entries list of memory regions for which IOVAs has to reserve. IOMMU framework reserve IOVA for this list of address range while initializing IOMMU domain of corresponding PCI EP connected to the HOST. PCIe host driver will ad

[RFC PATCH 2/3] iommu/dma: IOVA reserve for PCI host reserve address list

PCI host has list of resource entries contain memory address range for which IOVA address mapping has to be reserve. These address ranges are the address holes in dma-ranges property. It is similar to PCI IO resources address range reserving in IOMMU for each EP connected to corresponding host. S

[RFC PATCH 0/3] PCIe Host request to reserve IOVA

Few SOCs have limitation that their PCIe host can't allow few inbound address ranges. Allowed inbound address ranges are listed in dma-ranges DT property and this address ranges are required to do IOVA mapping. Remaining address ranges have to be reserved in IOVA mapping. PCIe Host driver of those

[RFC PATCH 1/2] dt-bindings: pci: Add drop mask property for MSI and IOMMU

This patch adds info about optional DT properties iommu-map-drop-mask and msi-map-drop-mask. A drop mask represents the bits which will be removed/dropped by system from Requester ID before mapping it to msi ID or stream ID. Signed-off-by: Anup Patel Signed-off-by: Oza Pawandeep Signed-off-by:

[RFC PATCH 0/2] Add sideband data extraction

These patches implements optional DT properties to generate smaller sideband data from RID which can be further mapped to MSI Device ID or Stream ID On some of the systems, sideband data is smaller than RID (16bits). For such system, sideband data has to be generated by dropping some of the RID bi

[RFC PATCH 2/2] pcie: sideband data by dropping RID bits

The MSI Device ID or Stream ID are passed as sideband data on the SOC bus to which PCI RC is connected. If sideband data on SOC bus is less than 16bits then PCI RC will have to derive sideband data from RID by dropping selected bits. This patch implements optional DT properties to generate smalle