From patchwork Wed Nov 26 17:00:11 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sudeep Holla X-Patchwork-Id: 5386871 Return-Path: X-Original-To: patchwork-linux-pm@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 3E5C0C11AC for ; Wed, 26 Nov 2014 17:00:25 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6E07D201C7 for ; Wed, 26 Nov 2014 17:00:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5DC482018E for ; Wed, 26 Nov 2014 17:00:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753036AbaKZRAS (ORCPT ); Wed, 26 Nov 2014 12:00:18 -0500 Received: from service87.mimecast.com ([91.220.42.44]:34120 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752630AbaKZRAQ convert rfc822-to-8bit (ORCPT ); Wed, 26 Nov 2014 12:00:16 -0500 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Wed, 26 Nov 2014 17:00:14 +0000 Received: from [10.1.207.30] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Nov 2014 17:00:11 +0000 Message-ID: <5476071B.1060705@arm.com> Date: Wed, 26 Nov 2014 17:00:11 +0000 From: Sudeep Holla User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Viresh Kumar , Rafael Wysocki , "rob.herring@linaro.org" CC: Sudeep Holla , "linaro-kernel@lists.linaro.org" , "linux-pm@vger.kernel.org" , Nishanth Menon , Stephen Boyd , "devicetree@vger.kernel.org" , Santosh Shilimkar , Lorenzo Pieralisi , Arnd Bergmann , Mike Turquette , "grant.likely@linaro.org" , "kesavan.abhilash@gmail.com" , Catalin Marinas , "k.chander@samsung.com" , "olof@lixom.net" , "ta.omasab@gmail.com" Subject: Re: [RFC] cpufreq: Add "dvfs-method" binding to probe cpufreq drivers References: <596a6d49f2b3e2837aa9a54a3e1249161d3c9265.1416991009.git.viresh.kumar@linaro.org> In-Reply-To: <596a6d49f2b3e2837aa9a54a3e1249161d3c9265.1416991009.git.viresh.kumar@linaro.org> X-OriginalArrivalTime: 26 Nov 2014 17:00:11.0883 (UTC) FILETIME=[70FA9BB0:01D0099A] X-MC-Unique: 114112617001403101 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org 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 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Viresh, On 26/11/14 08:46, Viresh Kumar wrote: > DT based cpufreq drivers doesn't require much support from platform code now a > days as most of the stuff is moved behind generic APIs. Like clk APIs for > changing clock rates, regulator APIs for changing voltages, etc. > > One of the bottleneck still left was how to select which cpufreq driver to probe > for a given platform as there might be multiple drivers available. > > Traditionally, we used to create platform devices from machine specific code > which binds with a cpufreq driver. And while we moved towards DT based device > creation, these devices stayed as is. > > The problem is getting worse now as we have architectures now with Zero platform > specific code. Forcefully these platforms have to create a new file in > drivers/cpufreq/ to just add these platform devices in order to use the generic > drivers like cpufreq-dt.c. > > This has been discussed again and again, but with no solution yet. Last it was > discussed here: > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256154.html > > This patch is an attempt towards getting the bindings. > > We only need to have one entry in cpus@cpu0 node which will match with drivers > name. > This seems fundamentally broken as the driver always needs to unconditionally refer to cpu0. Furthermore the node need not be called cpu0 as the name depends on its reg field. > We can then add another file drivers/cpufreq/device_dt.c, which will add a > platform device with the name it finds from cpus@cpu0 node and existing drivers > will work without any change. Or something else if somebody have a better > proposal. But lets fix the bindings first. IIUC you will retain the existing list of cpufreq-dt platform device creation as is. If not that breaks compatibility with old DT. > > Signed-off-by: Viresh Kumar > --- > .../devicetree/bindings/cpufreq/drivers.txt | 53 ++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/cpufreq/drivers.txt > > diff --git a/Documentation/devicetree/bindings/cpufreq/drivers.txt b/Documentation/devicetree/bindings/cpufreq/drivers.txt > new file mode 100644 > index 0000000..bd14917 > --- /dev/null > +++ b/Documentation/devicetree/bindings/cpufreq/drivers.txt > @@ -0,0 +1,53 @@ > +Binding to select which cpufreq driver to register > + > +It is a generic DT binding for selecting which cpufreq-driver to register for > +any platform. > + > +The property listed below must be defined under node /cpus/cpu@0 node. We don't > +support multiple CPUFreq driver currently for different cluster and so this > +information isn't required to be present in CPUs of all clusters. > + > +Required properties: > +- None > + > +Optional properties: > +- dvfs-method: CPUFreq driver to probe. For example: "arm-bL-cpufreq-dt", > + "cpufreq-dt", etc > + You should manage this with compatible rather than a new property as it's not a real hardware property. IMHO Rob's suggestion[1] should work fine. IIUC, you can have the driver which create this platform device if DT has generic compatible unconditionally(e.g "cpufreq-dt" as you have chosen above). For all existing DT you can create a blacklist of compatibles to match(as it doesn't have the generic compatible) covering all the existing platforms using cpufreq-dt driver, there by you can even remove the platform device creating from multiple places. IMO something like the patch below should work(not tested, also late_initcall is used just to demonstrate the idea) Rob, please correct me if my understanding is wrong. Regards, Sudeep [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-May/256191.html --->8 the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c index f657c571b18e..19a616e298e0 100644 --- a/drivers/cpufreq/cpufreq-dt.c +++ b/drivers/cpufreq/cpufreq-dt.c @@ -387,6 +387,32 @@ static struct platform_driver dt_cpufreq_platdrv = { }; module_platform_driver(dt_cpufreq_platdrv); +static const struct of_device_id compatible_machine_match[] = { + /* All new machines must have the below compatible to use this driver */ + { .compatible = "cpufreq-generic-dt" }, + /* BLACKLIST of existing users of cpufreq-dt below */ + { .compatible = "samsung,exynos5420" }, + { .compatible = "samsung,exynos5800" }, + {}, +}; + +static int cpufreq_generic_dt_init(void) +{ + struct device_node *root = of_find_node_by_path("/"); + struct platform_device_info devinfo = { .name = "cpufreq-dt", }; + /* + * Initialize the device for the platforms either + * blacklisted or compliant to generic compatible + */ + if (!of_match_node(compatible_machine_match, root)) + return -ENODEV; + + /* Instantiate cpufreq-dt */ + platform_device_register_full(&devinfo); + return 0; +} +late_initcall(cpufreq_generic_dt_init); + -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in