From mboxrd@z Thu Jan 1 00:00:00 1970 From: Viresh Kumar Subject: Re: [RFC] cpufreq: Add imx-cpufreq-dt driver Date: Thu, 25 Apr 2019 16:02:34 +0530 Message-ID: <20190425103234.4u6dsh4jxhifiux7@vireshk-i7> References: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Leonard Crestez Cc: Aisheng Dong , Abel Vesa , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , Shawn Guo , "linux-arm-kernel@lists.infradead.org" , Lucas Stach List-Id: linux-pm@vger.kernel.org On 25-04-19, 10:29, Leonard Crestez wrote: > Right now in upstream imx8m cpufreq support just lists a common subset > of OPPs because the higher ones should only be attempted after checking > speed grading in fuses. > > This is not a reasonable limitation and means we must still carry a > separate cpufreq driver in NXP tree. > > This is a small driver which checks speed grading from nvmem before > registering cpufreq-dt. Unlike imx6q-cpufreq and various other rejected > imx7/8 cpufreq drivers it contains no actual frequency switching code, > just fuse reading through nvmem API. > > Code is inspired by similar cpufreq wrappers from a dozen different > vendors. Currently for imx8mm but same issue applies to imx8mq and > others. > > Signed-off-by: Leonard Crestez > > --- > drivers/cpufreq/Kconfig.arm | 5 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/imx-cpufreq-dt.c | 101 +++++++++++++++++++++++++++ > 4 files changed, 109 insertions(+) > create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c > > Since nvmem is a module this driver also needs to be turned into a > proper module, right now it will simply fail if nvmem is unavailable at > init time. Let me know if you agree with this approach before I turn it > into a module. > > In vendor tree this is done in soc driver but many other vendors do it > in drivers/cpufreq so this is where it belongs. > > This is select by default in Kconfig, if anything fails then regular > cpufreq-dt is not available. This is intentional because higher OPPs are > potentially unstable. No objections on this stuff from me. This is how we are doing it for everyone using cpufreq-dt. -- viresh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 172D9C10F03 for ; Thu, 25 Apr 2019 10:32:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DC1D3217FA for ; Thu, 25 Apr 2019 10:32:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="QRyzd+R/" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730385AbfDYKcj (ORCPT ); Thu, 25 Apr 2019 06:32:39 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:34999 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726266AbfDYKch (ORCPT ); Thu, 25 Apr 2019 06:32:37 -0400 Received: by mail-pl1-f195.google.com with SMTP id w24so10902285plp.2 for ; Thu, 25 Apr 2019 03:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PgZEMgyACtouer8ENDXUIK5amDGb32d+qsYYoVzOlWg=; b=QRyzd+R/yJ0hnuf79dQP73fJ8BIRliqlJFg2JktL2rIreYSxjZV8s1a9ilhZMWR8hi KXf1OVtnLlJq/EXUI/n+q9PsCQtAt0vZ0g++O1LyMKDlAk1EX7rr3Opp9dmksb17+DVk EOwzHUdwIFvj39gzrCs+SWYhsvDX6Ni4Bx7VS46pGsOPRUpsR/qhnpnXcZJa4Yx5nRZi dmEsXr4kW5utNcQ/eWF/c4od5NmQnaYfTPAkZAyf66ZUyWb0VHaCSml2ys2gb9oCqNGY RAmD6IjHuWsHKBF5i+N/8+MRDLpS/68l3/3J+pVn6kf6UIQKuze2LlRbNFdpD+h86BII PCFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PgZEMgyACtouer8ENDXUIK5amDGb32d+qsYYoVzOlWg=; b=WvxY2oQla002VS5liVKIBwvhd9k0nZ2CRI4f1x7g2TnbdykZ0wQ/LkzITSdw/9UIqe bbYmkYX+NDS3awZNp0Mf45+SWIuXyajd7TlPnGIpf6sg9egvyGUv0423EhgpKvRwoKsB YkhALcZxc2tb2c47S7veHEJOvlIcNpU+omBzfabI6Su1mGI4TGwh/513+Gu38+R+4k68 /3vcOrmJB9lxEhl9nkIUL7GipTE3Q5h3pXx1jLbwb5I19RSRZoMUI4DSkm3CIpoEq1Pa cE62pz/kwWqQw52t3A3/0EzHDWd5+guv/KN5ywv+MdnbmrP/I+hFmHB33ZxIvHlnFP0A 5bvg== X-Gm-Message-State: APjAAAV0R481edsINMlymQ1Mi0gJvSCPNmptqMu7cMlwfHCpV2ejjdmK IgQcakoymodKPdE20k2YaEltCQ== X-Google-Smtp-Source: APXvYqzb07ubteAEDmS4LHNpDqoWtb6FvkHGcB03ZkfhYJprDGwHaTKfcIbJYIe63Wh0bTDKxRBfCg== X-Received: by 2002:a17:902:a582:: with SMTP id az2mr39006605plb.315.1556188356948; Thu, 25 Apr 2019 03:32:36 -0700 (PDT) Received: from localhost ([122.166.139.136]) by smtp.gmail.com with ESMTPSA id 132sm6515024pfw.87.2019.04.25.03.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 03:32:35 -0700 (PDT) Date: Thu, 25 Apr 2019 16:02:34 +0530 From: Viresh Kumar To: Leonard Crestez Cc: Lucas Stach , "Rafael J. Wysocki" , Abel Vesa , Shawn Guo , Aisheng Dong , Fabio Estevam , "kernel@pengutronix.de" , dl-linux-imx , "linux-arm-kernel@lists.infradead.org" , "linux-pm@vger.kernel.org" Subject: Re: [RFC] cpufreq: Add imx-cpufreq-dt driver Message-ID: <20190425103234.4u6dsh4jxhifiux7@vireshk-i7> References: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> User-Agent: NeoMutt/20180323-120-3dd1ac Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org Message-ID: <20190425103234.iFiZMWE9wIBdIXqPILQXzHK4vcL3Lm5NwXse_bjJGks@z> On 25-04-19, 10:29, Leonard Crestez wrote: > Right now in upstream imx8m cpufreq support just lists a common subset > of OPPs because the higher ones should only be attempted after checking > speed grading in fuses. > > This is not a reasonable limitation and means we must still carry a > separate cpufreq driver in NXP tree. > > This is a small driver which checks speed grading from nvmem before > registering cpufreq-dt. Unlike imx6q-cpufreq and various other rejected > imx7/8 cpufreq drivers it contains no actual frequency switching code, > just fuse reading through nvmem API. > > Code is inspired by similar cpufreq wrappers from a dozen different > vendors. Currently for imx8mm but same issue applies to imx8mq and > others. > > Signed-off-by: Leonard Crestez > > --- > drivers/cpufreq/Kconfig.arm | 5 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/imx-cpufreq-dt.c | 101 +++++++++++++++++++++++++++ > 4 files changed, 109 insertions(+) > create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c > > Since nvmem is a module this driver also needs to be turned into a > proper module, right now it will simply fail if nvmem is unavailable at > init time. Let me know if you agree with this approach before I turn it > into a module. > > In vendor tree this is done in soc driver but many other vendors do it > in drivers/cpufreq so this is where it belongs. > > This is select by default in Kconfig, if anything fails then regular > cpufreq-dt is not available. This is intentional because higher OPPs are > potentially unstable. No objections on this stuff from me. This is how we are doing it for everyone using cpufreq-dt. -- viresh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05F74C10F03 for ; Thu, 25 Apr 2019 10:32:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C75CC2084B for ; Thu, 25 Apr 2019 10:32:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="B6p7MlRX"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="QRyzd+R/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C75CC2084B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NjV3Ai+yULhdUPYK1wjQtEnni8dx5QL+mu91xiI/dWA=; b=B6p7MlRXBS/Wku YylIW7QveU6zYhnPGI7QG6obCplCQldoS3i+UtgzQlZH3tiZjAyD2uTYNpwG/irLdiwrTIBGPII72 wrz+cvaqAENVS1HgmFGZxnVlivu1ZyvqYvQ+WOIkA5TBTPrBKJyHsZhSyAqDJnyLanSGoazgXcvhX HfKkPBSx4nGzWuYMQtHbzmcwMajqqXA7B7BST0UnXYFpEQ7NaMMhhRny0WBL1JYcN5Y2tGhTHMcRg ZKEtPXCuBV3WURpQucd239758pxGa4xK/qQ7rDGw1b7yz/QRcSg/Z9TTbIBcDSvyuXg6Q66hfgKlw WflNIk0tuid+qDiBLx5w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJbgR-0001HQ-Uu; Thu, 25 Apr 2019 10:32:51 +0000 Received: from mail-pl1-x644.google.com ([2607:f8b0:4864:20::644]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hJbgF-00013a-0S for linux-arm-kernel@lists.infradead.org; Thu, 25 Apr 2019 10:32:40 +0000 Received: by mail-pl1-x644.google.com with SMTP id d9so4965252pls.8 for ; Thu, 25 Apr 2019 03:32:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PgZEMgyACtouer8ENDXUIK5amDGb32d+qsYYoVzOlWg=; b=QRyzd+R/yJ0hnuf79dQP73fJ8BIRliqlJFg2JktL2rIreYSxjZV8s1a9ilhZMWR8hi KXf1OVtnLlJq/EXUI/n+q9PsCQtAt0vZ0g++O1LyMKDlAk1EX7rr3Opp9dmksb17+DVk EOwzHUdwIFvj39gzrCs+SWYhsvDX6Ni4Bx7VS46pGsOPRUpsR/qhnpnXcZJa4Yx5nRZi dmEsXr4kW5utNcQ/eWF/c4od5NmQnaYfTPAkZAyf66ZUyWb0VHaCSml2ys2gb9oCqNGY RAmD6IjHuWsHKBF5i+N/8+MRDLpS/68l3/3J+pVn6kf6UIQKuze2LlRbNFdpD+h86BII PCFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PgZEMgyACtouer8ENDXUIK5amDGb32d+qsYYoVzOlWg=; b=h6G+l/0IByjF4I6JWfG8uG7utkAmlJqs5KEubNH4pNl/sDNy0RD+6i8SqYkah+f2i6 osqpto7XvVLXGVQxQWSk2fhGnR8gc2+Q1qodijc2sRi78wtpmbC6/S50KRqeksoiS0rv +39zhbuHuwAOj0KRPjVTwvYZAKOZIYIKVXqwu3dZIyONCmCA49aR4pcY1RSRbCN7Kq7Y Q81/3iVl6y2gA/dvYlNMe3ACGVeD+RXPICnYzcbE+tREvGXfZ0wHkWZurJJLtIXqQFdj GGaecTue7Iu09R7lq//88F5kj58fge9CqcgWwU/bcrdguPVczR6pjf+r5LE22PRamsTn rhtw== X-Gm-Message-State: APjAAAXPGz2INykSOKYI0jTdObvbpiR4XzWdIRRqBOgu3BxOS1r05A9p Ft2XH26X3l07SKcJHJRxR0WoWA== X-Google-Smtp-Source: APXvYqzb07ubteAEDmS4LHNpDqoWtb6FvkHGcB03ZkfhYJprDGwHaTKfcIbJYIe63Wh0bTDKxRBfCg== X-Received: by 2002:a17:902:a582:: with SMTP id az2mr39006605plb.315.1556188356948; Thu, 25 Apr 2019 03:32:36 -0700 (PDT) Received: from localhost ([122.166.139.136]) by smtp.gmail.com with ESMTPSA id 132sm6515024pfw.87.2019.04.25.03.32.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Apr 2019 03:32:35 -0700 (PDT) Date: Thu, 25 Apr 2019 16:02:34 +0530 From: Viresh Kumar To: Leonard Crestez Subject: Re: [RFC] cpufreq: Add imx-cpufreq-dt driver Message-ID: <20190425103234.4u6dsh4jxhifiux7@vireshk-i7> References: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <83a3ade389239bd492ee646aa4868c5e37e65434.1556187603.git.leonard.crestez@nxp.com> User-Agent: NeoMutt/20180323-120-3dd1ac X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190425_033239_052893_E46FECD3 X-CRM114-Status: GOOD ( 17.06 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Aisheng Dong , Abel Vesa , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" , dl-linux-imx , "kernel@pengutronix.de" , Fabio Estevam , Shawn Guo , "linux-arm-kernel@lists.infradead.org" , Lucas Stach Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 25-04-19, 10:29, Leonard Crestez wrote: > Right now in upstream imx8m cpufreq support just lists a common subset > of OPPs because the higher ones should only be attempted after checking > speed grading in fuses. > > This is not a reasonable limitation and means we must still carry a > separate cpufreq driver in NXP tree. > > This is a small driver which checks speed grading from nvmem before > registering cpufreq-dt. Unlike imx6q-cpufreq and various other rejected > imx7/8 cpufreq drivers it contains no actual frequency switching code, > just fuse reading through nvmem API. > > Code is inspired by similar cpufreq wrappers from a dozen different > vendors. Currently for imx8mm but same issue applies to imx8mq and > others. > > Signed-off-by: Leonard Crestez > > --- > drivers/cpufreq/Kconfig.arm | 5 ++ > drivers/cpufreq/Makefile | 1 + > drivers/cpufreq/cpufreq-dt-platdev.c | 2 + > drivers/cpufreq/imx-cpufreq-dt.c | 101 +++++++++++++++++++++++++++ > 4 files changed, 109 insertions(+) > create mode 100644 drivers/cpufreq/imx-cpufreq-dt.c > > Since nvmem is a module this driver also needs to be turned into a > proper module, right now it will simply fail if nvmem is unavailable at > init time. Let me know if you agree with this approach before I turn it > into a module. > > In vendor tree this is done in soc driver but many other vendors do it > in drivers/cpufreq so this is where it belongs. > > This is select by default in Kconfig, if anything fails then regular > cpufreq-dt is not available. This is intentional because higher OPPs are > potentially unstable. No objections on this stuff from me. This is how we are doing it for everyone using cpufreq-dt. -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel