| Message ID | 20131201172914.GV2879@titan.lakedaemon.net |
|---|---|
| State | New |
| Headers | show |
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@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Thomas, On Wed, Dec 11, 2013 at 12:50:37PM -0500, Jason Cooper wrote: > On Sun, Dec 01, 2013 at 12:29:14PM -0500, Jason Cooper wrote: > > Here's an mvebu driver we've had on the ML for a while, and it's been in > > -next for 5 days. > > Just checking to make sure this hasn't slipped off of your plate. > I'm not able to see where this one might have been pulled, could you please pull or let me know if it's not acceptable? thx, Jason. > > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: > > > > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) > > > > are available in the git repository at: > > > > git://git.infradead.org/linux-mvebu.git tags/mvebu-irqchip-3.14 > > > > for you to fetch changes up to 40b367d95fb3d60fc1edb9ba8f6ef52272e48936: > > > > irqchip: irq-dove: Add PMU interrupt controller. (2013-11-26 15:04:53 +0000) > > > > ---------------------------------------------------------------- > > mvebu irqchip changes for v3.14 > > > > - add Dove PMU interrupt controller > > > > ---------------------------------------------------------------- > > Andrew Lunn (1): > > irqchip: irq-dove: Add PMU interrupt controller. > > > > .../interrupt-controller/marvell,dove-pmu-intc.txt | 17 +++ > > drivers/irqchip/Makefile | 1 + > > drivers/irqchip/irq-dove.c | 126 +++++++++++++++++++++ > > 3 files changed, 144 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/interrupt-controller/marvell,dove-pmu-intc.txt > > create mode 100644 drivers/irqchip/irq-dove.c > > > > _______________________________________________ > > linux-arm-kernel mailing list > > linux-arm-kernel@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
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
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
> 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
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
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?
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.
> > 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
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?
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
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.
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
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!
> >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
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.
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
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 :)
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
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