- 31 Jul, 2015 2 commits
-
-
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 <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/3357968.0IznKtY3Q9@joel-zenbookSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
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 29 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 <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Yijing Wang <wangyijing@huawei.com> Cc: Ma Jun <majun258@huawei.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Duc Dang <dhdang@apm.com> Cc: Hanjun Guo <hanjun.guo@linaro.org> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1438091186-10244-20-git-send-email-marc.zyngier@arm.comSigned-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:
-
Marc Zyngier authored
A number of platforms do not need to use the msi-parent property, as the host bridge itself provides the MSI controller. Allow this configuration by performing an irq domain lookup based on the host bridge node if it doesn't have a valid msi-parent property. Acked-by:
-
Marc Zyngier authored
In order to populate the PCI host bridge msi_domain, use the "msi-parent" attribute to lookup a corresponding irq domain. If found, this is our MSI domain. This gets plugged into the core PCI code. Acked-by:
-
Marc Zyngier authored
In order to be able to populate the device msi_domain field, add the necessary hooks to propagate the host bridge msi_domain across secondary busses to devices. So far, nobody populates the initial msi_domain. Acked-by:
-
Marc Zyngier authored
As MSI-type features are creeping into non-PCI devices, it is starting to make sense to give our struct device some form of support for this, by allowing a pointer to an MSI irq domain to be set/retrieved. Reviewed-by:
-
Marc Zyngier authored
When creating a PCI/MSI domain, tag it with DOMAIN_BUS_PCI_MSI so that it can be looked-up using irq_find_matching_host(). Acked-by:
-
Marc Zyngier authored
It is not uncommon (at least with the ARM stuff) to have a piece of hardware that implements different flavours of "interrupts". A typical example of this is the GICv3 ITS, which implements standard PCI/MSI support, but also some form of "generic MSI". So far, the PCI/MSI domain is registered using the ITS device_node, so that irq_find_host can return it. On the contrary, the raw MSI domain is not registered with an device_node, making it impossible to be looked up by another subsystem (obviously, using the same device_node twice would only result in confusion, as it is not defined which one irq_find_host would return). A solution to this is to "type" domains that may be aliasing, and to be able to lookup an device_node that matches a given type. For this, we introduce irq_find_matching_host() as a superset of irq_find_host: struct irq_domain *irq_find_matching_host(struct device_node *node, enum irq_domain_bus_token bus_token); where bus_token is the "type" we want to match the domain against (so far, only DOMAIN_BUS_ANY is defined). This result in some moderately invasive changes on the PPC side (which is the only user of the .match method). This has otherwise no functionnal change. Reviewed-by: -
Masanari Iida authored
The following warning is emitted for make xmldocs: Warning(.//kernel/irq/chip.c:1009): No description found for parameter 'vcpu_info' Warning(.//kernel/irq/chip.c:1009): Excess function parameter 'dest' description in 'irq_chip_set_vcpu_affinity_parent' Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Link: http://lkml.kernel.org/r/1438164576-5945-1-git-send-email-standby24x7@gmail.comSigned-off-by:
-
Thomas Gleixner authored
Pull in upstream fixes before applying conflicting changes
-
Jiang Liu authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Cc: Chris Zankel <chris@zankel.net> Link: http://lkml.kernel.org/r/20150713172018.264485572@linutronix.deSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Jiang Liu authored
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by:
-
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:
-
Jiang Liu authored
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Also replace generic_handle_irq with generic_handle_irq_desc() to avoid looking up irq_desc again. Signed-off-by:
-
Thomas Gleixner authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
-
Jiang Liu authored
This is a preparatory patch for refactoring the internals if irq_data. Signed-off-by:
-
Jiang Liu authored
Use accessor irq_data_get_node() to hide struct irq_data implementation detail, so we can move irq_data->node to irq_data_common once all usage sites are fixed. Signed-off-by:
-
- 27 Jul, 2015 9 commits
-
-
Thomas Gleixner authored
__irq_set_chip_handler_name_locked() is about to be replaced. Use irq_set_chip_handler_name_locked() instead. Signed-off-by:
-
Jiang Liu authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
-
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:
-
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and update was done with coccinelle. Signed-off-by:
-
Jiang Liu authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
-
Jiang Liu authored
This is a preparatory patch for moving irq_data struct members. Signed-off-by:
-
Florian Fainelli authored
Our irq-bcm7120-l2 interrupt controller driver utilizes the same handler function for the different parent interrupts it services: UPG_MAIN, UPG_BSC for instance. The problem is that function reads the IRQSTAT register which can combine interrupt causes for different parent interrupts, such that we can end-up in the following situation: - CPU takes an interrupt - bcm7120_l2_intc_irq_handle() reads IRQSTAT - generic_handle_irq() is invoked - there are still pending interrupts flagged in IRQSTAT from a different parent - handle_bad_irq() is invoked for these since they come from a different irq_desc/irq In order to fix this, make sure that we always mask IRQSTAT with the appropriate bits that correspond go the parent interrupt source this is coming from. To simplify things, associate an unique structure per parent interrupt handler to avoid multiplying the number of lookups. Fixes: a5042de2 ("irqchip: bcm7120-l2: Add Broadcom BCM7120-style Level 2 interrupt controller") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Cc: linux-mips@linux-mips.org Cc: cernekee@gmail.com Cc: jason@lakedaemon.net Cc: bcm-kernel-feedback-list@broadcom.com Cc: gregory.0xf0@gmail.com Cc: computersforpeace@gmail.com Link: http://lkml.kernel.org/r/1437691941-3100-1-git-send-email-f.fainelli@gmail.comSigned-off-by:
-
Brian Norris authored
Make use of the new irq_chip_generic suspend/resume callbacks. This is required because if there are no installed child IRQs for this chip, the irq_chip::irq_{suspend,resume} functions will not be called. However, we still need to save/restore the forwarding mask, to enable the top-level GIC interrupt; otherwise, we lose UART output after S3 resume. In addition to refactoring the callbacks, we have to self-initialize the mask cache, since the genirq core also doesn't initialize this until the first child IRQ is installed. The original problem report is described in extra detail here: http://lkml.kernel.org/g/20150619224123.GL4917@ld-irv-0074Signed-off-by:Brian Norris <computersforpeace@gmail.com> Tested-by:
-
Brian Norris authored
Some (admittedly odd) irqchips perform functions that are not directly related to any of their child IRQ lines, and therefore need to perform some tasks during suspend/resume regardless of whether there are any "installed" interrupts for the irqchip. However, the current generic-chip framework does not call the chip's irq_{suspend,resume} when there are no interrupts installed (this makes sense, because there are no irq_data objects for such a call to be made). More specifically, irq-bcm7120-l2 configures both a forwarding mask (which affects other top-level GIC IRQs) and a second-level interrupt mask (for managing its own child interrupts). The former must be saved/restored on suspend/resume, even when there's nothing to do for the latter. This patch adds a new set of suspend/resume hooks to irq_chip_generic, to help represent *chip* suspend/resume, rather than IRQ suspend/resume. These callbacks will always be called for an IRQ chip (regardless of the installed interrupts) and are based on the per-chip irq_chip_generic struct, rather than the per-IRQ irq_data struct. The original problem report is described in extra detail here: http://lkml.kernel.org/g/20150619224123.GL4917@ld-irv-0074Signed-off-by:
-
