Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755428AbbG0Bgo (ORCPT ); Sun, 26 Jul 2015 21:36:44 -0400 Received: from dd34104.kasserver.com ([85.13.151.79]:52908 "EHLO dd34104.kasserver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755364AbbG0Bgn (ORCPT ); Sun, 26 Jul 2015 21:36:43 -0400 X-Greylist: delayed 502 seconds by postgrey-1.27 at vger.kernel.org; Sun, 26 Jul 2015 21:36:42 EDT From: Timo Sigurdsson To: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com, ijc+devicetree@hellion.org.uk, galak@codeaurora.org, linux@arm.linux.org.uk, maxime.ripard@free-electrons.com, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Cc: Timo Sigurdsson Subject: [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi Date: Mon, 27 Jul 2015 03:28:06 +0200 Message-Id: <1437960486-2809-1-git-send-email-public_timo.s@silentcreek.de> X-Mailer: git-send-email 2.1.4 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3062 Lines: 107 sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU driver, so add them to allow for voltage-scaling with cpufreq-dt. With the regulators enabled, we can define board-specific operating points. The defined CPU voltages are more conservative (based on the values used by the vendor), so they should be more failsafe across all boards of this kind out there. I'm posting this as RFC as I would like to make a few more remarks and raise questions along the way (plus, I'm anything but an experienced developer, so a a critical review might help). I checked the regulator definitions against the schematics released by LeMaker. I also compared that to the DT and schematics of Cubiboard 2 and Cubietruck. Of course, I also tested the patch on the actual hardware and it works fine for me. The CPU voltages are slightly higher than those set in sun7i-a20.dtsi and even though they work well for me, I thought it might be safer to use the more conservative values used by LeMaker in their old fex file. Would you agree? Besides, it it ok to have this in one patch or should it be splitted in two (one for the regulators and one for the opp)? Did I miss something important? Signed-off-by: Timo Sigurdsson --- arch/arm/boot/dts/sun7i-a20-bananapi.dts | 47 +++++++++++++++++++++++++++++--- 1 file changed, 43 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts index 9f7b472..2bcbb0e 100644 --- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts +++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts @@ -92,6 +92,22 @@ status = "okay"; }; +&cpu0 { + cpu-supply = <®_dcdc2>; + operating-points = < + /* kHz uV */ + 1008000 1450000 + 960000 1425000 + 912000 1425000 + 864000 1350000 + 720000 1250000 + 528000 1150000 + 312000 1100000 + 144000 1050000 + >; + cooling-max-level = <7>; +}; + &ehci0 { status = "okay"; }; @@ -119,13 +135,9 @@ status = "okay"; axp209: pmic@34 { - compatible = "x-powers,axp209"; reg = <0x34>; interrupt-parent = <&nmi_intc>; interrupts = <0 IRQ_TYPE_LEVEL_LOW>; - - interrupt-controller; - #interrupt-cells = <1>; }; }; @@ -182,6 +194,33 @@ }; }; +#include "axp209.dtsi" + +®_dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; +}; + +®_dcdc3 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1400000>; + regulator-name = "vdd-int-dll"; +}; + +®_ldo1 { + regulator-name = "vdd-rtc"; +}; + +®_ldo2 { + regulator-always-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "avcc"; +}; + ®_usb1_vbus { status = "okay"; }; -- 2.1.4 -- 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/