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=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,UNPARSEABLE_RELAY, URIBL_BLOCKED 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 F0F8AC43219 for ; Thu, 2 May 2019 06:19:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C6A2D2085A for ; Thu, 2 May 2019 06:19:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726338AbfEBGTj (ORCPT ); Thu, 2 May 2019 02:19:39 -0400 Received: from mailgw01.mediatek.com ([210.61.82.183]:8295 "EHLO mailgw01.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726202AbfEBGTj (ORCPT ); Thu, 2 May 2019 02:19:39 -0400 X-UUID: 7e95605b17544ffc80cac70bcfe2c597-20190502 X-UUID: 7e95605b17544ffc80cac70bcfe2c597-20190502 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw01.mediatek.com (envelope-from ) (mhqrelay.mediatek.com ESMTP with TLS) with ESMTP id 759783719; Thu, 02 May 2019 14:19:33 +0800 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 14:19:31 +0800 Received: from [172.21.77.4] (172.21.77.4) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 2 May 2019 14:19:31 +0800 Message-ID: <1556777971.12123.35.camel@mtksdaap41> Subject: Re: [RFC v1 1/3] dt-bindings: soc: add mtk svs dt-bindings From: Roger Lu To: Stephen Boyd CC: "Rafael J . Wysocki" , Matthias Brugger , Rob Herring , Viresh Kumar , Mark Rutland , Nishanth Menon , , , "Kevin Hilman" , , , , , Date: Thu, 2 May 2019 14:19:31 +0800 In-Reply-To: <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> References: <20190430112012.4514-1-roger.lu@mediatek.com> <20190430112012.4514-2-roger.lu@mediatek.com> <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-SNTS-SMTP: 2E2F08777EB39D1A247C11B19DDF97D305EB6283DD65100F47975443F62BB5352000:8 X-MTK: N Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dear Stephen, Thanks for the review. On Tue, 2019-04-30 at 13:31 -0700, Stephen Boyd wrote: > Quoting Roger Lu (2019-04-30 04:20:10) > > Document the binding for enabling mtk svs on MediaTek SoC. > > > > Signed-off-by: Roger Lu > > --- > > .../devicetree/bindings/power/mtk-svs.txt | 70 +++++++++++++++++++ > > 1 file changed, 70 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..355329db74ba > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/mtk-svs.txt > > @@ -0,0 +1,70 @@ > > +* Mediatek Smart Voltage Scaling (MTK SVS) > > + > > +This describes the device tree binding for the MTK SVS controller > > +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 > > +- nvmem-cells: Phandle to the calibration data provided by a nvmem device. > > +- nvmem-cell-names: Should be "svs-calibration-data" and "calibration-data" > > +- svs_xxx: Phandle of svs_bank device for controlling corresponding opp > > Properties shouldn't have underscores in them. Use dashes? Ok. I'll use dashes. > > > + table and power-domains. > > +- vxxx-supply: Phandle to each regulator. vxxx can be "vcpu_little", > > + "vcpu_big", "vcci" and "vgpu". > > + > > +Example: > > + > > + svs: svs@1100b000 { > > + compatible = "mediatek,mt8183-svs"; > > + reg = <0 0x1100b000 0 0x1000>; > > + interrupts = ; > > + 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 { > > + 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 = <&cluster2_opp>; > > + }; > > + > > + svs_gpu: svs_gpu { > > + compatible = "mediatek,mt8183-svs-gpu"; > > + power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_2D>; > > + operating-points-v2 = <&gpu_opp_table>; > > + }; > > It looks like you need multiple OPPs for a single device, because it has > different independent power supplies it wants to associate the OPP > tables with? Yes. SVS has different controllers inside the hardware in order to calculate and optimize different OPP table voltage part. > Why can't these OPP tables be attached to the devices that > use them, i.e. CPU, GPU, CCI, etc.? Seems odd that those devices don't > have OPP tables that this hardware block can look up somehow. Those OPP tables are attached by our DVFS node (please refers below patch). SVS just shares with their OPP table and help optimize these OPP tables' voltage part. Add cpufreq DTS node to the mt8183 and mt8183-evb https://patchwork.kernel.org/patch/10921675/ > Similarly, > the power domains should probably be part of the devices that are using > them and not these sub-nodes that are mirroring the other hardware > blocks in the system? Oh. There is a svs controller in GPU power-domain. We need to turn on GPU power so that svs controller can work functionally. Therefore, we add GPU power-domains in our svs_gpu sub-node. > > > + }; > > + > > + &svs_cpu_little { > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger Lu Subject: Re: [RFC v1 1/3] dt-bindings: soc: add mtk svs dt-bindings Date: Thu, 2 May 2019 14:19:31 +0800 Message-ID: <1556777971.12123.35.camel@mtksdaap41> References: <20190430112012.4514-1-roger.lu@mediatek.com> <20190430112012.4514-2-roger.lu@mediatek.com> <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> Sender: linux-kernel-owner@vger.kernel.org To: Stephen Boyd Cc: "Rafael J . Wysocki" , Matthias Brugger , Rob Herring , Viresh Kumar , Mark Rutland , Nishanth Menon , devicetree@vger.kernel.org, linux-pm@vger.kernel.org, Kevin Hilman , linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Angus.Lin@mediatek.com, Andy-YT.Liu@mediatek.com List-Id: devicetree@vger.kernel.org Dear Stephen, Thanks for the review. On Tue, 2019-04-30 at 13:31 -0700, Stephen Boyd wrote: > Quoting Roger Lu (2019-04-30 04:20:10) > > Document the binding for enabling mtk svs on MediaTek SoC. > > > > Signed-off-by: Roger Lu > > --- > > .../devicetree/bindings/power/mtk-svs.txt | 70 +++++++++++++++++++ > > 1 file changed, 70 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..355329db74ba > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/mtk-svs.txt > > @@ -0,0 +1,70 @@ > > +* Mediatek Smart Voltage Scaling (MTK SVS) > > + > > +This describes the device tree binding for the MTK SVS controller > > +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 > > +- nvmem-cells: Phandle to the calibration data provided by a nvmem device. > > +- nvmem-cell-names: Should be "svs-calibration-data" and "calibration-data" > > +- svs_xxx: Phandle of svs_bank device for controlling corresponding opp > > Properties shouldn't have underscores in them. Use dashes? Ok. I'll use dashes. > > > + table and power-domains. > > +- vxxx-supply: Phandle to each regulator. vxxx can be "vcpu_little", > > + "vcpu_big", "vcci" and "vgpu". > > + > > +Example: > > + > > + svs: svs@1100b000 { > > + compatible = "mediatek,mt8183-svs"; > > + reg = <0 0x1100b000 0 0x1000>; > > + interrupts = ; > > + 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 { > > + 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 = <&cluster2_opp>; > > + }; > > + > > + svs_gpu: svs_gpu { > > + compatible = "mediatek,mt8183-svs-gpu"; > > + power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_2D>; > > + operating-points-v2 = <&gpu_opp_table>; > > + }; > > It looks like you need multiple OPPs for a single device, because it has > different independent power supplies it wants to associate the OPP > tables with? Yes. SVS has different controllers inside the hardware in order to calculate and optimize different OPP table voltage part. > Why can't these OPP tables be attached to the devices that > use them, i.e. CPU, GPU, CCI, etc.? Seems odd that those devices don't > have OPP tables that this hardware block can look up somehow. Those OPP tables are attached by our DVFS node (please refers below patch). SVS just shares with their OPP table and help optimize these OPP tables' voltage part. Add cpufreq DTS node to the mt8183 and mt8183-evb https://patchwork.kernel.org/patch/10921675/ > Similarly, > the power domains should probably be part of the devices that are using > them and not these sub-nodes that are mirroring the other hardware > blocks in the system? Oh. There is a svs controller in GPU power-domain. We need to turn on GPU power so that svs controller can work functionally. Therefore, we add GPU power-domains in our svs_gpu sub-node. > > > + }; > > + > > + &svs_cpu_little { > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek 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=-7.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,T_DKIMWL_WL_HIGH,UNPARSEABLE_RELAY,URIBL_BLOCKED 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 1955FC43219 for ; Thu, 2 May 2019 06:20:15 +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 DE42B2089E for ; Thu, 2 May 2019 06:20:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="hXIWM4C8" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DE42B2089E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.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:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hSdKRs8xJrckUGTdU2Hp+0/TW0iLK7kBVw3yS2Hzdhk=; b=hXIWM4C8YXSn1O Htm2ESty55pOjhobxUwZTHGs9j7s3HDpL0PfT9mtpOmDv40836e6e0gihfkTPGuM+G5yX0P6MSs5s r6NrcgvdrdKuEKsAxsZNI/im7JcE4SBrXWmt4z8nR+uG7awWz2reBmWdHYAObVkbK6ASN9shvwWpQ fejoAXKGwad40oPL/HtPHs5CJ+apEhFpMzu24eKFvTOm8zxmwZ1YUgHToDis8vroeX1cTluLr2u8C eDuz0izuWtrZJFjxb9lU4QuZkWfqb9BeVUQcTRp3pf45GXj2e5nEp1shkd1YtI2NN1RxZ4616g2qb Iq+YUfaA0wPYCKTteiZw==; 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 1hM54Z-0000s4-5E; Thu, 02 May 2019 06:19:59 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hM54U-0000rX-5c; Thu, 02 May 2019 06:19:56 +0000 X-UUID: b1f68a2e1a7d4243838937cd640a314e-20190501 X-UUID: b1f68a2e1a7d4243838937cd640a314e-20190501 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 1135422410; Wed, 01 May 2019 22:19:41 -0800 Received: from MTKMBS02N2.mediatek.inc (172.21.101.101) by MTKMBS62DR.mediatek.inc (172.29.94.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 May 2019 23:19:40 -0700 Received: from mtkcas07.mediatek.inc (172.21.101.84) by mtkmbs02n2.mediatek.inc (172.21.101.101) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 2 May 2019 14:19:31 +0800 Received: from [172.21.77.4] (172.21.77.4) by mtkcas07.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Thu, 2 May 2019 14:19:31 +0800 Message-ID: <1556777971.12123.35.camel@mtksdaap41> Subject: Re: [RFC v1 1/3] dt-bindings: soc: add mtk svs dt-bindings From: Roger Lu To: Stephen Boyd Date: Thu, 2 May 2019 14:19:31 +0800 In-Reply-To: <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> References: <20190430112012.4514-1-roger.lu@mediatek.com> <20190430112012.4514-2-roger.lu@mediatek.com> <155665629219.168659.8221738507474891604@swboyd.mtv.corp.google.com> X-Mailer: Evolution 3.10.4-0ubuntu2 MIME-Version: 1.0 X-TM-SNTS-SMTP: 2E2F08777EB39D1A247C11B19DDF97D305EB6283DD65100F47975443F62BB5352000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190501_231954_218671_1B5D9086 X-CRM114-Status: GOOD ( 19.47 ) 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: Mark Rutland , Nishanth Menon , Angus.Lin@mediatek.com, devicetree@vger.kernel.org, Viresh Kumar , linux-pm@vger.kernel.org, "Rafael J . Wysocki" , linux-kernel@vger.kernel.org, Kevin Hilman , Rob Herring , linux-mediatek@lists.infradead.org, Andy-YT.Liu@mediatek.com, Matthias Brugger , linux-arm-kernel@lists.infradead.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 Dear Stephen, Thanks for the review. On Tue, 2019-04-30 at 13:31 -0700, Stephen Boyd wrote: > Quoting Roger Lu (2019-04-30 04:20:10) > > Document the binding for enabling mtk svs on MediaTek SoC. > > > > Signed-off-by: Roger Lu > > --- > > .../devicetree/bindings/power/mtk-svs.txt | 70 +++++++++++++++++++ > > 1 file changed, 70 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..355329db74ba > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/power/mtk-svs.txt > > @@ -0,0 +1,70 @@ > > +* Mediatek Smart Voltage Scaling (MTK SVS) > > + > > +This describes the device tree binding for the MTK SVS controller > > +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 > > +- nvmem-cells: Phandle to the calibration data provided by a nvmem device. > > +- nvmem-cell-names: Should be "svs-calibration-data" and "calibration-data" > > +- svs_xxx: Phandle of svs_bank device for controlling corresponding opp > > Properties shouldn't have underscores in them. Use dashes? Ok. I'll use dashes. > > > + table and power-domains. > > +- vxxx-supply: Phandle to each regulator. vxxx can be "vcpu_little", > > + "vcpu_big", "vcci" and "vgpu". > > + > > +Example: > > + > > + svs: svs@1100b000 { > > + compatible = "mediatek,mt8183-svs"; > > + reg = <0 0x1100b000 0 0x1000>; > > + interrupts = ; > > + 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 { > > + 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 = <&cluster2_opp>; > > + }; > > + > > + svs_gpu: svs_gpu { > > + compatible = "mediatek,mt8183-svs-gpu"; > > + power-domains = <&scpsys MT8183_POWER_DOMAIN_MFG_2D>; > > + operating-points-v2 = <&gpu_opp_table>; > > + }; > > It looks like you need multiple OPPs for a single device, because it has > different independent power supplies it wants to associate the OPP > tables with? Yes. SVS has different controllers inside the hardware in order to calculate and optimize different OPP table voltage part. > Why can't these OPP tables be attached to the devices that > use them, i.e. CPU, GPU, CCI, etc.? Seems odd that those devices don't > have OPP tables that this hardware block can look up somehow. Those OPP tables are attached by our DVFS node (please refers below patch). SVS just shares with their OPP table and help optimize these OPP tables' voltage part. Add cpufreq DTS node to the mt8183 and mt8183-evb https://patchwork.kernel.org/patch/10921675/ > Similarly, > the power domains should probably be part of the devices that are using > them and not these sub-nodes that are mirroring the other hardware > blocks in the system? Oh. There is a svs controller in GPU power-domain. We need to turn on GPU power so that svs controller can work functionally. Therefore, we add GPU power-domains in our svs_gpu sub-node. > > > + }; > > + > > + &svs_cpu_little { > > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel