Re: [PATCH 0/2] ARM SMMU fixes

On 08/04/14 14:41, Laurent Pinchart wrote: I've obviously forgotten that Will was away for a month. CC'ing Marc Zyngier. On Thursday 03 April 2014 01:52:55 Laurent Pinchart wrote: On Friday 28 February 2014 16:37:08 Laurent Pinchart wrote: Hello Will, I've studied your arm-smmu driver

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

On 01/05/14 15:36, Dave Martin wrote: On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote: On Thursday 01 May 2014 12:15:35 Dave Martin wrote: On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd Bergmann wrote: On Tuesday 29 April 2014 19:16:02 Dave Martin wrote: [...] For example,

Re: [PATCH v12 11/31] documentation: iommu: add binding document of Exynos System MMU

On 01/05/14 16:53, Arnd Bergmann wrote: On Thursday 01 May 2014 16:11:48 Marc Zyngier wrote: On 01/05/14 15:36, Dave Martin wrote: On Thu, May 01, 2014 at 02:29:50PM +0100, Arnd Bergmann wrote: On Thursday 01 May 2014 12:15:35 Dave Martin wrote: On Tue, Apr 29, 2014 at 10:46:18PM +0200, Arnd

Re: [RFC PATCH v6 04/20] iommu/arm-smmu: add capability IOMMU_CAP_INTR_REMAP

On Fri, Jun 27 2014 at 10:57:28 PM, Chalamarla, Tirumalesh tirumalesh.chalama...@caviumnetworks.com wrote: Marc, What is your opinion on ITS emulation . is it should be part of KVM or VFIO. Making any sort of emulation part of VFIO sounds quite wrong. That's not what VFIO

Re: [PATCH v13 00/18] VFIO support for platform devices

Hi Baptiste, On 26/02/15 17:02, Baptiste Reynal wrote: Hi everyone, Are there any comments on this patch series? If not, Is there anything keeping this series from getting merged upstream? For a start, it looks like the dependency mentioned below is still not in, which is a bit of a

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

On 27/07/15 10:46, Mark Rutland wrote: On Mon, Jul 27, 2015 at 09:02:46AM +0100, Marc Zyngier wrote: Hi Mark, Hi, On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used in a couple of drivers despite being fairly underspecified. This patch adds a generic binding for MSIs

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

v4.3. Marc, can I take it from your use of the binding that you are happy to provide your ack? Definitely. Acked-by: Marc Zyngier marc.zyng...@arm.com M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

On Thu, 23 Jul 2015 19:26:11 +0100 David Daney dda...@caviumnetworks.com wrote: On 07/23/2015 09:52 AM, Mark Rutland wrote: [...] +MSI clients +=== + +MSI clients are devices which generate MSIs. For each MSI they wish to +generate, the doorbell and payload may be configured,

Re: [PATCH 1/3] Docs: dt: add generic MSI bindings

Hi Mark, On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used in a couple of drivers despite being fairly underspecified. This patch adds a generic binding for MSIs (including the existing msi-parent property) enabling the description of platform devices capable of using MSIs.

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

On 23/07/15 17:52, Mark Rutland wrote: Currently msi-parent is used by a few bindings to describe the relationship between a PCI root complex and a single MSI controller, but this property does not have a generic binding document. Additionally, msi-parent is insufficient to describe more

[PATCH v3] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- * From v2: - MSI indexes as an enum -

[PATCH] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/iommu/arm-smmu-v3.

[PATCH v2] iommu/arm-smmu: Add support for MSI on SMMUv3

Despite being a platform device, the SMMUv3 is capable of signaling interrupts using MSIs. Hook it into the platform MSI framework and enjoy faults being reported in a new and exciting way. Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- Now rebased on top of Will's iommu/devel

Re: [PATCH v3] iommu/arm-smmu: Add support for MSI on SMMUv3

On 13/10/15 16:41, Will Deacon wrote: > Hi Marc, > > On Thu, Oct 08, 2015 at 03:52:00PM +0100, Marc Zyngier wrote: >> Despite being a platform device, the SMMUv3 is capable of signaling >> interrupts using MSIs. Hook it into the platform MSI framework and >> enjoy fau

Re: [PATCH v2 3/7] of/irq: Break out msi-map lookup (again)

