[GIT PULL] irqchip: dove: drivers for v3.14

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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.

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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

[GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[RESEND PATCH] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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@d0050 {
-				compatible = "marvell,dove-pmu-intc";
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0xd0050 0x8>;
-				interrupts = <33>;
-				marvell,#interrupts = <7>;
-			};
-
 			pinctrl: pin-ctrl@d0200 {
 				compatible = "marvell,dove-pinctrl";
 				reg = <0xd0200 0x10>;
-- 
1.8.5.5

[RESEND PATCH] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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@d0050 {
-				compatible = "marvell,dove-pmu-intc";
-				interrupt-controller;
-				#interrupt-cells = <1>;
-				reg = <0xd0050 0x8>;
-				interrupts = <33>;
-				marvell,#interrupts = <7>;
-			};
-
 			pinctrl: pin-ctrl@d0200 {
 				compatible = "marvell,dove-pinctrl";
 				reg = <0xd0200 0x10>;
@@ -610,8 +601,6 @@
 			rtc: real-time-clock@d8500 {
 				compatible = "marvell,orion-rtc";
 				reg = <0xd8500 0x20>;
-				interrupt-parent = <&pmu_intc>;
-				interrupts = <5>;
 			};
 
 			gpio2: gpio-ctrl@e8400 {
-- 
1.8.5.5

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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

[GIT PULL] irqchip: dove: drivers for v3.14

[Thomas Gleixner]

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

Re: [GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

[GIT PULL] irqchip: dove: drivers for v3.14

[Jason Cooper]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Jason Cooper]

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

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Jason Cooper]

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

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

> 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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

> 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

[tip:irq/core] Revert irqchip: irq-dove: Add PMU interrupt controller

[tip-bot for Jason Cooper]

Commit-ID:  eb9cf4e8ec646a553f3b561d7a9e81acf044d876
Gitweb:     http://git.kernel.org/tip/eb9cf4e8ec646a553f3b561d7a9e81acf044d876
Author:     Jason Cooper <jason@lakedaemon.net>
AuthorDate: Tue, 4 Mar 2014 05:32:40 +0000
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Tue, 4 Mar 2014 11:10:17 +0100

Revert irqchip: irq-dove: Add PMU interrupt controller

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>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Link: http://lkml.kernel.org/r/1393911160-7688-1-git-send-email-jason@lakedaemon.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 .../interrupt-controller/marvell,dove-pmu-intc.txt |  17 ---
 drivers/irqchip/Makefile                           |   1 -
 drivers/irqchip/irq-dove.c                         | 126 ---------------------
 3 files changed, 144 deletions(-)

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 1feb582..0000000
--- 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@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 98589e7..5194afb 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 788acd8..0000000
--- 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);

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Sebastian Hesselbarth]

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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Sebastian Hesselbarth]

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

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Russell King - ARM Linux]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Sebastian Hesselbarth]

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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Sebastian Hesselbarth]

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

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Jason Cooper]

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.

Re: [PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

[PATCH V2] ARM: dove: dt: revert PMU interrupt controller node

[Andrew Lunn]

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

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Russell King - ARM Linux]

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.

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Russell King - ARM Linux]

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.

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Andrew Lunn]

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

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Andrew Lunn]

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

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Carlo Caione]

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

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Carlo Caione]

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

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Thomas Gleixner]

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

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Thomas Gleixner]

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

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Russell King - ARM Linux]

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.

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Russell King - ARM Linux]

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.

Re: [PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Thomas Gleixner]

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

[PATCH] Revert "irqchip: irq-dove: Add PMU interrupt controller."

[Thomas Gleixner]

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