- 27 Aug, 2015 3 commits
-
-
Marc Zyngier authored
So far, GICv2 has been used with EOImode == 0. The effect of this mode is to perform the priority drop and the deactivation of the interrupt at the same time. While this works perfectly for Linux (we only have a single priority), it causes issues when an interrupt is forwarded to a guest, and when we want the guest to perform the EOI itself. For this case, the GIC architecture provides EOImode == 1, where: - A write to the EOI register drops the priority of the interrupt and leaves it active. Other interrupts at the same priority level can now be taken, but the active interrupt cannot be taken again - A write to the DIR marks the interrupt as inactive, meaning it can now be taken again. We only enable this feature when booted in HYP mode and that the device-tree reported a suitable CPU interface. Observable behaviour should remain unchanged. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Reviewed-and-tested-by:
Eric Auger <eric.auger@linaro.org> Cc: Christoffer Dall <christoffer.dall@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: kvmarm@lists.cs.columbia.edu Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1440604845-28229-4-git-send-email-marc.zyngier@arm.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Marc Zyngier authored
Commit 0a4377de ("genirq: Introduce irq_set_vcpu_affinity() to target an interrupt to a VCPU") added just what we needed at the lowest level to allow an interrupt to be deactivated by a guest. When such a request reaches the GIC, it knows it doesn't need to perform the deactivation anymore, and can safely leave the guest do its magic. This of course requires additional support in both VFIO and KVM. Signed-off-by:
-
Marc Zyngier authored
So far, GICv3 has been used in with EOImode == 0. The effect of this mode is to perform the priority drop and the deactivation of the interrupt at the same time. While this works perfectly for Linux (we only have a single priority), it causes issues when an interrupt is forwarded to a guest, and when we want the guest to perform the EOI itself. For this case, the GIC architecture provides EOImode == 1, where: - A write to ICC_EOIR1_EL1 drops the priority of the interrupt and leaves it active. Other interrupts at the same priority level can now be taken, but the active interrupt cannot be taken again - A write to ICC_DIR_EL1 marks the interrupt as inactive, meaning it can now be taken again. This patch converts the driver to be able to use this new mode, depending on whether or not the kernel can behave as a hypervisor. No feature change. Signed-off-by:
-
- 24 Aug, 2015 1 commit
-
-
Shenwei Wang authored
IMX7D contains a new version of GPC IP block (GPCv2). It has two major functions: power management and wakeup source management. When the system is in WFI (wait for interrupt) mode, the GPC block will be the first block on the platform to be activated and signaled. In normal wait mode during cpu idle, the system can be woken up by any enabled interrupts. In standby or suspend mode, the system can only be wokem up by the pre-defined wakeup sources. Based-on-patch-by:
Anson Huang <b20788@freescale.com> Signed-off-by:
Shenwei Wang <shenwei.wang@freescale.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: <shawn.guo@linaro.org> Cc: <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1440443055-7291-1-git-send-email-shenwei.wang@freescale.comSigned-off-by:
-
- 20 Aug, 2015 4 commits
-
-
Eric Anholt authored
This interrupt controller is the new root interrupt controller with the timer, PMU events, and IPIs, and the bcm2835's interrupt controller is chained off of it to handle the peripherals. I wrote the interrupt chip support, while Andrea Merello wrote the IPI code. Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Stephen Warren <swarren@wwwdotorg.org> Cc: linux-rpi-kernel@lists.infradead.org Cc: Lee Jones <lee@kernel.org> Cc: Jason Cooper <jason@lakedaemon.net> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1438902033-31477-5-git-send-email-eric@anholt.netSigned-off-by:
-
Eric Anholt authored
This is a new per-cpu root interrupt controller on the Raspberry Pi 2, which will chain to the bcm2835 interrupt controller for peripheral interrupts. Signed-off-by:
-
Eric Anholt authored
The BCM2836 (Raspberry Pi 2) uses two levels of interrupt handling with the CPU-local interrupts being the root, so we need to register ours as chained off of the CPU's local interrupt. Signed-off-by:
-
Eric Anholt authored
For BCM2836, we want to chain into this IRQ chip from the root controller, and for chaining we need to do something else instead of handle_IRQ() once we have decoded the IRQ. Note that this changes the behavior a little bit: Previously for a non-shortcut IRQ, we'd loop reading and handling the second level IRQ status until it was cleared before returning to the loop reading the top level IRQ status (Note that the top level bit is just an OR of the low level bits). For the expected case of just one interrupt to be handled, this was an extra register read, so we're down from 4 to 3 reads. Signed-off-by:
-
- 18 Aug, 2015 1 commit
-
-
Jiang Liu authored
There's a typo in commit e39758e0 in linux-next, which incorrectly spells "msi_desc_to_pci_sysdata()" as "msi_desc_to_pci_sys_data()" and causes build failure: > ../drivers/pci/host/pcie-xilinx.c:235:3: error: implicit declaration of function 'msi_desc_to_pci_sys_data' [-Werror=implicit-function-declaration] Fixes: e39758e0 "PCI: Use helper functions to access fields in struct msi_desc" Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Mark Brown <broonie@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com> Cc: Srikanth Thokala <sthokal@xilinx.com> Cc: Rob Herring <robh@kernel.org> Cc: Yijing Wang <wangyijing@huawei.com> Link: http://lkml.kernel.org/r/1439912763-10645-1-git-send-email-jiang.liu@linux.intel.comSigned-off-by:
-
- 04 Aug, 2015 2 commits
-
-
Jon Hunter authored
Commit 32289506 ("irqchip: gic: Preserve gic V2 bypass bits in cpu ctrl register") added a new function, gic_cpu_if_up(), to program the GIC CPU_CTRL register. This function assumes that there is only one GIC instance present and hence always uses the chip data for the primary GIC controller. Although it is not common for there to be a secondary, some devices do support a secondary. Therefore, fix this by passing gic_cpu_if_up() a pointer to the appropriate chip data structure. Similarly, the function gic_cpu_if_down() only assumes that there is a single GIC instance present. Update this function so that an instance number is passed for the appropriate GIC and return an error code on failure. The vexpress TC2 (which has a single GIC) is currently the only user of this function and so update it accordingly. Note that because the TC2 only has a single GIC, the call to gic_cpu_if_down() should always be successful. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Reviewed-by:
-
Jon Hunter authored
The gic_init_bases() function initialises an array that stores the mapping between the GIC and CPUs. This array is a global array that is unconditionally initialised on every call to gic_init_bases(). Although, it is not common for there to be more than one GIC instance, there are some devices that do support nested GIC controllers and gic_init_bases() can be called more than once. A 2nd call to gic_init_bases() will clear the previous CPU mapping and will only setup the mapping again for the CPU calling gic_init_bases(). Fix this by only allowing the CPU map to be configured for the primary GIC. For secondary GICs the CPU map is not relevant because these GICs do not directly route the interrupts to the main CPU(s) but to other GICs or devices. Signed-off-by:
-
- 01 Aug, 2015 4 commits
-
-
Thomas Gleixner authored
Chained irq handlers usually set up handler data as well. We now have a function to set both under irq_desc->lock. Replace the two calls with one. Search and conversion was done with coccinelle. Reported-by:Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by:
-
- 31 Jul, 2015 12 commits
-
-
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Jiang Liu authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
-
Jiang Liu authored
Use helper function irq_data_get_irq_handler_data() to hide irq_desc implementation details. This allows to move irq_data->handler_data to irq_data_common, once all usage sites are converted. Signed-off-by:
-
Jiang Liu authored
Use access helper irq_data_get_affinity_mask() to hide implementation details of struct irq_desc. Signed-off-by:
-
Jiang Liu authored
Use access helper irq_data_get_affinity_mask() to hide implementation details of struct irq_desc. Signed-off-by:
-
Thomas Gleixner authored
Make irq a local variable and retrieve domain from the irq descriptor which avoid a redundant lookup. Signed-off-by: -
Ralf Baechle authored
Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Joel Porquet authored
All drivers using the macro IRQCHIP_DECLARE have been converted to using global header include/linux/irqchip.h. Local header drivers/irqchip/irqchip.h is now useless and can be removed. Signed-off-by:
Joel Porquet <joel@porquet.org> Cc: vgupta@synopsys.com Cc: monstr@monstr.eu Cc: ralf@linux-mips.org Cc: jason@lakedaemon.net Link: http://lkml.kernel.org/r/2818400.nekF4hg2Ig@joel-zenbookSigned-off-by:
-
Joel Porquet authored
The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h'. See commit 91e20b50 ("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h"). This patch removes inclusions of private header 'drivers/irqchip/irqchip.h'and replaces them with the inclusion of 'include/linux/irqchip.h'. Signed-off-by:
-
Joel Porquet authored
The IRQCHIP_DECLARE macro migrated to 'include/linux/irqchip.h'. See commit 91e20b50 ("irqchip: Move IRQCHIP_DECLARE macro to include/linux/irqchip.h"). This patch removes the inclusion of private header 'drivers/irqchip/irqchip.h' and replaces it with the inclusion of 'include/linux/irqchip.h'. Signed-off-by:
-
- 29 Jul, 2015 13 commits
-
-
Marc Zyngier authored
The only three users of that field are not using the msi_controller structure anymore, so drop it altogether. Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Marc Zyngier authored
The X-Gene MSI driver only uses the msi_controller structure as a way to match the host bridge with its MSI HW, and thus the msi_domain. But now that we can directly associate an msi_domain with a device, there is no use keeping this msi_controller around. Just remove all traces of msi_controller from the driver. Tested-by:
Duc Dang <dhdang@apm.com> Acked-by:
-
Marc Zyngier authored
In order to support non-PCI MSI with GICv2m, add the minimal required entry points for the MSI domain, which is actually almost nothing (we just use the defaults provided by the core code). Signed-off-by:
-
Marc Zyngier authored
GICv2m only uses the msi_controller structure as a way to match the host bridge with its MSI HW, and thus the msi_domain. But now that we can directly associate an msi_domain with a device, there is no use keeping this msi_controller around. Just remove all traces of msi_controller from the driver. Also tag the inner (non-PCI) domain with DOMAIN_BUS_NEXUS. Signed-off-by:
-
Marc Zyngier authored
In order to support non-PCI MSI with the GICv3 ITS, add the minimal required entry points for the MSI domain (an msi_prepare implementation). The rest is only boilerplate code to find the raw ITS domain. Signed-off-by:
-
Marc Zyngier authored
We can now lookup the base ITS domain, making it possible to initialize the PCI/MSI code independently from the main ITS subsystem. This allows us to remove all the previously add hooks. Signed-off-by:
-
Marc Zyngier authored
The GICv3 ITS only uses the msi_controller structure as a way to match the host bridge with its MSI HW, and thus the msi_domain. But now that we can directly associate an msi_domain with a device, there is no use keeping this msi_controller around. Just remove all traces of msi_controller from the driver. Signed-off-by:
-
Marc Zyngier authored
Now that we can distinguish between multiple domains carrying the same device_node, tag the raw ITS domain with DOMAIN_BUS_NEXUS. This will allow MSI providers built on top of the raw ITS domain to identify it. Signed-off-by:
-
Marc Zyngier authored
It is becoming obvious that having the PCI/MSI code in the same file as the the core ITS code is giving people implementing non-PCI MSI support the wrong kind of idea. In order to make things a bit clearer, let's move the PCI/MSI code out to its own file. Hopefully it will make it clear that whoever thinks of hooking into the core ITS better have a very strong point. We use a temporary entry point that will get removed in a subsequent patch, once the proper infrastructure is added. Signed-off-by:
-
Marc Zyngier authored
Some IRQ domains are not designed to directly provide interrupts to devices, but strictly to be used by other domains. An example of this is the GICv3 ITS, which is completely bus agnostic, and on which it is possible to implement a PCI/MSI domain. Just introduce the irq_domain_bus_token property for now. Signed-off-by:
-
Marc Zyngier authored
With the msi_list and the msi_domain properties now being at the generic device level, it is starting to be relatively easy to offer a generic way of providing non-PCI MSIs. The two major hurdles with this idea are: - Lack of global ID that identifies a device: this is worked around by having a global ID allocator for each device that gets enrolled in the platform MSI subsystem - Lack of standard way to write the message in the generating device. This is solved by mandating driver code to provide a write_msg callback, so that everyone can have their own square wheel Apart from that, the API is fairly straightforward: - platform_msi_create_irq_domain creates an MSI domain that gets tagged with DOMAIN_BUS_PLATFORM_MSI - platform_msi_domain_alloc_irqs allocate MSIs for a given device, populating the msi_list - platform_msi_domain_free_irqs does what is written on the tin [ tglx: Created a seperate struct platform_msi_desc and added kerneldoc entries ] Signed-off-by:
-
Marc Zyngier authored
As for PCI, we're able to populate the msi_domain field at probe time, provided that the device tree has an "msi-parent" property. Signed-off-by:
-
Marc Zyngier authored
Now that we can easily find which MSI domain a PCI device is using, use dev_get_msi_domain as a way to retrieve the information. The original code is still used as a fallback. Acked-by:
Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by:
-
