From patchwork Fri Jun 27 00:06:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 4432721 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id DDC999F402 for ; Fri, 27 Jun 2014 00:06:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 19F7A2039E for ; Fri, 27 Jun 2014 00:06:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 15EE42039D for ; Fri, 27 Jun 2014 00:06:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751840AbaF0AGM (ORCPT ); Thu, 26 Jun 2014 20:06:12 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:44732 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751777AbaF0AGD (ORCPT ); Thu, 26 Jun 2014 20:06:03 -0400 Received: from smtp.codeaurora.org (localhost [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 02EE213F64C; Fri, 27 Jun 2014 00:06:02 +0000 (UTC) Received: by smtp.codeaurora.org (Postfix, from userid 486) id E760613F64B; Fri, 27 Jun 2014 00:06:01 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 Received: from [10.46.167.8] (i-global254.qualcomm.com [199.106.103.254]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sboyd@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 152FC13F62C; Fri, 27 Jun 2014 00:06:01 +0000 (UTC) Message-ID: <53ACB568.4000903@codeaurora.org> Date: Thu, 26 Jun 2014 17:06:00 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Viresh Kumar CC: "Rafael J. Wysocki" , Shawn Guo , Lists linaro-kernel , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , Arvind Chauhan , Mike Turquette , "linux-arm-kernel@lists.infradead.org" , linux-arm-msm@vger.kernel.org, Sachin Kamat , Thomas P Abraham , Nishanth Menon , Tomasz Figa , Mark Brown , Mark Rutland Subject: Re: [PATCH 2/2] cpufreq: cpu0: Extend support beyond CPU0 References: <53AB1CC1.4010907@codeaurora.org> In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 06/26/14 03:52, Viresh Kumar wrote: > On 26 June 2014 00:32, Stephen Boyd wrote: >> I don't think this driver should be using regulator_get_optional() (Mark >> B. please correct me if I'm wrong). I doubt a supply is actually >> optional for CPUs, just some DTs aren't specifying them. In those cases, >> the regulator core will insert a dummy supply and the code will work >> without having to check for probe defer and error pointers. > Hi Stephen, > > Thanks for your comments. > > Leaving the above one, I have tried to fix all you mentioned. And it surely > looks much better now. > > I would like to wait for a day or two before sending V2, as people might > be reviewing it and the above issue is still wide open.. > > But in case you wanna test it (completely changed I must say, but > for good), its here: > > git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2 I gave it a spin. It looks mostly good except for the infinite loop: which I hope is ok. Finally, checking for equivalent pointers from clk_get() will work now, but it isn't future-proof if/when the clock framework starts returning dynamically allocated clock pointers for each clk_get() invocation. Maybe we need a function in the common clock framework that tells us if the clocks are the same either via DT or by taking two clock pointers? diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index b7ee67c4d1c0..6744321ae33d 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -138,8 +138,10 @@ try_again: } /* Try with "cpu-supply" */ - if (reg == reg_cpu0) + if (reg == reg_cpu0) { + reg = reg_cpu; goto try_again; + } dev_warn(cpu_dev, "failed to get cpu%d regulator: %ld\n", cpu, PTR_ERR(cpu_reg)); and I think we just want reg_cpu to be "cpu", not "cpu-supply" because I think the regulator core adds in the "-supply" part already. After fixing that I can get cpufreq going. I'm currently working on populating the OPPs at runtime without relying on DT. So eventually I'll need this patch: diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c index b7ee67c4d1c0..6744321ae33d 100644 --- a/drivers/cpufreq/cpufreq-cpu0.c +++ b/drivers/cpufreq/cpufreq-cpu0.c @@ -239,11 +241,6 @@ static int cpu0_cpufreq_init(struct cpufreq_policy *policy) } ret = of_init_opp_table(cpu_dev); - if (ret) { - dev_err(cpu_dev, "failed to init OPP table: %d\n", ret); - goto out_put_node; - } - ret = dev_pm_opp_init_cpufreq_table(cpu_dev, &freq_table); if (ret) { dev_err(cpu_dev, "failed to init cpufreq table: %d\n", ret);