linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] irqchip: dw-apb-ictl: add irq_set_affinity support
Date: Sat, 4 Jul 2015 18:33:21 +0800	[thread overview]
Message-ID: <20150704183321.565e2489@xhacker> (raw)
In-Reply-To: <20150704100827.GC7557@n2100.arm.linux.org.uk>

Dear Russell, Thomas,

On Sat, 4 Jul 2015 11:08:27 +0100
Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:

> On Sat, Jul 04, 2015 at 11:53:57AM +0200, Thomas Gleixner wrote:
> > On Sat, 4 Jul 2015, Russell King - ARM Linux wrote:
> > 
> > > On Sat, Jul 04, 2015 at 01:19:30PM +0800, Jisheng Zhang wrote:
> > > > On Marvell Berlin SoCs, the cpu's local timer is shutdown when the cpu
> > > > goes to a deep idle state, then the timer framework will be notified to
> > > > use a broadcast timer instead. The broadcast timer uses dw-apb-ictl as
> > > > interrupt chip, this patch adds irq_set_affinity support so that the
> > > > going to deep idle state cpu can set the interrupt affinity of the
> > > > broadcast interrupt to avoid unnecessary wakeups and IPIs.
> > > 
> > > NAK to this patch.
> > > 
> > > The real question is - if CPU0 is the CPU going offline, why is it
> > > still receiving _any_ interrupts - all interrupts should be migrated
> > > off it, including the chained interrupts.
> > > 
> > > Sounds like there's a bug in the migration code which needs further
> > > investigation, rather than hacking around the problem by introducing
> > > lots of driver code.
> > 
> > I think you misunderstood the changelog, which is horrible btw.
> > 
> > So the real reason to do this is to steer the broadcast interrupt to
> > the CPU which has the earliest expiry time. This avoids that another
> > cpu is woken from idle just to deliver the broadcast IPI to the other
> > cpu.
> 
> Unless I'm mistaken, the code does this by messing around with the parent
> interrupt affinity of a chained interrupt, which really isn't a good thing
> to do, because it migrates every interrupt on the child interrupt
> controller.
> 

Yep, that's the problem although it doesn't matter in our case for other 
interrupts don't care the affinity at all.
I'm requesting our HW people to connect timer interrupt to GIC directly in
future chips. But for the existing chips, this patch does really reduce
power consumption, is there any elegant solution?

PS: I noticed that exynos-combiner.c also migrated every interrupt on the
child irq controller.

Any suggestions are appreciated.

Thanks,
Jisheng

  reply	other threads:[~2015-07-04 10:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-04  5:19 [PATCH v2 0/2] irqchip: dw-apb-ictl: add irq_set_affinity support Jisheng Zhang
2015-07-04  5:19 ` [PATCH v2 1/2] irqchip: dw-apb-ictl: add private data structure Jisheng Zhang
2015-07-04  5:19 ` [PATCH v2 2/2] irqchip: dw-apb-ictl: add irq_set_affinity support Jisheng Zhang
2015-07-04  8:26   ` Russell King - ARM Linux
2015-07-04  8:50     ` Jisheng Zhang
2015-07-04  9:25       ` Russell King - ARM Linux
2015-07-04  9:35         ` Jisheng Zhang
2015-07-04  9:43           ` Jisheng Zhang
2015-07-04  9:53     ` Thomas Gleixner
2015-07-04 10:08       ` Russell King - ARM Linux
2015-07-04 10:33         ` Jisheng Zhang [this message]
2015-07-04 12:49         ` Thomas Gleixner
2015-07-04 13:16           ` Jisheng Zhang
2015-07-04 13:42             ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150704183321.565e2489@xhacker \
    --to=jszhang@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).