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 works around that. (It's been sent recently as well but in an old thread.) * 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. There are a few things which are missing from this driver, such sa the DT binding documentation. This will follow once people are happy with the first four patches, in particular where to locate the PMU driver in the kernel tree. Currently, I have it in arch/arm/mach-dove, which is where the legacy Dove code lives, so it's not ideal. 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 really 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. arch/arm/Kconfig | 1 + arch/arm/boot/dts/dove.dtsi | 25 +++ arch/arm/mach-dove/Makefile | 1 + arch/arm/mach-dove/common.c | 2 + arch/arm/mach-dove/common.h | 1 + arch/arm/mach-dove/include/mach/pm.h | 17 -- arch/arm/mach-dove/irq.c | 87 -------- arch/arm/mach-dove/pmu.c | 410 +++++++++++++++++++++++++++++++++++ drivers/base/power/domain.c | 26 ++- drivers/base/power/runtime.c | 5 + include/linux/pm.h | 1 + 11 files changed, 466 insertions(+), 110 deletions(-) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
