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.7 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS autolearn=unavailable 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 F1995C10F13 for ; Mon, 8 Apr 2019 16:14:18 +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 C2CF121473 for ; Mon, 8 Apr 2019 16:14:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="MqjaKzQM"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="F9TU8KgG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2CF121473 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ZIPk63ER8dV0Drr1OHjBTWjqH3XMB7gsWVKGpIx3cJ8=; b=MqjaKzQM/AnVTD PU5mPpdFPfcbxphgH3Stw4Q8pxtUABZVt1mJJoI0ukxh4zxsJJaFp6vEoPTtH7mYQPLiztptXRWJL Ym9zvo6QwFeyto2rFQygsV35ESp13M/lAH9mNTAxuxRdtdJ5cFHRRMdFjmZZNDhzI462qHAmg6PdE +RQrD99kM+1eKGxf0gTtMnX5bvX2X+aUDZ/ACN4y4O05eIUyYcv5gL+kaYuNPGvheVOuYZIVBh+3D AkF2SY/7iZt7xusFm4LG3uZpEMnG7osu7/Ca0p2xzBsibilL9wDd0GfHdSoph4WtxX6M+J/e4Vyj0 Eeao5l9kDmio0wIT2s1Q==; 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 1hDWuU-0001th-Vw; Mon, 08 Apr 2019 16:14:14 +0000 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hDWuR-0001tB-8e for linux-arm-kernel@lists.infradead.org; Mon, 08 Apr 2019 16:14:12 +0000 Received: by mail-it1-x142.google.com with SMTP id v8so368033itf.0 for ; Mon, 08 Apr 2019 09:14:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/tGx6xAR3YCjanY8oQehQa0QqUSHh/RTqgaBS7JAGck=; b=F9TU8KgGQs2jcdOWKFua1MEy03htztSYf3L/ZwY9nkEuCCpcUU4ltKBVzMsgyqX+Hs 5ojxcfbr1JhR4QoWFJjfRbnj37gsG5awLuQc8xs7luC7MjPS5ab85tu0oQI3WcnvAoiv QO7bdB9syGjXy2lUUp4eBrnjDo9uD7h1sVNy9y9I3n7eX8XAdOmCCDH9g+kcdMJ2kz8B u3i3k7KWVcJRq46ZEgCrgnkyN1SrDVOm/52xSCP6PnHrZ5xuGrsgv9OandFKGD8fuSZs rWjPCA/ht7Nt3q4CqupA3CU7V15CU0h4bvfnqq2igiPG8A0Av+6RV6qUSd5xqpxwTSi/ VN7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/tGx6xAR3YCjanY8oQehQa0QqUSHh/RTqgaBS7JAGck=; b=TwJqIyDL7b3ARaFAnjny/o19pSjm8NDUALcvcSK8UfhJDDSqzWE82xFg9KRQeRZxKR 2Sg0oVclPZU5eRGaHd7F94B0ZEfESoPyf8TAXjGMQLpxG5FcE3tnJ2o2DcyKHS8Cy+PK /elThTaVisFPnaSe3nY1ApiMmJr/guUwVTikXVcQWWXiFwVw2gG7OZTDKesHeiMLvd1d rtI80sQi2QkIQfVkTggoLebOGUWkNiA/spJUEky5Gkn0U4fuXrdMrM0f997RJK8qONbt ySNIQpPqajMyUsA8NbrIZ3jGGyzuQrP0Xs3v/9QGppNKWSU5JoOxAUdZjrbh9V0QBevM cahw== X-Gm-Message-State: APjAAAWBbV3e4AsjhLvr8g3fDytvE7M3Q5eqfzWLCsKI0PzKqYHR4zwQ HyvSom8narFndNLm/HhT49n4UL/Uuv1A6SLants= X-Google-Smtp-Source: APXvYqx6M8eQx9p9BYMoe6Qv9uywuoTe6QWpJe8brWgXjWRdFDqOoitU9vZ565qRUD6e2XnLh44p2mTpTR3P1m0yE/I= X-Received: by 2002:a24:e346:: with SMTP id d67mr3028631ith.42.1554740049908; Mon, 08 Apr 2019 09:14:09 -0700 (PDT) MIME-Version: 1.0 References: <20190405102455.15311-1-tiny.windzz@gmail.com> <20190405102455.15311-3-tiny.windzz@gmail.com> <20190405145532.cstvbv3mxbzrmpxp@flea> In-Reply-To: <20190405145532.cstvbv3mxbzrmpxp@flea> From: Frank Lee Date: Tue, 9 Apr 2019 00:13:58 +0800 Message-ID: Subject: Re: [PATCH 2/2] dt-bindings: cpufreq: Document operating-points-v2-sunxi-cpu To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190408_091411_304932_B177833F X-CRM114-Status: GOOD ( 28.01 ) 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: nm@ti.com, mark.rutland@arm.com, Linux PM , sboyd@kernel.org, vireshk@kernel.org, rjw@rjwysocki.net, Linux Kernel Mailing List , Chen-Yu Tsai , robh+dt@kernel.org, Linux ARM , Greg Kroah-Hartman , mchehab+samsung@kernel.org, davem@davemloft.net, devicetree@vger.kernel.org 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 Fri, Apr 5, 2019 at 10:55 PM Maxime Ripard wrote: > > Hi, > > On Fri, Apr 05, 2019 at 06:24:55AM -0400, Yangtao Li wrote: > > Allwinner Process Voltage Scaling Tables defines the voltage and > > frequency value based on the speedbin blown in the efuse combination. > > The sunxi-cpufreq-nvmem driver reads the 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. > > > > This change adds documentation for the DT bindings. > > The "operating-points-v2-sunxi-cpu" DT extends the "operating-points-v2" > > with following parameters: > > - nvmem-cells (NVMEM area containig the speedbin information) > > - opp-supported-hw: A single 32 bit bitmap value, > > representing compatible HW: > > 0: speedbin 0 > > 1: speedbin 1 > > 2: speedbin 2 > > 3-31: unused > > > > Signed-off-by: Yangtao Li > > --- > > .../bindings/opp/sunxi-nvmem-cpufreq.txt | 235 ++++++++++++++++++ > > 1 file changed, 235 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > > > > diff --git a/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > > new file mode 100644 > > index 000000000000..80201d4e5147 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/opp/sunxi-nvmem-cpufreq.txt > > @@ -0,0 +1,235 @@ > > +Allwinner Technologies, Inc. NVMEM CPUFreq and OPP bindings > > +=================================== > > + > > +For some SoCs, the CPU frequency subset and voltage value of each OPP > > +varies based on the silicon variant in use. Allwinner Process Voltage > > +Scaling Tables defines the voltage and frequency value based on the > > +speedbin blown in the efuse combination. The sunxi-cpufreq-nvmem driver > > +reads the efuse value from the SoC to provide the OPP framework with > > +required information. > > + > > +Required properties: > > +-------------------- > > +In 'cpus' nodes: > > +- operating-points-v2: Phandle to the operating-points-v2 table to use. > > + > > +In 'operating-points-v2' table: > > +- compatible: Should be > > + - 'operating-points-v2-sunxi-cpu'. > > +- nvmem-cells: A phandle pointing to a nvmem-cells node representing the > > + efuse registers that has information about the > > + speedbin that is used to select the right frequency/voltage > > + value pair. > > + Please refer the for nvmem-cells > > + bindings Documentation/devicetree/bindings/nvmem/nvmem.txt > > + and also examples below. > > + > > +In every OPP node: > > +- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. > > + Bitmap: > > + 0: speedbin 0 > > + 1: speedbin 1 > > + 2: speedbin 2 > > + 3-31: unused > > I'm wondering if that's the right approach. > > I guess we could also have three different OPP tables, and pass them > all three through a phandle array, and have the kernel code select > which one is relevant based on the SID content It's ok. But why not use the way we already have? Is it necessary to introduce new helper? > > Another option would be to use the OF_DYNAMIC code to fill > operating-points-v2 at kernel boot, before (or when) cpufreq kicks in. My thought is to keep the same with others. And this situation may make thingis complex though it works. Hi vireshk, I want to hear from you. Yours, Yangtao > > ATF could also do that work. > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel