From patchwork Wed Sep 10 04:29:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 4874121 Return-Path: X-Original-To: patchwork-linux-arm-msm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 74B48C0338 for ; Wed, 10 Sep 2014 04:29:32 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 969B0201B9 for ; Wed, 10 Sep 2014 04:29:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 86F0820145 for ; Wed, 10 Sep 2014 04:29:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750851AbaIJE32 (ORCPT ); Wed, 10 Sep 2014 00:29:28 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:57785 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbaIJE31 (ORCPT ); Wed, 10 Sep 2014 00:29:27 -0400 Received: by mail-pa0-f50.google.com with SMTP id bj1so4900504pad.23 for ; Tue, 09 Sep 2014 21:29:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=xXA+6RLgUwwK84YhXTIyvpPT/CIsDHP5mCf7ONBxfkM=; b=iQ4jhApnymLmRBYTvVOtH/uwCVoryxmreqTROeQPYRyPFgjElBRuxwAsUYF/J3uYbQ J26MHmv3gFe4Z/XopX2BuFs7xDdUivr/oWMH+D5dnnLEXZLvOEPqgOnvUJ9Igi/SW037 n60Wg5cQ1LArakPcrKND91HRS15mg4zChh45RVQ4DzrtniPIEhC2y61jlbVIIAMWkOhz MPIbA4fCapJ/vlrir7F0kBjwY3NetupPqZP3/YO+XwfH4iz9Fz/suFt+uFPpt4qoIOQk MxJ/91vJmyR8L1UB3nfnw539D4CG4J+pgECyd/UPt7UNAAvss2FRaUm+WXdTouc3AURh Xx9g== X-Gm-Message-State: ALoCoQl7bXfSIE0/ghOlf3/YyhjYuJ/K78kGDxyUdE8Wv9TvsrjS7x1L9DrPCOiuIUrOn7+oQfwN X-Received: by 10.69.31.10 with SMTP id ki10mr35376395pbd.11.1410323367227; Tue, 09 Sep 2014 21:29:27 -0700 (PDT) Received: from localhost ([122.167.129.166]) by mx.google.com with ESMTPSA id b14sm13217102pdk.2.2014.09.09.21.29.25 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 21:29:26 -0700 (PDT) From: Viresh Kumar To: Rafael Wysocki Cc: linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, shawn.guo@linaro.org, sboyd@codeaurora.org, linux-arm-msm@vger.kernel.org, spk.linux@gmail.com, thomas.ab@samsung.com, t.figa@samsung.com, santosh.shilimkar@ti.com, thomas.petazzoni@free-electrons.com, pramod.gurav@smartplayin.com, rob.herring@linaro.org, mike.turquette@linaro.org, Viresh Kumar Subject: [PATCH] cpufreq: dt: Support platforms with separate clock lines for each CPU Date: Wed, 10 Sep 2014 09:59:07 +0530 Message-Id: X-Mailer: git-send-email 2.0.3.693.g996b0fd Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org X-Spam-Status: No, score=-9.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP There has been lots of discussion over mailing lists about how to get CPU's clock sharing information for platforms as CPUFreq core depends on that. It doesn't look that there will be any immediate solution to that as there are multiple views over how to get that from DT. But there are platforms (already upstreamed) which depend on this requirement and are waiting for a solution to sail through. The common thing about them (Krait and Mvebu) is that all CPUs have independent clock lines and that makes things easier for us. So, this patch creates another Kconfig option to indicate if all CPUs share same clock line or all have independent. The complex cases of multiple clusters having separate clock lines, but having same for all CPUs within a cluster isn't addressed yet. This is a *short-term* solution for getting these platforms up an running and a DT based solution should be upstreamed soon. Signed-off-by: Viresh Kumar Acked-by: Viresh Kumar --- Yesterday again I was pinged by Thomas about the status of this work and the thread isn't going anywhere. He is blocked with just this to get his platform running on mainline. Will it be possible to get this through as a temporary solution? drivers/cpufreq/Kconfig | 9 +++++++++ drivers/cpufreq/cpufreq-dt.c | 17 +++++++++++++++-- 2 files changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig index 3489f8f..a755227 100644 --- a/drivers/cpufreq/Kconfig +++ b/drivers/cpufreq/Kconfig @@ -196,6 +196,15 @@ config CPUFREQ_DT If in doubt, say N. +config CPUFREQ_DT_INDEPENDENT_CLOCKS + bool "CPUs change clocks independently" + depends on CPUFREQ_DT + help + Selecting this will make cpufreq-dt driver believe that all CPUs have + independent clock lines and so all will have separate 'struct + cpufreq_policy' instances for them. This must be replaced by proper DT + bindings later on. + menu "x86 CPU frequency scaling drivers" depends on X86 source "drivers/cpufreq/Kconfig.x86" diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index e002650..dbb6f22 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -266,9 +266,22 @@ static int cpufreq_init(struct cpufreq_policy *policy) policy->driver_data = priv; policy->clk = cpu_clk; - ret = cpufreq_generic_init(policy, freq_table, transition_latency); - if (ret) + ret = cpufreq_table_validate_and_show(policy, freq_table); + if (ret) { + dev_err(cpu_dev, "%s: invalid frequency table: %d\n", __func__, + ret); goto out_cooling_unregister; + } + + policy->cpuinfo.transition_latency = transition_latency; + +#ifndef CONFIG_CPUFREQ_DT_INDEPENDENT_CLOCKS + /* + * The driver only supports the SMP configuartion where all processors + * share the clock and voltage and clock. + */ + cpumask_setall(policy->cpus); +#endif return 0;