[FOR DISCUSSION 0/9] Dove PMU support

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

This is a re-posting of the patch set which I posted almost 10 months
ago to support the Dove PMU, with a few additional changes.  This set
is based upon 3.19.

In this set are:

* two patches which Rafael originally acked, but there was indecision
  last time around how to handle them due to potential conflicts with
  work that Ulf was doing.  These patches have been updated to apply
  cleanly to 3.19.  I don't know if people want to take these as
  fixes to the PM domain code or not (hence why I'm posting this
  series during the merge window - if it weren't for this, I'd hold
  it off.)

* what I regard as a fix to the PM domain code; as a result of a
  previous commit, the PM domain code mismatches the runtime PM state,
  which leads to the PM domain being unexpectedly left on.  This patch
  has been re-worked to try an alternative approach, syncing the PM
  domain state with the runtime PM state after the probe has completed.

* the addition of the core Dove PMU driver, which consists of a reset,
  IRQ controller, and power domains.  The reset and power domain code
  has to be closely related due to the power up/down requirements of
  the GPU/VPU subsystems needing to be performed atomically.  (This
  requirement prevents it using the MFD infrastructure, because we
  would need to hold spinlocks while calling several different
  sub-drivers.)

* addition of the RTC interrupt, so we can now receive and act on
  alarms generated by the Dove RTC.

* addition of the DT descriptions for the GPU and VPU power domains.
  These patches do not themselves add the DT descriptions for these
  units, so these patches serve as illustrations how these should be
  described.

I've also included the DT binding documentation as a separate patch this
time around, and moved the PMU driver to drivers/soc/dove.

There are some gotchas with it - PM domains need to be created prior
to any device which uses them being probed, so it is best if the driver
is initialised early in the kernel boot.  We may be able to get away
with a core_initcall() or a postcore_initcall().

I'd ideally like to get these queued for merging in the _next_ merge
window if at all possible, if only to reduce the number of patches I've
been carrying for the last few years.  Failing that, if at least the
patches which Rafael has already acked could be applied, that would at
least get /some/ form of forward progress.

 Documentation/devicetree/bindings/soc/dove/pmu.txt |  49 +++
 arch/arm/boot/dts/dove.dtsi                        |  25 ++
 arch/arm/mach-mvebu/Kconfig                        |   1 +
 drivers/base/platform.c                            |   2 +
 drivers/base/power/common.c                        |  15 +
 drivers/base/power/domain.c                        |  33 +-
 drivers/soc/Makefile                               |   1 +
 drivers/soc/dove/Makefile                          |   1 +
 drivers/soc/dove/pmu.c                             | 399 +++++++++++++++++++++
 include/linux/pm.h                                 |   1 +
 include/linux/pm_domain.h                          |   4 +
 include/linux/soc/dove/pmu.h                       |   6 +
 12 files changed, 532 insertions(+), 5 deletions(-)

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.