| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Using the interrupt affinity mask for checking locality is not really
working well on architectures which support effective affinity masks.
The affinity mask is either the system wide default or set by user space,
but the architecture can or even must reduce the mask to the effective set,
which means that checking the affinity mask itself does not really tell
about the actual target CPUs.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Tariq Toukan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
No driver has any business with the internals of an interrupt
descriptor. Storing a pointer to it just to use yet another helper at the
actual usage site to retrieve the affinity mask is creative at best. Just
because C does not allow encapsulation does not mean that the kernel has no
limits.
Retrieve a pointer to the affinity mask itself and use that. It's still
using an interface which is usually not for random drivers, but definitely
less hideous than the previous hack.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: Tariq Toukan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Going through a full irq descriptor lookup instead of just using the proper
helper function which provides direct access is suboptimal.
In fact it _is_ wrong because the chip callback needs to get the chip data
which is relevant for the chip while using the irq descriptor variant
returns the irq chip data of the top level chip of a hierarchy. It does not
matter in this case because the chip is the top level chip, but that
doesn't make it more correct.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Use the proper core function.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Logan Gunthorpe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
First of all drivers have absolutely no business to dig into the internals
of an irq descriptor. That's core code and subject to change. All of this
information is readily available to /proc/interrupts in a safe and race
free way.
Remove the inspection code which is a blatant violation of subsystem
boundaries and racy against concurrent modifications of the interrupt
descriptor.
Print the irq line instead so the information can be looked up in a sane
way in /proc/interrupts.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Let the core code do the fiddling with irq_desc.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Driver code has no business with the internals of the irq descriptor.
Aside of that the count is per interrupt line and therefore takes
interrupts from other devices into account which share the interrupt line
and are not handled by the graphics driver.
Replace it with a pmu private count which only counts interrupts which
originate from the graphics card.
To avoid atomics or heuristics of some sort make the counter field
'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and
postprocessing can easily deal with the occasional wraparound.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Nothing uses the result and nothing should ever use it in driver code.
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The irq descriptor is already there, no need to look it up again.
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Most users of kstat_irqs_cpu() have the irq descriptor already. No point in
calling into the core code and looking it up once more.
Use it in per_cpu_count_show() to start with.
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
No more users outside the core code.
Signed-off-by: Thomas Gleixner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The SMP variant works perfectly fine on UP as well.
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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/[email protected]
|
|
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 c3c0c2e18d94 ("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: f55c73aef890 ("irqchip/pdc: Add PDC interrupt controller for QCOM SoCs")
Signed-off-by: Douglas Anderson <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Tested-by: Maulik Shah <[email protected]>
Reviewed-by: Maulik Shah <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Link: https://lore.kernel.org/r/20201211141514.v4.1.I2702919afc253e2a451bebc3b701b462b2d22344@changeid
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: John Garry <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: Thomas Gleixner <[email protected]>
Signed-off-by: John Garry <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Tested-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Tested-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: Marc Zyngier <[email protected]>
Tested-by: John Garry <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: a5b659bd4bc7 ("irqchip/ti-sci-intr: Add support for INTR being a parent to INTR")
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: 5c4b585d2910 ("irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC")
Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Jason Cooper <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
|
|
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 c5e5ec033c4ab25c53f1fd217849e75deb0bf7bf.
Signed-off-by: Valentin Schneider <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: Valentin Schneider <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
This patch extends irqchip driver for oceleot to be used with other
vcoreiii base platforms.
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
controllers
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: Gregory CLEMENT <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Convert device tree bindings for Microsemi Ocelot SoC ICPU Interrupt
Controller to YAML format
Signed-off-by: Gregory CLEMENT <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: e6b78f2c3e14 ("irqchip: Add the Alpine MSIX interrupt controller")
Signed-off-by: Marc Zyngier <[email protected]>
Reviewed-by: Antoine Tenart <[email protected]>
Cc: Tsahee Zidenberg <[email protected]>
Cc: Antoine Tenart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Update bindings for Layerscape external irqs,
support more SoCs(LS1043A, LS1046A, LS1088A,
LS208xA, LX216xA)
Signed-off-by: Biwen Li <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Acked-by: Rob Herring <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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 <[email protected]>
Signed-off-by: Biwen Li <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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: a93f1d903fa34fc2c5d9fa450bd ("irqchip: Add driver for Loongson-3 HyperTransport PIC controller")
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Fix a capitalization typo.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|