From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752130AbbDBKsp (ORCPT ); Thu, 2 Apr 2015 06:48:45 -0400 Received: from mail-wi0-f177.google.com ([209.85.212.177]:36788 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751215AbbDBKsn (ORCPT ); Thu, 2 Apr 2015 06:48:43 -0400 Date: Thu, 2 Apr 2015 11:48:38 +0100 From: Lee Jones To: Geert Uytterhoeven Cc: Mike Turquette , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , kernel@stlinux.com, Stephen Boyd , "devicetree@vger.kernel.org" Subject: Re: [PATCH v3 0/4] clk: st: New always-on clock domain Message-ID: <20150402104838.GZ9447@x1> References: <1424799222-9301-1-git-send-email-lee.jones@linaro.org> <20150304120003.GL32624@x1> <20150306190812.11109.82130@quantum> <20150309092804.GB3427@x1> <20150326135144.GI5951@x1> <20150326193818.GQ5951@x1> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 02 Apr 2015, Geert Uytterhoeven wrote: > On Thu, Mar 26, 2015 at 8:38 PM, Lee Jones wrote: > > On Thu, 26 Mar 2015, Geert Uytterhoeven wrote: > >> On Thu, Mar 26, 2015 at 2:51 PM, Lee Jones wrote: > >> > On Wed, 25 Mar 2015, Geert Uytterhoeven wrote: > >> >> On Mon, Mar 9, 2015 at 10:28 AM, Lee Jones wrote: > >> >> > On Fri, 06 Mar 2015, Mike Turquette wrote: > >> >> >> This approach looks fine to me. In practice I think it is restricted 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 best. > >> >> > > >> >> > Agreed. > >> >> > >> >> 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 clock > >> >> correctly in > >> >> the future. > >> > > >> > Would you mind taking the time to explain what you think those > >> > limitations are? > >> > >> If you add a "clk-always-on" node, the clock will always on using that DT. > >> That will still be true later, when you get a better understanding of the > >> hardware, and might discover you're gonna need a driver for the currently > >> hidden core component that's driven by the clock, and may want to manage > >> that clock. > > > > So I have two points here. > > > > First point; I think you're looking at an older version of my set. > > The newer one can be found at [1] and no longer uses 'always-on' > > nodes. Instead the 'clk-always-on' property is applied to the > > provider. See the documentation patch [2] for more details. > > Thanks, I was indeed looking at an old version. > Still, that doesn't change that the clock to not be disabled in specified > explicitly from DT. > > > Second point; this binding is _not_ to be used as a hack because the > > hardware isn't understood. Genuine uses are for clocks that must not > > be turned off ever, else bad things will happen. If the hardware is > > not understood, use 'clk-disable-unused' on the kernel cmdline > > instead. [...] > > If this clock should _genuinely_ be always-on, then use my new > > binding in the clock controller node and the Clk framework will not > > turn it off. > > It's supposed to be on when the application ARM core(s) is/are running. > Many SoCs also have smaller cores (SH, Cortex R or M), intended to > run a real-time OS. If the RT core is in charge, it may decide to shut down > the application ARM core(s), incl. supposedly always-on modules like > the ARM GIC. > > I couldn't find a detailed block diagram of the STiH4xx SoCs, but at least > STiH416 has an "ST proprietary multi-compartmental security IP and DRM > processor". You might be interested in the latest incarnation of the set. See if it solves your issues. https://lkml.org/lkml/2015/4/1/267 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog