lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1437960486-2809-1-git-send-email-public_timo.s@silentcreek.de>
Date:	Mon, 27 Jul 2015 03:28:06 +0200
From:	Timo Sigurdsson <public_timo.s@...entcreek.de>
To:	robh+dt@...nel.org, pawel.moll@....com, mark.rutland@....com,
	ijc+devicetree@...lion.org.uk, galak@...eaurora.org,
	linux@....linux.org.uk, maxime.ripard@...e-electrons.com,
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, linux-sunxi@...glegroups.com
Cc:	Timo Sigurdsson <public_timo.s@...entcreek.de>
Subject: [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

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 <public_timo.s@...entcreek.de>
---
 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 = <&reg_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"
+
+&reg_dcdc2 {
+	regulator-always-on;
+	regulator-min-microvolt = <1050000>;
+	regulator-max-microvolt = <1450000>;
+	regulator-name = "vdd-cpu";
+};
+
+&reg_dcdc3 {
+	regulator-always-on;
+	regulator-min-microvolt = <1000000>;
+	regulator-max-microvolt = <1400000>;
+	regulator-name = "vdd-int-dll";
+};
+
+&reg_ldo1 {
+	regulator-name = "vdd-rtc";
+};
+
+&reg_ldo2 {
+	regulator-always-on;
+	regulator-min-microvolt = <3000000>;
+	regulator-max-microvolt = <3000000>;
+	regulator-name = "avcc";
+};
+
 &reg_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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