From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Coquelin Subject: Re: [RFC PATCH v2 0/2] clk: Support for DT assigned clock parents and rates Date: Fri, 21 Mar 2014 12:20:14 +0100 Message-ID: <532C206E.1020907@st.com> References: <1393870533-20845-1-git-send-email-s.nawrocki@samsung.com> <53187C13.3040202@st.com> <532AE239.9000800@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <532AE239.9000800@samsung.com> Sender: linux-kernel-owner@vger.kernel.org To: Sylwester Nawrocki , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org Cc: mark.rutland@arm.com, mturquette@linaro.org, gregkh@linuxfoundation.org, t.figa@samsung.com, sw0312.kim@samsung.com, linux-kernel@vger.kernel.org, kyungmin.park@samsung.com, robh+dt@kernel.org, galak@codeaurora.org, grant.likely@linaro.org, linux@arm.linux.org.uk, m.szyprowski@samsung.com, t-kristo@ti.com List-Id: devicetree@vger.kernel.org On 03/20/2014 01:42 PM, Sylwester Nawrocki wrote: > Hi Maxime, > > On 06/03/14 14:45, Maxime Coquelin wrote: >> Hi Sylwester, >> >> I like the principle of your implementation, but I have two questions: >> 1 - How can we manage PM with this solution, as the parent/rate will be >> set only once at probe time? >> 2 - How to set the parent of a parent clock (which can be shared with >> other devices)? Same question about the parent rates. > > Thanks for your feedback and apologies for late reply. No problem! Apologies accepted ;) > > IIUC your first concern is about a situation when clocks need to be > reconfigured upon each resume from system sleep or runtime PM resume ? Yes. This is the case of the STi SoCs. When resuming from system sleep, the clocks-related registers are restored at their boot state. > As I mentioned in v1 of the RFC I was considering having individual > drivers calling explicitly the clocks set up routine. Presumably this > would allow to resolve the power management related issue. From a functional point of view, that would indeed resolve the PM related issue. But I'm not sure that on a performance point of view, parsing the DT at each driver's resume call is an efficient way. > One example I'm aware the approach as in this RFC wouldn't work is > when a device in a SoC belongs to a power domain, which needs to be > first switched on before we can start setting up and the clocks' > configuration get lost after the power domain switch off. Yes, that's another case to handle. I don't know which platforms are in that case, but not STi SoCs for your information. > > OTOH I suspect devices for which one-time clocks setup is sufficient > will be quite common. And for these there would need to be a single > call to the setup routine in probe() I guess, since it wouldn't be > possible to figure out just from the DT data when the actual call > should be made. > > For a global clocks configuration, I thought about specifying that > in the clocks controller node, and then to have the setup routine > called e.g. from of_clk_init(). I think that could work well enough, > together with the patch [1], adding clock dependencies handling. > But then the clock frequency set up function would need to be > modified to respect the clock parent relationships, similarly as > in patch series [2]. A just noticed [2] recently, after posting > this RFC (adding Tero at Cc). OK, I agree with the approach. There is still the PM issue remaining with these clocks, but I think that is not related to your series as we already have the issue currently. Thanks, Maxime > > -- > Regards, > Sylwester > > [1] http://www.spinics.net/lists/arm-kernel/msg310507.html > [2] http://www.spinics.net/lists/linux-omap/msg103069.html >