property. Drag the > core parsing routine up yet another layer into the general OF-PCI code, > and further generalise it for either kind of lookup in either flavour > of map property. > > CC: Rob Herring <robh...@kernel.org> > CC: Frank Rowand <frowand.l...@gmail.com> >

Re: [RFC v3 02/15] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO

; __u32 flags; > #define VFIO_IOMMU_INFO_PGSIZES (1 << 0) /* supported page sizes info */ > +#define VFIO_IOMMU_INFO_REQUIRE_MSI_MAP (1 << 1)/* MSI must be mapped */ > __u64 iova_pgsizes; /* Bitmap of supported page sizes */ > }; > FWIW: Acked-by: Marc Zyngier <marc.zyng...@arm.com> M. -- Jazz is not dead. It just smells funny. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC v3 07/15] iommu: iommu_get/put_single_reserved

On Fri, 12 Feb 2016 08:13:09 + Eric Auger wrote: > This patch introduces iommu_get/put_single_reserved. > > iommu_get_single_reserved allows to allocate a new reserved iova page > and map it onto the physical page that contains a given physical address. > It returns

Re: [RFC v3 15/15] irqchip/gicv2m/v3-its-pci-msi: IOMMU map the MSI frame when needed

On Fri, 12 Feb 2016 08:13:17 + Eric Auger wrote: > In case the msi_desc references a device attached to an iommu > domain, the msi address needs to be mapped in the IOMMU. Else any > MSI write transaction will cause a fault. > > gic_set_msi_addr detects that case and

Re: [PATCH v8 7/8] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

On 28/04/16 09:22, Eric Auger wrote: > This patch handles the iommu mapping of MSI doorbells that require to > be mapped in an iommu domain. This happens on msi_domain_alloc/free_irqs > since this is called in code that can sleep (pci_enable/disable_msi): > iommu_map/unmap is not stated as atomic.

Re: [PATCH v7 5/8] genirq/irq: introduce msi_doorbell's structs and related callback

On 19/04/16 18:13, Eric Auger wrote: > The purpose is to be able to retrieve the MSI doorbells of an irqchip. > This is now needed since on some platforms those doorbells must be > iommu mapped (in case the MSIs transit through an IOMMU that do not > bypass those transactions). > > The assumption

Re: [PATCH v7 8/8] genirq/msi: use the MSI doorbell's IOVA when requested

On 19/04/16 18:13, Eric Auger wrote: > On MSI message composition we now use the MSI doorbell's IOVA in > place of the doorbell's PA in case the device is upstream to an > IOMMU that requires MSI addresses to be mapped. The doorbell's > allocation and mapping happened on an early stage

