- 15 Dec, 2020 8 commits
-
-
Thomas Gleixner authored
No more users outside the core code. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20201210194043.268774449@linutronix.de
-
Thomas Gleixner authored
The SMP variant works perfectly fine on UP as well. Signed-off-by:
-
Thomas Gleixner authored
Both the per cpu stats and the accumulated count are accessed lockless and can be concurrently modified. That's intentional and the stats are a rough estimate anyway. Annotate them with data_race(). Signed-off-by:
-
Thomas Gleixner authored
Provide an accessor to the effective interrupt affinity mask. Going to be used to replace open coded fiddling with the irq descriptor. Signed-off-by:
-
Thomas Gleixner authored
irq_set_lockdep_class() is used from modules and requires irq_to_desc() to be exported. Move it into the core code which lifts another requirement for the export. Signed-off-by:
-
Thomas Gleixner authored
These checks are used by modules and prevent the removal of the export of irq_to_desc(). Move the accessor into the core. Signed-off-by:
-
Thomas Gleixner authored
This function uses irq_to_desc() and is going to be used by modules to replace the open coded irq_to_desc() (ab)usage. The final goal is to remove the export of irq_to_desc() so driver cannot fiddle with it anymore. Move it into the core code and fixup the usage sites to include the proper header. Signed-off-by:
-
Thomas Gleixner authored
Merge tag 'irqchip-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core Pull irqchip updates for 5.11 from Marc Zyngier: - Preliminary support for managed interrupts on platform devices - Correctly identify allocation of MSIs proxyied by another device - Remove the fasteoi IPI flow which has been proved useless - Generalise the Ocelot support to new SoCs - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation - Work around spurious interrupts on Qualcomm PDC - Random fixes and cleanups Link: https://lore.kernel.org/r/20201212135626.1479884-1-maz@kernel.org
-
- 12 Dec, 2020 1 commit
-
-
Douglas Anderson authored
We have a problem if we use gpio-keys and configure wakeups such that we only want one edge to wake us up. AKA: wakeup-event-action = <EV_ACT_DEASSERTED>; wakeup-source; Specifically we end up with a phantom interrupt that blocks suspend if the line was already high and we want wakeups on rising edges (AKA we want the GPIO to go low and then high again before we wake up). The opposite is also problematic. Specifically, here's what's happening today: 1. Normally, gpio-keys configures to look for both edges. Due to the current workaround introduced in commit c3c0c2e1 ("pinctrl: qcom: Handle broken/missing PDC dual edge IRQs on sc7180"), if the line was high we'd configure for falling edges. 2. At suspend time, we change to look for rising edges. 3. After qcom_pdc_gic_set_type() runs, we get a phantom interrupt. We can solve this by just clearing the phantom interrupt. NOTE: it is possible that this could cause problems for a client with very specific needs, but there's not much we can do with this hardware. As an example, let's say the interrupt signal is currently high and the client is looking for falling edges. The client now changes to look for rising edges. The client could possibly expect that if the line has a short pulse low (and back high) that it would always be detected. Specifically no matter when the pulse happened, it should either have tripped the (old) falling edge trigger or the (new) rising edge trigger. We will simply not trip it. We could narrow down the race a bit by polling our parent before changing types, but no matter what we do there will still be a period of time where we can't tell the difference between a real transition (or more than one transition) and the phantom. Fixes: f55c73ae ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Marc Zyngier <maz@kernel.org> Tested-by:
Maulik Shah <mkshah@codeaurora.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201211141514.v4.1.I2702919afc253e2a451bebc3b701b462b2d22344@changeid
-
- 11 Dec, 2020 27 commits
-
-
John Garry authored
Drivers for multi-queue platform devices may also want managed interrupts for handling HW queue completion interrupts, so add support. The function accepts an affinity descriptor pointer, which covers all IRQs expected for the device. The function is devm class as the only current in-tree user will also use devm method for requesting the interrupts; as such, the function is made as devm as it can ensure ordering of freeing the irq and disposing of the mapping. Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
John Garry authored
The functionality of acpi_dev_irqresource_disabled() is same as in common irqresource_disabled(), so drop acpi_dev_irqresource_disabled() in favour of that function. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/r/1606905417-183214-4-git-send-email-john.garry@huawei.com
-
John Garry authored
Add a common function to set the fields for a irq resource to disabled, which mimics what is done in acpi_dev_irqresource_disabled(), with a view to replace that function. Signed-off-by:
-
John Garry authored
Add a function to allow the affinity of an interrupt be switched to managed, such that interrupts allocated for platform devices may be managed. This new interface has certain limitations, and attempts to use it in the following circumstances will fail: - For when the kernel is configured for generic IRQ reservation mode (in config GENERIC_IRQ_RESERVATION_MODE). The reason being that it could conflict with managed vs. non-managed interrupt accounting. - The interrupt is already started, which should not be the case during init - The interrupt is already configured as managed, which means double init Suggested-by:
-
Marc Zyngier authored
An aliasing PCI bridge is another case where we should flag the corresponding allocation as "proxied", as MSIs are coming with the bridge's RID, and not the originating device's. Signed-off-by:
-
Marc Zyngier authored
The ITS already has some notion of "shared" devices. Let's map the MSI_ALLOC_FLAGS_PROXY_DEVICE flag onto this internal property. Signed-off-by:
-
Marc Zyngier authored
We have two flavours of platform-MSI: - MSIs generated by devices for themselves (the usual case) - MSIs generated on behalf of other devices, as the generating device is some form of bridge (either a wire-to-MSI bridge, or even a non-transparent PCI bridge that repaints the PCI requester ID). In the latter case, the underlying interrupt architecture may need to track this in order to keep the mapping alive even when no MSI are currently being generated. Add a set of flags to the generic msi_alloc_info_t structure, as well as the MSI_ALLOC_FLAGS_PROXY_DEVICE flag that will get advertized by the platform-MSI code when allocating an irqdomain for a device. Signed-off-by:
-
Lokesh Vutla authored
ti_sci_intr_irq_domain_free() assumes that out_irq of intr is stored in data->chip_data and uses it for calling ti_sci irq_free() and then mark the out_irq as available resource. But ti_sci_intr_irq_domain_alloc() is storing p_hwirq(parent's hardware irq) which is translated from out_irq. This is causing resource leakage and eventually out_irq resources might be exhausted. Fix ti_sci_intr_irq_domain_alloc() by storing the out_irq in data->chip_data. Fixes: a5b659bd ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR") Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Lokesh Vutla authored
On a successful probe, the driver tries to print a success message with INTA device id. It uses pdev->id for printing the id but id is stored in inta->ti_sci_id. Fix it by correcting the dev_info parameter. Fixes: 5c4b585d ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC") Signed-off-by:
-
Vineet Gupta authored
NPS platform has been removed from ARC port and there are no in-tree users of it now. So RIP ! Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Valentin Schneider authored
handle_percpu_devid_fasteoi_ipi() has no more users, and handle_percpu_devid_irq() can do all that it was supposed to do. Get rid of it. This reverts commit c5e5ec03. Signed-off-by:
Valentin Schneider <valentin.schneider@arm.com> Signed-off-by:
-
Valentin Schneider authored
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by:
-
Valentin Schneider authored
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by:
-
Valentin Schneider authored
As done for the Arm GIC irqchips, move IPIs to handle_percpu_devid_irq() as handle_percpu_devid_fasteoi_ipi() isn't actually required. Signed-off-by:
-
Valentin Schneider authored
handle_percpu_devid_fasteoi_ipi() states: * The biggest difference with the IRQ version is that the interrupt is * EOIed early, as the IPI could result in a context switch, and we need to * make sure the IPI can fire again All that can actually happen scheduler-wise within the handling of an IPI is the raising of TIF_NEED_RESCHED (and / or folding thereof into preempt_count); see scheduler_ipi() or sched_ttwu_pending() for instance. Said flag / preempt_count is evaluated some time later before returning to whatever context was interrupted, and this gates a call to preempt_schedule_irq() (arm64_preempt_schedule_irq() in arm64). Per the above, SGI's do not need a different handler than PPI's, so make them use the same (handle_percpu_devid_irq). Signed-off-by:
-
Gregory CLEMENT authored
This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Jaguar2. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20201125103206.136498-7-gregory.clement@bootlin.com
-
Gregory CLEMENT authored
This patch extends irqchip driver for ocelot to be used with an other vcoreiii base platform: Serval. Based on a larger patch from Lars Povlsen <lars.povlsen@microchip.com> Signed-off-by:
-
Gregory CLEMENT authored
This patch extends irqchip driver for oceleot to be used with an other vcoreiii base platform: Luton. For this platform there is a few differences: - the interrupt must be enabled for the parent controller - there is no trigger register needed to be managed Signed-off-by:
-
Gregory CLEMENT authored
This patch extends irqchip driver for oceleot to be used with other vcoreiii base platforms. Signed-off-by:
-
Gregory CLEMENT authored
Add the Device Tree binding documentation for the Microsemi Jaguar2, Luton and Serval interrupt controller that is part of the ICPU. It is connected directly to the MIPS core interrupt controller. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20201125103206.136498-3-gregory.clement@bootlin.com
-
Gregory CLEMENT authored
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt Controller to YAML format Signed-off-by:
-
Shenming Lu authored
The 10us delay of the poll on the GICR_VPENDBASER.Dirty bit is too high, which might greatly affect the total scheduling latency of a vCPU in our measurement. So we reduce it to 1 to lessen the impact. Signed-off-by:
Shenming Lu <lushenming@huawei.com> Signed-off-by:
-
Marc Zyngier authored
The alpine-msi driver has an interesting allocation error handling, where it frees the same interrupts repeatedly. Hilarity follows. This code is probably never executed, but let's fix it nonetheless. Fixes: e6b78f2c ("irqchip: Add the Alpine MSIX interrupt controller") Signed-off-by:
Antoine Tenart <atenart@kernel.org> Cc: Tsahee Zidenberg <tsahee@annapurnalabs.com> Cc: Antoine Tenart <atenart@kernel.org> Link: https://lore.kernel.org/r/20201129135525.396671-1-maz@kernel.org
-
Biwen Li authored
Update bindings for Layerscape external irqs, support more SoCs(LS1043A, LS1046A, LS1088A, LS208xA, LX216xA) Signed-off-by:
Biwen Li <biwen.li@nxp.com> Signed-off-by:
-
Hou Zhiqiang authored
Add an new IRQ chip declaration for LS1043A and LS1088A, and cleanup the use of the "bit_reverse" property, now gated on the Soc type. Signed-off-by:
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by:
-
Huacai Chen authored
Fix build warnings as below: drivers/irqchip/irq-loongson-htpic.c: In function 'htpic_reg_init': >> drivers/irqchip/irq-loongson-htpic.c:62:12: warning: variable 'val' set but not used [-Wunused-but-set-variable] 62 | uint32_t val; | ^~~ drivers/irqchip/irq-loongson-htpic.c: At top level: >> drivers/irqchip/irq-loongson-htpic.c:84:12: warning: no previous prototype for 'htpic_of_init' [-Wmissing-prototypes] 84 | int __init htpic_of_init(struct device_node *node, struct device_node *parent) | ^~~~~~~~~~~~~ Fixes: a93f1d90 ("irqchip: Add driver for Loongson-3 HyperTransport PIC controller") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Huacai Chen <chenhuacai@kernel.org> Signed-off-by:
-
Geert Uytterhoeven authored
Fix a capitalization typo. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
- 02 Dec, 2020 4 commits
-
-
Frederic Weisbecker authored
Now that account_hardirq_enter() is called after HARDIRQ_OFFSET has been incremented, there is nothing left that prevents us from also moving tick_irq_enter() after HARDIRQ_OFFSET is incremented. The desired outcome is to remove the nasty hack that prevents softirqs from being raised through ksoftirqd instead of the hardirq bottom half. Also tick_irq_enter() then becomes appropriately covered by lockdep. Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Signed-off-by:
-
Frederic Weisbecker authored
IRQ time entry is currently accounted before HARDIRQ_OFFSET or SOFTIRQ_OFFSET are incremented. This is convenient to decide to which index the cputime to account is dispatched. Unfortunately it prevents tick_irq_enter() from being called under HARDIRQ_OFFSET because tick_irq_enter() has to be called before the IRQ entry accounting due to the necessary clock catch up. As a result we don't benefit from appropriate lockdep coverage on tick_irq_enter(). To prepare for fixing this, move the IRQ entry cputime accounting after the preempt offset is incremented. This requires the cputime dispatch code to handle the extra offset. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20201202115732.27827-5-frederic@kernel.org
-
Frederic Weisbecker authored
The 3 architectures implementing CONFIG_VIRT_CPU_ACCOUNTING_NATIVE all have their own version of irq time accounting that dispatch the cputime to the appropriate index: hardirq, softirq, system, idle, guest... from an all-in-one function. Instead of having these ad-hoc versions, move the cputime destination dispatch decision to the core code and leave only the actual per-index cputime accounting to the architecture. Signed-off-by:
-
Frederic Weisbecker authored
s390 has its own version of IRQ entry accounting because it doesn't account the idle time the same way the other architectures do. Only the actual idle sleep time is accounted as idle time, the rest of the idle task execution is accounted as system time. Make the generic IRQ entry accounting aware of architectures that have their own way of accounting idle time and convert s390 to use it. This prepares s390 to get involved in further consolidations of IRQ time accounting. Signed-off-by:
-
