From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755099AbbCELCL (ORCPT ); Thu, 5 Mar 2015 06:02:11 -0500 Received: from mail-ob0-f170.google.com ([209.85.214.170]:44969 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754887AbbCELCH (ORCPT ); Thu, 5 Mar 2015 06:02:07 -0500 MIME-Version: 1.0 In-Reply-To: <20150305105104.GJ11010@pengutronix.de> References: <1425466152-7867-1-git-send-email-pi-cheng.chen@linaro.org> <20150304112109.GB11010@pengutronix.de> <20150305074207.GC11010@pengutronix.de> <20150305091948.GH11010@pengutronix.de> <20150305105104.GJ11010@pengutronix.de> Date: Thu, 5 Mar 2015 16:32:06 +0530 Message-ID: Subject: Re: [PATCH] clk: mediatek: Export CPU mux clocks for CPU frequency control From: Viresh Kumar To: Sascha Hauer , Russell King - ARM Linux Cc: Pi-Cheng Chen , Mark Rutland , James Liao , Linaro Kernel Mailman List , Mike Turquette , Pawel Moll , Ian Campbell , Stephen Boyd , Linux Kernel Mailing List , Henry Chen , Chen Fan , "devicetree@vger.kernel.org" , Rob Herring , linux-mediatek@lists.infradead.org, Kumar Gala , Matthias Brugger , "Joe.C" , Eddie Huang , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5 March 2015 at 16:21, Sascha Hauer wrote: > Given the variance of different SoCs I don't think it makes sense > to try to handle all these cases. Instead the cpufreq-dt driver > should just call clk_set_rate() on the CPU clock with the desired > target frequency. Everything else should be handled in the clock > driver which has intimate knowledge about the SoC anyway. I agree.. @Russell: I wanted to ask you this since sometime.. On CPU-freq changes we fire PRE/POST notifiers and they are used for updating loops_per_jiffies which then controls delays. Now, it is fine to do that for normal frequencies, but what should be the approach for intermediate frequencies ? Intermediate freqs: On some platforms changing PLL's straight away isn't considered safe and so we switch parent to another stable clock, change PLL rate and switch back. The *wild* thought I earlier had was to fire these notifiers for even these intermediate frequencies, otherwise some of the delays will end before they should have and that *might* cause other problems. I wanted to know what do you (and other champs) think about this.. Thanks in advance for your advice.