From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [PATCH v3 0/4] clk: st: New always-on clock domain Date: Thu, 26 Mar 2015 13:51:44 +0000 Message-ID: <20150326135144.GI5951@x1> References: <1424799222-9301-1-git-send-email-lee.jones@linaro.org> <20150304120003.GL32624@x1> <20150306190812.11109.82130@quantum> <20150309092804.GB3427@x1> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Geert Uytterhoeven Cc: Mike Turquette , "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org, Stephen Boyd , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: > Hi Lee, >=20 > On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wro= te: > > On Fri, 06 Mar 2015, Mike Turquette wrote: > >> Quoting Lee Jones (2015-03-04 04:00:03) > >> > Mike, > >> > > >> > Do you want me to resend this set with Robert's Reviewed-by appl= ied, > >> > or are you happy to apply it yourself? > >> > >> No need for the resend. I am hoping for a final review from a DT h= uman. > >> > >> This approach looks fine to me. In practice I think it is restrict= ed to > >> hardware blocks that don't exist in DT yet (e.g. no driver, in the= case > >> of your interconnect) and that restriction is probably for the bes= t. > > > > Agreed. >=20 > I think this restriction should be documented in the DT binding more = clearly, > as adding a "clk-always-on" node prohibits you from handling the cloc= k > correctly in > the future. Would you mind taking the time to explain what you think those limitations are? > Still, for simple devices where you don't have a driver, but have "pr= edictable" > bindings (e.g. a bus like "simple-pm-bus"), I think it's better to ad= d > a device node > for that simple device now, incl. a reference to the clock, and have = a simple > driver that binds to the device, or platform code that looks for a > compatible node, > and enables the clock. That way you don't have to make any chances to= the DTS > later, when you'll have a real driver. >=20 > >> > > v2 =3D> 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 =3D> v2: > >> > > - Turned the ST specific driver into a generic one > >> > > > >> > > Hardware can have a bunch of clocks which must not be turned o= ff. > >> > > 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 i= s to > >> > > restart. > >> > > > >> > > To avoid either of these two scenarios from catastrophically > >> > > disabling the running system we have implemented a clock domai= n > >> > > where clocks are consumed and references are taken, thus preve= nting > >> > > them from being shut down by the framework. >=20 > Gr{oetje,eeting}s, >=20 > Geert >=20 --=20 Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org =E2=94=82 Open source software for ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" i= n the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html