Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp839444imm; Wed, 23 May 2018 06:25:54 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpYf1oCqaz6sJ5WEOQQKEtv9fUnkwQLtaX1RmlOsikWckBrxLIW3guYKqkm9hNIjdwUFSv0 X-Received: by 2002:a65:5d0f:: with SMTP id e15-v6mr2403043pgr.119.1527081954883; Wed, 23 May 2018 06:25:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527081954; cv=none; d=google.com; s=arc-20160816; b=SZhR1PhwKIXDko8y9VhT4nVWvMvvQ+4WCgLu/pgFYjNWJrkODzu9HxJpLohaEZfbNX fywoxCJLnrzT8sEp34yNWIftq1iXiWxcwPCPlBnywmlv+Vq7hfu33w2tELj3u6TnUQNm PURtinp3sbD+tmNScghaE0p8r7oSqu9O/xil10YwDk86KRp0cp3lgjTBag4v8qtef7fE s1+UHufjSfOXnwQ0QiS9yRLaQuWkQXfvpxG/4SdPziR6wRzYjYCvnN1Ln4S/kgk6bRus 3XmPfqaKip55Zjues2eg/ShwZcn8R9LdgBIQwqapc8fQFdEa6Z5jzh10hRdGp4Nm2ytf FSKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:to:subject:cc :arc-authentication-results; bh=jUbYuxNodOCvCCb9e7sUCgM4M49n5mKkUdvpd+PiCLQ=; b=nA7sRyRFrpQeQpA7GYYQTsgj/XD9/HalN5H0M6Y841nxrjlueEjDQtxyiebQC1o7Bk M5ZXxpxyLb8m9EvsvSd1JqTr94Lu/KiHcX11kD0Ng4oSdK4eNJJLajX8ITomY1ljjz45 4bPJqQm10kBxW3RX/dkYhSMS4fvMCt3qxaFnW+S+Eo14I98GQ/r6PdLeBMMqZzqkX1+O UgjHKqFT8GknPhWGsU1A1edvv4hiPCg3NPJx/GYoDuVmV/v6DhhrNpDZJjUpf4eis8XU aMXEPKR2j7roreBs3VLMmNPCCb2clWpNxF71mRD58y6DTB5L80BaVYyvmrawQIVZ65rV j7vA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y21-v6si18928574pll.353.2018.05.23.06.25.40; Wed, 23 May 2018 06:25:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932960AbeEWNZ3 (ORCPT + 99 others); Wed, 23 May 2018 09:25:29 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932844AbeEWNZ1 (ORCPT ); Wed, 23 May 2018 09:25:27 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1F69D80D; Wed, 23 May 2018 06:25:27 -0700 (PDT) Received: from [10.1.210.28] (unknown [10.1.210.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EBA703F24A; Wed, 23 May 2018 06:25:24 -0700 (PDT) Cc: Sudeep Holla Subject: Re: [PATCH v11 1/2] cpufreq: Add Kryo CPU scaling driver To: Ilia Lin , vireshk@kernel.org, nm@ti.com, sboyd@kernel.org, robh@kernel.org, mark.rutland@arm.com, rjw@rjwysocki.net, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <1527079139-3558-1-git-send-email-ilialin@codeaurora.org> <1527079139-3558-2-git-send-email-ilialin@codeaurora.org> From: Sudeep Holla Organization: ARM Message-ID: <1ec7645d-72b6-5a1a-48c3-831a3c484a0e@arm.com> Date: Wed, 23 May 2018 14:25:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1527079139-3558-2-git-send-email-ilialin@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/05/18 13:38, Ilia Lin wrote: > In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, > the CPU frequency subset and voltage value of each OPP varies > based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables > defines the voltage and frequency value based on the msm-id in SMEM > and speedbin blown in the efuse combination. > The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC > to provide the OPP framework with required information. > This is used to determine the voltage and frequency value for each OPP of > operating-points-v2 table when it is parsed by the OPP framework. > > Signed-off-by: Ilia Lin > --- > drivers/cpufreq/Kconfig.arm | 10 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 3 + > drivers/cpufreq/qcom-cpufreq-kryo.c | 181 +++++++++++++++++++++++++++++++++++ > 4 files changed, 195 insertions(+) > create mode 100644 drivers/cpufreq/qcom-cpufreq-kryo.c > > diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm > index de55c7d..0bfd40e 100644 > --- a/drivers/cpufreq/Kconfig.arm > +++ b/drivers/cpufreq/Kconfig.arm > @@ -124,6 +124,16 @@ config ARM_OMAP2PLUS_CPUFREQ > depends on ARCH_OMAP2PLUS > default ARCH_OMAP2PLUS > > +config ARM_QCOM_CPUFREQ_KRYO > + bool "Qualcomm Kryo based CPUFreq" > + depends on QCOM_QFPROM > + depends on QCOM_SMEM > + select PM_OPP > + help > + This adds the CPUFreq driver for Qualcomm Kryo SoC based boards. > + > + If in doubt, say N. > + Sorry but just noticed now, any reason why this can't be module. I can't imagine any. [..] > +static int qcom_cpufreq_kryo_probe(struct platform_device *pdev) > +{ > + struct opp_table *opp_tables[NR_CPUS] = {0}; > + struct platform_device *cpufreq_dt_pdev; > + enum _msm8996_version msm8996_version; > + struct nvmem_cell *speedbin_nvmem; > + struct device_node *np; > + struct device *cpu_dev; [..] > + > + cpufreq_dt_pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0); > + if (!IS_ERR(cpufreq_dt_pdev)) > + return 0; > + > + ret = PTR_ERR(cpufreq_dt_pdev); > + dev_err(cpu_dev, "Failed to register platform device\n"); > + > +free_opp: > + for_each_possible_cpu(cpu) { > + if (IS_ERR_OR_NULL(opp_tables[cpu])) > + break; > + dev_pm_opp_put_supported_hw(opp_tables[cpu]); > + } > + > + return ret; > +} > + > +static int __init qcom_cpufreq_kryo_init(void) > +{ > + /* > + * Since the driver depends on smem and nvmem drivers, which may > + * return EPROBE_DEFER, all the real activity is done in the probe, > + * which may be defered as well. The init here is only registering > + * a platform device. > + */ > + platform_device_register_simple("qcom-cpufreq-kryo", -1, NULL, 0); > + return 0; > +} > +module_init(qcom_cpufreq_kryo_init); Do you need this at all ? See below on how to eliminate the need for this. > + > +static struct platform_driver qcom_cpufreq_kryo_driver = { > + .probe = qcom_cpufreq_kryo_probe, > + .driver = { > + .name = "qcom-cpufreq-kryo", > + }, > +}; > +builtin_platform_driver(qcom_cpufreq_kryo_driver); Use builtin_platform_driver_probe and remove qcom_cpufreq_kryo_init or use module_platform_driver_probe if it can be module. -- Regards, Sudeep