Re: [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

On 19/04/16 18:13, Eric Auger wrote: > This patch implements the msi_doorbell_info callback in the > gicv2m driver. > > The driver now is able to return its doorbell characteristics > (base, size, prot). A single doorbell is exposed. > > This will allow the msi layer to iommu_map this doorbell

Re: [PATCH v7 09/10] iommu/dma-reserved-iommu: iommu_msi_mapping_translate_msg

On 19/04/16 17:56, Eric Auger wrote: > Introduce iommu_msi_mapping_translate_msg whose role consists in > detecting whether the device's MSIs must to be mapped into an IOMMU. > It case it must, the function overrides the MSI msg originally composed > and replaces the doorbell's PA by a

Re: [PATCH v7 6/8] irqchip/gicv2m: implement msi_doorbell_info callback

On Wed, 20 Apr 2016 14:33:17 +0200 Eric Auger <eric.au...@linaro.org> wrote: > Marc, > On 04/20/2016 11:27 AM, Marc Zyngier wrote: > > On 19/04/16 18:13, Eric Auger wrote: > >> This patch implements the msi_doorbell_info callback in the > >> gicv2m driv

Re: [PATCH v6.1] iommu/dma: Add support for mapping MSIs

vice attached to one of our DMA > ops domains. > > CC: Thomas Gleixner <t...@linutronix.de> > CC: Jason Cooper <ja...@lakedaemon.net> > CC: Marc Zyngier <marc.zyng...@arm.com> > CC: linux-ker...@vger.kernel.org > Signed-off-by: Robin Murphy <robin.mur...@arm.

Re: [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

Geetha, On 22/10/16 05:54, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt

Re: [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

On 15/11/16 07:00, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt controller are

Re: [PATCH v2] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

On 15/11/16 18:24, David Daney wrote: > On 11/15/2016 01:26 AM, Marc Zyngier wrote: >> On 15/11/16 07:00, Geetha sowjanya wrote: >>> From: Tirumalesh Chalamarla <tirumalesh.chalama...@cavium.com> >>> >>>This patch implements Cavium ThunderX err

Re: [PATCH v6 17/18] vfio/type1: Check MSI remapping at irq domain level

On 06/01/17 09:08, Auger Eric wrote: > Hi Bharat > > On 06/01/2017 09:50, Bharat Bhushan wrote: >> Hi Eric, >> >>> -Original Message- >>> From: Eric Auger [mailto:eric.au...@redhat.com] >>> Sent: Friday, January 06, 2017 12:35 AM >>> To: eric.au...@redhat.com; eric.auger@gmail.com;

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 06/01/17 04:27, Bharat Bhushan wrote: > Hi Mark, > >> -Original Message- >> From: Auger Eric [mailto:eric.au...@redhat.com] >> Sent: Thursday, January 05, 2017 5:39 PM >> To: Marc Zyngier <marc.zyng...@arm.com>; eric.auger@gmail.com; >&

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

Hi Eric, On 04/01/17 13:32, Eric Auger wrote: > This new function checks whether all platform and PCI > MSI domains implement IRQ remapping. This is useful to > understand whether VFIO passthrough is safe with respect > to interrupts. > > On ARM typically an MSI controller can sit downstream >

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 04/01/17 14:11, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 14:46, Marc Zyngier wrote: >> Hi Eric, >> >> On 04/01/17 13:32, Eric Auger wrote: >>> This new function checks whether all platform and PCI >>> MSI domains implement IRQ remapping.

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 10:45, Auger Eric wrote: > Hi Marc, > > On 04/01/2017 16:27, Marc Zyngier wrote: >> On 04/01/17 14:11, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 14:46, Marc Zyngier wrote: >>>> Hi Eric, >>>> >>>&g

Re: [PATCH v5 13/17] irqdomain: irq_domain_check_msi_remap

On 05/01/17 11:29, Auger Eric wrote: > Hi Marc, > > On 05/01/2017 12:25, Marc Zyngier wrote: >> On 05/01/17 10:45, Auger Eric wrote: >>> Hi Marc, >>> >>> On 04/01/2017 16:27, Marc Zyngier wrote: >>>> On 04/01/17 14:11, Auger Eric wrote: >&g

Re: [PATCH v7 16/19] irqchip/gicv3-its: Sets IRQ_DOMAIN_FLAG_MSI_REMAP

info->data = its; > inner_domain->host_data = info; > For patches 13 to 16, and provided that you address the couple of nits I mentioned in reply to patches 13 and 15: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> Thanks, M. -- Jazz is not dead. It just s

Re: [PATCH v7 13/19] irqdomain: Add irq domain MSI and MSI_REMAP flags

Hi Eric, On 09/01/17 13:46, Eric Auger wrote: > We introduce two new enum values for the irq domain flag: > - IRQ_DOMAIN_FLAG_MSI indicates the irq domain corresponds to > an MSI domain > - IRQ_DOMAIN_FLAG_MSI_REMAP indicates the irq domain has MSI > remapping capabilities. > > Those values

Re: [PATCH v7 15/19] irqdomain: irq_domain_check_msi_remap

On 09/01/17 13:46, Eric Auger wrote: > This new function checks whether all MSI irq domains > implement IRQ remapping. This is useful to understand > whether VFIO passthrough is safe with respect to interrupts. > > On ARM typically an MSI controller can sit downstream > to the IOMMU without

Re: [PATCH v3] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

Geetha, On 20/12/16 11:06, Geetha sowjanya wrote: > From: Tirumalesh Chalamarla > > This patch implements Cavium ThunderX erratum 28168. > > PCI requires stores complete in order. Due to erratum #28168 > PCI-inbound MSI-X store to the interrupt controller

Re: [PATCH] iommu: Avoid NULL group dereference

ng rather familiar, but now it's backed by the reasoning of having > a robust API able to do the expected thing for all devices regardless. > > Fixes: 05f80300dc8b ("iommu: Finish making iommu_group support mandatory") > Reported-by: Shawn Lin <shawn@rock-chips.c

Re: PCIe oops for NULL pointer dereference during next-20170807 and next-20170815

On 17/08/17 08:58, Joerg Roedel wrote: > On Thu, Aug 17, 2017 at 03:02:31PM +0800, Shawn Lin wrote: >> So should we revert this commit or maybe we could add some checking >> into gic-v2m and gic-v3-its to see if the dev is iommu-capable? If not, >> we should create another routine to map MSI msg.

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

On 17/08/17 10:01, Shawn Lin wrote: > Hi Marc > > On 2017/8/17 16:52, Marc Zyngier wrote: >> On 17/08/17 09:28, Shawn Lin wrote: >>> If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't >>> have iommu support, we don't need to do iommu_dma_map_msi_ms

Re: [PATCH] irqchip/gic-{v2m, v3-its}: check iommu capable before doing iommu map

On 17/08/17 09:28, Shawn Lin wrote: > If a PCIe RC use gic-v2m or gic-v3-its as a msi domain but doesn't > have iommu support, we don't need to do iommu_dma_map_msi_msg to > get mapped iommu address as all we need is the physical address. > Otherwise we see the oops shown below as we can't get a

Re: [PATCH v8 3/3] iommu/arm-smmu-v3: Add workaround for Cavium ThunderX2 erratum #126

On 21/06/17 10:08, Will Deacon wrote: > Hi Geetha, > > On Wed, Jun 21, 2017 at 12:09:45PM +0530, Geetha Akula wrote: >> On Tue, Jun 20, 2017 at 11:30 PM, Will Deacon wrote: >>> On Tue, Jun 20, 2017 at 07:47:39PM +0530, Geetha sowjanya wrote: From: Geetha Sowjanya

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 17:49, Ray Jui wrote: > Hi Will, > > On 5/30/17 8:14 AM, Will Deacon wrote: >> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote: >>> I'm writing to check with you to see if the latest arm-smmu.c driver in >>> v4.12-rc Linux for smmu-500 can support mapping that is only specific

Re: Device address specific mapping of arm,mmu-500

On 30/05/17 18:16, Ray Jui wrote: > Hi Marc, > > On 5/30/17 9:59 AM, Marc Zyngier wrote: >> On 30/05/17 17:49, Ray Jui wrote: >>> Hi Will, >>> >>> On 5/30/17 8:14 AM, Will Deacon wrote: >>>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray

Re: [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper

On 27/09/17 14:32, Shameer Kolothum wrote: > From: John Garry > > On some platforms msi-controller address regions have to be excluded > from normal IOVA allocation in that they are detected and decoded in > a HW specific way by system components and so they cannot be

Re: [PATCH v8 2/5] ACPI/IORT: Add msi address regions reservation helper

On 27/09/17 14:32, Shameer Kolothum wrote: > On some platforms msi parent address regions have to be excluded from > normal IOVA allocation in that they are detected and decoded in a HW > specific way by system components and so they cannot be considered normal > IOVA address space. > > Add a

Re: [PATCH v12 1/3] ACPI/IORT: Add msi address regions reservation helper

/irqchip/irq-gic-v3-its.c | 3 +- > include/linux/acpi_iort.h| 7 ++- > 3 files changed, 116 insertions(+), 5 deletions(-) For the ITS part: Reviewed-by: Marc Zyngier <marc.zyng...@arm.com> M. ___ iommu mailing list

Re: [PATCH] drm/rockchip: vop: fix irq disabled after vop driver probed

[Thanks Robin for pointing me to that patch.] Hi Heiko, On 24/05/18 23:06, Heiko Stübner wrote: > From: Sandy Huang > > The vop irq is shared between vop and iommu and irq probing in the > iommu driver moved to the probe function recently. This can in some > cases lead to

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

On 13/06/18 10:20, Thomas Gleixner wrote: > On Wed, 13 Jun 2018, Julien Thierry wrote: >> On 13/06/18 09:34, Peter Zijlstra wrote: >>> On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote: diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index 5426627..dbc5e02

Re: [PATCH v2] iommu/arm-smmu-v3: limit reporting of MSI allocation failures

i_msg); > if (ret) { > - dev_warn(dev, "failed to allocate MSIs\n"); > + dev_warn(dev, "failed to allocate MSIs - falling back to wired > irqs\n"); > return; > } > > Acked-by: Marc Zyngier &

Re: [PATCH] iommu/arm-smmu-v3: suppress MSI allocation failure message

On 17/01/18 18:54, Robin Murphy wrote: > [ +Marc just in case ] > > On 17/01/18 18:39, Nate Watterson wrote: >> From: Sinan Kaya >> >> Even though QDF2400 supports MSI interrupts with SMMUv3, it is not enabled >> in ACPI FW to preserve compatibility with older kernel

[PATCH] iommu/rockchip: Perform a reset on shutdown

our back. Note that we need to be extra cautious when doing so, as the IOMMU may not be clocked if controlled by a another master, as typical on Rockchip system. Suggested-by: Robin Murphy <robin.mur...@arm.com> Signed-off-by: Marc Zyngier <marc.zyng...@arm.com> --- drivers/iommu/rock

[PATCH] iommu/rockchip: Handle errors returned from PM framework

investigation, let's output a single warning (instead of flodding the console). In both cases, bail with an IRQ_NONE. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 7 --- 1 file changed, 4 insertions(+), 3

Re: [PATCH] iommu/rockchip: Handle errors returned from PM framework

Hi Heiko, On 06/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Sonntag, 5. August 2018, 14:46:16 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >>

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

On 07/08/18 13:09, Heiko Stuebner wrote: > Hi Marc, > > Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >> pm_runtime_get_if_in_use can fail: either PM has been disabled >> altogether (-EINVAL), or the device hasn't been enabled yet (0). >> Sadly, the

[PATCH 0/2] iommu/rockchip: Runtime PM fixes

). [1] https://www.spinics.net/lists/arm-kernel/msg670229.html Marc Zyngier (2): iommu/rockchip: Handle errors returned from PM framework iommu/rockchip: Move irq request past pm_runtime_enable drivers/iommu/rockchip-iommu.c | 45 +- 1 file changed, 28

[PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 21 +++-- 1 file c

[PATCH 2/2] iommu/rockchip: Move irq request past pm_runtime_enable

in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletion

Re: [PATCH 1/2] iommu/rockchip: Handle errors returned from PM framework

On 07/08/18 14:15, Heiko Stuebner wrote: > Am Dienstag, 7. August 2018, 14:31:49 CEST schrieb Marc Zyngier: >> On 07/08/18 13:09, Heiko Stuebner wrote: >>> Hi Marc, >>> >>> Am Dienstag, 7. August 2018, 10:54:05 CEST schrieb Marc Zyngier: >>>> pm_ru

[PATCH v2 4/4] iommu/rockchip: Move irq request past pm_runtime_enable

in, which advocates for a more synchronized interrupt enabling/disabling approach. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-iommu.c | 24 +--- 1 file c

[PATCH v2 2/4] arm64: rockchip: Force CONFIG_PM on Rockchip systems

already does). Signed-off-by: Marc Zyngier --- arch/arm64/Kconfig.platforms | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index d5aeac351fc3..21a715ad8222 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms

[PATCH v2 0/4] iommu/rockchip: Runtime PM fixes

/arm-kernel/msg670229.html * From v1: - Collected RBs from Heiko - Added two patches forcing CONFIG_PM on all Rockchip platforms at Heiko's request, following the example set by Tegra platforms. Marc Zyngier (4): ARM: rockchip: Force CONFIG_PM on Rockchip systems arm64: rockchip: Force

[PATCH v2 3/4] iommu/rockchip: Handle errors returned from PM framework

let's handle this case throughout the driver, with a WARN_ON_ONCE so that we can try and work out what happened. Fixes: 0f181d3cf7d98 ("iommu/rockchip: Add runtime PM support") Reviewed-by: Heiko Stuebner Signed-off-by: Marc Zyngier --- drivers/iommu/rockchip-io

[PATCH v2 1/4] ARM: rockchip: Force CONFIG_PM on Rockchip systems

already does). Signed-off-by: Marc Zyngier --- arch/arm/mach-rockchip/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig index fafd3d7f9f8c..8ca926522026 100644 --- a/arch/arm/mach-rockchip/Kconfig +++ b/arch/arm/mach-rockchip

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

mmu->dev, irq, iommu); + pm_runtime_force_suspend(>dev); } Looks OK to me. I don't think there is a point in using devm_irq* anymore in this driver, but that's a separate issue. Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

