- 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:
Marc Zyngier <marc.zyngier@arm.com> Cc: <linux-arm-kernel@lists.infradead.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Jason Cooper <jason@lakedaemon.net> Link: http://lkml.kernel.org/r/1438332252-25248-2-git-send-email-jonathanh@nvidia.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
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 <jiang.liu@linux.intel.com> Cc: David S. Miller <davem@davemloft.net> Link: http://lkml.kernel.org/r/1433145945-789-27-git-send-email-jiang.liu@linux.intel.comSigned-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 22 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:
-
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:
Ingo Molnar <mingo@kernel.org>
-
