aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/exported-sql-viewer.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2019-11-16genirq: Introduce irq_chip_get/set_parent_state callsMaulik Shah2-0/+50
On certain QTI chipsets some GPIOs are direct-connect interrupts to the GIC to be used as regular interrupt lines. When the GPIOs are not used for interrupt generation the interrupt line is disabled. But disabling the interrupt at GIC does not prevent the interrupt to be reported as pending at GIC_ISPEND. Later, when drivers call enable_irq() on the interrupt, an unwanted interrupt occurs. Introduce get and set methods for irqchip's parent to clear it's pending irq state. This then can be invoked by the GPIO interrupt controller on the parents in it hierarchy to clear the interrupt before enabling the interrupt. Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1573855915-9841-7-git-send-email-ilina@codeaurora.org [updated commit text and minor code fixes]
2019-11-16irqdomain: Add bus token DOMAIN_BUS_WAKEUPLina Iyer1-0/+1
A single controller can handle normal interrupts and wake-up interrupts independently, with a different numbering space. It is thus crucial to allow the driver for such a controller discriminate between the two. A simple way to do so is to tag the wake-up irqdomain with a "bus token" that indicates the wake-up domain. This slightly abuses the notion of bus, but also radically simplifies the design of such a driver. Between two evils, we choose the least damaging. Suggested-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Lina Iyer <ilina@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1573855915-9841-2-git-send-email-ilina@codeaurora.org
2019-11-11irqchip/ti-sci-inta: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))Markus Elfring1-2/+3
A coccicheck run provided information like the following. drivers/irqchip/irq-ti-sci-inta.c:250:9-16: WARNING: ERR_CAST can be used with vint_desc. Generated by: scripts/coccinelle/api/err_cast.cocci Thus adjust the exception handling in one if branch. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/776b7135-26af-df7d-c3a9-4339f7bf1f15@web.de
2019-11-10irqchip: Ingenic: Add process for more than one irq at the same time.Zhou Yanjie1-6/+11
Add process for the situation that more than one irq is coming to a single chip at the same time. The original code will only respond to the lowest setted bit in JZ_REG_INTC_PENDING, and then exit the interrupt dispatch function. After exiting the interrupt dispatch function, since the second interrupt has not yet responded, the interrupt dispatch function is again entered to process the second interrupt. This creates additional unnecessary overhead, and the more interrupts that occur at the same time, the more overhead is added. The improved method in this patch is to check whether there are still unresponsive interrupts after processing the lowest setted bit interrupt. If there are any, the processing will be processed according to the bit in JZ_REG_INTC_PENDING, and the interrupt dispatch function will be exited until all processing is completed. Signed-off-by: Zhou Yanjie <zhouyanjie@zoho.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/1570015525-27018-6-git-send-email-zhouyanjie@zoho.com
2019-11-10irqchip: ingenic: Alloc generic chips from IRQ domainPaul Cercueil1-13/+17
By creating the generic chips from the IRQ domain, we don't rely on the JZ4740_IRQ_BASE macro. It also makes the code a bit cleaner. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1570015525-27018-5-git-send-email-zhouyanjie@zoho.com
2019-11-10irqchip: ingenic: Get virq number from IRQ domainPaul Cercueil1-1/+6
Get the virq number from the IRQ domain instead of calculating it from the hardcoded irq base. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1570015525-27018-4-git-send-email-zhouyanjie@zoho.com
2019-11-10irqchip: ingenic: Error out if IRQ domain creation failedPaul Cercueil1-5/+10
If we cannot create the IRQ domain, the driver should fail to probe instead of succeeding with just a warning message. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1570015525-27018-3-git-send-email-zhouyanjie@zoho.com
2019-11-10irqchip: ingenic: Drop redundant irq_suspend / irq_resume functionsPaul Cercueil2-37/+1
The same behaviour can be obtained by using the IRQCHIP_MASK_ON_SUSPEND flag on the IRQ chip. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/1570015525-27018-2-git-send-email-zhouyanjie@zoho.com
2019-11-10irqchip: Place CONFIG_SIFIVE_PLIC into the menuJonathan Neuschäfer1-2/+2
Somehow CONFIG_SIFIVE_PLIC ended up outside of the "IRQ chip support" menu. Fixes: 8237f8bc4f6e ("irqchip: add a SiFive PLIC driver") Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Palmer Dabbelt <palmer@sifive.com> Acked-by: Palmer Dabbelt <palmer@sifive.com> Link: https://lore.kernel.org/r/20191002144452.10178-1-j.neuschaefer@gmx.net
2019-11-10irqchip/gic-v3-its: Make vlpi_lock a spinlockMarc Zyngier1-9/+9
The VLPI map is currently a mutex, and that's a bad idea as this lock can be taken in non-preemptible contexts. Convert it to a raw spinlock, and turn the memory allocation of the VLPI map to be atomic. Reported-by: Heyi Guo <guoheyi@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191108165805.3071-12-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Lock VLPI map array before translating itMarc Zyngier1-2/+4
Obtaining the mapping ivformation for a VLPI should always be done with the vlpi_lock for this device held. Otherwise, we expose ourselves to races against a concurrent unmap. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191108165805.3071-11-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Synchronise INT/CLEAR commands targetting a VLPI using VSYNCMarc Zyngier1-4/+75
We have so far always injected/cleared VLPIs using either INT+SYNC or CLEAR+SYNC sequences, but that's pretty wrong for two reasons: - SYNC only synchronises physical LPIs - The collection ID that for the associated LPI doesn't match the redistributor the vPE is associated with Instead, send an {INT,CLEAR}+VSYNC for forwarded LPIs, ensuring that the ITS synchronises against the virtual pending table. Reported-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191108165805.3071-10-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Synchronise INV command targetting a VLPI using VSYNCMarc Zyngier1-1/+35
We have so far alwways invalidated VLPIs usinc an INV+SYNC sequence, but that's pretty wrong for two reasons: - SYNC only synchronises physical LPIs - The collection ID that for the associated LPI doesn't match the redistributor the vPE is associated with Instead, send an INV+VSYNC for forwarded LPIs, ensuring that the ITS can properly synchronise the invalidation of VLPIs. Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling") Reported-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191108165805.3071-9-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Add its_vlpi_map helpersMarc Zyngier1-15/+32
Obtaining the mapping information for a VLPI is something quite common, and the GICv4.1 code is going to make even more use of it. Expose it as a separate set of helpers. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-8-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-8-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Kill its->device_ids and use TYPER copy insteadMarc Zyngier2-12/+14
Now that we have a copy of TYPER in the ITS structure, rely on this to provide the same service as its->device_ids, which gets axed. Errata workarounds are now updating the cached fields instead of requiring a separate field in the ITS structure. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-7-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-7-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Kill its->ite_size and use TYPER copy insteadMarc Zyngier2-5/+5
Now that we have a copy of TYPER in the ITS structure, rely on this to provide the same service as its->ite_size, which gets axed. Errata workarounds are now updating the cached fields instead of requiring a separate field in the ITS structure. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-6-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-6-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Make is_v4 use a TYPER copyMarc Zyngier1-12/+14
Instead of caching the GICv4 compatibility in a discrete way, cache the TYPER register instead, which can then be used to implement the same functionnality. This will get used more extensively in subsequent patches. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-5-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-5-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Allow LPI invalidation via the DirectLPI interfaceMarc Zyngier1-8/+32
We currently don't make much use of the DirectLPI feature, and it would be beneficial to do this more, if only because it becomes a mandatory feature for GICv4.1. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-4-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-4-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Factor out wait_for_syncr primitiveMarc Zyngier1-6/+9
Waiting for a redistributor to have performed an operation is a common thing to do, and the idiom is already spread around. As we're going to make even more use of this, let's have a primitive that does just that. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191027144234.8395-3-maz@kernel.org Link: https://lore.kernel.org/r/20191108165805.3071-3-maz@kernel.org
2019-11-10irqchip/gic-v3-its: Free collection mapping on device teardownMarc Zyngier1-1/+1
We allocate the collection mapping on device creation, but somehow free it on the irqdomain free path, which is pretty inconsistent and has led to bugs in the past. Move it to the point where we teardown the device, making the alloc/free symetric. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20191108165805.3071-2-maz@kernel.org
2019-11-10dt-bindings: qcom,pdc: Add compatible for sc7180Rajendra Nayak1-1/+2
Add the compatible string for sc7180 SoC from Qualcomm. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20191108092824.9773-8-rnayak@codeaurora.org
2019-11-10drivers: irqchip: qcom-pdc: Move to an SoC independent compatibleRajendra Nayak1-1/+1
Remove the sdm845 SoC specific compatible to make the driver easily reusable across other SoC's with the same IP block. This will reduce further churn adding any SoC specific compatibles unless really needed. Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lina Iyer <ilina@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20191108092824.9773-7-rnayak@codeaurora.org
2019-11-10irqchip: Add support for Layerscape external interrupt linesRasmus Villemoes3-0/+202
The LS1021A allows inverting the polarity of six interrupt lines IRQ[0:5] via the scfg_intpcr register, effectively allowing IRQ_TYPE_LEVEL_LOW and IRQ_TYPE_EDGE_FALLING for those. We just need to check the type, set the relevant bit in INTPCR accordingly, and fixup the type argument before calling the GIC's irq_set_type. In fact, the power-on-reset value of the INTPCR register on the LS1021A is so that all six lines have their polarity inverted. Hence any hardware connected to those lines is unusable without this: If the line is indeed active low, the generic GIC code will reject an irq spec with IRQ_TYPE_LEVEL_LOW, while if the line is active high, we must obviously disable the polarity inversion (writing 0 to the relevant bit) before unmasking the interrupt. Some other Layerscape SOCs (LS1043A, LS1046A) have a similar feature, just with a different number of external interrupt lines (and a different POR value for the INTPCR register). This driver should be prepared for supporting those by properly filling out the device tree node. I have the reference manuals for all three boards, but I've only tested the driver on an LS1021A. Unfortunately, the Kconfig symbol ARCH_LAYERSCAPE only exists on arm64, so do as is done for irq-ls-scfg-msi.c: introduce a new symbol which is set when either ARCH_LAYERSCAPE or SOC_LS1021A is set. Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20191107122115.6244-3-linux@rasmusvillemoes.dk