Hi Sammer, On 11/04/18 16:58, Goel, Sameer wrote: > > > On 3/28/2018 9:00 AM, Marc Zyngier wrote: >> On 2018-03-28 15:39, Timur Tabi wrote: >>> From: Sameer Goel <sg...@codeaurora.org> >>> >>> Set SMMU_GBPA to abort all incoming trans

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 12/04/18 11:17, Robin Murphy wrote: > On 11/04/18 17:54, Marc Zyngier wrote: >> Hi Sammer, >> >> On 11/04/18 16:58, Goel, Sameer wrote: >>> >>> >>> On 3/28/2018 9:00 AM, Marc Zyngier wrote: >>>> On 2018-03-28 15:39, Tim

Re: [PATCH] iommu/arm-smmu-v3: Set GBPA to abort all transactions

On 2018-03-28 15:39, Timur Tabi wrote: From: Sameer Goel Set SMMU_GBPA to abort all incoming translations during the SMMU reset when SMMUEN==0. This prevents a race condition where a stray DMA from the crashed primary kernel can try to access an IOVA address as an

Re: [PATCH] iommu/rockchip: Free irqs in shutdown handler

ta(pdev); > + int i = 0, irq; > + > + while ((irq = platform_get_irq(pdev, i++)) != -ENXIO) > + devm_free_irq(iommu->dev, irq, iommu); > + > pm_runtime_force_suspend(>dev); > } > > -- > 2.17.0 > Acked-by: Marc Zyngier

