* [GIT PULL] irqchip: dove: drivers for v3.14
@ 2013-12-01 17:29 Jason Cooper
2013-12-11 17:50 ` Jason Cooper
0 siblings, 1 reply; 35+ messages in thread
From: Jason Cooper @ 2013-12-01 17:29 UTC (permalink / raw)
To: linux-arm-kernel
Thomas,
Here's an mvebu driver we've had on the ML for a while, and it's been in
-next for 5 days.
thx,
Jason.
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-irqchip-3.14
for you to fetch changes up to 40b367d95fb3d60fc1edb9ba8f6ef52272e48936:
irqchip: irq-dove: Add PMU interrupt controller. (2013-11-26 15:04:53 +0000)
----------------------------------------------------------------
mvebu irqchip changes for v3.14
- add Dove PMU interrupt controller
----------------------------------------------------------------
Andrew Lunn (1):
irqchip: irq-dove: Add PMU interrupt controller.
.../interrupt-controller/marvell,dove-pmu-intc.txt | 17 +++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-dove.c | 126 +++++++++++++++++++++
3 files changed, 144 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt
create mode 100644 drivers/irqchip/irq-dove.c
^ permalink raw reply [flat|nested] 35+ messages in thread* [GIT PULL] irqchip: dove: drivers for v3.14 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 0 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2013-12-11 17:50 UTC (permalink / raw) To: linux-arm-kernel Thomas, On Sun, Dec 01, 2013 at 12:29:14PM -0500, Jason Cooper wrote: > Thomas, > > Here's an mvebu driver we've had on the ML for a while, and it's been in > -next for 5 days. Just checking to make sure this hasn't slipped off of your plate. thx, Jason. > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: > > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) > > are available in the git repository at: > > git://git.infradead.org/linux-mvebu.git tags/mvebu-irqchip-3.14 > > for you to fetch changes up to 40b367d95fb3d60fc1edb9ba8f6ef52272e48936: > > irqchip: irq-dove: Add PMU interrupt controller. (2013-11-26 15:04:53 +0000) > > ---------------------------------------------------------------- > mvebu irqchip changes for v3.14 > > - add Dove PMU interrupt controller > > ---------------------------------------------------------------- > Andrew Lunn (1): > irqchip: irq-dove: Add PMU interrupt controller. > > .../interrupt-controller/marvell,dove-pmu-intc.txt | 17 +++ > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-dove.c | 126 +++++++++++++++++++++ > 3 files changed, 144 insertions(+) > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt > create mode 100644 drivers/irqchip/irq-dove.c > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2013-12-11 17:50 ` Jason Cooper @ 2014-01-10 18:34 ` Jason Cooper 2014-01-28 17:35 ` Jason Cooper 0 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-01-10 18:34 UTC (permalink / raw) To: linux-arm-kernel Thomas, On Wed, Dec 11, 2013 at 12:50:37PM -0500, Jason Cooper wrote: > On Sun, Dec 01, 2013 at 12:29:14PM -0500, Jason Cooper wrote: > > Here's an mvebu driver we've had on the ML for a while, and it's been in > > -next for 5 days. > > Just checking to make sure this hasn't slipped off of your plate. > I'm not able to see where this one might have been pulled, could you please pull or let me know if it's not acceptable? thx, Jason. > > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: > > > > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) > > > > are available in the git repository at: > > > > git://git.infradead.org/linux-mvebu.git tags/mvebu-irqchip-3.14 > > > > for you to fetch changes up to 40b367d95fb3d60fc1edb9ba8f6ef52272e48936: > > > > irqchip: irq-dove: Add PMU interrupt controller. (2013-11-26 15:04:53 +0000) > > > > ---------------------------------------------------------------- > > mvebu irqchip changes for v3.14 > > > > - add Dove PMU interrupt controller > > > > ---------------------------------------------------------------- > > Andrew Lunn (1): > > irqchip: irq-dove: Add PMU interrupt controller. > > > > .../interrupt-controller/marvell,dove-pmu-intc.txt | 17 +++ > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-dove.c | 126 +++++++++++++++++++++ > > 3 files changed, 144 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt > > create mode 100644 drivers/irqchip/irq-dove.c > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-01-10 18:34 ` Jason Cooper @ 2014-01-28 17:35 ` Jason Cooper 2014-02-04 18:59 ` Thomas Gleixner 0 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-01-28 17:35 UTC (permalink / raw) To: linux-arm-kernel Thomas, On Fri, Jan 10, 2014 at 01:34:30PM -0500, Jason Cooper wrote: > On Wed, Dec 11, 2013 at 12:50:37PM -0500, Jason Cooper wrote: > > On Sun, Dec 01, 2013 at 12:29:14PM -0500, Jason Cooper wrote: > > > Here's an mvebu driver we've had on the ML for a while, and it's been in > > > -next for 5 days. > > > > Just checking to make sure this hasn't slipped off of your plate. > > > > I'm not able to see where this one might have been pulled, could you > please pull or let me know if it's not acceptable? I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting near to the end of the merge window and there's been no activity on this pull request. Please let us know if there's anything we can do to assist. thx, Jason. > > > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: > > > > > > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) > > > > > > are available in the git repository at: > > > > > > git://git.infradead.org/linux-mvebu.git tags/mvebu-irqchip-3.14 > > > > > > for you to fetch changes up to 40b367d95fb3d60fc1edb9ba8f6ef52272e48936: > > > > > > irqchip: irq-dove: Add PMU interrupt controller. (2013-11-26 15:04:53 +0000) > > > > > > ---------------------------------------------------------------- > > > mvebu irqchip changes for v3.14 > > > > > > - add Dove PMU interrupt controller > > > > > > ---------------------------------------------------------------- > > > Andrew Lunn (1): > > > irqchip: irq-dove: Add PMU interrupt controller. > > > > > > .../interrupt-controller/marvell,dove-pmu-intc.txt | 17 +++ > > > drivers/irqchip/Makefile | 1 + > > > drivers/irqchip/irq-dove.c | 126 +++++++++++++++++++++ > > > 3 files changed, 144 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt > > > create mode 100644 drivers/irqchip/irq-dove.c > > > > > > _______________________________________________ > > > linux-arm-kernel mailing list > > > linux-arm-kernel at lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel at lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-01-28 17:35 ` Jason Cooper @ 2014-02-04 18:59 ` Thomas Gleixner 2014-02-04 19:05 ` Jason Cooper 2014-02-04 21:12 ` Jason Cooper 0 siblings, 2 replies; 35+ messages in thread From: Thomas Gleixner @ 2014-02-04 18:59 UTC (permalink / raw) To: linux-arm-kernel On Tue, 28 Jan 2014, Jason Cooper wrote: > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > near to the end of the merge window and there's been no activity on this > pull request. > > Please let us know if there's anything we can do to assist. Nah. I simply forgot about it. About to send a pull request to Linus. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-04 18:59 ` Thomas Gleixner @ 2014-02-04 19:05 ` Jason Cooper 2014-02-04 21:12 ` Jason Cooper 1 sibling, 0 replies; 35+ messages in thread From: Jason Cooper @ 2014-02-04 19:05 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > On Tue, 28 Jan 2014, Jason Cooper wrote: > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > near to the end of the merge window and there's been no activity on this > > pull request. > > > > Please let us know if there's anything we can do to assist. > > Nah. I simply forgot about it. About to send a pull request to Linus. Great, thanks! Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-04 18:59 ` Thomas Gleixner 2014-02-04 19:05 ` Jason Cooper @ 2014-02-04 21:12 ` Jason Cooper 2014-02-04 21:30 ` Thomas Gleixner 1 sibling, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-02-04 21:12 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > On Tue, 28 Jan 2014, Jason Cooper wrote: > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > near to the end of the merge window and there's been no activity on this > > pull request. > > > > Please let us know if there's anything we can do to assist. > > Nah. I simply forgot about it. About to send a pull request to Linus. hmmm. I see the pull request contains the patches from mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip (dove): 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. which is what this thread was originally a pull request for. Are you planning to send a second pull request to Linus? thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-04 21:12 ` Jason Cooper @ 2014-02-04 21:30 ` Thomas Gleixner 2014-02-07 18:08 ` Jason Cooper 0 siblings, 1 reply; 35+ messages in thread From: Thomas Gleixner @ 2014-02-04 21:30 UTC (permalink / raw) To: linux-arm-kernel On Tue, 4 Feb 2014, Jason Cooper wrote: > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > > On Tue, 28 Jan 2014, Jason Cooper wrote: > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > > near to the end of the merge window and there's been no activity on this > > > pull request. > > > > > > Please let us know if there's anything we can do to assist. > > > > Nah. I simply forgot about it. About to send a pull request to Linus. > > hmmm. I see the pull request contains the patches from > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip > (dove): > > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. > > which is what this thread was originally a pull request for. > > > Are you planning to send a second pull request to Linus? Duh. I'll pick that up tomorrow ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-04 21:30 ` Thomas Gleixner @ 2014-02-07 18:08 ` Jason Cooper 2014-02-17 19:24 ` [RESEND PATCH] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Jason Cooper @ 2014-02-07 18:08 UTC (permalink / raw) To: linux-arm-kernel On Tue, Feb 04, 2014 at 10:30:53PM +0100, Thomas Gleixner wrote: > On Tue, 4 Feb 2014, Jason Cooper wrote: > > > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > > > On Tue, 28 Jan 2014, Jason Cooper wrote: > > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > > > near to the end of the merge window and there's been no activity on this > > > > pull request. > > > > > > > > Please let us know if there's anything we can do to assist. > > > > > > Nah. I simply forgot about it. About to send a pull request to Linus. > > > > hmmm. I see the pull request contains the patches from > > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip > > (dove): > > > > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. > > > > which is what this thread was originally a pull request for. > > > > > > Are you planning to send a second pull request to Linus? > > Duh. I'll pick that up tomorrow Ping? thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [RESEND PATCH] ARM: dove: dt: revert PMU interrupt controller node 2014-02-07 18:08 ` 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 20:00 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper 2 siblings, 0 replies; 35+ messages in thread From: Jason Cooper @ 2014-02-17 19:24 UTC (permalink / raw) To: linux-arm-kernel The corresponding driver didn't make it into v3.14, so we need to remove the node. Dove systems fail to boot with the node present and no driver. This node will be re-added when the driver makes it to mainline. Signed-off-by: Jason Cooper <jason@lakedaemon.net> --- Sorry for the resend, infradead.org didn't like the way I specified the list address. And after more careful reading, I missed a '>' in my cut-n-paste of Andrew's email address. Sorry for the unnecessary noise. Also, I plan to submit this in mvebu/dt-fixes for v3.14 arch/arm/boot/dts/dove.dtsi | 9 --------- 1 file changed, 9 deletions(-) diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi index 2b76524f4aa7..967898528062 100644 --- a/arch/arm/boot/dts/dove.dtsi +++ b/arch/arm/boot/dts/dove.dtsi @@ -379,15 +379,6 @@ #clock-cells = <1>; }; - pmu_intc: pmu-interrupt-ctrl at d0050 { - compatible = "marvell,dove-pmu-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd0050 0x8>; - interrupts = <33>; - marvell,#interrupts = <7>; - }; - pinctrl: pin-ctrl at d0200 { compatible = "marvell,dove-pinctrl"; reg = <0xd0200 0x10>; -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 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:32 ` Jason Cooper 2014-02-18 20:51 ` Thomas Gleixner 2014-02-17 20:00 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper 2 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-02-17 19:32 UTC (permalink / raw) To: linux-arm-kernel Thomas, On Fri, Feb 07, 2014 at 01:08:36PM -0500, Jason Cooper wrote: > On Tue, Feb 04, 2014 at 10:30:53PM +0100, Thomas Gleixner wrote: > > On Tue, 4 Feb 2014, Jason Cooper wrote: > > > > > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > > > > On Tue, 28 Jan 2014, Jason Cooper wrote: > > > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > > > > near to the end of the merge window and there's been no activity on this > > > > > pull request. > > > > > > > > > > Please let us know if there's anything we can do to assist. > > > > > > > > Nah. I simply forgot about it. About to send a pull request to Linus. > > > > > > hmmm. I see the pull request contains the patches from > > > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip > > > (dove): > > > > > > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. > > > > > > which is what this thread was originally a pull request for. > > > > > > > > > Are you planning to send a second pull request to Linus? > > > > Duh. I'll pick that up tomorrow > > Ping? I think it's safe to say that the Dove PMU interrupt controller isn't going to make it in to v3.14. I've posted a patch to remove the DT node for v3.14. If you don't mind, I'll go ahead and take this pull request through the mvebu tree for v3.15. So that way it's off your plate and you don't have to worry about it. There's more mvebu irqchip stuff on the way :) thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-17 19:32 ` [GIT PULL] irqchip: dove: drivers for v3.14 Jason Cooper @ 2014-02-18 20:51 ` Thomas Gleixner 2014-02-19 15:18 ` Jason Cooper 0 siblings, 1 reply; 35+ messages in thread From: Thomas Gleixner @ 2014-02-18 20:51 UTC (permalink / raw) To: linux-arm-kernel On Mon, 17 Feb 2014, Jason Cooper wrote: > On Fri, Feb 07, 2014 at 01:08:36PM -0500, Jason Cooper wrote: > > On Tue, Feb 04, 2014 at 10:30:53PM +0100, Thomas Gleixner wrote: > > > On Tue, 4 Feb 2014, Jason Cooper wrote: > > > > > > > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > > > > > On Tue, 28 Jan 2014, Jason Cooper wrote: > > > > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > > > > > near to the end of the merge window and there's been no activity on this > > > > > > pull request. > > > > > > > > > > > > Please let us know if there's anything we can do to assist. > > > > > > > > > > Nah. I simply forgot about it. About to send a pull request to Linus. > > > > > > > > hmmm. I see the pull request contains the patches from > > > > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip > > > > (dove): > > > > > > > > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. > > > > > > > > which is what this thread was originally a pull request for. > > > > > > > > > > > > Are you planning to send a second pull request to Linus? > > > > > > Duh. I'll pick that up tomorrow > > > > Ping? > > I think it's safe to say that the Dove PMU interrupt controller isn't > going to make it in to v3.14. I've posted a patch to remove the DT node > for v3.14. Yes, sorry. I messed that one up. > If you don't mind, I'll go ahead and take this pull request through the > mvebu tree for v3.15. So that way it's off your plate and you don't > have to worry about it. I pushed it out to tip/irq/core now. > There's more mvebu irqchip stuff on the way :) You have an entry in my mail filter rules now, so you'll end up in the priority queue with your pull requests :) Btw, I just looked at that dove driver and if you look at the other drivers/irqchip variants which use the generic irq domain/chip stuff, then the code in the init functions +/- some minimalistic fixes is just the same boiler plate except for quirks or a few register writes. This the diff of the relevant code for orion and dove. --- drivers/irqchip/irq-orion.c 2014-02-18 21:27:35.655468837 +0100 +++ drivers/irqchip/irq-dove.c 2014-02-18 21:27:57.099469874 +0100 @@ -1,14 +1,10 @@ +#define DOVE_PMU_IRQ_CAUSE 0x00 +#define DOVE_PMU_IRQ_MASK 0x04 -/* - * Orion SoC bridge interrupt controller - */ -#define ORION_BRIDGE_IRQ_CAUSE 0x00 -#define ORION_BRIDGE_IRQ_MASK 0x04 - -static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc) +static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc) { struct irq_domain *d = irq_get_handler_data(irq); - struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, irq); - u32 stat = readl_relaxed(gc->reg_base + ORION_BRIDGE_IRQ_CAUSE) & + struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0); + u32 stat = readl_relaxed(gc->reg_base + DOVE_PMU_IRQ_CAUSE) & gc->mask_cache; Identical except for the register constants, which are identical as well. while (stat) { @@ -123,17 +36,14 @@ } } -static int __init orion_bridge_irq_init(struct device_node *np, - struct device_node *parent) +static int __init dove_pmu_irq_init(struct device_node *np, + struct device_node *parent) { unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN; struct resource r; struct irq_domain *domain; struct irq_chip_generic *gc; - int ret, irq, nrirqs = 32; - - /* get optional number of interrupts provided */ - of_property_read_u32(np, "marvell,#interrupts", &nrirqs); + int ret, irq, nrirqs = 7; So the difference here is nrirqs domain = irq_domain_add_linear(np, nrirqs, &irq_generic_chip_ops, NULL); @@ -174,19 +107,20 @@ return -ENOMEM; } - gc->chip_types[0].regs.ack = ORION_BRIDGE_IRQ_CAUSE; - gc->chip_types[0].regs.mask = ORION_BRIDGE_IRQ_MASK; - gc->chip_types[0].chip.irq_ack = irq_gc_ack_clr_bit; + gc->chip_types[0].regs.ack = DOVE_PMU_IRQ_CAUSE; + gc->chip_types[0].regs.mask = DOVE_PMU_IRQ_MASK; + gc->chip_types[0].chip.irq_ack = pmu_irq_ack; gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit; gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit; - /* mask all interrupts */ - writel(0, gc->reg_base + ORION_BRIDGE_IRQ_MASK); + /* mask and clear all interrupts */ + writel(0, gc->reg_base + DOVE_PMU_IRQ_MASK); + writel(0, gc->reg_base + DOVE_PMU_IRQ_CAUSE); irq_set_handler_data(irq, domain); - irq_set_chained_handler(irq, orion_bridge_irq_handler); + irq_set_chained_handler(irq, dove_pmu_irq_handler); return 0; } -IRQCHIP_DECLARE(orion_bridge_intc, - "marvell,orion-bridge-intc", orion_bridge_irq_init); +IRQCHIP_DECLARE(dove_pmu_intc, + "marvell,dove-pmu-intc", dove_pmu_irq_init); I omitted the second variant in irq-orion.c which is the same boilerplate with a few minimal changes. It'd be really nice if someone would sit down and make one or two general irqchip init function which gets rid of this copied code and reduces the init functions to the bare minimum. That's not only true for the orion/dove case it's the same for lot of irq-*.c variants plus minus the individual extras and of course bugs. Thanks, tglx ^ permalink raw reply [flat|nested] 35+ messages in thread
* [GIT PULL] irqchip: dove: drivers for v3.14 2014-02-18 20:51 ` Thomas Gleixner @ 2014-02-19 15:18 ` Jason Cooper 0 siblings, 0 replies; 35+ messages in thread From: Jason Cooper @ 2014-02-19 15:18 UTC (permalink / raw) To: linux-arm-kernel Thomas! Hi! On Tue, Feb 18, 2014 at 09:51:31PM +0100, Thomas Gleixner wrote: > On Mon, 17 Feb 2014, Jason Cooper wrote: > > On Fri, Feb 07, 2014 at 01:08:36PM -0500, Jason Cooper wrote: > > > On Tue, Feb 04, 2014 at 10:30:53PM +0100, Thomas Gleixner wrote: > > > > On Tue, 4 Feb 2014, Jason Cooper wrote: > > > > > > > > > On Tue, Feb 04, 2014 at 07:59:58PM +0100, Thomas Gleixner wrote: > > > > > > On Tue, 28 Jan 2014, Jason Cooper wrote: > > > > > > > I see you pulled in mvebu/irqchip-fixes. Thanks for that. It's getting > > > > > > > near to the end of the merge window and there's been no activity on this > > > > > > > pull request. > > > > > > > > > > > > > > Please let us know if there's anything we can do to assist. > > > > > > > > > > > > Nah. I simply forgot about it. About to send a pull request to Linus. > > > > > > > > > > hmmm. I see the pull request contains the patches from > > > > > mvebu/irqchip-fixes (armada), but not the patches from mvebu/irqchip > > > > > (dove): > > > > > > > > > > 40b367d95fb3 irqchip: irq-dove: Add PMU interrupt controller. > > > > > > > > > > which is what this thread was originally a pull request for. > > > > > > > > > > > > > > > Are you planning to send a second pull request to Linus? > > > > > > > > Duh. I'll pick that up tomorrow > > > > > > Ping? > > > > I think it's safe to say that the Dove PMU interrupt controller isn't > > going to make it in to v3.14. I've posted a patch to remove the DT node > > for v3.14. > > Yes, sorry. I messed that one up. No problem, I just wasn't sure how hard to push and didn't want to be a d*ck. > > If you don't mind, I'll go ahead and take this pull request through the > > mvebu tree for v3.15. So that way it's off your plate and you don't > > have to worry about it. > > I pushed it out to tip/irq/core now. Ok, great! > > There's more mvebu irqchip stuff on the way :) > > You have an entry in my mail filter rules now, so you'll end up in the > priority queue with your pull requests :) Ahhh... That's the magic sauce. :) > Btw, I just looked at that dove driver and if you look at the other > drivers/irqchip variants which use the generic irq domain/chip stuff, > then the code in the init functions +/- some minimalistic fixes is > just the same boiler plate except for quirks or a few register writes. Yes, thanks for not insisting on this cleanup/consolidation right now. :) In this window we're currently adding three new SoCs to mach-mvebu (Armada 375, 380, and 385), the associated drivers, and we're finally migrating the DT enabled kirkwood from mach-kirkwood into mach-mvebu. And it looks like mach-dove might be ready to migrate in as well this window. Once the dust settles next window, I'll keep this consolidation on our radar. We've already done the same for other drivers (watchdog jumps out). thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 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:32 ` [GIT PULL] irqchip: dove: drivers for v3.14 Jason Cooper @ 2014-02-17 20:00 ` Jason Cooper 2014-03-03 15:02 ` Russell King - ARM Linux 2 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-02-17 20:00 UTC (permalink / raw) To: linux-arm-kernel The corresponding driver didn't make it into v3.14, so we need to remove the node. Dove systems fail to boot with the node present and no driver. This node will be re-added when the driver makes it to mainline. Signed-off-by: Jason Cooper <jason@lakedaemon.net> --- Changes from v1: - removed the reference to pmu_intc. Destined for the mvebu/dt-fixes branch for v3.14, node will be re-added once the driver hits mainline for v3.15 arch/arm/boot/dts/dove.dtsi | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi index 2b76524f4aa7..187fd46b7b5e 100644 --- a/arch/arm/boot/dts/dove.dtsi +++ b/arch/arm/boot/dts/dove.dtsi @@ -379,15 +379,6 @@ #clock-cells = <1>; }; - pmu_intc: pmu-interrupt-ctrl at d0050 { - compatible = "marvell,dove-pmu-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd0050 0x8>; - interrupts = <33>; - marvell,#interrupts = <7>; - }; - pinctrl: pin-ctrl at d0200 { compatible = "marvell,dove-pinctrl"; reg = <0xd0200 0x10>; @@ -610,8 +601,6 @@ rtc: real-time-clock at d8500 { compatible = "marvell,orion-rtc"; reg = <0xd8500 0x20>; - interrupt-parent = <&pmu_intc>; - interrupts = <5>; }; gpio2: gpio-ctrl at e8400 { -- 1.8.5.5 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-02-17 20:00 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Jason Cooper @ 2014-03-03 15:02 ` Russell King - ARM Linux 2014-03-03 17:37 ` Andrew Lunn 0 siblings, 1 reply; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-03 15:02 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 17, 2014 at 08:00:36PM +0000, Jason Cooper wrote: > The corresponding driver didn't make it into v3.14, so we need to remove > the node. Dove systems fail to boot with the node present and no > driver. > > This node will be re-added when the driver makes it to mainline. I'm going to stick my oar in on this and ask what is a very fundamental question. If we're adding the PMU interrupt controller as a separate "device" aren't we describing our implementation rather than the hardware? It isn't a separate device as far as the description of it in the reference manuals. Moreover, should the PMU interrupt controller be something which is handled by a separate chunk of code to a driver for the PMU as a whole, or are we storing up problems with resource clashes? I can quite see a PMU driver coming along in the future offering a pair of generic power domains for the GPU and VPU, and such a driver would need to map all the PMU registers so it can access the power control, reset and isolator registers. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-03 15:02 ` Russell King - ARM Linux @ 2014-03-03 17:37 ` Andrew Lunn 2014-03-03 18:15 ` Russell King - ARM Linux 0 siblings, 1 reply; 35+ messages in thread From: Andrew Lunn @ 2014-03-03 17:37 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 03, 2014 at 03:02:15PM +0000, Russell King - ARM Linux wrote: > On Mon, Feb 17, 2014 at 08:00:36PM +0000, Jason Cooper wrote: > > The corresponding driver didn't make it into v3.14, so we need to remove > > the node. Dove systems fail to boot with the node present and no > > driver. > > > > This node will be re-added when the driver makes it to mainline. > > I'm going to stick my oar in on this and ask what is a very fundamental > question. > > If we're adding the PMU interrupt controller as a separate "device" > aren't we describing our implementation rather than the hardware? It > isn't a separate device as far as the description of it in the reference > manuals. > > Moreover, should the PMU interrupt controller be something which is > handled by a separate chunk of code to a driver for the PMU as a whole, > or are we storing up problems with resource clashes? I can quite see > a PMU driver coming along in the future offering a pair of generic > power domains for the GPU and VPU, and such a driver would need to map > all the PMU registers so it can access the power control, reset and > isolator registers. Hi Russell I suspect you are right, we are storing up problems. During the 4 months between submitting this driver and actually getting it accepted, i've learned quite a bit. I tried to implement cpufreq for Dove and ran into the problems you mention. The registers in the PMU are interleaved so that you cannot cleanly separate out the range needed for cpufreq. We probably need a PMU device, which exports a register syscon and have the interrupt controller make use of it. Andrew ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-03 17:37 ` Andrew Lunn @ 2014-03-03 18:15 ` Russell King - ARM Linux 2014-03-03 22:24 ` Jason Cooper 0 siblings, 1 reply; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-03 18:15 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 03, 2014 at 06:37:40PM +0100, Andrew Lunn wrote: > On Mon, Mar 03, 2014 at 03:02:15PM +0000, Russell King - ARM Linux wrote: > > On Mon, Feb 17, 2014 at 08:00:36PM +0000, Jason Cooper wrote: > > > The corresponding driver didn't make it into v3.14, so we need to remove > > > the node. Dove systems fail to boot with the node present and no > > > driver. > > > > > > This node will be re-added when the driver makes it to mainline. > > > > I'm going to stick my oar in on this and ask what is a very fundamental > > question. > > > > If we're adding the PMU interrupt controller as a separate "device" > > aren't we describing our implementation rather than the hardware? It > > isn't a separate device as far as the description of it in the reference > > manuals. > > > > Moreover, should the PMU interrupt controller be something which is > > handled by a separate chunk of code to a driver for the PMU as a whole, > > or are we storing up problems with resource clashes? I can quite see > > a PMU driver coming along in the future offering a pair of generic > > power domains for the GPU and VPU, and such a driver would need to map > > all the PMU registers so it can access the power control, reset and > > isolator registers. > > Hi Russell > > I suspect you are right, we are storing up problems. > > During the 4 months between submitting this driver and actually > getting it accepted, i've learned quite a bit. I tried to implement > cpufreq for Dove and ran into the problems you mention. The registers > in the PMU are interleaved so that you cannot cleanly separate out the > range needed for cpufreq. We probably need a PMU device, which exports > a register syscon and have the interrupt controller make use of it. I know it's a pain to say this, but maybe we should hold off with the PMU IRQ controller patch for a while longer until we get a proper idea of what we're doing with the PMU? If you have a look at my "Generic PM domains - too noisy?" email earlier today on LAKML, you can see some of the code I'm talking about above - I have that running at the moment on my CuBox. I'm going to be doing some power measurements soon with various different autosuspend delays to see what effect it has. If we do end up with a PMU driver, then I think that unless there's a real need, it should just integrate things like the PM domains, IRQ controller and maybe (depending on how complex it is) the cpufreq bits. MFD is all very well, but I feel that sometimes it brings along additional complexity at times when that complexity isn't needed. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-03 18:15 ` Russell King - ARM Linux @ 2014-03-03 22:24 ` Jason Cooper 2014-03-04 3:08 ` Jason Cooper 2014-03-04 9:26 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Andrew Lunn 0 siblings, 2 replies; 35+ messages in thread From: Jason Cooper @ 2014-03-03 22:24 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 03, 2014 at 06:15:30PM +0000, Russell King - ARM Linux wrote: > On Mon, Mar 03, 2014 at 06:37:40PM +0100, Andrew Lunn wrote: > > On Mon, Mar 03, 2014 at 03:02:15PM +0000, Russell King - ARM Linux wrote: > > > On Mon, Feb 17, 2014 at 08:00:36PM +0000, Jason Cooper wrote: > > > > The corresponding driver didn't make it into v3.14, so we need to remove > > > > the node. Dove systems fail to boot with the node present and no > > > > driver. > > > > > > > > This node will be re-added when the driver makes it to mainline. > > > > > > I'm going to stick my oar in on this and ask what is a very fundamental > > > question. Better now than later ;-) > > > If we're adding the PMU interrupt controller as a separate "device" > > > aren't we describing our implementation rather than the hardware? It > > > isn't a separate device as far as the description of it in the reference > > > manuals. I could have sworn this was discussed with this particular patchset, but I'm unable to find the conversation in my archives. Neither during the patch submission process, nor the (long) pull request thread. Perhaps it was an irc conversation? Andrew, Sebastian, can you find a link? iirc, one of the DT maintainers (Mark Rutland?) raised the same concern and I thought we answered that sufficiently... > > > Moreover, should the PMU interrupt controller be something which is > > > handled by a separate chunk of code to a driver for the PMU as a whole, > > > or are we storing up problems with resource clashes? I can quite see > > > a PMU driver coming along in the future offering a pair of generic > > > power domains for the GPU and VPU, and such a driver would need to map > > > all the PMU registers so it can access the power control, reset and > > > isolator registers. > > > > Hi Russell > > > > I suspect you are right, we are storing up problems. > > > > During the 4 months between submitting this driver and actually > > getting it accepted, i've learned quite a bit. I tried to implement > > cpufreq for Dove and ran into the problems you mention. The registers > > in the PMU are interleaved so that you cannot cleanly separate out the > > range needed for cpufreq. We probably need a PMU device, which exports > > a register syscon and have the interrupt controller make use of it. This isn't the first time we've had this problem with Marvell SoCs. We added c5ca95b507c8 ARM: 7930/1: Introduce atomic MMIO modify To work around a much smaller version of this similar problem. > I know it's a pain to say this, but maybe we should hold off with the > PMU IRQ controller patch for a while longer until we get a proper idea > of what we're doing with the PMU? I've no issue with reverting this driver. I'll ask arm-soc to hold off on pulling the latest mvebu DT pull request which contains the DT node. I _really_ don't want to do a revert of a revert of a revert. :-/ thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-03 22:24 ` 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 9:26 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Andrew Lunn 1 sibling, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-03-04 3:08 UTC (permalink / raw) To: linux-arm-kernel On Mon, Mar 03, 2014 at 05:24:06PM -0500, Jason Cooper wrote: > I've no issue with reverting this driver. I'll ask arm-soc to hold off > on pulling the latest mvebu DT pull request which contains the DT node. > I _really_ don't want to do a revert of a revert of a revert. :-/ Done. I'll work on reverting the driver tomorrow. It's currently in tip/irq/core queued for v3.15. thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-04 3:08 ` Jason Cooper @ 2014-03-04 5:32 ` Jason Cooper 2014-03-05 0:41 ` Russell King - ARM Linux 0 siblings, 1 reply; 35+ messages in thread From: Jason Cooper @ 2014-03-04 5:32 UTC (permalink / raw) To: linux-arm-kernel This reverts commit 40b367d95fb3d60fc1edb9ba8f6ef52272e48936. Russell King has raised the idea of creating a proper PMU driver for this SoC that would incorporate the functionality currently in this driver. It would also cover the use case for the graphics subsystem on this SoC. To prevent having to maintain the devicetree ABI for this limited interrupt-handler driver, we revert the driver before it hits a mainline tagged release (eg v3.15). Signed-off-by: Jason Cooper <jason@lakedaemon.net> --- Thomas, Well, this is embarrassing. It took so long to get this driver on the road to mainline, only to realize today that we were going to paint ourselves into a corner wrt the devicetree ABI this creates. So, rather let a bad ABI make it to mainline, we revert the driver. We'll sit down with Russell, who's most familiar with the graphics subsystem on this SoC, and hammer out a better longterm solution. You can pick this, or I can send you an incremental pull request. Whichever is easiest for you. I've already removed the DT node from the mvebu tree, so this won't be used by anything. thx, Jason. .../interrupt-controller/marvell,dove-pmu-intc.txt | 17 --- drivers/irqchip/Makefile | 1 - drivers/irqchip/irq-dove.c | 126 --------------------- 3 files changed, 144 deletions(-) delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt delete mode 100644 drivers/irqchip/irq-dove.c diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt deleted file mode 100644 index 1feb5825d372..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt +++ /dev/null @@ -1,17 +0,0 @@ -Marvell Dove Power Management Unit interrupt controller - -Required properties: -- compatible: shall be "marvell,dove-pmu-intc" -- reg: base address of PMU interrupt registers starting with CAUSE register -- interrupts: PMU interrupt of the main interrupt controller -- interrupt-controller: identifies the node as an interrupt controller -- #interrupt-cells: number of cells to encode an interrupt source, shall be 1 - -Example: - pmu_intc: pmu-interrupt-ctrl at d0050 { - compatible = "marvell,dove-pmu-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd0050 0x8>; - interrupts = <33>; - }; diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile index f743006ce7ad..c60b9010b152 100644 --- a/drivers/irqchip/Makefile +++ b/drivers/irqchip/Makefile @@ -1,7 +1,6 @@ obj-$(CONFIG_IRQCHIP) += irqchip.o obj-$(CONFIG_ARCH_BCM2835) += irq-bcm2835.o -obj-$(CONFIG_ARCH_DOVE) += irq-dove.o obj-$(CONFIG_ARCH_EXYNOS) += exynos-combiner.o obj-$(CONFIG_ARCH_MMP) += irq-mmp.o obj-$(CONFIG_ARCH_MVEBU) += irq-armada-370-xp.o diff --git a/drivers/irqchip/irq-dove.c b/drivers/irqchip/irq-dove.c deleted file mode 100644 index 788acd89848a..000000000000 --- a/drivers/irqchip/irq-dove.c +++ /dev/null @@ -1,126 +0,0 @@ -/* - * Marvell Dove SoCs PMU IRQ chip driver. - * - * Andrew Lunn <andrew@lunn.ch> - * - * This file is licensed under the terms of the GNU General Public - * License version 2. This program is licensed "as is" without any - * warranty of any kind, whether express or implied. - */ - -#include <linux/io.h> -#include <linux/irq.h> -#include <linux/of.h> -#include <linux/of_address.h> -#include <linux/of_irq.h> -#include <asm/exception.h> -#include <asm/mach/irq.h> - -#include "irqchip.h" - -#define DOVE_PMU_IRQ_CAUSE 0x00 -#define DOVE_PMU_IRQ_MASK 0x04 - -static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc) -{ - struct irq_domain *d = irq_get_handler_data(irq); - struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0); - u32 stat = readl_relaxed(gc->reg_base + DOVE_PMU_IRQ_CAUSE) & - gc->mask_cache; - - while (stat) { - u32 hwirq = ffs(stat) - 1; - - generic_handle_irq(irq_find_mapping(d, gc->irq_base + hwirq)); - stat &= ~(1 << hwirq); - } -} - -static void pmu_irq_ack(struct irq_data *d) -{ - struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); - struct irq_chip_type *ct = irq_data_get_chip_type(d); - u32 mask = ~d->mask; - - /* - * The PMU mask register is not RW0C: it is RW. This means that - * the bits take whatever value is written to them; if you write - * a '1', you will set the interrupt. - * - * Unfortunately this means there is NO race free way to clear - * these interrupts. - * - * So, let's structure the code so that the window is as small as - * possible. - */ - irq_gc_lock(gc); - mask &= irq_reg_readl(gc->reg_base + ct->regs.ack); - irq_reg_writel(mask, gc->reg_base + ct->regs.ack); - irq_gc_unlock(gc); -} - -static int __init dove_pmu_irq_init(struct device_node *np, - struct device_node *parent) -{ - unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN; - struct resource r; - struct irq_domain *domain; - struct irq_chip_generic *gc; - int ret, irq, nrirqs = 7; - - domain = irq_domain_add_linear(np, nrirqs, - &irq_generic_chip_ops, NULL); - if (!domain) { - pr_err("%s: unable to add irq domain\n", np->name); - return -ENOMEM; - } - - ret = irq_alloc_domain_generic_chips(domain, nrirqs, 1, np->name, - handle_level_irq, clr, 0, IRQ_GC_INIT_MASK_CACHE); - if (ret) { - pr_err("%s: unable to alloc irq domain gc\n", np->name); - return ret; - } - - ret = of_address_to_resource(np, 0, &r); - if (ret) { - pr_err("%s: unable to get resource\n", np->name); - return ret; - } - - if (!request_mem_region(r.start, resource_size(&r), np->name)) { - pr_err("%s: unable to request mem region\n", np->name); - return -ENOMEM; - } - - /* Map the parent interrupt for the chained handler */ - irq = irq_of_parse_and_map(np, 0); - if (irq <= 0) { - pr_err("%s: unable to parse irq\n", np->name); - return -EINVAL; - } - - gc = irq_get_domain_generic_chip(domain, 0); - gc->reg_base = ioremap(r.start, resource_size(&r)); - if (!gc->reg_base) { - pr_err("%s: unable to map resource\n", np->name); - return -ENOMEM; - } - - gc->chip_types[0].regs.ack = DOVE_PMU_IRQ_CAUSE; - gc->chip_types[0].regs.mask = DOVE_PMU_IRQ_MASK; - gc->chip_types[0].chip.irq_ack = pmu_irq_ack; - gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit; - gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit; - - /* mask and clear all interrupts */ - writel(0, gc->reg_base + DOVE_PMU_IRQ_MASK); - writel(0, gc->reg_base + DOVE_PMU_IRQ_CAUSE); - - irq_set_handler_data(irq, domain); - irq_set_chained_handler(irq, dove_pmu_irq_handler); - - return 0; -} -IRQCHIP_DECLARE(dove_pmu_intc, - "marvell,dove-pmu-intc", dove_pmu_irq_init); -- 1.9.0 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-04 5:32 ` [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." Jason Cooper @ 2014-03-05 0:41 ` Russell King - ARM Linux 2014-03-05 9:24 ` Andrew Lunn ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-05 0:41 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 05:32:40AM +0000, Jason Cooper wrote: > -static void dove_pmu_irq_handler(unsigned int irq, struct irq_desc *desc) > -{ > - struct irq_domain *d = irq_get_handler_data(irq); > - struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0); > - u32 stat = readl_relaxed(gc->reg_base + DOVE_PMU_IRQ_CAUSE) & > - gc->mask_cache; > - > - while (stat) { > - u32 hwirq = ffs(stat) - 1; > - > - generic_handle_irq(irq_find_mapping(d, gc->irq_base + hwirq)); > - stat &= ~(1 << hwirq); > - } > -} > - > -static void pmu_irq_ack(struct irq_data *d) > -{ > - struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d); > - struct irq_chip_type *ct = irq_data_get_chip_type(d); > - u32 mask = ~d->mask; > - > - /* > - * The PMU mask register is not RW0C: it is RW. This means that > - * the bits take whatever value is written to them; if you write > - * a '1', you will set the interrupt. > - * > - * Unfortunately this means there is NO race free way to clear > - * these interrupts. > - * > - * So, let's structure the code so that the window is as small as > - * possible. > - */ > - irq_gc_lock(gc); > - mask &= irq_reg_readl(gc->reg_base + ct->regs.ack); > - irq_reg_writel(mask, gc->reg_base + ct->regs.ack); > - irq_gc_unlock(gc); > -} Jason, Thomas, I've just been giving the above a whirl here with the RTC, and it doesn't seem to quite work as it should. Not your problem, because it's as the code is originally. Let's say you set an alarm for 10sec time. When the alarm fires: - we read the PMU interrupt status, mask it with the mask register, and find the RTC pending. - we call the genirq layer for this interrupt. - genirq does the mask + ack thing. - the RTC interrupt handler is called, and there's the RTC says there's an interrupt pending. - the RTC handler clears the interrupt, and returns. - genirq unmasks the interrupt, and returns. - dove_pmu_irq_handler() is re-entered, and again, we find that the RTC interrupt is pending. - follow the above... - the RTC interrupt handler is called, but this time there's no interrupt pending, so returns IRQ_NONE - genirq unmasks the interrupt, and returns. The reason this happens is that the attempt to "ack" - rather "clear" the interrupt the first time around has no effect - the RTC is still asserting the interrupt, so the write to clear the register results in the bit remaining set. The second time around, we've already cleared the RTC interrupt, so this time, the ack clears the interrupt down properly. 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? 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! -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-05 0:41 ` Russell King - ARM Linux @ 2014-03-05 9:24 ` Andrew Lunn 2014-03-05 11:52 ` Carlo Caione 2014-03-05 14:42 ` Thomas Gleixner 2 siblings, 0 replies; 35+ messages in thread From: Andrew Lunn @ 2014-03-05 9:24 UTC (permalink / raw) To: linux-arm-kernel > >From the spec, it looks like this is probably true of DFSDone as well. The cpufreq driver makes use of DFSDone. I've never had it loop endlessly. There is also no action needed to clear it in the DFS hardware. Andrew ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-05 0:41 ` Russell King - ARM Linux 2014-03-05 9:24 ` Andrew Lunn @ 2014-03-05 11:52 ` Carlo Caione 2014-03-05 14:42 ` Thomas Gleixner 2 siblings, 0 replies; 35+ messages in thread From: Carlo Caione @ 2014-03-05 11:52 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 5, 2014 at 1:41 AM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Tue, Mar 04, 2014 at 05:32:40AM +0000, Jason Cooper wrote: > > Jason, Thomas, > > I've just been giving the above a whirl here with the RTC, and it > doesn't seem to quite work as it should. Not your problem, because it's > as the code is originally. > > Let's say you set an alarm for 10sec time. When the alarm fires: > > - we read the PMU interrupt status, mask it with the mask register, > and find the RTC pending. > - we call the genirq layer for this interrupt. > - genirq does the mask + ack thing. > - the RTC interrupt handler is called, and there's the RTC says there's > an interrupt pending. > - the RTC handler clears the interrupt, and returns. > - genirq unmasks the interrupt, and returns. > - dove_pmu_irq_handler() is re-entered, and again, we find that the > RTC interrupt is pending. > - follow the above... > - the RTC interrupt handler is called, but this time there's no interrupt > pending, so returns IRQ_NONE > - genirq unmasks the interrupt, and returns. > > The reason this happens is that the attempt to "ack" - rather "clear" the > interrupt the first time around has no effect - the RTC is still asserting > the interrupt, so the write to clear the register results in the bit > remaining set. > > The second time around, we've already cleared the RTC interrupt, so this > time, the ack clears the interrupt down properly. > > 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? I don't know if this could help but I have a very similar problem with the NMI controller found on sun6i/sun7i for which is pending the patchset http://comments.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7554 Also in that case the first ACK has no effect and in the end I use the unmask hook in the irqchip driver to ACK again the line before unmasking it (the whole discussion about this problem among me, Maxime and Hans is in this thread http://www.spinics.net/lists/arm-kernel/msg299952.html ) I also proposed a small (and as it turned out incomplete) patch here http://www.spinics.net/lists/arm-kernel/msg305616.html but in the end I preferred to use the unmask hook. -- Carlo Caione ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-05 0:41 ` Russell King - ARM Linux 2014-03-05 9:24 ` Andrew Lunn 2014-03-05 11:52 ` Carlo Caione @ 2014-03-05 14:42 ` Thomas Gleixner 2014-03-05 19:20 ` Russell King - ARM Linux 2 siblings, 1 reply; 35+ messages in thread From: Thomas Gleixner @ 2014-03-05 14:42 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-05 14:42 ` Thomas Gleixner @ 2014-03-05 19:20 ` Russell King - ARM Linux 2014-03-05 21:36 ` Thomas Gleixner 0 siblings, 1 reply; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-05 19:20 UTC (permalink / raw) To: linux-arm-kernel On Wed, Mar 05, 2014 at 03:42:34PM +0100, Thomas Gleixner wrote: > On Wed, 5 Mar 2014, Russell King - ARM Linux wrote: > > 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? Yep. Let's take the code: ldr r0, [r1] ; read the interrupt cause register and r0, r0, r2 ; clear interrupts we've serviced str r0, [r1] ; write it back The problem here is if a transitory interrupt is received between the load and store, the write can clear it back to zero. There's nothing which can be done to get around that - which is why I'd prefer to do this as infrequently as necessary. > Is the datasheet for this stuff public available? Thankfully, it is, but like many such things, it'll leave you with /lots/ of questions. In the case of this register, the documentation only goes as far as describing the bits, but doesn't really describe their behaviour. Much of that can only come via experimentation with the hardware. :( > I don't think it matters in which order you process multiple pending > interrupts. Me neither - I'm just going to use fls() for no other reason that it produces more efficient code. My comments on that were to see whether I'd missed anything, and to stave off any review comments about why it's changed :) -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller." 2014-03-05 19:20 ` Russell King - ARM Linux @ 2014-03-05 21:36 ` Thomas Gleixner 0 siblings, 0 replies; 35+ messages in thread From: Thomas Gleixner @ 2014-03-05 21:36 UTC (permalink / raw) To: linux-arm-kernel On Wed, 5 Mar 2014, Russell King - ARM Linux wrote: > On Wed, Mar 05, 2014 at 03:42:34PM +0100, Thomas Gleixner wrote: > > On Wed, 5 Mar 2014, Russell King - ARM Linux wrote: > > > 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? > > Yep. Let's take the code: > > ldr r0, [r1] ; read the interrupt cause register > and r0, r0, r2 ; clear interrupts we've serviced > str r0, [r1] ; write it back > > The problem here is if a transitory interrupt is received between the > load and store, the write can clear it back to zero. There's nothing > which can be done to get around that - which is why I'd prefer to do > this as infrequently as necessary. Yes, that's the only sensible thing you can do. Is there any transient interrupt connected to that irq controller or is this as vague as the rest of the documentation? > > Is the datasheet for this stuff public available? > > Thankfully, it is, but like many such things, it'll leave you with /lots/ > of questions. In the case of this register, the documentation only goes > as far as describing the bits, but doesn't really describe their behaviour. > Much of that can only come via experimentation with the hardware. :( Sigh. I really want to understand why SoC companies waste lots of resources to implement pointless and disfunctional variants of interrupt controllers (or timers) over and over. Thanks, tglx ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-03 22:24 ` Jason Cooper 2014-03-04 3:08 ` Jason Cooper @ 2014-03-04 9:26 ` Andrew Lunn 2014-03-04 10:39 ` Sebastian Hesselbarth 1 sibling, 1 reply; 35+ messages in thread From: Andrew Lunn @ 2014-03-04 9:26 UTC (permalink / raw) To: linux-arm-kernel > I could have sworn this was discussed with this particular patchset, but > I'm unable to find the conversation in my archives. Neither during the > patch submission process, nor the (long) pull request thread. > > Perhaps it was an irc conversation? Andrew, Sebastian, can you find a > link? iirc, one of the DT maintainers (Mark Rutland?) raised the same > concern and I thought we answered that sufficiently... Hi Jason It was the cpufreq driver which caused the discussion. I looked at it for a while, and then task swapped onto the kirkwood move into mach-mvebu. Andrew ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 9:26 ` [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node Andrew Lunn @ 2014-03-04 10:39 ` Sebastian Hesselbarth 2014-03-04 12:11 ` Russell King - ARM Linux 0 siblings, 1 reply; 35+ messages in thread From: Sebastian Hesselbarth @ 2014-03-04 10:39 UTC (permalink / raw) To: linux-arm-kernel On 03/04/2014 10:26 AM, Andrew Lunn wrote: >> I could have sworn this was discussed with this particular patchset, but >> I'm unable to find the conversation in my archives. Neither during the >> patch submission process, nor the (long) pull request thread. >> >> Perhaps it was an irc conversation? Andrew, Sebastian, can you find a >> link? iirc, one of the DT maintainers (Mark Rutland?) raised the same >> concern and I thought we answered that sufficiently... > > It was the cpufreq driver which caused the discussion. I looked at it > for a while, and then task swapped onto the kirkwood move into > mach-mvebu. I guess you are looking for this discussion http://comments.gmane.org/gmane.linux.power-management.general/41053 and specifically Mark's remarks on PMU and DT in here http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 BTW, +1 for a single PMU node that either serves an mfd (or type of) driver or that subsystem drivers derive their resources from. Looking at Dove FS, that would also include clock gating, which could be a mess to sort out.. anyway, let's get it on. Sebastian ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 10:39 ` Sebastian Hesselbarth @ 2014-03-04 12:11 ` Russell King - ARM Linux 2014-03-04 13:53 ` Jason Cooper 0 siblings, 1 reply; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-04 12:11 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 11:39:43AM +0100, Sebastian Hesselbarth wrote: > On 03/04/2014 10:26 AM, Andrew Lunn wrote: >>> I could have sworn this was discussed with this particular patchset, but >>> I'm unable to find the conversation in my archives. Neither during the >>> patch submission process, nor the (long) pull request thread. >>> >>> Perhaps it was an irc conversation? Andrew, Sebastian, can you find a >>> link? iirc, one of the DT maintainers (Mark Rutland?) raised the same >>> concern and I thought we answered that sufficiently... >> >> It was the cpufreq driver which caused the discussion. I looked at it >> for a while, and then task swapped onto the kirkwood move into >> mach-mvebu. > > I guess you are looking for this discussion > > http://comments.gmane.org/gmane.linux.power-management.general/41053 > > and specifically Mark's remarks on PMU and DT in here > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 > > BTW, +1 for a single PMU node that either serves an mfd (or type > of) driver or that subsystem drivers derive their resources from. > Looking at Dove FS, that would also include clock gating, which > could be a mess to sort out.. anyway, let's get it on. So we have cpufreq, pm domains and an irq controller. What's the plan for this, who's going to look at sorting this out? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 12:11 ` Russell King - ARM Linux @ 2014-03-04 13:53 ` Jason Cooper 2014-03-04 13:54 ` Andrew Lunn 2014-03-04 14:02 ` Sebastian Hesselbarth 0 siblings, 2 replies; 35+ messages in thread From: Jason Cooper @ 2014-03-04 13:53 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 12:11:36PM +0000, Russell King - ARM Linux wrote: > On Tue, Mar 04, 2014 at 11:39:43AM +0100, Sebastian Hesselbarth wrote: > > On 03/04/2014 10:26 AM, Andrew Lunn wrote: > >>> I could have sworn this was discussed with this particular patchset, but > >>> I'm unable to find the conversation in my archives. Neither during the > >>> patch submission process, nor the (long) pull request thread. > >>> > >>> Perhaps it was an irc conversation? Andrew, Sebastian, can you find a > >>> link? iirc, one of the DT maintainers (Mark Rutland?) raised the same > >>> concern and I thought we answered that sufficiently... > >> > >> It was the cpufreq driver which caused the discussion. I looked at it > >> for a while, and then task swapped onto the kirkwood move into > >> mach-mvebu. > > > > I guess you are looking for this discussion > > > > http://comments.gmane.org/gmane.linux.power-management.general/41053 > > > > and specifically Mark's remarks on PMU and DT in here > > > > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 > > > > BTW, +1 for a single PMU node that either serves an mfd (or type > > of) driver or that subsystem drivers derive their resources from. > > Looking at Dove FS, that would also include clock gating, which > > could be a mess to sort out.. anyway, let's get it on. > > So we have cpufreq, pm domains and an irq controller. What's the plan > for this, who's going to look at sorting this out? Andrew, Sebastian? I'm currently task-saturated... thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 13:53 ` Jason Cooper @ 2014-03-04 13:54 ` Andrew Lunn 2014-03-04 14:01 ` Russell King - ARM Linux 2014-03-04 14:02 ` Sebastian Hesselbarth 1 sibling, 1 reply; 35+ messages in thread From: Andrew Lunn @ 2014-03-04 13:54 UTC (permalink / raw) To: linux-arm-kernel > > So we have cpufreq, pm domains and an irq controller. What's the plan > > for this, who's going to look at sorting this out? > > Andrew, Sebastian? I'm currently task-saturated... I doubt i will be doing anything with it for the remainder of this cycle. I would like to finish converting kirkwood to DT before starting on anything new. Andrew ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 13:54 ` Andrew Lunn @ 2014-03-04 14:01 ` Russell King - ARM Linux 2014-03-04 14:41 ` Andrew Lunn 0 siblings, 1 reply; 35+ messages in thread From: Russell King - ARM Linux @ 2014-03-04 14:01 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 02:54:52PM +0100, Andrew Lunn wrote: > > > So we have cpufreq, pm domains and an irq controller. What's the plan > > > for this, who's going to look at sorting this out? > > > > Andrew, Sebastian? I'm currently task-saturated... > > I doubt i will be doing anything with it for the remainder of this > cycle. I would like to finish converting kirkwood to DT before > starting on anything new. Okay, can someone send me the cpufreq code then please? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 14:01 ` Russell King - ARM Linux @ 2014-03-04 14:41 ` Andrew Lunn 0 siblings, 0 replies; 35+ messages in thread From: Andrew Lunn @ 2014-03-04 14:41 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 02:01:36PM +0000, Russell King - ARM Linux wrote: > On Tue, Mar 04, 2014 at 02:54:52PM +0100, Andrew Lunn wrote: > > > > So we have cpufreq, pm domains and an irq controller. What's the plan > > > > for this, who's going to look at sorting this out? > > > > > > Andrew, Sebastian? I'm currently task-saturated... > > > > I doubt i will be doing anything with it for the remainder of this > > cycle. I would like to finish converting kirkwood to DT before > > starting on anything new. > > Okay, can someone send me the cpufreq code then please? Hi Russell Take a look at: https://github.com/lunn/linux.git v3.13-rc2-rafael-next-dove-cpufreq The cpufreq drivers/framework have been going through quite a bit of refactoring recently, so maybe some work will be needed on it. Andrew ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 13:53 ` Jason Cooper 2014-03-04 13:54 ` Andrew Lunn @ 2014-03-04 14:02 ` Sebastian Hesselbarth 2014-03-04 14:18 ` Jason Cooper 1 sibling, 1 reply; 35+ messages in thread From: Sebastian Hesselbarth @ 2014-03-04 14:02 UTC (permalink / raw) To: linux-arm-kernel On 03/04/2014 02:53 PM, Jason Cooper wrote: > On Tue, Mar 04, 2014 at 12:11:36PM +0000, Russell King - ARM Linux wrote: >> On Tue, Mar 04, 2014 at 11:39:43AM +0100, Sebastian Hesselbarth wrote: >>> On 03/04/2014 10:26 AM, Andrew Lunn wrote: >>>>> I could have sworn this was discussed with this particular patchset, but >>>>> I'm unable to find the conversation in my archives. Neither during the >>>>> patch submission process, nor the (long) pull request thread. >>>>> >>>>> Perhaps it was an irc conversation? Andrew, Sebastian, can you find a >>>>> link? iirc, one of the DT maintainers (Mark Rutland?) raised the same >>>>> concern and I thought we answered that sufficiently... >>>> >>>> It was the cpufreq driver which caused the discussion. I looked at it >>>> for a while, and then task swapped onto the kirkwood move into >>>> mach-mvebu. >>> >>> I guess you are looking for this discussion >>> >>> http://comments.gmane.org/gmane.linux.power-management.general/41053 >>> >>> and specifically Mark's remarks on PMU and DT in here >>> >>> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 >>> >>> BTW, +1 for a single PMU node that either serves an mfd (or type >>> of) driver or that subsystem drivers derive their resources from. >>> Looking at Dove FS, that would also include clock gating, which >>> could be a mess to sort out.. anyway, let's get it on. >> >> So we have cpufreq, pm domains and an irq controller. What's the plan >> for this, who's going to look at sorting this out? > > Andrew, Sebastian? I'm currently task-saturated... Phew, looks like I'll have to take it? Are you guys ok with having a single PMU node with syscon provided regmap and make all drivers depend on it? I'd like to get a go from Russell here, as he has clearly something in mind. We can consolidate drivers later if required. If we start that now, we definitely risk running out of time for v3.15. Sebastian ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node 2014-03-04 14:02 ` Sebastian Hesselbarth @ 2014-03-04 14:18 ` Jason Cooper 0 siblings, 0 replies; 35+ messages in thread From: Jason Cooper @ 2014-03-04 14:18 UTC (permalink / raw) To: linux-arm-kernel On Tue, Mar 04, 2014 at 03:02:25PM +0100, Sebastian Hesselbarth wrote: > On 03/04/2014 02:53 PM, Jason Cooper wrote: > >On Tue, Mar 04, 2014 at 12:11:36PM +0000, Russell King - ARM Linux wrote: > >>On Tue, Mar 04, 2014 at 11:39:43AM +0100, Sebastian Hesselbarth wrote: > >>>On 03/04/2014 10:26 AM, Andrew Lunn wrote: > >>>>>I could have sworn this was discussed with this particular patchset, but > >>>>>I'm unable to find the conversation in my archives. Neither during the > >>>>>patch submission process, nor the (long) pull request thread. > >>>>> > >>>>>Perhaps it was an irc conversation? Andrew, Sebastian, can you find a > >>>>>link? iirc, one of the DT maintainers (Mark Rutland?) raised the same > >>>>>concern and I thought we answered that sufficiently... > >>>> > >>>>It was the cpufreq driver which caused the discussion. I looked at it > >>>>for a while, and then task swapped onto the kirkwood move into > >>>>mach-mvebu. > >>> > >>>I guess you are looking for this discussion > >>> > >>>http://comments.gmane.org/gmane.linux.power-management.general/41053 > >>> > >>>and specifically Mark's remarks on PMU and DT in here > >>> > >>>http://permalink.gmane.org/gmane.linux.ports.arm.kernel/285384 > >>> > >>>BTW, +1 for a single PMU node that either serves an mfd (or type > >>>of) driver or that subsystem drivers derive their resources from. > >>>Looking at Dove FS, that would also include clock gating, which > >>>could be a mess to sort out.. anyway, let's get it on. > >> > >>So we have cpufreq, pm domains and an irq controller. What's the plan > >>for this, who's going to look at sorting this out? > > > >Andrew, Sebastian? I'm currently task-saturated... > > Phew, looks like I'll have to take it? > > Are you guys ok with having a single PMU node with syscon provided > regmap and make all drivers depend on it? I'd like to get a go from > Russell here, as he has clearly something in mind. > > We can consolidate drivers later if required. If we start that now, > we definitely risk running out of time for v3.15. Honestly, mvebu has enough going on atm. I would target v3.16 and take our time. At least with the binding. If the driver comes together easily, we could always do like we did for mbus. Do a legacy init from the board (soc) file, then switch to the dt binding once everyone is happy with it. v3.14-rc6 is less than a week away, so I'll be sending final mvebu pull requests late Wednesday/Thursday... v3.14-rcX has been awful quiet, there might not be an -rc7. thx, Jason. ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2014-03-05 21:36 UTC | newest] Thread overview: 35+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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-02-04 18:59 ` Thomas Gleixner 2014-02-04 19:05 ` Jason Cooper 2014-02-04 21:12 ` Jason Cooper 2014-02-04 21:30 ` Thomas Gleixner 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:32 ` [GIT PULL] irqchip: dove: drivers for v3.14 Jason Cooper 2014-02-18 20:51 ` Thomas Gleixner 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-03-03 15:02 ` Russell King - ARM Linux 2014-03-03 17:37 ` Andrew Lunn 2014-03-03 18:15 ` Russell King - ARM Linux 2014-03-03 22:24 ` 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-05 0:41 ` Russell King - ARM Linux 2014-03-05 9:24 ` Andrew Lunn 2014-03-05 11:52 ` Carlo Caione 2014-03-05 14:42 ` Thomas Gleixner 2014-03-05 19:20 ` Russell King - ARM Linux 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 10:39 ` Sebastian Hesselbarth 2014-03-04 12:11 ` Russell King - ARM Linux 2014-03-04 13:53 ` Jason Cooper 2014-03-04 13:54 ` Andrew Lunn 2014-03-04 14:01 ` Russell King - ARM Linux 2014-03-04 14:41 ` Andrew Lunn 2014-03-04 14:02 ` Sebastian Hesselbarth 2014-03-04 14:18 ` Jason Cooper
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).