From: Thomas Gleixner <tglx@linutronix.de> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>, Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>, Gregory CLEMENT <gregory.clement@free-electrons.com>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." Date: Wed, 5 Mar 2014 15:42:34 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.02.1403051445020.18573@ionos.tec.linutronix.de> (raw) In-Reply-To: <20140305004139.GT21483@n2100.arm.linux.org.uk> On Wed, 5 Mar 2014, Russell King - ARM Linux wrote: > In some ways, this is good news - it shows that the bits in this register > latch '1' when an interrupt is pending, and remain '1' while the block > continues to assert its interrupt signal - but can we say that the other > interrupt functions in this register have that behaviour? > > >From the spec, it looks like this is probably true of DFSDone as well. > DVSDone - I see no separate status register containing status bits > indicating what the cause of the DVSDone status is. The thermal bits - > if it's a transitory excursion, may not hold. Battery fault... we > can guess. > > Now, genirq doesn't have a good way to handle this. I'll also say that > because of the above, I've always been worried about hardware races when > trying to clear down interrupts in this register - I'd much prefer not > to touch it unless absolutely necessary. So... how about this instead? > > u32 stat = readl_relaxed(gc->reg_base + DOVE_PMC_IRQ_CAUSE) & > gc->mask_cache; > u32 done = ~0; > > while (stat) { > unsigned hwirq = ffs(stat) - 1; > > stat &= ~(1 << hwirq); > done &= ~(1 << hwirq); > > generic_handle_irq(irq_find_mapping(domain, hwirq)); > } > > irq_gc_lock(gc); > done &= readl_relaxed(gc->reg_base + DOVE_PMC_IRQ_CAUSE); > writel_relaxed(done, gc->reg_base + DOVE_PMC_IRQ_CAUSE); > irq_gc_unlock(gc); > > This results in the RTC alarm test receiving exactly one interrupt for > each alarm expiry, as it should do. Thoughts? You are worried about clearing an interrupt which is transitory and not kept active at the device level until you handled it for real, right? Is the datasheet for this stuff public available? > Another question: ffs(stat) - any reason to use ffs() there rather than > fls(stat) which would result in simpler code? r1 = ffs(r4 = stat) creates: > > 198: e2641000 rsb r1, r4, #0 > 19c: e1a00006 mov r0, r6 > 1a0: e0011004 and r1, r1, r4 > 1a4: e16f1f11 clz r1, r1 > 1a8: e261101f rsb r1, r1, #31 > > whereas fls(stat): > > 198: e16f1f14 clz r1, r4 > 19c: e261101f rsb r1, r1, #31 > 1a0: e1a00006 mov r0, r6 > > Kind of a micro-optimisation, but I see no reason to prefer one over the > other except for this - and I think the switch to ffs() was made in the > hope of optimising this code! I don't think it matters in which order you process multiple pending interrupts. Thanks, tglx
WARNING: multiple messages have this Message-ID (diff)
From: tglx@linutronix.de (Thomas Gleixner) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." Date: Wed, 5 Mar 2014 15:42:34 +0100 (CET) [thread overview] Message-ID: <alpine.DEB.2.02.1403051445020.18573@ionos.tec.linutronix.de> (raw) In-Reply-To: <20140305004139.GT21483@n2100.arm.linux.org.uk> On Wed, 5 Mar 2014, Russell King - ARM Linux wrote: > In some ways, this is good news - it shows that the bits in this register > latch '1' when an interrupt is pending, and remain '1' while the block > continues to assert its interrupt signal - but can we say that the other > interrupt functions in this register have that behaviour? > > >From the spec, it looks like this is probably true of DFSDone as well. > DVSDone - I see no separate status register containing status bits > indicating what the cause of the DVSDone status is. The thermal bits - > if it's a transitory excursion, may not hold. Battery fault... we > can guess. > > Now, genirq doesn't have a good way to handle this. I'll also say that > because of the above, I've always been worried about hardware races when > trying to clear down interrupts in this register - I'd much prefer not > to touch it unless absolutely necessary. So... how about this instead? > > u32 stat = readl_relaxed(gc->reg_base + DOVE_PMC_IRQ_CAUSE) & > gc->mask_cache; > u32 done = ~0; > > while (stat) { > unsigned hwirq = ffs(stat) - 1; > > stat &= ~(1 << hwirq); > done &= ~(1 << hwirq); > > generic_handle_irq(irq_find_mapping(domain, hwirq)); > } > > irq_gc_lock(gc); > done &= readl_relaxed(gc->reg_base + DOVE_PMC_IRQ_CAUSE); > writel_relaxed(done, gc->reg_base + DOVE_PMC_IRQ_CAUSE); > irq_gc_unlock(gc); > > This results in the RTC alarm test receiving exactly one interrupt for > each alarm expiry, as it should do. Thoughts? You are worried about clearing an interrupt which is transitory and not kept active at the device level until you handled it for real, right? Is the datasheet for this stuff public available? > Another question: ffs(stat) - any reason to use ffs() there rather than > fls(stat) which would result in simpler code? r1 = ffs(r4 = stat) creates: > > 198: e2641000 rsb r1, r4, #0 > 19c: e1a00006 mov r0, r6 > 1a0: e0011004 and r1, r1, r4 > 1a4: e16f1f11 clz r1, r1 > 1a8: e261101f rsb r1, r1, #31 > > whereas fls(stat): > > 198: e16f1f14 clz r1, r4 > 19c: e261101f rsb r1, r1, #31 > 1a0: e1a00006 mov r0, r6 > > Kind of a micro-optimisation, but I see no reason to prefer one over the > other except for this - and I think the switch to ffs() was made in the > hope of optimising this code! I don't think it matters in which order you process multiple pending interrupts. Thanks, tglx
next prev parent reply other threads:[~2014-03-05 14:42 UTC|newest] Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-12-01 17:29 [GIT PULL] irqchip: dove: drivers for v3.14 Jason Cooper 2013-12-11 17:50 ` Jason Cooper 2014-01-10 18:34 ` Jason Cooper 2014-01-28 17:35 ` Jason Cooper 2014-01-28 17:35 ` Jason Cooper 2014-02-04 18:59 ` Thomas Gleixner 2014-02-04 18:59 ` Thomas Gleixner 2014-02-04 19:05 ` Jason Cooper 2014-02-04 19:05 ` Jason Cooper 2014-02-04 21:12 ` Jason Cooper 2014-02-04 21:12 ` Jason Cooper 2014-02-04 21:30 ` Thomas Gleixner 2014-02-04 21:30 ` Thomas Gleixner 2014-02-07 18:08 ` Jason Cooper 2014-02-07 18:08 ` Jason Cooper 2014-02-17 19:24 ` [RESEND PATCH] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper 2014-02-17 19:24 ` Jason Cooper 2014-02-17 19:32 ` [GIT PULL] irqchip: dove: drivers for v3.14 Jason Cooper 2014-02-17 19:32 ` Jason Cooper 2014-02-18 20:51 ` Thomas Gleixner 2014-02-18 20:51 ` Thomas Gleixner 2014-02-19 15:18 ` Jason Cooper 2014-02-19 15:18 ` Jason Cooper 2014-02-17 20:00 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper 2014-02-17 20:00 ` Jason Cooper 2014-03-03 15:02 ` Russell King - ARM Linux 2014-03-03 15:02 ` Russell King - ARM Linux 2014-03-03 17:37 ` Andrew Lunn 2014-03-03 17:37 ` Andrew Lunn 2014-03-03 18:15 ` Russell King - ARM Linux 2014-03-03 18:15 ` Russell King - ARM Linux 2014-03-03 22:24 ` Jason Cooper 2014-03-03 22:24 ` Jason Cooper 2014-03-04 3:08 ` Jason Cooper 2014-03-04 3:08 ` Jason Cooper 2014-03-04 5:32 ` [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." Jason Cooper 2014-03-04 5:32 ` Jason Cooper 2014-03-04 10:13 ` [tip:irq/core] Revert irqchip: irq-dove: Add PMU interrupt controller tip-bot for Jason Cooper 2014-03-05 0:41 ` [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." Russell King - ARM Linux 2014-03-05 0:41 ` Russell King - ARM Linux 2014-03-05 9:24 ` Andrew Lunn 2014-03-05 9:24 ` Andrew Lunn 2014-03-05 11:52 ` Carlo Caione 2014-03-05 11:52 ` Carlo Caione 2014-03-05 14:42 ` Thomas Gleixner [this message] 2014-03-05 14:42 ` Thomas Gleixner 2014-03-05 19:20 ` Russell King - ARM Linux 2014-03-05 19:20 ` Russell King - ARM Linux 2014-03-05 21:36 ` Thomas Gleixner 2014-03-05 21:36 ` Thomas Gleixner 2014-03-04 9:26 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Andrew Lunn 2014-03-04 9:26 ` Andrew Lunn 2014-03-04 10:39 ` Sebastian Hesselbarth 2014-03-04 10:39 ` Sebastian Hesselbarth 2014-03-04 12:11 ` Russell King - ARM Linux 2014-03-04 12:11 ` Russell King - ARM Linux 2014-03-04 13:53 ` Jason Cooper 2014-03-04 13:53 ` Jason Cooper 2014-03-04 13:54 ` Andrew Lunn 2014-03-04 13:54 ` Andrew Lunn 2014-03-04 14:01 ` Russell King - ARM Linux 2014-03-04 14:01 ` Russell King - ARM Linux 2014-03-04 14:41 ` Andrew Lunn 2014-03-04 14:41 ` Andrew Lunn 2014-03-04 14:02 ` Sebastian Hesselbarth 2014-03-04 14:02 ` Sebastian Hesselbarth 2014-03-04 14:18 ` Jason Cooper 2014-03-04 14:18 ` Jason Cooper
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=alpine.DEB.2.02.1403051445020.18573@ionos.tec.linutronix.de \ --to=tglx@linutronix.de \ --cc=andrew@lunn.ch \ --cc=gregory.clement@free-electrons.com \ --cc=jason@lakedaemon.net \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=sebastian.hesselbarth@googlemail.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.