On Wed, 20 Oct 2021 06:21:44 +0100,
Lu Baolu wrote:
>
> On 2021/10/20 0:37, Sven Peter via iommu wrote:
> > The iova allocator is capable of handling any granularity which is a power
> > of two. Remove the much stronger condition that the granularity must be
> > smaller or equal to the CPU page s
On Thu, 21 Oct 2021 03:22:30 +0100,
Lu Baolu wrote:
>
> On 10/20/21 10:22 PM, Marc Zyngier wrote:
> > On Wed, 20 Oct 2021 06:21:44 +0100,
> > Lu Baolu wrote:
> >>
> >> On 2021/10/20 0:37, Sven Peter via iommu wrote:
> >>> + /*
> >>&
On Fri, 22 Oct 2021 03:52:38 +0100,
Lu Baolu wrote:
>
> On 10/21/21 4:10 PM, Marc Zyngier wrote:
> > On Thu, 21 Oct 2021 03:22:30 +0100,
> > Lu Baolu wrote:
> >>
> >> On 10/20/21 10:22 PM, Marc Zyngier wrote:
> >>> On Wed, 20 Oct 2021 06:21:44
On Sat, 27 Nov 2021 01:22:03 +,
Thomas Gleixner wrote:
>
> Use __msi_get_vector() and handle the return values to be compatible.
>
> No functional change intended.
You wish ;-).
[ 15.779540] pcieport 0001:00:01.0: AER: request AER IRQ -22 failed
Notice how amusing the IRQ number is?
>
[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 a stall if the irq is
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 10
as it deserves 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
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).
>
s, so 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 +++--
a fix).
[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 change
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
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,
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
way Tegra 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
inics.net/lists/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
ar
s, so 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/r
way Tegra 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/mac
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
rq(iommu->dev, irq, iommu);
+
pm_runtime_force_suspend(&pdev->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
drvdata(pdev);
> + int i = 0, irq;
> +
> + while ((irq = platform_get_irq(pdev, i++)) != -ENXIO)
> + devm_free_irq(iommu->dev, irq, iommu);
> +
> pm_runtime_force_suspend(&pdev->dev);
> }
>
> --
> 2.17.0
>
Acked-by: Marc Zyn
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
pr
outing at me while everything
was indeed working just fine.
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, 23 Jul 2015 19:26:11 +0100
David Daney 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, though sideban
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 MSI
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
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
>>>
e
> need to rework that before 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
M.
--
Jazz is not dead. It just smells funny...
___
i
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
---
drivers/iommu/arm-smmu-v3.c | 78
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
---
Now rebased on top of Will's iommu/devel branch, which leads to
a sli
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
---
* From v2:
- MSI indexes as an enum
- Fixed stupid 16bit writes
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
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
---
* From v3:
- Pass the device as a parameter to the MSI destructor
e/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 7d7a4c6..43e183b 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -400,6 +400,7 @@ struct vfio_iommu_type1_info {
> __u32 argsz;
> __u32 flags;
> #define VFIO_IOMMU_INFO_P
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 the iova that is mapped o
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 allocates an iova bound
On 18/02/16 15:33, Eric Auger wrote:
> Hi Marc,
> On 02/18/2016 12:33 PM, Marc Zyngier wrote:
>> 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
On 18/02/16 16:42, Eric Auger wrote:
> Hello,
> On 02/18/2016 12:06 PM, Marc Zyngier wrote:
>> On Fri, 12 Feb 2016 08:13:09 +
>> Eric Auger wrote:
>>
>>> This patch introduces iommu_get/put_single_reserved.
>>>
>>> iommu_get_single_reserved
On Tue, 05 Jul 2022 14:52:43 +0100,
Serge Semin wrote:
>
> Hi Samuel
>
> On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote:
> > The MIPS GIC irqchip driver may be selected in a uniprocessor
> > configuration, but it unconditionally registers an IPI domain.
> >
> > Limit the part of
On Sun, 03 Jul 2022 16:22:03 +0100,
Oleksandr wrote:
>
>
> On 01.07.22 23:00, Samuel Holland wrote:
>
>
> Hello Samuel
>
> > Some architectures and irqchip drivers modify the cpumask returned by
> > irq_data_get_affinity_mask, usually by copying in to it. This is
> > problematic for uniproces
101 - 139 of 139 matches
Mail list logo
