[PATCH 0/5] Migrate GIC to fasteoi flow control

[PATCH 0/5] Migrate GIC to fasteoi flow control

[Will Deacon]

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

[Will Deacon]

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).

Cc: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/common/gic.c |   23 +++++++++--------------
 1 files changed, 9 insertions(+), 14 deletions(-)

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 2243772..9def30b 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -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);
 	}
 
-- 
1.7.0.4

[PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip

[Will Deacon]

On 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.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Colin Cross <ccross@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/plat-omap/gpio.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 971d186..1d2d1c7 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -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)
-- 
1.7.0.4

[PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip

[Santosh Shilimkar]

> -----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 chip
>
> On 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.
>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Colin Cross <ccross@google.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
Thanks Will for changes. They look fine.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

I will test your series tomorrow on OMAP with some
GPIO interrupts.


>  arch/arm/plat-omap/gpio.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index 971d186..1d2d1c7 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -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)
> --
> 1.7.0.4
>

[PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip

[Santosh Shilimkar]

Will,
> -----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 chip
>
> > -----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 chip
> >
> > On 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.
> >
> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Colin Cross <ccross@google.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> Thanks Will for changes. They look fine.
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>
> 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 <santosh.shilimkar@ti.com>

Regards,
Santosh

[PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip

[Will Deacon]

Hi Santosh,

> > > On 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.
> > >
> > > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > > Cc: Colin Cross <ccross@google.com>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > Thanks Will for changes. They look fine.
> > Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> >
> > 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 <santosh.shilimkar@ti.com>

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

[Tony Lindgren]

* Will Deacon <will.deacon@arm.com> [110221 07:28]:
> On 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.
> 
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Colin Cross <ccross@google.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

Acked-by: Tony Lindgren <tony@atomide.com>

[PATCH 2/5] ARM: omap: update GPIO chained IRQ handler to use EOI in parent chip

[Will Deacon]

> * Will Deacon <will.deacon@arm.com> [110221 07:28]:
> > On 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.
> >
> > Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> > Cc: Colin Cross <ccross@google.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> 
> Acked-by: Tony Lindgren <tony@atomide.com>

Thanks Tony, I'll add your ack.

Will

[PATCH 3/5] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip

[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 <ccross@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-tegra/gpio.c |   17 +----------------
 1 files changed, 1 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
index ad80488..5019b01 100644
--- a/arch/arm/mach-tegra/gpio.c
+++ b/arch/arm/mach-tegra/gpio.c
@@ -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
-- 
1.7.0.4

[PATCH 3/5] ARM: tegra: update GPIO chained IRQ handler to use EOI in parent chip

[Colin Cross]

On Mon, Feb 21, 2011 at 7:28 AM, Will Deacon <will.deacon@arm.com> wrote:
> 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 <ccross@google.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> ?arch/arm/mach-tegra/gpio.c | ? 17 +----------------
> ?1 files changed, 1 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-tegra/gpio.c b/arch/arm/mach-tegra/gpio.c
> index ad80488..5019b01 100644
> --- a/arch/arm/mach-tegra/gpio.c
> +++ b/arch/arm/mach-tegra/gpio.c
> @@ -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
> --
> 1.7.0.4
>
>
>

Acked-by: Colin Cross <ccross@android.com>

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

[Will Deacon]

Hi Colin,

> On Mon, Feb 21, 2011 at 7:28 AM, Will Deacon <will.deacon@arm.com> wrote:
> > 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 <ccross@google.com>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm/mach-tegra/gpio.c |   17 +----------------
> >  1 files changed, 1 insertions(+), 16 deletions(-)

[...]

> Acked-by: Colin Cross <ccross@android.com>

Thanks Colin.

> 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

[Russell King - ARM Linux]

On Tue, Feb 22, 2011 at 07:21:09PM -0000, Will Deacon wrote:
> 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

[Will Deacon]

Hi Russell,

> On Tue, Feb 22, 2011 at 07:21:09PM -0000, Will Deacon wrote:
> > 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.

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/

> 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"

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.
 
> 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

[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 <kyungmin.park@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-s5pv310/irq-combiner.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-s5pv310/irq-combiner.c b/arch/arm/mach-s5pv310/irq-combiner.c
index 1ea4a9e..24d5604 100644
--- a/arch/arm/mach-s5pv310/irq-combiner.c
+++ b/arch/arm/mach-s5pv310/irq-combiner.c
@@ -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 = {
-- 
1.7.0.4

[PATCH 4/5] ARM: s5pv310: update IRQ combiner to use EOI in parent chip

[Kyungmin Park]

Tested-by: Kyungmin Park <kyungmin.park@samsung.com>

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

On Tue, Feb 22, 2011 at 12:28 AM, Will Deacon <will.deacon@arm.com> wrote:
> 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 <kyungmin.park@samsung.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> ?arch/arm/mach-s5pv310/irq-combiner.c | ? ?7 ++-----
> ?1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-s5pv310/irq-combiner.c b/arch/arm/mach-s5pv310/irq-combiner.c
> index 1ea4a9e..24d5604 100644
> --- a/arch/arm/mach-s5pv310/irq-combiner.c
> +++ b/arch/arm/mach-s5pv310/irq-combiner.c
> @@ -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 = {
> --
> 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

[Will Deacon]

Hi Kyungmin,

> Tested-by: Kyungmin Park <kyungmin.park@samsung.com>
> 
> It's boot and working at mainline.

Thanks for testing this.
 
> 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

[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 <adharmap@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
 arch/arm/mach-msm/gpio-v2.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
index 0de19ec..04fb411 100644
--- a/arch/arm/mach-msm/gpio-v2.c
+++ b/arch/arm/mach-msm/gpio-v2.c
@@ -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)
-- 
1.7.0.4

[PATCH 5/5] ARM: msm: update GPIO chained IRQ handler to use EOI in parent chip

[Abhijeet Dharmapurikar]

Will Deacon wrote:
> 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 <adharmap@codeaurora.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  arch/arm/mach-msm/gpio-v2.c |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
> index 0de19ec..04fb411 100644
> --- a/arch/arm/mach-msm/gpio-v2.c
> +++ b/arch/arm/mach-msm/gpio-v2.c
> @@ -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

[Thomas Gleixner]

On Wed, 23 Feb 2011, Abhijeet Dharmapurikar wrote:

> Will Deacon wrote:
> > 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 <adharmap@codeaurora.org>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> >  arch/arm/mach-msm/gpio-v2.c |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
> > index 0de19ec..04fb411 100644
> > --- a/arch/arm/mach-msm/gpio-v2.c
> > +++ b/arch/arm/mach-msm/gpio-v2.c
> > @@ -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

[Will Deacon]

> On Wed, 23 Feb 2011, Abhijeet Dharmapurikar wrote:
> 
> > Will Deacon wrote:
> > > 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 <adharmap@codeaurora.org>
> > > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > > ---
> > >  arch/arm/mach-msm/gpio-v2.c |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
> > > index 0de19ec..04fb411 100644
> > > --- a/arch/arm/mach-msm/gpio-v2.c
> > > +++ b/arch/arm/mach-msm/gpio-v2.c
> > > @@ -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();

Something like this?

diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
index 0de19ec..90a968f 100644
--- a/arch/arm/mach-msm/gpio-v2.c
+++ b/arch/arm/mach-msm/gpio-v2.c
@@ -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

[Thomas Gleixner]

On Thu, 24 Feb 2011, Will Deacon wrote:
> > On Wed, 23 Feb 2011, Abhijeet Dharmapurikar wrote:
> 
> Something like this?
> 
> diff --git a/arch/arm/mach-msm/gpio-v2.c b/arch/arm/mach-msm/gpio-v2.c
> index 0de19ec..90a968f 100644
> --- a/arch/arm/mach-msm/gpio-v2.c
> +++ b/arch/arm/mach-msm/gpio-v2.c
> @@ -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);

Yep. Thanks,

     tglx
>