Re: [PATCH] iommu: rockchip: Drop verbose prints in the interrupt handler

On 26/09/18 18:31, Ezequiel Garcia wrote: On Tue, 2018-09-25 at 13:29 +0200, Joerg Roedel wrote: On Thu, Aug 30, 2018 at 07:28:32PM -0300, Ezequiel Garcia wrote: Printing verbosely via WARN macros and friends in interrupt handlers is strongly discouraged. Drop them and use proper ratelimited

Re: [PATCH v2 4/7] irqchip/gic-v3-its: Don't map the MSI page in its_irq_compose_msi_msg()

On 01/05/2019 12:14, Julien Grall wrote: > On 30/04/2019 13:34, Auger Eric wrote: >> Hi Julien, > > Hi Eric, > > Thank you for the review! > >> >> On 4/29/19 4:44 PM, Julien Grall wrote: >>> its_irq_compose_msi_msg() may be called from non-preemptible context. >>> However, on RT,

Re: [PATCH v2 2/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts

On 29/04/2019 15:44, Julien Grall wrote: > On RT, iommu_dma_map_msi_msg() may be called from non-preemptible > context. This will lead to a splat with CONFIG_DEBUG_ATOMIC_SLEEP as > the function is using spin_lock (they can sleep on RT). > > iommu_dma_map_msi_msg() is used to map the MSI page in

Re: [PATCH v2 0/7] iommu/dma-iommu: Split iommu_dma_map_msi_msg in two parts

Hi Julien, On 29/04/2019 15:44, Julien Grall wrote: > Hi all, > > On RT, the function iommu_dma_map_msi_msg expects to be called from > preemptible > context. However, this is not always the case resulting a splat with > !CONFIG_DEBUG_ATOMIC_SLEEP: > > [ 48.875777] BUG: sleeping function

Re: [PATCH v3 6/7] irqchip/gic-v3-mbi: Don't map the MSI page in mbi_compose_m{b, s}i_msg()

On 01/05/2019 14:58, Julien Grall wrote: > The functions mbi_compose_m{b, s}i_msg may be called from non-preemptible > context. However, on RT, iommu_dma_map_msi_msg() requires to be called > from a preemptible context. > > A recent patch split iommu_dma_map_msi_msg in two new functions: > one

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

Hi Julien, On 18/04/2019 18:26, Julien Grall wrote: > When an MSI doorbell is located downstream of an IOMMU, it is required > to swizzle the physical address with an appropriately-mapped IOVA for any > device attached to one of our DMA ops domain. > > At the moment, the allocation of the

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

On 23/04/2019 14:19, Robin Murphy wrote: > On 23/04/2019 12:46, Marc Zyngier wrote: >> On 23/04/2019 11:51, Julien Grall wrote: >>> On 4/23/19 11:23 AM, Marc Zyngier wrote: >>>> Hi Julien, >>> >>> Hi Marc, >>> >>>> On 18/04/

Re: [PATCH 1/7] genirq/msi: Add a new field in msi_desc to store an IOMMU cookie

On 23/04/2019 11:51, Julien Grall wrote: > On 4/23/19 11:23 AM, Marc Zyngier wrote: >> Hi Julien, > > Hi Marc, > >> On 18/04/2019 18:26, Julien Grall wrote: >>> When an MSI doorbell is located downstream of an IOMMU, it is required >>> to swizzle the phy

Re: [PATCH v6 09/22] vfio: VFIO_IOMMU_BIND/UNBIND_MSI

Hi Vincent, On 10/04/2019 13:35, Vincent Stehlé wrote: > On Thu, Apr 04, 2019 at 08:55:25AM +0200, Auger Eric wrote: >> Hi Marc, Robin, Alex, > (..) >> Do you think this is a reasonable assumption to consider devices within >> the same host iommu group share the same MSI doorbell? > > Hi Eric, >

Re: [PATCH] iommu/dma: Handle MSI mappings separately

n business with a bnx2x device passed to a guest. FWIW: Tested-by: Marc Zyngier Thanks, M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu/rockchip: Don't provoke WARN for harmless IRQs

return ret; if (WARN_ON(clk_bulk_enable(iommu->num_clocks, iommu->clocks))) Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundat

Re: arm-smmu-v3 high cpu usage for NVMe

Hi John, On 2020-03-20 16:20, John Garry wrote: I've run a bunch of netperf instances on multiple cores and collecting SMMU usage (on TaiShan 2280). I'm getting the following ratio pretty consistently. - 6.07% arm_smmu_iotlb_sync - 5.74% arm_smmu_tlb_inv_range 5.09%

Re: arm-smmu-v3 high cpu usage for NVMe

On 2020-03-23 09:03, John Garry wrote: On 20/03/2020 16:33, Marc Zyngier wrote: JFYI, I've been playing for "perf annotate" today and it's giving strange results for my NVMe testing. So "report" looks somewhat sane, if not a worryingly high % for arm_smmu_cmdq_issue_cmdlist(

Re: arm-smmu-v3 high cpu usage for NVMe

On Tue, 24 Mar 2020 09:18:10 + John Garry wrote: > On 23/03/2020 09:16, Marc Zyngier wrote: > > + Julien, Mark > > Hi Marc, > > >>> Time to enable pseudo-NMIs in the PMUv3 driver... > >>> > >> > >> Do you know if there is any p

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

Hi Jason, On 2020-08-28 13:19, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote: On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote: [...] > And I can't figure out what's special about tegra, rcar, and xilinx > that makes them need it as

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

On 2020-08-28 13:54, Jason Gunthorpe wrote: On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote: > So the arch_setup_msi_irq/etc is not really an arch hook, but some > infrastructure to support those 4 PCI root port drivers. I happen to have a *really old* patch addressing Te

Re: [patch V2 17/46] PCI/MSI: Rework pci_msi_domain_calc_hwirq()

On Wed, 26 Aug 2020 12:16:45 +0100, Thomas Gleixner wrote: > > From: Thomas Gleixner > > Retrieve the PCI device from the msi descriptor instead of doing so at the > call sites. > > Signed-off-by: Thomas Gleixner > Acked-by: Bjorn Helgaas Acked-by: Marc Zyngier

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

On Wed, 26 Aug 2020 20:47:38 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:57 +0100, > > Thomas Gleixner wrote: > >> /** > >> - * msi_domain_free_irqs - Free interrupts from a MSI interr

Re: [patch V2 43/46] genirq/msi: Provide and use msi_domain_set_default_info_flags()

On 2020-08-26 12:17, Thomas Gleixner wrote: MSI interrupts have some common flags which should be set not only for PCI/MSI interrupts. Move the PCI/MSI flag setting into a common function so it can be reused. Signed-off-by: Thomas Gleixner --- V2: New patch --- drivers/pci/msi.c |7

Re: [patch V2 23/46] irqdomain/msi: Provide DOMAIN_BUS_VMD_MSI

ch(domain->bus_token) { > + case DOMAIN_BUS_PCI_MSI: > + case DOMAIN_BUS_VMD_MSI: > + break; > + default: > return false; > + } > > if (!(info->flags & MSI_FLAG_MUST_REACTIVATE)) > return false; Acked-by: Mar

Re: [patch V2 41/46] platform-msi: Provide default irq_chip:: Ack

= irq_chip_mask_parent; > if (!chip->irq_unmask) > chip->irq_unmask = irq_chip_unmask_parent; > + if (!chip->irq_ack) > + chip->irq_ack = irq_chip_ack_parent; > if (!chip->irq_eoi) > chip->irq_eoi = irq_chip_

Re: [patch V2 29/46] irqdomain/msi: Allow to override msi_domain_alloc/free_irqs()

truct irq_dom > } > > /** > + * __msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain > associated tp @dev Spurious __. > + * @domain: The domain to managing the interrupts > + * @dev: Pointer to device struct of the device for which the interrupts >

Re: [patch V2 19/46] x86/msi: Use generic MSI domain ops

msi_prepare); > > -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc) > -{ > - arg->desc = desc; > - arg->hwirq = pci_msi_domain_calc_hwirq(desc); > -} > -EXPORT_SYMBOL_GPL(pci_msi_set_desc); I think that at this stage, pci_msi_domain_calc_hwirq() can

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

/irq/chip.c +++ b/kernel/irq/chip.c @@ -1544,7 +1544,7 @@ int irq_chip_compose_msi_msg(struct irq_data *data, struct msi_msg *msg) struct irq_data *pos = NULL; #ifdef CONFIG_IRQ_DOMAIN_HIERARCHY - for (; data; data = data->parent_data) + for (; data && !pos; data = data->paren

Re: [patch V2 04/46] genirq/chip: Use the first chip in irq_chip_compose_msi_msg()

On Wed, 26 Aug 2020 22:19:56 +0100, Thomas Gleixner wrote: > > On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote: > > On Wed, 26 Aug 2020 12:16:32 +0100, > > Thomas Gleixner wrote: > >> --- > >> V2: New patch. Note, that this might break other stuff which reli

Re: [patch V2 24/46] PCI: vmd: Mark VMD irqdomain with DOMAIN_BUS_VMD_MSI

MSI domain. > + */ > + irq_domain_update_bus_token(vmd->irq_domain, DOMAIN_BUS_VMD_MSI); > + One day, we'll be able to set the token at domain creation time. In the meantime, Acked-by: Marc Zyngier M. -- Without deviation from the norm, progress is not possibl

Re: [patch V2 34/46] PCI/MSI: Make arch_.*_msi_irq[s] fallbacks selectable

nel to support the Xilinx AXI PCIe @@ -105,7 +106,6 @@ config PCIE_XILINX_CPM bool "Xilinx Versal CPM host bridge support" depends on ARCH_ZYNQMP || COMPILE_TEST select PCI_HOST_COMMON - select PCI_MSI_ARCH_FALLBACKS help

Re: [PATCH v7 13/24] iommu/arm-smmu-v3: Enable broadcast TLB maintenance

On 2020-05-21 15:17, Will Deacon wrote: [+Marc] On Tue, May 19, 2020 at 07:54:51PM +0200, Jean-Philippe Brucker wrote: The SMMUv3 can handle invalidation targeted at TLB entries with shared ASIDs. If the implementation supports broadcast TLB maintenance, enable it and keep track of it in a

Re: [PATCH v3 22/35] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

t_name = irqchip_fwnode_get_name, > +}; > EXPORT_SYMBOL_GPL(irqchip_fwnode_ops); > > /** Acked-by: Marc Zyngier -- Without deviation from the norm, progress is not possible. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 11/12] bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver

++-- drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c | 15 +- 5 files changed, 47 insertions(+), 40 deletions(-) For this patch and the following one: Acked-by: Marc Zyngier M. -- Jazz is not dead. It just smells funny... ___ iommu mailing

  1   2   >