On Tue, 24 Feb 2015, Lee Jones wrote: > v2 => v3: > - Ensure DT actually reflects h/w > - i.e. Nodes should not contain a mishmash of different IP > blocks, but should identify related h/w. In the current > example we use interconnects > - Change naming from clkdomain to clk-always-on > - Place "do not abuse" warning in documentation > > v1 => v2: > - Turned the ST specific driver into a generic one > > Hardware can have a bunch of clocks which must not be turned off. > If drivers a) fail to obtain a reference to any of these or b) give > up a previously obtained reference during suspend, the common clk > framework will attempt to turn them off and the hardware will > subsequently die. The only way to recover from this failure is to > restart. > > To avoid either of these two scenarios from catastrophically > disabling the running system we have implemented a clock domain > where clocks are consumed and references are taken, thus preventing > them from being shut down by the framework. > > *** BLURB HERE *** *grumble*, that's annoying, as I removed this. I guess Git caches the patches before sending them. > Lee Jones (4): > ARM: sti: stih407-family: Supply defines for CLOCKGEN A0 > ARM: sti: stih407-family: Add platform interconnects to always-on clk > domain > clk: Provide an always-on clock domain framework > clk: dt: Introduce always-on clock domain documentation > > .../devicetree/bindings/clock/clk-always-on.txt | 35 ++++++++++++ > arch/arm/boot/dts/stih407-family.dtsi | 15 ++++++ > drivers/clk/Makefile | 1 + > drivers/clk/clk-always-on.c | 62 ++++++++++++++++++++++ > include/dt-bindings/clock/stih407-clks.h | 4 ++ > 5 files changed, 117 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt > create mode 100644 drivers/clk/clk-always-on.c > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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
