Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965434AbbDXHJ1 (ORCPT ); Fri, 24 Apr 2015 03:09:27 -0400 Received: from mail-la0-f47.google.com ([209.85.215.47]:35946 "EHLO mail-la0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965004AbbDXHJZ (ORCPT ); Fri, 24 Apr 2015 03:09:25 -0400 MIME-Version: 1.0 In-Reply-To: <20150423125358.GA29702@leverpostej> References: <1429522047-16675-1-git-send-email-pi-cheng.chen@linaro.org> <1429522047-16675-3-git-send-email-pi-cheng.chen@linaro.org> <20150423125358.GA29702@leverpostej> Date: Fri, 24 Apr 2015 15:09:23 +0800 Message-ID: Subject: Re: [PATCH 2/2] ARM64: mt8173: dts Add MT8173 cpufreq driver support From: Pi-Cheng Chen To: Mark Rutland Cc: Viresh Kumar , Mike Turquette , Matthias Brugger , "Joe.C" , Eddie Huang , Howard Chen , "fan.chen@mediatek.com" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linaro-kernel@lists.linaro.org" , "linux-mediatek@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3370 Lines: 96 Hi Mark, Thanks for reviewing. On Thu, Apr 23, 2015 at 8:53 PM, Mark Rutland wrote: > On Mon, Apr 20, 2015 at 10:27:27AM +0100, pi-cheng.chen wrote: >> This patch adds voltage supplies and clocks used by MT8173 cpufreq driver. >> >> Signed-off-by: pi-cheng.chen > > This series has no bindings for these properties. Will add documents for these. > >> --- >> arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 9 +++++++++ >> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 6 ++++++ >> 2 files changed, 15 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts >> index 96e141c..7a00cfe 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts >> +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts >> @@ -330,3 +330,12 @@ >> status = "okay"; >> clock-frequency = <100000>; >> }; >> + >> +&cpu0 { >> + proc-supply = <&mt6397_vpca15_reg>; >> +}; >> + >> +&cpu2 { >> + proc-supply = <&da9211_vcpu_reg>; >> + sram-supply = <&mt6397_vsramca7_reg>; >> +}; > > > Why do only two CPUs have these properties, and why does one need an > sram-supply? For better description of hardware, I think putting these properties in all CPUs share the same supplies is logical. For each cluster of MT8173, we have both PROC and SRAM supplies. But only on one cluster (cpu2 and cpu3) we need to control both voltage supplies. The SRAM supply on cpu0 cluster is controlled by hardware automatically. Therefore I put sram-supply only on cpu2. For better description of hardware, it might be a good idea to put the SRAM supply in cpu0 also though we don't use it in the driver, right? > >> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> index d9cc84e..b8a5454 100644 >> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi >> @@ -51,6 +51,9 @@ >> device_type = "cpu"; >> compatible = "arm,cortex-a53"; >> reg = <0x000>; >> + clocks = <&infracfg INFRA_CA53SEL>, >> + <&apmixedsys APMIXED_MAINPLL>; >> + clock-names = "cpu", "intermediate"; >> }; >> >> cpu1: cpu@1 { >> @@ -65,6 +68,9 @@ >> compatible = "arm,cortex-a57"; >> reg = <0x100>; >> enable-method = "psci"; >> + clocks = <&infracfg INFRA_CA57SEL>, >> + <&apmixedsys APMIXED_MAINPLL>; >> + clock-names = "cpu", "intermediate"; >> }; > > We should really describe this information per-cpu rather than assuming > that it's the same for siblings. Arbitrarily making one CPU in each > cluster (or other arbitrary grouping) special for the binding is silly. Yes, I agree with you and same above. I did these because most of the platforms in kernel did these. So should I do it the way you suggest? Thanks. Best Regards, Pi-Cheng > > Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/