Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3626287ybl; Sun, 12 Jan 2020 23:05:10 -0800 (PST) X-Google-Smtp-Source: APXvYqx7juV7SK9yrx4TZHGxgnlRd8sIjF8ApDKJ0tThMLfRK3ZZqSDlCsuneAylwemXQAZSMCvB X-Received: by 2002:aca:5fc6:: with SMTP id t189mr11889211oib.166.1578899110028; Sun, 12 Jan 2020 23:05:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578899110; cv=none; d=google.com; s=arc-20160816; b=DkQJJunY0Jjhb9Sci/Wr4L4dav1b2GPqqMttVFaKVVn9EPBuv21o1Uh4ms10KvrDZr vj3BecTXd6swIM2tRNid+Q2hpS+JyKnOBFWKYbNCkcPhY2PoPOfsEMrCeTczim63ar+K 5V4vSGHtctYwf1QXY6Hxihx/wGPvkbHUyFQG0ZBPiBaBD5keq5Z8qj4K7QilLlVfwOXO OhzXLg6dFxsnVQwc/+c6/Tj8Ku8Up09AXJgmKRHFXfZ/2cXlqYt3Gos7dT30AIZRJhfe 4nBeAjiA4G/260pAMSWqF3ph0WFJKaIhXrLbYS0xSY6lc6zjgJI9cyr4QODzXgupnwnY 25kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2K36+LY4tN/Cuk9TuKZ9obMWdWD2cQOBdE1ooq67vcY=; b=YQTPPuPG7QKugA3s6Xe69YxMDR4HBBTXW17z0ot+mQCNDbWF0E1hYdvjt8ZazmJnVA Dg+kCzBEKMGrW8rF2afJGn5ipdhkpUeoInsw3qGm+7yqETUoAU1lySRyXkyvlJj+WTHx nCWf2raAwL7lylvI98u0ZVXkpWYwu60v+HOb19pZQ9o8e5F/M7DLv+k7yoNbDHFfIdiG FlRocGAs3bKLyXGrv8d+E6xubdHsXkHz3gpogrXocQMjp417rT9KZl++XzIxVY3Wh7SF 2xA7/HDqENeIFeHfxC1Bo4CrY8A0AYvTMGlKhEGLC0yzlVFs1bOxRXSPMjujZAjl5Fp5 D/2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b="A/xMlDoR"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w1si5974349oia.169.2020.01.12.23.04.57; Sun, 12 Jan 2020 23:05:10 -0800 (PST) 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; dkim=pass header.i=@chromium.org header.s=google header.b="A/xMlDoR"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728669AbgAMHC6 (ORCPT + 99 others); Mon, 13 Jan 2020 02:02:58 -0500 Received: from mail-qk1-f196.google.com ([209.85.222.196]:42907 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725954AbgAMHC6 (ORCPT ); Mon, 13 Jan 2020 02:02:58 -0500 Received: by mail-qk1-f196.google.com with SMTP id z14so7579497qkg.9 for ; Sun, 12 Jan 2020 23:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2K36+LY4tN/Cuk9TuKZ9obMWdWD2cQOBdE1ooq67vcY=; b=A/xMlDoReXGb70l5stlQeC5VS6KsRtK3WJhpU6b+scCfDM3Vf0zDYy+RAF+OIF4lrA fMSXjyto0aKufDajYSWeZzCh/lOr7eBgVuz3C3n1aNEXCmodW5s7FMPq2vhMpGeMawu5 dM1ZJv50OY3YhDsvyyQCa9w5fBvuu34+PBwbY= 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=2K36+LY4tN/Cuk9TuKZ9obMWdWD2cQOBdE1ooq67vcY=; b=kr00BFy4jQT61lzQgrlnEQJFHuiXlX3BOX4ULs9RDMTs+xBL9512UE/psyugmxfcI4 uiRtm4SeZ9m3Lh7d4KsRMIrXoW1fyMeAPk8IhcLlQAly3Xyz5aeq9vn/oYx5abO2pReB dAhqnanlHQn0mgvPF1hT08Rxbu50NO5hZZxSwbor7aNpBdmzzJGgLz9MhrLQRnAOlfAs j5UtKVcUI8cY1w4icYkI+A2U/qdH8XyJSEG85T9XvXu9hQItKDRjzPnAGjODKffxEJ7r yLKsznWrcvJKK3+45Rj1395Wj5ptVwOvkPhcKdu4Dy9xlKWuNOd8zjZlsZ1v8evhugF1 lUzg== X-Gm-Message-State: APjAAAV4QN5lYtMu1ZKrmrQRLHkbLaBp9/RDjNUa97RiObkig/vjrHV8 VdFEp50QVnD+tSJkIOukYs9USArIPdarHGbmLjCfUh5S X-Received: by 2002:a05:620a:6d7:: with SMTP id 23mr14161009qky.299.1578898977343; Sun, 12 Jan 2020 23:02:57 -0800 (PST) MIME-Version: 1.0 References: <20190906100514.30803-1-roger.lu@mediatek.com> <20190906100514.30803-2-roger.lu@mediatek.com> <20190930133548.GA24574@bogus> <1577429450.10290.47.camel@mtksdaap41> In-Reply-To: <1577429450.10290.47.camel@mtksdaap41> From: Nicolas Boichat Date: Mon, 13 Jan 2020 15:02:46 +0800 Message-ID: Subject: Re: [PATCH v5 1/3] dt-bindings: soc: add mtk svs dt-bindings To: Roger Lu Cc: Rob Herring , Kevin Hilman , Nicolas Boichat , Stephen Boyd , Fan Chen , HenryC Chen , YT Lee , Angus Lin , Mark Rutland , Matthias Brugger , Nishanth Menon , Devicetree List , linux-arm Mailing List , "moderated list:ARM/Mediatek SoC support" , lkml , linux-pm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 27, 2019 at 2:51 PM Roger Lu wrote: > > Dear Rob, > > Sorry for the late reply. > > On Mon, 2019-09-30 at 08:35 -0500, Rob Herring wrote: > > On Fri, Sep 06, 2019 at 06:05:13PM +0800, Roger Lu wrote: > > > Document the binding for enabling mtk svs on MediaTek SoC. > > > > > > Signed-off-by: Roger Lu > > > --- > > > .../devicetree/bindings/power/mtk-svs.txt | 88 +++++++++++++++++++ > > > 1 file changed, 88 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/power/mtk-svs.txt > > > > > > diff --git a/Documentation/devicetree/bindings/power/mtk-svs.txt b/Documentation/devicetree/bindings/power/mtk-svs.txt > > > new file mode 100644 > > > index 000000000000..6a71992ef162 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/power/mtk-svs.txt > > > @@ -0,0 +1,88 @@ > > > +* Mediatek Smart Voltage Scaling (MTK SVS) > > > + > > > +This describes the device tree binding for the MTK SVS controller (bank) > > > +which helps provide the optimized CPU/GPU/CCI voltages. This device also > > > +needs thermal data to calculate thermal slope for accurately compensate > > > +the voltages when temperature change. > > > + > > > +Required properties: > > > +- compatible: > > > + - "mediatek,mt8183-svs" : For MT8183 family of SoCs > > > +- reg: Address range of the MTK SVS controller. > > > +- interrupts: IRQ for the MTK SVS controller. > > > +- clocks, clock-names: Clocks needed for the svs controller. required > > > + clocks are: > > > + "main_clk": Main clock needed for register access > > > > '_clk' is redundant. > > Oh Okay. I'll remove _clk. Thanks. > > > > > > +- nvmem-cells: Phandle to the calibration data provided by a nvmem device. > > > +- nvmem-cell-names: Should be "svs-calibration-data" and "calibration-data" > > > + > > > +Subnodes: > > > +- svs_cpu_little: SVS bank device node of little CPU > > > + compatible: "mediatek,mt8183-svs-cpu-little" > > > + operating-points-v2: OPP table hooked by SVS little CPU bank. > > > + SVS will optimze this OPP table voltage part. > > > + vcpu-little-supply: PMIC buck of little CPU > > > +- svs_cpu_big: SVS bank device node of big CPU > > > + compatible: "mediatek,mt8183-svs-cpu-big" > > > + operating-points-v2: OPP table hooked by SVS big CPU bank. > > > + SVS will optimze this OPP table voltage part. > > > + vcpu-big-supply: PMIC buck of big CPU > > > +- svs_cci: SVS bank device node of CCI > > > + compatible: "mediatek,mt8183-svs-cci" > > > + operating-points-v2: OPP table hooked by SVS CCI bank. > > > + SVS will optimze this OPP table voltage part. > > > + vcci-supply: PMIC buck of CCI > > > +- svs_gpu: SVS bank device node of GPU > > > + compatible: "mediatek,mt8183-svs-gpu" > > > + operating-points-v2: OPP table hooked by SVS GPU bank. > > > + SVS will optimze this OPP table voltage part. > > > + vgpu-spply: PMIC buck of GPU > > > + > > > +Example: > > > + > > > + svs: svs@1100b000 { > > > + compatible = "mediatek,mt8183-svs"; > > > + reg = <0 0x1100b000 0 0x1000>; > > > + interrupts = ; > > > > GIC interrupts are 3 cells, you have 4. > > Oops, I'll remove the fourth parameter. Thanks a lot. > > > > > > + clocks = <&infracfg CLK_INFRA_THERM>; > > > + clock-names = "main_clk"; > > > + nvmem-cells = <&svs_calibration>, <&thermal_calibration>; > > > + nvmem-cell-names = "svs-calibration-data", "calibration-data"; > > > + > > > + svs_cpu_little: svs_cpu_little { > > > > Don't use '_' in node names. > > Okay. I'll replace it with '-'. Thanks. > > > > > > + compatible = "mediatek,mt8183-svs-cpu-little"; > > > + operating-points-v2 = <&cluster0_opp>; > > > + }; > > > + > > > + svs_cpu_big: svs_cpu_big { > > > + compatible = "mediatek,mt8183-svs-cpu-big"; > > > + operating-points-v2 = <&cluster1_opp>; > > > + }; > > > + > > > + svs_cci: svs_cci { > > > + compatible = "mediatek,mt8183-svs-cci"; > > > + operating-points-v2 = <&cci_opp>; > > > + }; > > > + > > > + svs_gpu: svs_gpu { > > > + compatible = "mediatek,mt8183-svs-gpu"; > > > + power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_2D>; > > > + operating-points-v2 = <&gpu_opp_table>; > > > + }; > > > + }; > > > + > > > + &svs_cpu_little { > > > + vcpu-little-supply = <&mt6358_vproc12_reg>; > > > > It's already defined to have OPP and supply in the cpu nodes. Parse them > > to get this information rather than duplicating it here. > > > > The same should apply to the CCI and GPU. > > Please let me explain the reason why I add SVS sub-nodes. I ever try to > parse other nodes to get desired power-domains/OPP table. However, it > makes SVS driver harder to develop and maintain. > > 1. When a SVS-controller-init wants GPU_CORE0's OPP table in one node > but it needs power-domains(GPU_MFG_2D) in another node, it becomes > complicated and confusing when SVS sub-node tries to parse many nodes. > Therefore, we want SVS sub-node to focus on what SVS bank requires by > how we do in this patch. > > 2. In hardware point of view, SVS controller depends on other hardware's > power only. All the SVS controller registers are in SVS hardware. So, we > think It's good that SVS sub-node describes what SVS controller requires > instead of linking other subsys nodes and parse the property that SVS > controller needs. > > 3. We want SVS driver to have a generic way to attain subsys device for > using "pm_runtime and OPP framework" API. If SVS driver tries to parse > CPU(little/big core) and other subsys device node(e.g cci/gpu), it means > SVS driver has to maintain different methodologies(cpu-specific? > devfreq? others?) in order to get CPU(little/big core) and other subsys > device(e.g cci/gpu) for using "pm_runtime and OPP framework" API. (Didn't see this more complete reply before replying to v6, I can see your argument, but if we wanted to push further to have the sub-device node in the DT) From what I see, the SVS driver for node x (cpu/cci/gpu) requires only 3 things: - An OPP table => that should always be "operating-points-v2" property of the node x. - A power domain => that should always be power-domains property of node x. - A regulator. That one is a bit tricky as the cpu/cci uses "proc", but gpu uses "mali" (at least on 8183). But maybe you can add a child-regulator-name property or something to the DT so that the SVS driver can find the correct regulator? Seems like the solution could be quite generic? > > > > Rob > > Sincerely, > Roger Lu.