RE: RFC: extend iommu-map binding to support #iommu-cells > 1

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Friday, December 16, 2016 10:50 AM > To: Stuart Yoder <stuart.yo...@nxp.com>; Mark Rutland <mark.rutl...@arm.com> > Cc: will.dea...@arm.com; robh...@kernel.org; Bharat Bhushan

RE: RFC: extend iommu-map binding to support #iommu-cells > 1

> >>> The existing iommu-map binding did not account for the situation where > >>> #iommu-cells == 2, as permitted in the ARM SMMU binding. The 2nd cell > >>> of the IOMMU specifier being the SMR mask. The existing binding defines > >>> the mapping as: > >>>Any RID r in the interval

RE: RFC: extend iommu-map binding to support #iommu-cells > 1

> -Original Message- > From: Bharat Bhushan > Sent: Thursday, December 15, 2016 9:46 PM > To: Stuart Yoder <stuart.yo...@nxp.com>; Mark Rutland <mark.rutl...@arm.com>; > robin.mur...@arm.com; > will.dea...@arm.com > Cc: robh...@kernel.org; Nipun G

[PATCH] Docs: dt: Be explicit and consistent in reference to IOMMU specifiers

-specifier to "IOMMU specifier" so we are 100% consistent everywhere with terminology and capitalization. Signed-off-by: Stuart Yoder <stuart.yo...@nxp.com> --- Documentation/devicetree/bindings/iommu/arm,smmu.txt | 10 +- Documentation/devicetree/bindings/pci/pci-iommu.txt

RE: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries

> -Original Message- > From: Nipun Gupta [mailto:nipun.gu...@nxp.com] > Sent: Thursday, November 03, 2016 7:27 PM > To: robin.mur...@arm.com; will.dea...@arm.com; > linux-arm-ker...@lists.infradead.org; iommu@lists.linux- > foundation.org > Cc: Stuart Yoder <stua

RE: SMR masking and PCI

> -Original Message- > From: Stuart Yoder > Sent: Friday, October 28, 2016 12:12 PM > To: 'Robin Murphy' <robin.mur...@arm.com>; Mark Rutland <mark.rutl...@arm.com> > Cc: linux-arm-ker...@lists.infradead.org; Will Deacon <will.dea...@arm.com>; >

RE: SMR masking and PCI

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Friday, October 28, 2016 11:17 AM > To: Stuart Yoder <stuart.yo...@nxp.com>; Mark Rutland <mark.rutl...@arm.com> > Cc: linux-arm-ker...@lists.infradead.org; Will Deacon <

SMR masking and PCI

Hi Robin, A question about how the SMR masking defined in the arm,smmu binding relates to the PCI iommu-map. The #iommu-cells property defines the number of cells an "IOMMU specifier" takes and 2 is specified to be: SMMUs with stream matching support and complex masters may use a value of

RE: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Friday, July 01, 2016 12:40 PM > To: Stuart Yoder <stuart.yo...@nxp.com> > Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [RFC 1/2] i

RE: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout

> -Original Message- > From: Robin Murphy > Date: Tue, Jun 28, 2016 at 11:18 AM > Subject: [RFC 1/2] iommu/dma: Restrict IOVAs to physical memory layout > To: iommu@lists.linux-foundation.org, linux-arm-ker...@lists.infradead.org > > > Certain peripherals may be

RE: SMMU driver and stall vs terminate mode

> -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: Tuesday, June 21, 2016 4:43 AM > To: Robin Murphy <robin.mur...@arm.com> > Cc: Stuart Yoder <stuart.yo...@nxp.com>; > linux-arm-ker...@lists.infradead.org; iommu@lists.linux-

RE: SMMU driver and stall vs terminate mode

> -Original Message- > From: Robin Murphy [mailto:robin.mur...@arm.com] > Sent: Monday, June 20, 2016 11:09 AM > To: Stuart Yoder <stuart.yo...@nxp.com>; Will Deacon <will.dea...@arm.com> > Cc: linux-arm-ker...@lists.infradead.org; iommu@lists.linux-fou

SMMU driver and stall vs terminate mode

Robin/Will, Right now the SMMU driver is hardcoded to configure 'stall' mode for context faults: /* SCTLR */ reg = SCTLR_CFCFG | SCTLR_CFIE | SCTLR_CFRE | SCTLR_M | SCTLR_EAE_SBOP; We are running into an issue with a device where it seems behave sanely when SCTLR_CFCFG=0 ...i.e.

RE: RFC: extend IOMMU attributes

> -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: Thursday, February 18, 2016 10:22 AM > To: Stuart Yoder <stuart.yo...@nxp.com> > Cc: j...@8bytes.org; robin.mur...@arm.com; iommu@lists.linux-foundation.org; > linux-arm- > ker...

RFC: extend IOMMU attributes

Hi Joerg and Will, We are implementing support for some specialized NXP SoC network devices and have the desire to extend the mapping attributes beyond those currently in iommu.h. (I see there is a recent proposal to add an IOMMU_MMIO flag) What we have right now in Linux is a

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

> -Original Message- > From: Mark Rutland [mailto:mark.rutl...@arm.com] > Sent: Monday, September 07, 2015 1:05 PM > To: David Daney > Cc: Marc Zyngier; tirumalesh.chalama...@caviumnetworks.com; Richter, Robert; > Chintakuntla, Radha; > devicet...@vger.kernel.org;

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

-Original Message- From: Mark Rutland [mailto:mark.rutl...@arm.com] Sent: Thursday, August 06, 2015 1:15 PM To: Yoder Stuart-B08248; Marc Zyngier; Will Deacon Cc: devicet...@vger.kernel.org; Lorenzo Pieralisi; a...@arndb.de; linux-ker...@vger.kernel.org;

RE: [PATCH 2/3] Docs: dt: Add PCI MSI map bindings

From: Mark Rutland mark.rutl...@arm.com Date: Thu, Jul 23, 2015 at 11:52 AM [cut] diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt new file mode 100644 index 000..9b3cc81 --- /dev/null +++

Re: Master-aware devices and sideband ID data

On Fri, May 8, 2015 at 10:49 AM, Will Deacon will.dea...@arm.com wrote: Hi Stuart, On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote: On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland mark.rutl...@arm.com wrote: Hi all, For some devices, identification of particular masters

Re: Master-aware devices and sideband ID data

On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland mark.rutl...@arm.com wrote: Hi all, For some devices, identification of particular masters is critical to their operation (e.g. IOMMUs, MSI controllers). The identity of masters is determined from sideband signals on the bus, and it may or may

RE: SMMU 2-stage support

-Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Wednesday, April 15, 2015 11:18 AM To: Sethi Varun-B16395 Cc: Baptiste Reynal; Linux IOMMU; Yoder Stuart-B08248 Subject: Re: SMMU 2-stage support On Tue, Apr 14, 2015 at 02:32:26PM +0100, Varun Sethi wrote:

RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

, Jun 16, 2014 at 05:56:32PM +0100, Stuart Yoder wrote: Do you have use-cases where you really need to change these mappings dynamically? Yes. In the case of a PCI bus-- you may not know in advance how many PCI devices there are until you probe the bus. We have another FSL

RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

-Original Message- From: Sethi Varun-B16395 Sent: Tuesday, June 17, 2014 6:22 AM To: Will Deacon Cc: Mark Rutland; devicet...@vger.kernel.org; linux-samsung- s...@vger.kernel.org; Arnd Bergmann; Pawel Moll; Ian Campbell; Grant Grundler; Stephen Warren; Yoder Stuart-B08248; Rob

RE: [PATCH v2] devicetree: Add generic IOMMU device tree bindings

-Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: Monday, June 16, 2014 10:28 AM To: Sethi Varun-B16395 Cc: Thierry Reding; Mark Rutland; devicet...@vger.kernel.org; linux- samsung-...@vger.kernel.org; Pawel Moll; Arnd Bergmann; Ian Campbell; Grant Grundler;

RE: [RFC PATCH v5_v2 01/11] driver core: platform: add device binding path 'driver_override'

. Reviewed-by: Stuart Yoder stuart.yo...@freescale.com Stuart ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [PATCH] driver core: platform: add device binding path 'driver_override'

Phillips kim.phill...@freescale.com --- Reviewed-by: Stuart Yoder stuart.yo...@freescale.com ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: [RFC PATCH] PCI: Introduce new device binding path using pci_dev.driver_override

Another advantage to this approach is that we can specify a driver override to force a specific binding or prevent any binding. For instance when an IOMMU group is exposed to userspace through VFIO we require that all devices within that group are owned by VFIO. However, devices can be

RE: mechanism to allow a driver to bind to any device

, Stuart Yoder wrote: Hi Greg, We (Linaro, Freescale, Virtual Open Systems) are trying get an issue closed that has been perculating for a while around creating a mechanism that will allow kernel drivers like vfio can bind to devices of any type. This thread with you: http

RE: mechanism to allow a driver to bind to any device

...@linaro.org Subject: Re: mechanism to allow a driver to bind to any device On Mon, Mar 31, 2014 at 06:47:51PM +, Stuart Yoder wrote: I also, was at the point where I thought we should perhaps just go with current mechanisms and implement new_id for the platform bus...but Greg's recent

RE: mechanism to allow a driver to bind to any device

; christoffer.d...@linaro.org Subject: Re: mechanism to allow a driver to bind to any device On Wed, Mar 26, 2014 at 01:40:32AM +, Stuart Yoder wrote: Hi Greg, We (Linaro, Freescale, Virtual Open Systems) are trying get an issue closed that has been perculating for a while around creating

RE: mechanism to allow a driver to bind to any device

The other option for this is to having some sort of priority on the device probing with hotplugging. That is you can could do the following: 1) add the device vendor/model in vfio 2) unbind the BDF from the original driver. 3) hotplug happens - any new device that has the device

mechanism to allow a driver to bind to any device

Hi Greg, We (Linaro, Freescale, Virtual Open Systems) are trying get an issue closed that has been perculating for a while around creating a mechanism that will allow kernel drivers like vfio can bind to devices of any type. This thread with you:

RE: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

Roeck; Toshi Kani; Joe Perches; Dmitry Kasatkin; Michal Hocko; Bjorn Helgaas Subject: Re: [RFC PATCH v4 01/10] driver core: export driver_probe_device() On Thu, Feb 20, 2014 at 10:34:35PM +, Stuart Yoder wrote: -Original Message- From: Yoder Stuart-B08248 Sent

RE: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

() On Sat, Feb 15, 2014 at 04:33:44PM +, Stuart Yoder wrote: Why? driver_probe_device() allows a driver to explicitly bind to a specific device. What is conceptually wrong with allowing that? Because that's not how a bus should work, and the fact that no other

RE: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

Why? driver_probe_device() allows a driver to explicitly bind to a specific device. What is conceptually wrong with allowing that? Because that's not how a bus should work, and the fact that no other subsystem in the kernel does that might be a hint you are trying to do something a

RE: [RFC PATCH v4 01/10] driver core: export driver_probe_device()

-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Friday, February 14, 2014 4:27 PM To: Antonios Motakis Cc: alex.william...@redhat.com; kvm...@lists.cs.columbia.edu; iommu@lists.linux-foundation.org; linux-ker...@vger.kernel.org;

Re: RFC: vfio API changes needed for powerpc

Would is be possible for userspace to simply leave room for MSI bank mapping (how much room could be determined by something like VFIO_IOMMU_GET_MSI_BANK_COUNT) then document the API that userspace can DMA_MAP starting at the 0x0 address of the aperture, growing up, and VFIO will map banks on

Re: RFC: vfio API changes needed for powerpc

On Wed, Apr 3, 2013 at 2:18 PM, Scott Wood scottw...@freescale.com wrote: On 04/03/2013 02:09:45 PM, Stuart Yoder wrote: Would is be possible for userspace to simply leave room for MSI bank mapping (how much room could be determined by something like VFIO_IOMMU_GET_MSI_BANK_COUNT

Re: RFC: vfio API changes needed for powerpc

On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood scottw...@freescale.com wrote: On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote: Alex, We are in the process of implementing vfio-pci support for the Freescale IOMMU (PAMU). It is an aperture/window-based IOMMU and is quite different than x86,

Re: RFC: vfio API changes needed for powerpc

On Tue, Apr 2, 2013 at 3:32 PM, Alex Williamson alex.william...@redhat.com wrote: 2. MSI window mappings The more problematic question is how to deal with MSIs. We need to create mappings for up to 3 MSI banks that a device may need to target to generate interrupts. The Linux MSI

Re: RFC: vfio API changes needed for powerpc

On Tue, Apr 2, 2013 at 3:47 PM, Scott Wood scottw...@freescale.com wrote: On 04/02/2013 03:38:42 PM, Stuart Yoder wrote: On Tue, Apr 2, 2013 at 2:39 PM, Scott Wood scottw...@freescale.com wrote: On 04/02/2013 12:32:00 PM, Yoder Stuart-B08248 wrote: Alex, We are in the process

Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.

On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi varun.se...@freescale.com wrote: [cut] +static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain, unsigned long iova) +{ + u32 win_cnt = dma_domain-win_cnt; + struct dma_window *win_ptr = +

Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.

Some more comments... On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi varun.se...@freescale.com wrote: +/* Handling access violations */ +#define make64(high, low) (((u64)(high) 32) | (low)) + +struct pamu_isr_data { + void __iomem *pamu_reg_base;/* Base address of PAMU regs*/ +

Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.

Have not got through the entire file, but have a few comments... +/* + * Set the PAACE type as primary and set the coherency required domain + * attribute + */ +static void pamu_setup_default_xfer_to_host_ppaace(struct paace *ppaace) +{ + set_bf(ppaace-addr_bitfields, PAACE_AF_PT,

RFC: additional domain attributes specific to PAMU

Joerg, The attributes you have defined look good and are mechanisms we need to determine if iommu is aperture based, get max # of windows, set actual number of windows, etc. However, there are a couple of other attributes we need: diff --git a/include/linux/iommu.h b/include/linux/iommu.h index