Migrate GIC to fasteoi flow control
cover Migrate GIC to fasteoi flow control
Hello,
The following patchset updates the GIC code to use fasteoi as the method of flow control. This is important because it removes accesses to the distributor (which are expensive in a virtualised system) from the critical interrupt path.
Changing the GIC irq_chip structure means updating all of the chained IRQ handlers which use the GIC as their primary controller. I believe I've done that in the patches below, but I would appreciate feedback and/or acked-bys from the platform people to confirm that I've got it right. It's not easy code to follow and it looks like some of the chained handlers are designed to work with multiple primary controllers.
Finally, if you think I've missed your platform then please shout!
Thanks,
Will
Will Deacon (5):
ARM: gic: use handle_fasteoi_irq for SPIs
ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
ARM: s5pv310: update IRQ combiner to use EOI in parent chip
ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
arch/arm/common/gic.c | 23 +++++++++-------------- arch/arm/mach-msm/gpio-v2.c | 2 +- arch/arm/mach-s5pv310/irq-combiner.c | 7 ++----- arch/arm/mach-tegra/gpio.c | 17 +---------------- arch/arm/plat-omap/gpio.c | 5 ++++- 5 files changed, 17 insertions(+), 37 deletions(-)
PATCH 1/5 ARM: gic: use handle_fasteoi_irq for SPIs
Currently, the gic uses handle_level_irq for handling SPIs (Shared Peripheral Interrupts), requiring active interrupts to be masked at the distributor level during IRQ handling.
On a virtualised system, only the CPU interfaces are virtualised in hardware. Accesses to the distributor must be trapped by the hypervisor, adding latency to the critical interrupt path in Linux.
This patch modifies the GIC code to use handle_fasteoi_irq for handling interrupts, which only requires us to signal EOI to the CPU interface when handling is complete. Cascaded IRQ handling is also updated so that EOI is signalled after handling.
Note that commit 846afbd1 ("GIC: Dont disable INT in ack callback") broke cascading interrupts by forgetting to add IRQ masking. This is no longer an issue because the unmask call is now unnecessary.
Tested on Versatile Express and Realview EB (1176 w/ cascaded GICs).
--- arch/arm/common/gic.c | 23 +++++++++-------------- 1 files changed, 9 insertions(+), 14 deletions(-)
arch/arm/common/gic.c +9 -14
@@ -71,13 +71,6 @@ static inline unsigned int gic_irq(struct irq_data *d)/* * Routines to acknowledge, disable and enable interrupts */ -static void gic_ack_irq (struct irq_data *d) -{ -spin_lock (&irq_controller_lock); -writel (gic_irq (d),gic_cpu_base (d) +GIC_CPU_EOI ); -spin_unlock (&irq_controller_lock); -} -static void gic_mask_irq (struct irq_data *d) {u32 mask =1 << (d->irq %32 );
@@ -96,6 +89,11 @@ static void gic_unmask_irq(struct irq_data *d)spin_unlock (&irq_controller_lock); } +static void gic_eoi_irq (struct irq_data *d) +{ +writel (gic_irq (d),gic_cpu_base (d) +GIC_CPU_EOI ); +} +static int gic_set_type (struct irq_data *d,unsigned int type) {void __iomem *base =gic_dist_base (d);
@@ -174,9 +172,6 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)unsigned int cascade_irq, gic_irq;unsigned long status; -/* primary controller ack'ing */ - chip->irq_ack (&desc->irq_data); -spin_lock (&irq_controller_lock); status =readl (chip_data->cpu_base +GIC_CPU_INTACK );spin_unlock (&irq_controller_lock);
@@ -192,15 +187,15 @@ static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)generic_handle_irq (cascade_irq); out: -/* primary controller unmasking */ - chip->irq_unmask (&desc->irq_data); +/* primary controller EOI */ + chip->irq_eoi (&desc->irq_data); }static struct irq_chip gic_chip = { .name ="GIC" , - .irq_ack = gic_ack_irq, .irq_mask = gic_mask_irq, .irq_unmask = gic_unmask_irq, + .irq_eoi = gic_eoi_irq, .irq_set_type = gic_set_type, #ifdef CONFIG_SMP .irq_set_affinity = gic_set_cpu,
@@ -275,7 +270,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic,for (i = irq_start; i < irq_limit; i++) {set_irq_chip (i, &gic_chip);set_irq_chip_data (i, gic); -set_irq_handler (i, handle_level_irq); +set_irq_handler (i, handle_fasteoi_irq);set_irq_flags (i,IRQF_VALID |IRQF_PROBE ); }
Signature · 1 line
1.7.0.4
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
In reply to Will DeaconOn OMAP4, gpio_irq_handler can be chained to a physical interrupt using the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow model, the chained handler must invoke ->irq_eoi once handling is complete.
This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.
--- arch/arm/plat-omap/gpio.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)
arch/arm/plat-omap/gpio.c +4 -1
@@ -1144,7 +1144,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc)u32 retrigger =0 ;int unmasked =0 ; - desc->irq_data.chip->irq_ack (&desc->irq_data); +if (desc->irq_data.chip->irq_ack) + desc->irq_data.chip->irq_ack (&desc->irq_data); bank =get_irq_data (irq);#ifdef CONFIG_ARCH_OMAP1
@@ -1238,6 +1239,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) exit:if (!unmasked) desc->irq_data.chip->irq_unmask (&desc->irq_data); +if (desc->irq_data.chip->irq_eoi) + desc->irq_data.chip->irq_eoi (&desc->irq_data); }static void gpio_irq_shutdown (struct irq_data *d)
Signature · 1 line
1.7.0.4
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 24 lines
-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com]
Sent: Monday, February 21, 2011 8:58 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux at arm.linux.org.uk; adharmap at codeaurora.org; rabin at rab.in; tglx at linutronix.de; catalin.marinas at arm.com; santosh.shilimkar at ti.com; ccross at google.com; kyungmin.park at samsung.com; Will Deacon
Subject: [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chipOn OMAP4,
gpio_irq_handlercan be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is complete.This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.
Quoted 4 lines
Cc Santosh Shilimkar <[email protected]>Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Thanks Will for changes. They look fine.
I will test your series tomorrow on OMAP with some GPIO interrupts.
Quoted 31 lines
arch/arm/plat-omap/gpio.c | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-)arch/arm/plat-omap/gpio.c +2
-1@@ -1144,7 +1144,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) u32 retrigger = 0;int unmasked =0 ; - desc->irq_data.chip->irq_ack (&desc->irq_data); +if (desc->irq_data.chip->irq_ack) + desc->irq_data.chip->irq_ack (&desc->irq_data); bank =get_irq_data (irq);#ifdef
CONFIG_ARCH_OMAP1arch/arm/plat-omap/gpio.c +2
-0@@ -1238,6 +1239,8 @@ static void gpio_irq_handler(unsigned int irq, struct irq_desc *desc) exit:if (!unmasked) desc->irq_data.chip->irq_unmask (&desc->irq_data); +if (desc->irq_data.chip->irq_eoi) + desc->irq_data.chip->irq_eoi (&desc->irq_data); }static void
gpio_irq_shutdown(struct irq_data *d)
--
1.7.0.4
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
Will,
Quoted 38 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Tuesday, February 22, 2011 12:45 AM
To: Will Deacon; linux-arm-kernel at lists.infradead.org
Cc: linux at arm.linux.org.uk; adharmap at codeaurora.org; rabin at rab.in; tglx at linutronix.de; catalin.marinas at arm.com; ccross at google.com; kyungmin.park at samsung.com
Subject: RE: [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chipQuoted 24 lines
-----Original Message-----
From: Will Deacon [mailto:will.deacon at arm.com]
Sent: Monday, February 21, 2011 8:58 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux at arm.linux.org.uk; adharmap at codeaurora.org; rabin at rab.in; tglx at linutronix.de; catalin.marinas at arm.com; santosh.shilimkar at ti.com; ccross at google.com; kyungmin.park at samsung.com; Will Deacon
Subject: [PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chipOn OMAP4,
gpio_irq_handlercan be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is complete.This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.Quoted 4 lines
Cc Santosh Shilimkar <[email protected]>Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Quoted 6 lines
Thanks Will for changes. They look fine.
I will test your series tomorrow on OMAP with some GPIO interrupts.
Tested your series on OMAP4 SDP, where GPIO is used for ethernet interrupts. They seems to work as expected. For omap changes,
Regards,
Santosh
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
Hi Santosh,
Quoted 20 lines
Quoted 20 lines
Quoted 13 lines
On OMAP4,
gpio_irq_handlercan be chained to a physical interrupt using
the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow
model, the chained handler must invoke ->irq_eoi once handling is complete.This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler
for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.Quoted 4 lines
Cc Santosh Shilimkar <[email protected]>Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>---
Thanks Will for changes. They look fine.
Quoted 7 lines
Quoted 3 lines
I will test your series tomorrow on OMAP with some GPIO interrupts.
Tested your series on OMAP4 SDP, where GPIO is used for ethernet interrupts. They seems to work as expected. For omap changes,
Tested-by Santosh Shilimkar <[email protected]>
That's good news, thanks! One down, three to go...
Will
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
In reply to Will DeaconQuoted 5 lines · Will Deacon
On OMAP4,
gpio_irq_handlercan be chained to a physical interrupt using the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow model, the chained handler must invoke ->irq_eoi once handling is complete.
Quoted 8 lines
This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.
Cc Santosh Shilimkar <[email protected]>Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>
PATCH 2/5 ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 11 lines · Will Deacon
Quoted 10 lines
On OMAP4,
gpio_irq_handlercan be chained to a physical interrupt using the GIC as the primary IRQ chip. Now that the GIC uses the fasteoi flow model, the chained handler must invoke ->irq_eoi once handling is complete.This patch adds a conditional call to ->irq_eoi in the GPIO IRQ handler for OMAP platforms. For OMAP implementations using other primary interrupt controllers, the ->irq_ack call remains and is also made conditional on the support offered by the controller.
Quoted 5 lines
Quoted 3 lines
Cc Santosh Shilimkar <[email protected]>Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>Acked-by Tony Lindgren <[email protected]>
Thanks Tony, I'll add your ack.
Will
PATCH 3/5 ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
In reply to Will DeaconThe chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent chip prior to handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
--- arch/arm/mach-tegra/gpio.c | 17 +---------------- 1 files changed, 1 insertions(+), 16 deletions(-)
arch/arm/mach-tegra/gpio.c +1 -16
@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)struct tegra_gpio_bank *bank;int port;int pin; -int unmasked =0 ; - - desc->irq_data.chip->irq_ack (&desc->irq_data); bank =get_irq_data (irq);
@@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)for_each_set_bit (pin, &sta,8 ) {__raw_writel (1 << pin,GPIO_INT_CLR (gpio)); - -/* if gpio is edge triggered, clear condition -* before executing the hander so that we don't -* miss edges -*/ -if (lvl & (0x100 << pin)) { - unmasked =1 ; - desc->irq_data.chip->irq_unmask (&desc->irq_data); - } -generic_handle_irq (gpio_to_irq (gpio + pin)); } } -if (!unmasked) - desc->irq_data.chip->irq_unmask (&desc->irq_data); - + desc->irq_data.chip->irq_eoi (&desc->irq_data); }#ifdef CONFIG_PM
Signature · 1 line
1.7.0.4
PATCH 3/5 ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 50 lines · Will Deacon
The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent chip prior to handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>---
?arch/arm/mach-tegra/gpio.c | ? 17 +---------------- ?1 files changed, 1 insertions(+), 16 deletions(-)arch/arm/mach-tegra/gpio.c +1
-16@@ -219,9 +219,6 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc) ? ? ? ?struct tegra_gpio_bank *bank; ? ? ? ?int port; ? ? ? ?int pin; - ? ? ? int unmasked = 0; - - ? ? ? desc->irq_data.chip->irq_ack(&desc->irq_data); ? ? ? ?bank = get_irq_data(irq);@@ -233,23 +230,11 @@ static void tegra_gpio_irq_handler(unsigned int irq, struct irq_desc *desc) ? ? ? ? ? ? ? ?for_each_set_bit(pin, &sta, 8) { ? ? ? ? ? ? ? ? ? ? ? ?__raw_writel(1 << pin, GPIO_INT_CLR(gpio)); - - ? ? ? ? ? ? ? ? ? ? ? /* if gpio is edge triggered, clear condition - ? ? ? ? ? ? ? ? ? ? ? ?* before executing the hander so that we don't - ? ? ? ? ? ? ? ? ? ? ? ?* miss edges - ? ? ? ? ? ? ? ? ? ? ? ?*/ - ? ? ? ? ? ? ? ? ? ? ? if (lvl & (0x100 << pin)) { - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? unmasked = 1; - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? desc->irq_data.chip->irq_unmask(&desc->irq_data); - ? ? ? ? ? ? ? ? ? ? ? } - ? ? ? ? ? ? ? ? ? ? ? ?generic_handle_irq(gpio_to_irq(gpio + pin)); ? ? ? ? ? ? ? ?} ? ? ? ?} - ? ? ? if (!unmasked) - ? ? ? ? ? ? ? desc->irq_data.chip->irq_unmask(&desc->irq_data); - + ? ? ? desc->irq_data.chip->irq_eoi(&desc->irq_data); ?}
Quoted 6 lines
?#ifdef
CONFIG_PM
--
1.7.0.4
Works with chained gpio handlers on Tegra, although the patch is filled with = escaping.
PATCH 3/5 ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
Hi Colin,
Quoted 12 lines · Will Deacon
Quoted 11 lines
The chained GPIO IRQ handler on Tegra calls ->irq_ack on the parent chip prior to handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
Cc Colin Cross <[email protected]>Signed-off-by Will Deacon <[email protected]>--- arch/arm/mach-tegra/gpio.c | 17 +---------------- 1 files changed, 1 insertions(+), 16 deletions(-)
[...]
Quoted 1 line
Acked-by Colin Cross <[email protected]>
Thanks Colin.
Quoted 2 lines
Works with chained gpio handlers on Tegra, although the patch is filled with = escaping.
Hmm, I've seen this problem before. See Russell's explanation here:
http://lists.arm.linux.org.uk/lurker/message/20101201.172105.938cf2c5.en.html
I don't believe it's a problem my end, but if it starts happening regularly I'll investigate further.
Cheers,
Will
PATCH 3/5 ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 6 lines · Will Deacon
Hmm, I've seen this problem before. See Russell's explanation here:
http://lists.arm.linux.org.uk/lurker/message/20101201.172105.938cf2c5.en.html
I don't believe it's a problem my end, but if it starts happening regularly I'll investigate further.
I wonder what's happening here is that the mailing list is converting your messages from quoted-printable to plain text.
Looking at two of your recent messages, one of them came via the mailing list. That one was not quoted-printable. These ones which you Cc'd me on, and arrived before the copy from the mailing list came through as quoted-printable though.
AFAIK, git-send-email doesn't generate quoted-printable mails. From what I remember, it doesn't generate any MIME headers at all either, expecting the first MTA to be able to figure out what to do with the following string of bytes. It's not surprising that some MTAs may do weird things with that.
I don't use git send-email, but instead have my own scripts based around git format-patch, and adds the following headers:
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
to each file it produces, as well as other header modifications. I've then got a separate script which sends the contents of the directory slowly (20sec between each message) via '/usr/sbin/sendmail' (iow, the local MTA - exim for me) to make it a little kinder on MTAs.
I did try with utf-8 but istr that caused problems, possibly resulting in qp-conversion, or maybe resulted in MTAs remarking it as a us-ascii charset. As 99.9999999% of stuff I mail out from git is 7bit ASCII...
PATCH 3/5 ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip
Hi Russell,
Quoted 8 lines · Will Deacon
Quoted 6 lines
Hmm, I've seen this problem before. See Russell's explanation here:
http://lists.arm.linux.org.uk/lurker/message/20101201.172105.938cf2c5.en.html
I don't believe it's a problem my end, but if it starts happening regularly I'll investigate further.
Quoted 7 lines
I wonder what's happening here is that the mailing list is converting your messages from quoted-printable to plain text.
Looking at two of your recent messages, one of them came via the mailing list. That one was not quoted-printable. These ones which you Cc'd me on, and arrived before the copy from the mailing list came through as quoted-printable though.
You've hit the nail on the head. On leaving ARM the headers get munged to:
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
The mailing list fixes that up. See the headers on one of the LPAE patches sent by Catalin:
https://patchwork.kernel.org/patch/502491/
Quoted 6 lines
AFAIK, git-send-email doesn't generate quoted-printable mails. From what I remember, it doesn't generate any MIME headers at all either, expecting the first MTA to be able to figure out what to do with the following string of bytes. It's not surprising that some MTAs may do weird things with that.
Quoted 6 lines
I don't use git send-email, but instead have my own scripts based around git format-patch, and adds the following headers:
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="us-ascii"
Even if I make sure my headers match this, they still get reverted to the stuff I mentioned earlier. If I specify Content-Transfer-Encoding: binary then it gets left alone but I'm not sure if that's better or worse than quoted-printable.
Quoted 4 lines
to each file it produces, as well as other header modifications. I've then got a separate script which sends the contents of the directory slowly (20sec between each message) via '
/usr/sbin/sendmail' (iow, the local MTA - exim for me) to make it a little kinder on MTAs.
Oh for a local MTA... (ports are all blocked here).
Will
PATCH 4/5 ARM: s5pv310: update IRQ combiner to use EOI in parent chip
In reply to Will DeaconThe IRQ combiner code invokes the ->irq_{un}mask routines of the parent chip.
This patch updates the cascaded handler to use EOI now that the GIC has moved to using the fasteoi flow model.
--- arch/arm/mach-s5pv310/irq-combiner.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-)
arch/arm/mach-s5pv310/irq-combiner.c +2 -5
@@ -59,9 +59,6 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)unsigned int cascade_irq, combiner_irq;unsigned long status; -/* primary controller ack'ing */ - chip->irq_ack (&desc->irq_data); -spin_lock (&irq_controller_lock); status =__raw_readl (chip_data->base +COMBINER_INT_STATUS );spin_unlock (&irq_controller_lock);
@@ -79,8 +76,8 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)generic_handle_irq (cascade_irq); out: -/* primary controller unmasking */ - chip->irq_unmask (&desc->irq_data); +/* primary controller EOI */ + chip->irq_eoi (&desc->irq_data); }static struct irq_chip combiner_chip = {
Signature · 1 line
1.7.0.4
PATCH 4/5 ARM: s5pv310: update IRQ combiner to use EOI in parent chip
It's boot and working at mainline.
It's just for record.
Current mainline codes doesn't have full features of s5pv310 (aka s5pc210 or exynos4210).
So I back-ported the same codes to 2.6.36. it's booted and working at boot time, but some times later it's hang.
no serial. I think as irq cores at arm changed, it requires the more patched than just this patch.
Thank you,
Kyungmin Park
Quoted 47 lines · Will Deacon
The IRQ combiner code invokes the ->irq_{un}mask routines of the parent chip.
This patch updates the cascaded handler to use EOI now that the GIC has moved to using the fasteoi flow model.
Cc Kyungmin Park <[email protected]>Signed-off-by Will Deacon <[email protected]>---
?arch/arm/mach-s5pv310/irq-combiner.c | ? ?7 ++----- ?1 files changed, 2 insertions(+), 5 deletions(-)arch/arm/mach-s5pv310/irq-combiner.c +0
-3@@ -59,9 +59,6 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) ? ? ? ?unsigned int cascade_irq, combiner_irq; ? ? ? ?unsigned long status; - ? ? ? /* primary controller ack'ing */ - ? ? ? chip->irq_ack(&desc->irq_data); - ? ? ? ?spin_lock(&irq_controller_lock); ? ? ? ?status = __raw_readl(chip_data->base + COMBINER_INT_STATUS); ? ? ? ?spin_unlock(&irq_controller_lock);@@ -79,8 +76,8 @@ static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc *desc) ? ? ? ? ? ? ? ?generic_handle_irq(cascade_irq);?out:
- ? ? ? /* primary controller unmasking */
- ? ? ?chip->irq_unmask(&desc->irq_data);
+ ? ? ? /* primary controller EOI */
+ ? ? ?chip->irq_eoi(&desc->irq_data);
?}?static struct
irq_chipcombiner_chip= {
--
1.7.0.4_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 4/5 ARM: s5pv310: update IRQ combiner to use EOI in parent chip
Hi Kyungmin,
Quoted 3 lines
Tested-by Kyungmin Park <[email protected]>It's boot and working at mainline.
Thanks for testing this.
Quoted 7 lines
It's just for record.
Current mainline codes doesn't have full features of s5pv310 (aka s5pc210 or exynos4210).
So I back-ported the same codes to 2.6.36. it's booted and working at boot time, but some times later it's hang.
no serial. I think as irq cores at arm changed, it requires the more patched than just this patch.
Interesting. I backported to v2.6.36 and stress-tested it for a few hours on my versatile express without any problems. If you diagnose this further, please let me know.
Will
PATCH 5/5 ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
In reply to Will DeaconThe chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
--- arch/arm/mach-msm/gpio-v2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-msm/gpio-v2.c +1 -1
@@ -318,7 +318,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)generic_handle_irq (msm_gpio_to_irq (&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + desc->chip->irq_eoi (irq); }static int msm_gpio_irq_set_wake (unsigned int irq,unsigned int on)
Signature · 1 line
1.7.0.4
PATCH 5/5 ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 17 lines · Will Deacon
The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
Cc Abhijeet Dharmapurikar <[email protected]>Signed-off-by Will Deacon <[email protected]>--- arch/arm/mach-msm/gpio-v2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)arch/arm/mach-msm/gpio-v2.c +0
-0
arch/arm/mach-msm/gpio-v2.c static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc) · line 321
Quoted 5 lines
arch/arm/mach-msm/gpio-v2.c +1
-1@@ -318,7 +318,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)generic_handle_irq (msm_gpio_to_irq (&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + desc->chip->irq_eoi (irq);
should be dec->chip->irq_eoi(&desc->irq_data);
--
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH 5/5 ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 13 lines · Abhijeet Dharmapurikar
Quoted 12 lines · Will Deacon
The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
Cc Abhijeet Dharmapurikar <[email protected]>Signed-off-by Will Deacon <[email protected]>--- arch/arm/mach-msm/gpio-v2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Quoted 13 lines
arch/arm/mach-msm/gpio-v2.c static void msm_summary_irq_handler(unsigned int irq, · line 322
Quoted 11 lines
arch/arm/mach-msm/gpio-v2.c +1
-1@@ -318,7 +318,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc) generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + desc->chip->irq_eoi (irq);should be
dec->chip->irq_eoi(&desc->irq_data);
Nope, it should do:
struct irq_chip *chip = get_irq_desc_chip(desc);
chip->irq_eoi();Thanks,
tglx
PATCH 5/5 ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 29 lines · Abhijeet Dharmapurikar
Quoted 14 lines
Quoted 12 lines · Will Deacon
The chained GPIO IRQ handler on MSM8x60 calls ->ack on the parent chip after handling the interrupt.
This patch updates the code to use ->irq_eoi now that the GIC has moved to using the fasteoi flow model.
Cc Abhijeet Dharmapurikar <[email protected]>Signed-off-by Will Deacon <[email protected]>--- arch/arm/mach-msm/gpio-v2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)Quoted 13 lines
arch/arm/mach-msm/gpio-v2.c static void msm_summary_irq_handler(unsigned int irq, · line 322
Quoted 11 lines
arch/arm/mach-msm/gpio-v2.c +1
-1@@ -318,7 +318,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc) generic_handle_irq(msm_gpio_to_irq(&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + desc->chip->irq_eoi (irq);should be
dec->chip->irq_eoi(&desc->irq_data);
Quoted 5 lines
Nope, it should do:
struct irq_chip *chip = get_irq_desc_chip(desc); chip->irq_eoi();
Something like this?
arch/arm/mach-msm/gpio-v2.c +2 -1
@@ -310,6 +310,7 @@ static int msm_gpio_irq_set_type(unsigned int irq, unsigned int flow_type)static void msm_summary_irq_handler (unsigned int irq,struct irq_desc *desc) {unsigned long i; +struct irq_chip *chip =get_irq_desc_chip (desc); for (i = find_first_bit(msm_gpio.enabled_irqs, NR_GPIO_IRQS); i < NR_GPIO_IRQS;
@@ -318,7 +319,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)generic_handle_irq (msm_gpio_to_irq (&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + chip->irq_eoi (&desc->irq_data); }
Will
PATCH 5/5 ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip
Quoted 17 lines · Will Deacon
Quoted 1 line · Abhijeet Dharmapurikar
Something like this?
arch/arm/mach-msm/gpio-v2.c +1
-0@@ -310,6 +310,7 @@ static int msm_gpio_irq_set_type(unsigned int irq, unsigned int flow_type)static void msm_summary_irq_handler (unsigned int irq,struct irq_desc *desc) {unsigned long i; +struct irq_chip *chip =get_irq_desc_chip (desc); for (i = find_first_bit(msm_gpio.enabled_irqs, NR_GPIO_IRQS); i < NR_GPIO_IRQS;
arch/arm/mach-msm/gpio-v2.c static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc) · line 322
Quoted 5 lines
arch/arm/mach-msm/gpio-v2.c +1
-1@@ -318,7 +319,7 @@ static void msm_summary_irq_handler(unsigned int irq, struct irq_desc *desc)generic_handle_irq (msm_gpio_to_irq (&msm_gpio.gpio_chip, i)); } - desc->chip->ack (irq); + chip->irq_eoi (&desc->irq_data);
Yep. Thanks,
tglx