From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752687AbbCED6m (ORCPT ); Wed, 4 Mar 2015 22:58:42 -0500 Received: from mail-qc0-f170.google.com ([209.85.216.170]:36288 "EHLO mail-qc0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750979AbbCED6j (ORCPT ); Wed, 4 Mar 2015 22:58:39 -0500 MIME-Version: 1.0 In-Reply-To: References: <1425458956-20665-1-git-send-email-pi-cheng.chen@linaro.org> <1425458956-20665-2-git-send-email-pi-cheng.chen@linaro.org> Date: Thu, 5 Mar 2015 09:28:38 +0530 Message-ID: Subject: Re: [PATCH v2 1/4] cpufreq-dt: add clock domain and intermediate frequency support From: Viresh Kumar To: Pi-Cheng Chen Cc: Matthias Brugger , Rob Herring , "Rafael J. Wysocki" , Thomas Petazzoni , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Catalin Marinas , Will Deacon , "Joe.C" , Eddie Huang , Howard Chen , Ashwin Chaugule , Mike Turquette , Chen Fan , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Linux Kernel Mailing List , "linux-pm@vger.kernel.org" , Linaro Kernel Mailman List , linux-mediatek@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 09:02, Pi-Cheng Chen wrote: > In the case of Mediatek SoC, the intermediate frequency might not be one entry > of OPP table. To elaborate, the source clock node of the CPUs/Cluster on > Mediatek SoC is a mux. The mux has several PLLs as parents. When we are > doing CPU frequency scaling, the mux should re-parent to another stable PLL, > wait until the original parent PLL become stable, and then switch back to the > original parent. In this case, we could but we might not want the intermediate > frequency as part of OPP table. Therefore I save intermediate_freq instead of > intermediate frequency index in the cpufreq_dt_platform_datat struct. Hmm, I remember that discussion. Okay leave it as is. > BTW, is this case that intermediate frequency is not necessarily be one entry > of OPP table supported in the OPPv2 bindings? Not yet, but will add a property for that.