* [PATCH 4/9] ARM: dts: armada388-clearfog: move DSA switch
From: Russell King @ 2017-01-02 14:58 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the DSA switch configuration to the clearfog .dts file as this is
only present on the pro models.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 75 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 69 ---------------------------
2 files changed, 75 insertions(+), 69 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index c5f2ca5f6144..a1176d23a444 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -53,4 +53,79 @@
model = "SolidRun Clearfog A1";
compatible = "solidrun,clearfog-a1", "marvell,armada388",
"marvell,armada385", "marvell,armada380";
+
+ dsa@0 {
+ compatible = "marvell,dsa";
+ dsa,ethernet = <ð1>;
+ dsa,mii-bus = <&mdio>;
+ pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
+ pinctrl-names = "default";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ switch@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4 0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan5";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan4";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan3";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan2";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan1";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "cpu";
+ };
+
+ port@6 {
+ /* 88E1512 external phy */
+ reg = <6>;
+ label = "lan6";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+};
+
+ð1 {
+ /* ethernet@30000 */
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&pinctrl {
+ clearfog_dsa0_clk_pins: clearfog-dsa0-clk-pins {
+ marvell,pins = "mpp46";
+ marvell,function = "ref";
+ };
+ clearfog_dsa0_pins: clearfog-dsa0-pins {
+ marvell,pins = "mpp23", "mpp41";
+ marvell,function = "gpio";
+ };
};
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 59438777287a..fb02997a52a1 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -77,11 +77,6 @@
bm,pool-long = <2>;
bm,pool-short = <1>;
status = "okay";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
};
ethernet@34000 {
@@ -235,14 +230,6 @@
};
pinctrl@18000 {
- clearfog_dsa0_clk_pins: clearfog-dsa0-clk-pins {
- marvell,pins = "mpp46";
- marvell,function = "ref";
- };
- clearfog_dsa0_pins: clearfog-dsa0-pins {
- marvell,pins = "mpp23", "mpp41";
- marvell,function = "gpio";
- };
clearfog_i2c1_pins: i2c1-pins {
/* SFP, PCIe, mSATA, mikrobus */
marvell,pins = "mpp26", "mpp27";
@@ -339,62 +326,6 @@
};
};
- dsa@0 {
- compatible = "marvell,dsa";
- dsa,ethernet = <ð1>;
- dsa,mii-bus = <&mdio>;
- pinctrl-0 = <&clearfog_dsa0_clk_pins &clearfog_dsa0_pins>;
- pinctrl-names = "default";
- #address-cells = <2>;
- #size-cells = <0>;
-
- switch@0 {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = <4 0>;
-
- port@0 {
- reg = <0>;
- label = "lan5";
- };
-
- port@1 {
- reg = <1>;
- label = "lan4";
- };
-
- port@2 {
- reg = <2>;
- label = "lan3";
- };
-
- port@3 {
- reg = <3>;
- label = "lan2";
- };
-
- port@4 {
- reg = <4>;
- label = "lan1";
- };
-
- port@5 {
- reg = <5>;
- label = "cpu";
- };
-
- port@6 {
- /* 88E1512 external phy */
- reg = <6>;
- label = "lan6";
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
- };
- };
-
gpio-keys {
compatible = "gpio-keys";
pinctrl-0 = <&rear_button_pins>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/9] ARM: dts: armada388-clearfog: move second PCIe port
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the second PCIe port to the clearfog .dts file as this is only
present on the pro models.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 51 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 28 ++--------------
2 files changed, 54 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index a1176d23a444..1ee953112d23 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -54,6 +54,23 @@
compatible = "solidrun,clearfog-a1", "marvell,armada388",
"marvell,armada385", "marvell,armada380";
+ soc {
+ internal-regs {
+ usb3@f0000 {
+ /* CON2, nearest CPU, USB2 only. */
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ pcie@3,0 {
+ /* Port 2, Lane 0. CON2, nearest CPU. */
+ reset-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+ };
+ };
+
dsa@0 {
compatible = "marvell,dsa";
dsa,ethernet = <ð1>;
@@ -119,6 +136,40 @@
};
};
+&expander0 {
+ /*
+ * PCA9655 GPIO expander:
+ * 0-CON3 CLKREQ#
+ * 1-CON3 PERST#
+ * 2-CON2 PERST#
+ * 3-CON3 W_DISABLE
+ * 4-CON2 CLKREQ#
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ * 7-CON2 W_DISABLE
+ * 8-JP4 P1
+ * 9-JP4 P4
+ * 10-JP4 P5
+ * 11-m.2 DEVSLP
+ * 12-SFP_LOS
+ * 13-SFP_TX_FAULT
+ * 14-SFP_TX_DISABLE
+ * 15-SFP_MOD_DEF0
+ */
+ pcie2_0_clkreq {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie2.0-clkreq";
+ };
+ pcie2_0_w_disable {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie2.0-w-disable";
+ };
+};
+
&pinctrl {
clearfog_dsa0_clk_pins: clearfog-dsa0-clk-pins {
marvell,pins = "mpp46";
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index fb02997a52a1..ef4fbc6db7cf 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -103,12 +103,12 @@
* PCA9655 GPIO expander, up to 1MHz clock.
* 0-CON3 CLKREQ#
* 1-CON3 PERST#
- * 2-CON2 PERST#
+ * 2-
* 3-CON3 W_DISABLE
- * 4-CON2 CLKREQ#
+ * 4-
* 5-USB3 overcurrent
* 6-USB3 power
- * 7-CON2 W_DISABLE
+ * 7-
* 8-JP4 P1
* 9-JP4 P4
* 10-JP4 P5
@@ -143,18 +143,6 @@
output-low;
line-name = "pcie1.0-w-disable";
};
- pcie2_0_clkreq {
- gpio-hog;
- gpios = <4 GPIO_ACTIVE_LOW>;
- input;
- line-name = "pcie2.0-clkreq";
- };
- pcie2_0_w_disable {
- gpio-hog;
- gpios = <7 GPIO_ACTIVE_LOW>;
- output-low;
- line-name = "pcie2.0-w-disable";
- };
usb3_ilimit {
gpio-hog;
gpios = <5 GPIO_ACTIVE_LOW>;
@@ -296,11 +284,6 @@
status = "okay";
};
- usb3@f0000 {
- /* CON2, nearest CPU, USB2 only. */
- status = "okay";
- };
-
usb3@f8000 {
/* CON7 */
status = "okay";
@@ -318,11 +301,6 @@
reset-gpios = <&expander0 1 GPIO_ACTIVE_LOW>;
status = "okay";
};
- pcie@3,0 {
- /* Port 2, Lane 0. CON2, nearest CPU. */
- reset-gpios = <&expander0 2 GPIO_ACTIVE_LOW>;
- status = "okay";
- };
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 6/9] ARM: dts: armada388-clearfog: move SPI CS1
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the SPI CS1 configuration to the clearfog .dts file as this is only
present on pro models.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 14 ++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 10 ++--------
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index 1ee953112d23..b56ce4a32519 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -179,4 +179,18 @@
marvell,pins = "mpp23", "mpp41";
marvell,function = "gpio";
};
+ clearfog_spi1_cs_pins: spi1-cs-pins {
+ marvell,pins = "mpp55";
+ marvell,function = "spi1";
+ };
+};
+
+&spi1 {
+ /*
+ * Add SPI CS pins for clearfog:
+ * CS0: W25Q32 (not populated on uSOM)
+ * CS1:
+ * CS2: mikrobus
+ */
+ pinctrl-0 = <&spi1_pins &clearfog_spi1_cs_pins &mikro_spi_pins>;
};
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index ef4fbc6db7cf..30b75379377a 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -227,10 +227,6 @@
marvell,pins = "mpp20";
marvell,function = "gpio";
};
- clearfog_spi1_cs_pins: spi1-cs-pins {
- marvell,pins = "mpp55";
- marvell,function = "spi1";
- };
mikro_pins: mikro-pins {
/* int: mpp22 rst: mpp29 */
marvell,pins = "mpp22", "mpp29";
@@ -323,12 +319,10 @@
/*
* Add SPI CS pins for clearfog:
* CS0: W25Q32 (not populated on uSOM)
- * CS1:
+ * CS1: PIC microcontroller (Pro models)
* CS2: mikrobus
*/
- pinctrl-0 = <&spi1_pins
- &clearfog_spi1_cs_pins
- &mikro_spi_pins>;
+ pinctrl-0 = <&spi1_pins &mikro_spi_pins>;
pinctrl-names = "default";
status = "okay";
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 7/9] ARM: dts: armada388-clearfog: move rear button
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the rear button support into the clearfog pro support file.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dts | 18 ++++++++++++++++++
arch/arm/boot/dts/armada-388-clearfog.dtsi | 18 ------------------
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
index b56ce4a32519..51887b85dba4 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -126,6 +126,20 @@
};
};
};
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button_0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
};
ð1 {
@@ -183,6 +197,10 @@
marvell,pins = "mpp55";
marvell,function = "spi1";
};
+ rear_button_pins: rear-button-pins {
+ marvell,pins = "mpp34";
+ marvell,function = "gpio";
+ };
};
&spi1 {
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 30b75379377a..770d4bff6884 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -240,10 +240,6 @@
marvell,pins = "mpp24", "mpp25";
marvell,function = "ua1";
};
- rear_button_pins: rear-button-pins {
- marvell,pins = "mpp34";
- marvell,function = "gpio";
- };
};
sata@a8000 {
@@ -299,20 +295,6 @@
};
};
};
-
- gpio-keys {
- compatible = "gpio-keys";
- pinctrl-0 = <&rear_button_pins>;
- pinctrl-names = "default";
-
- button_0 {
- /* The rear SW3 button */
- label = "Rear Button";
- gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
- linux,can-disable;
- linux,code = <BTN_0>;
- };
- };
};
&spi1 {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 8/9] ARM: dts: armada388-clearfog: add base model DTS file
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Rob Herring, Mark Rutland, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Add the DTS file to describe the clearfog base model.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-clearfog-base.dts | 94 ++++++++++++++++++++++++++
2 files changed, 95 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-base.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba75cbcc..22d2ca2b52ec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -921,6 +921,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
armada-388-clearfog.dtb \
+ armada-388-clearfog-base.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
armada-388-rd.dtb
diff --git a/arch/arm/boot/dts/armada-388-clearfog-base.dts b/arch/arm/boot/dts/armada-388-clearfog-base.dts
new file mode 100644
index 000000000000..f86e1876fb38
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-clearfog-base.dts
@@ -0,0 +1,94 @@
+/*
+ * Device Tree file for SolidRun Clearfog Base revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2015 Russell King
+ *
+ * This board is in development; the contents of this file work with
+ * the A1 rev 2.0 of the board, which does not represent final
+ * production board. Things will change, don't expect this file to
+ * remain compatible info the future.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "armada-388-clearfog.dtsi"
+
+/ {
+ model = "SolidRun Clearfog Base A1";
+ compatible = "solidrun,clearfog-base-a1",
+ "solidrun,clearfog-a1", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&rear_button_pins>;
+ pinctrl-names = "default";
+
+ button_0 {
+ /* The rear SW3 button */
+ label = "Rear Button";
+ gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
+ linux,can-disable;
+ linux,code = <BTN_0>;
+ };
+ };
+};
+
+ð1 {
+ phy = <&phy1>;
+};
+
+&mdio {
+ phy1: ethernet-phy@1 {
+ /*
+ * Annoyingly, the marvell phy driver configures the LED
+ * register, rather than preserving reset-loaded setting.
+ * We undo that rubbish here.
+ */
+ marvell,reg-init = <3 16 0 0x101e>;
+ reg = <1>;
+ };
+};
+
+&pinctrl {
+ rear_button_pins: rear-button-pins {
+ marvell,pins = "mpp44";
+ marvell,function = "gpio";
+ };
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 9/9] ARM: dts: armada388-clearfog: add pro model DTS file
From: Russell King @ 2017-01-02 14:59 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Rob Herring, Mark Rutland, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO43Q-0007yJ-ON-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Add the DTS file to describe the clearfog pro model - we update the
platform name and compatible string compared to the original version.
The original version remains for compatibility for the time being as
the name of the file has become established, and the machine name
and/or compatible may be used by userspace.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-388-clearfog-pro.dts | 55 +++++++++++++++++++++++++++
2 files changed, 56 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-388-clearfog-pro.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 22d2ca2b52ec..8cf288f8b84f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -922,6 +922,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-linksys-cobra.dtb \
armada-388-clearfog.dtb \
armada-388-clearfog-base.dtb \
+ armada-388-clearfog-pro.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
armada-388-rd.dtb
diff --git a/arch/arm/boot/dts/armada-388-clearfog-pro.dts b/arch/arm/boot/dts/armada-388-clearfog-pro.dts
new file mode 100644
index 000000000000..e0c630a4d92c
--- /dev/null
+++ b/arch/arm/boot/dts/armada-388-clearfog-pro.dts
@@ -0,0 +1,55 @@
+/*
+ * Device Tree file for SolidRun Clearfog Pro revision A1 rev 2.0 (88F6828)
+ *
+ * Copyright (C) 2015 Russell King
+ *
+ * This board is in development; the contents of this file work with
+ * the A1 rev 2.0 of the board, which does not represent final
+ * production board. Things will change, don't expect this file to
+ * remain compatible info the future.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+#include "armada-388-clearfog.dts"
+
+/ {
+ model = "SolidRun Clearfog Pro A1";
+ compatible = "solidrun,clearfog-pro-a1",
+ "solidrun,clearfog-a1", "marvell,armada388",
+ "marvell,armada385", "marvell,armada380";
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-02 15:05 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <1483365844.21014.6.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
On 2 January 2017 at 15:04, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> Perhaps a better approach would be to not combine this with wiphy
> registration, but require drivers that may use this to call a new
> helper function *before* wiphy registration (and *after* calling
> set_wiphy_dev()), like e.g.
>
> ieee80211_read_of_data(wiphy);
>
> (...)
>
> Yes, this would mean that it doesn't automatically get applied to
> arbitrary drivers, but it seems unlikely that arbitrary drivers like
> realtek USB would suddenly get OF node entries ... so that's not
> necessarily a bad thing.
>
> In the documentation for this function you could then document that it
> will modify flags, and as such must not be called when the sband and
> channel data is shared, getting rid of the waste/complexity of the copy
> you otherwise have to make in cfg80211.
I just think it may be better to stick to something like
ieee80211_read_of_freq_limits
or
wiphy_read_of_freq_limits
As you noted this function will be a bit specific because of modifying
(possibly shared) band channels. At some point we may want to add more
helpers for other OF properties which won't have extra requirements
for driver code. Some drivers may want to use them while not necessary
risking have shared band channels modified.
--
Rafał
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 3/3] cfg80211: support ieee80211-freq-limit DT property
From: Johannes Berg @ 2017-01-02 15:10 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Rafał Miłecki
In-Reply-To: <CACna6rzvvkXBBHrDj4vVgcM0GmzTxM-Bh60nXYOkRH1-2WrWMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 2017-01-02 at 16:05 +0100, Rafał Miłecki wrote:
> On 2 January 2017 at 15:04, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> wrote:
> > Perhaps a better approach would be to not combine this with wiphy
> > registration, but require drivers that may use this to call a new
> > helper function *before* wiphy registration (and *after* calling
> > set_wiphy_dev()), like e.g.
> >
> > ieee80211_read_of_data(wiphy);
> >
> > (...)
> I just think it may be better to stick to something like
> ieee80211_read_of_freq_limits
> or
> wiphy_read_of_freq_limits
I have no objection to that.
> As you noted this function will be a bit specific because of
> modifying (possibly shared) band channels. At some point we may want
> to add more helpers for other OF properties which won't have extra
> requirements for driver code. Some drivers may want to use them while
> not necessary risking have shared band channels modified.
That makes sense, although at that time we might still wish to have a
common "read it all" with the combined requirements. But we can cross
that bridge when we get to it.
johannes
^ permalink raw reply
* [PATCH 0/5] ARM: dts: armada388: rework clearfog's .dtsi references
From: Russell King @ 2017-01-02 15:25 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring, Sebastian Hesselbarth
In-Reply-To: <E1cO454-00083C-Tj@rmk-PC.armlinux.org.uk>
This patch series, based upon the previous series adding Clearfog Base
support, reworks the clearfog .dtsi file to reference nodes by label
rather than by path.
Not everything is moved - just those which had labels at the time the
patches were created.
arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +
arch/arm/boot/dts/armada-388-clearfog.dtsi | 353 ++++++++++-----------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 113 ++++---
3 files changed, 245 insertions(+), 236 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/5] ARM: dts: armada388-clearfog: add phy reset gpio-hog
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog-base.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-clearfog-base.dts b/arch/arm/boot/dts/armada-388-clearfog-base.dts
index f86e1876fb38..da788ea40717 100644
--- a/arch/arm/boot/dts/armada-388-clearfog-base.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog-base.dts
@@ -74,7 +74,17 @@
phy = <&phy1>;
};
+&gpio0 {
+ phy1_reset {
+ gpio-hog;
+ gpios = <19 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "phy1-reset";
+ };
+};
+
&mdio {
+ pinctrl-0 = <&mdio_pins µsom_phy_clk_pins &clearfog_phy_pins>;
phy1: ethernet-phy@1 {
/*
* Annoyingly, the marvell phy driver configures the LED
@@ -87,6 +97,11 @@
};
&pinctrl {
+ /* phy1 reset */
+ clearfog_phy_pins: clearfog-phy-pins {
+ marvell,pins = "mpp19";
+ marvell,function = "gpio";
+ };
rear_button_pins: rear-button-pins {
marvell,pins = "mpp44";
marvell,function = "gpio";
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: armada388-clearfog: move device specific pinctrl nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the device specific pinctrl nodes over to use the label form to
reference the pin mux controller, rather than replicating the device
node path.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 50 +++++++++++-----------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 27 ++++++------
2 files changed, 38 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 770d4bff6884..7946400b4bf2 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -217,31 +217,6 @@
status = "okay";
};
- pinctrl@18000 {
- clearfog_i2c1_pins: i2c1-pins {
- /* SFP, PCIe, mSATA, mikrobus */
- marvell,pins = "mpp26", "mpp27";
- marvell,function = "i2c1";
- };
- clearfog_sdhci_cd_pins: clearfog-sdhci-cd-pins {
- marvell,pins = "mpp20";
- marvell,function = "gpio";
- };
- mikro_pins: mikro-pins {
- /* int: mpp22 rst: mpp29 */
- marvell,pins = "mpp22", "mpp29";
- marvell,function = "gpio";
- };
- mikro_spi_pins: mikro-spi-pins {
- marvell,pins = "mpp43";
- marvell,function = "spi1";
- };
- mikro_uart_pins: mikro-uart-pins {
- marvell,pins = "mpp24", "mpp25";
- marvell,function = "ua1";
- };
- };
-
sata@a8000 {
/* pinctrl? */
status = "okay";
@@ -297,6 +272,31 @@
};
};
+&pinctrl {
+ clearfog_i2c1_pins: i2c1-pins {
+ /* SFP, PCIe, mSATA, mikrobus */
+ marvell,pins = "mpp26", "mpp27";
+ marvell,function = "i2c1";
+ };
+ clearfog_sdhci_cd_pins: clearfog-sdhci-cd-pins {
+ marvell,pins = "mpp20";
+ marvell,function = "gpio";
+ };
+ mikro_pins: mikro-pins {
+ /* int: mpp22 rst: mpp29 */
+ marvell,pins = "mpp22", "mpp29";
+ marvell,function = "gpio";
+ };
+ mikro_spi_pins: mikro-spi-pins {
+ marvell,pins = "mpp43";
+ marvell,function = "spi1";
+ };
+ mikro_uart_pins: mikro-uart-pins {
+ marvell,pins = "mpp24", "mpp25";
+ marvell,function = "ua1";
+ };
+};
+
&spi1 {
/*
* Add SPI CS pins for clearfog:
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index 6608657b9994..e397421d1531 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -94,20 +94,6 @@
};
};
- pinctrl@18000 {
- microsom_phy_clk_pins: microsom-phy-clk-pins {
- marvell,pins = "mpp45";
- marvell,function = "ref";
- };
- /* Optional eMMC */
- microsom_sdhci_pins: microsom-sdhci-pins {
- marvell,pins = "mpp21", "mpp28",
- "mpp37", "mpp38",
- "mpp39", "mpp40";
- marvell,function = "sd0";
- };
- };
-
rtc@a3800 {
/*
* If the rtc doesn't work, run "date reset"
@@ -134,6 +120,19 @@
};
};
+&pinctrl {
+ microsom_phy_clk_pins: microsom-phy-clk-pins {
+ marvell,pins = "mpp45";
+ marvell,function = "ref";
+ };
+ /* Optional eMMC */
+ microsom_sdhci_pins: microsom-sdhci-pins {
+ marvell,pins = "mpp21", "mpp28", "mpp37",
+ "mpp38", "mpp39", "mpp40";
+ marvell,function = "sd0";
+ };
+};
+
&spi1 {
/* The microsom has an optional W25Q32 on board, connected to CS0 */
pinctrl-0 = <&spi1_pins>;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: armada388-clearfog: move I2C nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the I2C nodes over to use the label form to reference the I2C
controllers, rather than replicating the device node path.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 245 ++++++++++++++---------------
1 file changed, 120 insertions(+), 125 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 7946400b4bf2..eeb845bbe3f3 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -92,131 +92,6 @@
};
};
- i2c@11000 {
- /* Is there anything on this? */
- clock-frequency = <100000>;
- pinctrl-0 = <&i2c0_pins>;
- pinctrl-names = "default";
- status = "okay";
-
- /*
- * PCA9655 GPIO expander, up to 1MHz clock.
- * 0-CON3 CLKREQ#
- * 1-CON3 PERST#
- * 2-
- * 3-CON3 W_DISABLE
- * 4-
- * 5-USB3 overcurrent
- * 6-USB3 power
- * 7-
- * 8-JP4 P1
- * 9-JP4 P4
- * 10-JP4 P5
- * 11-m.2 DEVSLP
- * 12-SFP_LOS
- * 13-SFP_TX_FAULT
- * 14-SFP_TX_DISABLE
- * 15-SFP_MOD_DEF0
- */
- expander0: gpio-expander@20 {
- /*
- * This is how it should be:
- * compatible = "onnn,pca9655",
- * "nxp,pca9555";
- * but you can't do this because of
- * the way I2C works.
- */
- compatible = "nxp,pca9555";
- gpio-controller;
- #gpio-cells = <2>;
- reg = <0x20>;
-
- pcie1_0_clkreq {
- gpio-hog;
- gpios = <0 GPIO_ACTIVE_LOW>;
- input;
- line-name = "pcie1.0-clkreq";
- };
- pcie1_0_w_disable {
- gpio-hog;
- gpios = <3 GPIO_ACTIVE_LOW>;
- output-low;
- line-name = "pcie1.0-w-disable";
- };
- usb3_ilimit {
- gpio-hog;
- gpios = <5 GPIO_ACTIVE_LOW>;
- input;
- line-name = "usb3-current-limit";
- };
- usb3_power {
- gpio-hog;
- gpios = <6 GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "usb3-power";
- };
- m2_devslp {
- gpio-hog;
- gpios = <11 GPIO_ACTIVE_HIGH>;
- output-low;
- line-name = "m.2 devslp";
- };
- sfp_los {
- /* SFP loss of signal */
- gpio-hog;
- gpios = <12 GPIO_ACTIVE_HIGH>;
- input;
- line-name = "sfp-los";
- };
- sfp_tx_fault {
- /* SFP laser fault */
- gpio-hog;
- gpios = <13 GPIO_ACTIVE_HIGH>;
- input;
- line-name = "sfp-tx-fault";
- };
- sfp_tx_disable {
- /* SFP transmit disable */
- gpio-hog;
- gpios = <14 GPIO_ACTIVE_HIGH>;
- output-low;
- line-name = "sfp-tx-disable";
- };
- sfp_mod_def0 {
- /* SFP module present */
- gpio-hog;
- gpios = <15 GPIO_ACTIVE_LOW>;
- input;
- line-name = "sfp-mod-def0";
- };
- };
-
- /* The MCP3021 is 100kHz clock only */
- mikrobus_adc: mcp3021@4c {
- compatible = "microchip,mcp3021";
- reg = <0x4c>;
- };
-
- /* Also something at 0x64 */
- };
-
- i2c@11100 {
- /*
- * Routed to SFP, mikrobus, and PCIe.
- * SFP limits this to 100kHz, and requires
- * an AT24C01A/02/04 with address pins tied
- * low, which takes addresses 0x50 and 0x51.
- * Mikrobus doesn't specify beyond an I2C
- * bus being present.
- * PCIe uses ARP to assign addresses, or
- * 0x63-0x64.
- */
- clock-frequency = <100000>;
- pinctrl-0 = <&clearfog_i2c1_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
-
sata@a8000 {
/* pinctrl? */
status = "okay";
@@ -272,6 +147,126 @@
};
};
+&i2c0 {
+ /* Is there anything on this? */
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ /*
+ * PCA9655 GPIO expander, up to 1MHz clock.
+ * 0-CON3 CLKREQ#
+ * 1-CON3 PERST#
+ * 2-
+ * 3-CON3 W_DISABLE
+ * 4-
+ * 5-USB3 overcurrent
+ * 6-USB3 power
+ * 7-
+ * 8-JP4 P1
+ * 9-JP4 P4
+ * 10-JP4 P5
+ * 11-m.2 DEVSLP
+ * 12-SFP_LOS
+ * 13-SFP_TX_FAULT
+ * 14-SFP_TX_DISABLE
+ * 15-SFP_MOD_DEF0
+ */
+ expander0: gpio-expander@20 {
+ /*
+ * This is how it should be:
+ * compatible = "onnn,pca9655", "nxp,pca9555";
+ * but you can't do this because of the way I2C works.
+ */
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells = <2>;
+ reg = <0x20>;
+
+ pcie1_0_clkreq {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "pcie1.0-clkreq";
+ };
+ pcie1_0_w_disable {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_LOW>;
+ output-low;
+ line-name = "pcie1.0-w-disable";
+ };
+ usb3_ilimit {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "usb3-current-limit";
+ };
+ usb3_power {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "usb3-power";
+ };
+ m2_devslp {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "m.2 devslp";
+ };
+ sfp_los {
+ /* SFP loss of signal */
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sfp-los";
+ };
+ sfp_tx_fault {
+ /* SFP laser fault */
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "sfp-tx-fault";
+ };
+ sfp_tx_disable {
+ /* SFP transmit disable */
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "sfp-tx-disable";
+ };
+ sfp_mod_def0 {
+ /* SFP module present */
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "sfp-mod-def0";
+ };
+ };
+
+ /* The MCP3021 is 100kHz clock only */
+ mikrobus_adc: mcp3021@4c {
+ compatible = "microchip,mcp3021";
+ reg = <0x4c>;
+ };
+
+ /* Also something at 0x64 */
+};
+
+&i2c1 {
+ /*
+ * Routed to SFP, mikrobus, and PCIe.
+ * SFP limits this to 100kHz, and requires an AT24C01A/02/04 with
+ * address pins tied low, which takes addresses 0x50 and 0x51.
+ * Mikrobus doesn't specify beyond an I2C bus being present.
+ * PCIe uses ARP to assign addresses, or 0x63-0x64.
+ */
+ clock-frequency = <100000>;
+ pinctrl-0 = <&clearfog_i2c1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
&pinctrl {
clearfog_i2c1_pins: i2c1-pins {
/* SFP, PCIe, mSATA, mikrobus */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: armada388-clearfog: move ethernet related nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the ethernet, buffer manager, and mdio nodes over to use label form
to reference the devices rather than replicating the device path.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 44 +++++++------
.../arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 76 +++++++++++-----------
2 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index eeb845bbe3f3..6149699eefc2 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -71,27 +71,6 @@
soc {
internal-regs {
- ethernet@30000 {
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <2>;
- bm,pool-short = <1>;
- status = "okay";
- };
-
- ethernet@34000 {
- phy-mode = "sgmii";
- buffer-manager = <&bm>;
- bm,pool-long = <3>;
- bm,pool-short = <1>;
- status = "okay";
-
- fixed-link {
- speed = <1000>;
- full-duplex;
- };
- };
-
sata@a8000 {
/* pinctrl? */
status = "okay";
@@ -147,6 +126,29 @@
};
};
+ð1 {
+ /* ethernet@30000 */
+ bm,pool-long = <2>;
+ bm,pool-short = <1>;
+ buffer-manager = <&bm>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+ð2 {
+ /* ethernet@34000 */
+ bm,pool-long = <3>;
+ bm,pool-short = <1>;
+ buffer-manager = <&bm>;
+ phy-mode = "sgmii";
+ status = "okay";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
&i2c0 {
/* Is there anything on this? */
clock-frequency = <100000>;
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index e397421d1531..681962a6395b 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -62,38 +62,6 @@
MBUS_ID(0x0c, 0x04) 0 0xf1200000 0x100000>;
internal-regs {
- ethernet@70000 {
- pinctrl-0 = <&ge0_rgmii_pins>;
- pinctrl-names = "default";
- phy = <&phy_dedicated>;
- phy-mode = "rgmii-id";
- buffer-manager = <&bm>;
- bm,pool-long = <0>;
- bm,pool-short = <1>;
- status = "okay";
- };
-
- mdio@72004 {
- /*
- * Add the phy clock here, so the phy can be
- * accessed to read its IDs prior to binding
- * with the driver.
- */
- pinctrl-0 = <&mdio_pins µsom_phy_clk_pins>;
- pinctrl-names = "default";
-
- phy_dedicated: ethernet-phy@0 {
- /*
- * Annoyingly, the marvell phy driver
- * configures the LED register, rather
- * than preserving reset-loaded setting.
- * We undo that rubbish here.
- */
- marvell,reg-init = <3 16 0 0x101e>;
- reg = <0>;
- };
- };
-
rtc@a3800 {
/*
* If the rtc doesn't work, run "date reset"
@@ -107,16 +75,46 @@
pinctrl-names = "default";
status = "okay";
};
-
- bm@c8000 {
- status = "okay";
- };
};
+ };
+};
- bm-bppi {
- status = "okay";
- };
+&bm {
+ status = "okay";
+};
+
+&bm_bppi {
+ status = "okay";
+};
+
+ð0 {
+ /* ethernet@70000 */
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ pinctrl-names = "default";
+ phy = <&phy_dedicated>;
+ phy-mode = "rgmii-id";
+ buffer-manager = <&bm>;
+ bm,pool-long = <0>;
+ bm,pool-short = <1>;
+ status = "okay";
+};
+
+&mdio {
+ /*
+ * Add the phy clock here, so the phy can be accessed to read its
+ * IDs prior to binding with the driver.
+ */
+ pinctrl-0 = <&mdio_pins µsom_phy_clk_pins>;
+ pinctrl-names = "default";
+ phy_dedicated: ethernet-phy@0 {
+ /*
+ * Annoyingly, the marvell phy driver configures the LED
+ * register, rather than preserving reset-loaded setting.
+ * We undo that rubbish here.
+ */
+ marvell,reg-init = <3 16 0 0x101e>;
+ reg = <0>;
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 5/5] ARM: dts: armada388-clearfog: move uart nodes
From: Russell King @ 2017-01-02 15:27 UTC (permalink / raw)
To: Andrew Lunn, devicetree-u79uwXL29TY76Z2rM5mHXA, Gregory Clement,
Jason Cooper
Cc: Sebastian Hesselbarth, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <E1cO4UH-0008SR-GW-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
Move the uart nodes over to use the label form to reference the serial
devices, rather than replicating the device node path.
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
arch/arm/boot/dts/armada-388-clearfog.dtsi | 14 +++++++-------
arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 12 ++++++------
2 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dtsi b/arch/arm/boot/dts/armada-388-clearfog.dtsi
index 6149699eefc2..0f5938bede53 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dtsi
+++ b/arch/arm/boot/dts/armada-388-clearfog.dtsi
@@ -93,13 +93,6 @@
wp-inverted;
};
- serial@12100 {
- /* mikrobus uart */
- pinctrl-0 = <&mikro_uart_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
-
usb@58000 {
/* CON3, nearest power. */
status = "okay";
@@ -305,3 +298,10 @@
pinctrl-names = "default";
status = "okay";
};
+
+&uart1 {
+ /* mikrobus uart */
+ pinctrl-0 = <&mikro_uart_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
index 681962a6395b..458884ff4c8c 100644
--- a/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
+++ b/arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi
@@ -69,12 +69,6 @@
*/
status = "okay";
};
-
- serial@12000 {
- pinctrl-0 = <&uart0_pins>;
- pinctrl-names = "default";
- status = "okay";
- };
};
};
};
@@ -144,3 +138,9 @@
status = "disabled";
};
};
+
+&uart0 {
+ pinctrl-0 = <&uart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 7/9] i2c: i2c-mux-simple: new driver
From: Peter Rosin @ 2017-01-02 15:30 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wolfram Sang, Rob Herring, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, devicetree,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Linux Documentation List
In-Reply-To: <CAHp75Vc2uYhaYJu_eU-uBq_PZrUgaoNt8sxpuRF8eEEs2kPUwg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2017-01-01 16:38, Andy Shevchenko wrote:
> On Wed, Nov 30, 2016 at 10:17 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> This is a generic simple i2c mux that uses the generic multiplexer
>> subsystem to do the muxing.
>
>> +static const struct of_device_id i2c_mux_of_match[] = {
>> + { .compatible = "i2c-mux-simple,parent-locked",
>> + .data = (void *)0, },
>> + { .compatible = "i2c-mux-simple,mux-locked",
>> + .data = (void *)1, },
>> + {},
>> +};
>
> Perhaps
>
> #define I2C_MUX_LOCKED_PARENT 0
> #define I2C_MUX_LOCKED 1
I2C_MUX_LOCKED is already "taken" in include/linux/i2c-mux.h but I'll
use SIMPLE_PARENT_LOCKED and SIMPLE_MUX_LOCKED instead.
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 8/9] dt-bindings: mux-adg792a: document devicetree bindings for ADG792A/G mux
From: Peter Rosin @ 2017-01-02 16:01 UTC (permalink / raw)
To: Jonathan Cameron, linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio, linux-doc
In-Reply-To: <d4c41153-aebf-be05-a323-1298e8c4ee65@kernel.org>
On 2017-01-01 12:00, Jonathan Cameron wrote:
> On 30/11/16 08:17, Peter Rosin wrote:
>> Analog Devices ADG792A/G is a triple 4:1 mux.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
> Few comments inline. Worth adding anything about the gpio (output pins) to
> the binding at this stage as well? Would certainly be nice to support
> them.
I'll add optional properties "gpio-controller;" and "#gpio-cells = <2>;"
with the usual interpretation in v7 (but no implementation...) Is that
enough?
> Jonathan
>> ---
>> .../devicetree/bindings/misc/mux-adg792a.txt | 64 ++++++++++++++++++++++
>> 1 file changed, 64 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/misc/mux-adg792a.txt
>>
>> diff --git a/Documentation/devicetree/bindings/misc/mux-adg792a.txt b/Documentation/devicetree/bindings/misc/mux-adg792a.txt
>> new file mode 100644
>> index 000000000000..4677f9ab1c55
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/misc/mux-adg792a.txt
>> @@ -0,0 +1,64 @@
>> +Bindings for Analog Devices ADG792A/G Triple 4:1 Multiplexers
>> +
>> +Required properties:
>> +- compatible : "adi,adg792a" or "adi,adg792g"
>> +- #mux-control-cells : <0> if parallel, or <1> if not.
>> +* Standard mux-controller bindings as decribed in mux-controller.txt
>> +
>> +Optional properties:
>> +- adi,parallel : if present, the three muxes are bound together with a single
>> + mux controller, controlling all three muxes in parallel.
>> +- adi,idle-state : if present, array of states the three mux controllers will
>> + have when idle (or, if parallel, a single idle-state).
> Hmm. These are actually a policy decision. As only one policy will make
> sense for a given set of hardware probably fine to have it in here I guess.
> Might be worth adding a note to say this though.
I don't really know what you want me to add, do you have a suggestion for the
wording?
>> +
>> +Mux controller states 0 through 3 correspond to signals A through D in the
>> +datasheet. Mux controller states 4 and 5 are only available as possible idle
>> +states. State 4 represents that nothing is connected, and state 5 represents
>> +that the mux controller keeps the mux in its previously selected state during
>> +the idle period. State 5 is the default idle state.
> I'm never a great fan of magic numbers. Can we represent this more cleanly by
> breaking it into multiple properties?
> Optional:
> adi,idle-switch-to-channel : switch to this channel when idle.
> adi,idle-high-impedance : <boolean> the nothing connected state?
>
> If neither present leaves it in previous state?
It's not that easy. adi,idle-state is an array when there are three single
pole quadruple throw muxes, so there really needs to be a number for each
desired idle-behavior. Unless you have a better idea for how to describe
that?
Cheers,
peda
>> +
>> +Example:
>> +
>> + /* three independent mux controllers (of which one is used) */
>> + &i2c0 {
>> + mux: adg792a@50 {
>> + compatible = "adi,adg792a";
>> + reg = <0x50>;
>> + #mux-control-cells = <1>;
>> + };
>> + };
>> +
>> + adc-mux {
>> + compatible = "iio-mux";
>> + io-channels = <&adc 0>;
>> + io-channel-names = "parent";
>> +
>> + mux-controls = <&mux 1>;
>> +
>> + channels = "sync-1", "", "out";
>> + };
>> +
>> +
>> + /*
>> + * Three parallel muxes with one mux controller, useful e.g. if
>> + * the adc is differential, thus needing two signals to be muxed
>> + * simultaneously for correct operation.
>> + */
>> + &i2c0 {
>> + pmux: adg792a@50 {
>> + compatible = "adi,adg792a";
>> + reg = <0x50>;
>> + #mux-control-cells = <0>;
>> + adi,parallel;
>> + };
>> + };
>> +
>> + diff-adc-mux {
>> + compatible = "iio-mux";
>> + io-channels = <&adc 0>;
>> + io-channel-names = "parent";
>> +
>> + mux-controls = <&pmux>;
>> +
>> + channels = "sync-1", "", "out";
>> + };
>>
>
^ permalink raw reply
* Re: [PATCHv2 0/5] Add generic pinctrl helpers for managing groups and function
From: Gary Bisson @ 2017-01-02 16:14 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161230155957.GB3940@atomide.com>
Hi Linus, Tony,
On Fri, Dec 30, 2016 at 07:59:57AM -0800, Tony Lindgren wrote:
> * Gary Bisson <gary.bisson@boundarydevices.com> [161230 07:43]:
> > Hi Linus,
> >
> > On Fri, Dec 30, 2016 at 3:39 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > > On Tue, Dec 27, 2016 at 6:19 PM, Tony Lindgren <tony@atomide.com> wrote:
> > >
> > >> Here are some changes to add generic helpers for managing pinctrl groups and
> > >> functions.
> > >
> > > I applied it, screwed around with it and pushed to the build servers to see
> > > if it survived.
> > >
> > > I really like the look of this and I hope lots of driver start to use it.
> > >
> > > Gary, I just applied your radix patches for i.MX, can you look if you can
> > > use the GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUCNTIONS
> > > that Tony invented and that I just merged to my devel branch in the
> > > pinctrl tree?
> >
> > Yes I will have a look. It does sound like a good idea. I'll share my
> > findings beginning of next week.
So I've had a look and indeed I can use some of it. Here is what my
series looks like:
drivers/pinctrl/freescale/Kconfig | 3 +-
drivers/pinctrl/freescale/pinctrl-imx.c | 273
+++++++++-----------------------
drivers/pinctrl/freescale/pinctrl-imx.h | 33 +---
3 files changed, 80 insertions(+), 229 deletions(-)
Mainly I've used the generic functions in pinctrl_ops and pinmux_ops and
switched to the generic group/function_desc structures instead of the
imx-specific one that didn't bring anything else.
However I couldn't use the 'add' functions to add elements since the
parsing is done at probe time in its own way. So I've keep the
radix_insert functions. This could be modified though, it just requires
to modify the driver even more which I didn't feel like doing right now.
> OK great. Note that we may be able to come up also with a generic
> iterator function for the node_to_map functions so maybe see if
> you come up with some ideas for that while experimenting :)
I haven't had time to think about a generic node_to_map yet, but I
hopefully will have some time in a near future to think about it. Right
now it doesn't look obvious.
Also, I have some comments about your patches (already applied) which I
will send as a reply to the original patches.
Regards,
Gary
^ permalink raw reply
* Re: [3/5] pinctrl: core: Add generic pinctrl functions for managing groups
From: Gary Bisson @ 2017-01-02 16:21 UTC (permalink / raw)
To: Tony Lindgren
Cc: Linus Walleij, Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio, devicetree, linux-kernel, linux-omap
In-Reply-To: <20161227172003.6517-4-tony@atomide.com>
Hi Tony,
On Tue, Dec 27, 2016 at 09:20:01AM -0800, Tony Lindgren wrote:
> We can add generic helpers for function handling for cases where the pin
> controller driver does not need to use static arrays.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Shouldn't the patch title be:
pinctrl: core: Add generic pinmux functions for managing functions
It looks like a copy/paste issue since both patches have the same title:
824bef17d16c pinctrl: core: Add generic pinctrl functions for managing
groups
d70a0fb14682 pinctrl: core: Add generic pinctrl functions for managing
groups
That's actually my only remark, I had another comment about freeing the
trees but it is actually done in the unregister so everything is good.
Regards,
Gary
^ permalink raw reply
* [PATCH V3 1/2] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-02 16:32 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This new file should be used for properties that apply to all wireless
devices.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Switch to a single ieee80211-freq-limit property that allows specifying
*multiple* ranges. This resolves problem with more complex rules as pointed
by Felx.
Make description implementation agnostic as pointed by Arend.
Rename node to wifi as suggested by Martin.
V3: Use more real-life frequencies in the example.
---
.../devicetree/bindings/net/wireless/ieee80211.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ieee80211.txt b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
new file mode 100644
index 0000000..0cd1219
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ieee80211.txt
@@ -0,0 +1,18 @@
+Common IEEE 802.11 properties
+
+This provides documentation of common properties that are valid for all wireless
+devices.
+
+Optional properties:
+ - ieee80211-freq-limit : list of supported frequency ranges in KHz
+
+Example:
+
+pcie@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ wifi@0,0 {
+ reg = <0x0000 0 0 0 0>;
+ ieee80211-freq-limit = <2402000 2482000>,
+ <5170000 5250000>;
+ };
+};
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V3 2/2] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-02 16:32 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170102163209.2445-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
It allows specifying hardware limitations of supported channels. This
may be useful for specifying single band devices or devices that support
only some part of the whole band.
This can be useful for some tri-band routers that have separated radios
for lower and higher part of 5 GHz band.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
V2: Put main code in core.c as it isn't strictly part of regulatory - pointed
by Arend.
Update to support ieee80211-freq-limit (new property).
V3: Introduce separated wiphy_read_of_freq_limits function.
Add extra sanity checks for DT data.
Move code back to reg.c as suggested by Johannes.
---
include/net/cfg80211.h | 23 ++++++++++
net/wireless/core.c | 1 +
net/wireless/reg.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 142 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..5002625 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3515,6 +3515,9 @@ struct wiphy_iftype_ext_capab {
* attribute indices defined in &enum nl80211_bss_select_attr.
*
* @cookie_counter: unique generic cookie counter, used to identify objects.
+ *
+ * @n_freq_limits: number of frequency limits
+ * @freq_limits: array of extra frequency limits
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3646,6 +3649,9 @@ struct wiphy {
u64 cookie_counter;
+ unsigned int n_freq_limits;
+ struct ieee80211_freq_range *freq_limits;
+
char priv[0] __aligned(NETDEV_ALIGN);
};
@@ -4278,6 +4284,23 @@ const u8 *cfg80211_find_vendor_ie(unsigned int oui, int oui_type,
*/
/**
+ * wiphy_read_of_freq_limits - read frequency limits from device tree
+ *
+ * @wiphy: the wireless device to get extra limits for
+ *
+ * Some devices may have extra limitations specified in DT. This may be useful
+ * for chipsets that normally support more bands but are limited due to board
+ * design (e.g. by antennas or extermal power amplifier).
+ *
+ * This function reads info from DT and uses it to *modify* channels (disable
+ * unavailable ones) in a regulary code. It's usually a *bad* idea to use it in
+ * drivers with *shared* channel data as DT limitations are device specific.
+ *
+ * As this function access device node it has to be called after set_wiphy_dev.
+ */
+int wiphy_read_of_freq_limits(struct wiphy *wiphy);
+
+/**
* regulatory_hint - driver hint to the wireless core a regulatory domain
* @wiphy: the wireless device giving the hint (used only for reporting
* conflicts)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 158c59e..c1b5fc7 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -940,6 +940,7 @@ void cfg80211_dev_free(struct cfg80211_registered_device *rdev)
void wiphy_free(struct wiphy *wiphy)
{
+ kfree(wiphy->freq_limits);
put_device(&wiphy->dev);
}
EXPORT_SYMBOL(wiphy_free);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..e00fd5b 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1158,6 +1158,120 @@ static uint32_t reg_rule_to_chan_bw_flags(const struct ieee80211_regdomain *regd
return bw_flags;
}
+int wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ const __be32 *p;
+ int len, i, err;
+
+ if (wiphy->n_freq_limits)
+ return 0;
+
+ if (!dev)
+ return 0;
+ np = dev_of_node(dev);
+ if (!np)
+ return 0;
+
+ prop = of_find_property(np, "ieee80211-freq-limit", &len);
+ if (!prop)
+ return 0;
+
+ if (!len || len % sizeof(u32) || len / sizeof(u32) % 2) {
+ dev_err(dev, "ieee80211-freq-limit wrong format");
+ return -EPROTO;
+ }
+ wiphy->n_freq_limits = len / sizeof(u32) / 2;
+
+ wiphy->freq_limits = kzalloc(wiphy->n_freq_limits * sizeof(*wiphy->freq_limits),
+ GFP_KERNEL);
+ if (!wiphy->freq_limits) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ p = NULL;
+ for (i = 0; i < wiphy->n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &wiphy->freq_limits[i];
+
+ p = of_prop_next_u32(prop, p, &limit->start_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ p = of_prop_next_u32(prop, p, &limit->end_freq_khz);
+ if (!p) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ if (!limit->start_freq_khz ||
+ !limit->end_freq_khz ||
+ limit->start_freq_khz >= limit->end_freq_khz) {
+ err = -EINVAL;
+ goto out;
+ }
+ }
+
+ return 0;
+
+out:
+ dev_err(dev, "Failed to get limits: %d\n", err);
+ kfree(wiphy->freq_limits);
+ wiphy->n_freq_limits = 0;
+
+ return err;
+}
+EXPORT_SYMBOL(wiphy_read_of_freq_limits);
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < wiphy->n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &wiphy->freq_limits[i];
+
+ if (reg_does_bw_fit(limit, MHZ_TO_KHZ(chan->center_freq), bw))
+ return true;
+ }
+
+ return false;
+}
+
+static void wiphy_freq_limits_apply(struct wiphy *wiphy)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (!wiphy->n_freq_limits)
+ return;
+
+ for (band = 0; band < NUM_NL80211_BANDS; band++) {
+ struct ieee80211_supported_band *sband = wiphy->bands[band];
+
+ if (!sband)
+ continue;
+
+ for (i = 0; i < sband->n_channels; i++) {
+ struct ieee80211_channel *chan = &sband->channels[i];
+
+ if (chan->flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
/*
* Note that right now we assume the desired channel bandwidth
* is always 20 MHz for each individual channel (HT40 uses 20 MHz
@@ -1693,6 +1807,8 @@ static void wiphy_update_regulatory(struct wiphy *wiphy,
for (band = 0; band < NUM_NL80211_BANDS; band++)
handle_band(wiphy, initiator, wiphy->bands[band]);
+ wiphy_freq_limits_apply(wiphy);
+
reg_process_beacons(wiphy);
reg_process_ht_flags(wiphy);
reg_call_notifier(wiphy, lr);
@@ -1800,6 +1916,8 @@ void wiphy_apply_custom_regulatory(struct wiphy *wiphy,
bands_set++;
}
+ wiphy_freq_limits_apply(wiphy);
+
/*
* no point in calling this if it won't have any effect
* on your device's supported bands.
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V3 3/2] brcmfmac: use wiphy_read_of_freq_limits to get extra limits
From: Rafał Miłecki @ 2017-01-02 16:32 UTC (permalink / raw)
To: Johannes Berg, linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170102163209.2445-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
There are some devices (e.g. Netgear R8000 home router) with one chipset
model used for different radios, some of them limited to subbands. NVRAM
entries don't contain any extra info on such limitations and firmware
reports full list of channels to us. We need to store extra limitation
info on DT to support such devices properly.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This patch should probably go through wireless-driver-next, I'm sending
it just as a proof of concept. It was succesfully tested on SmartRG
SR400ac with BCM43602.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..dab4082 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6825,6 +6825,7 @@ struct brcmf_cfg80211_info *brcmf_cfg80211_attach(struct brcmf_pub *drvr,
goto priv_out;
brcmf_dbg(INFO, "Registering custom regulatory\n");
+ wiphy_read_of_freq_limits(wiphy);
wiphy->reg_notifier = brcmf_cfg80211_reg_notifier;
wiphy->regulatory_flags |= REGULATORY_CUSTOM_REG;
wiphy_apply_custom_regulatory(wiphy, &brcmf_regdom);
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 00/22] add support for AXP20X and AXP22X power supply drivers
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-iio, linux-kernel,
Quentin Schulz, bonbons, icenowy, linux-arm-kernel
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose
information and data of the various power supplies they support such as
ACIN, battery and VBUS. For example, they expose the current battery
voltage, charge or discharge, as well as ACIN and VBUS current voltages
and currents, internal PMIC temperature and ADC on 2 different GPIOs
when in the right mode (for the AXP209 only).
The ACIN power supply driver is added by this patch. The AXP20X and
AXP22X can both read the status and the "usability" of the power supply
but only the AXP209 will be able to tell the current current and voltage
of the power supply by reading ADC channels. It is simply not supported
by the AXP22X PMICs.
The battery power supply driver is also added by this patch. The AXP20X
and AXP22X share most of their behaviour but have slight variations. The
allowed target voltages for battery charging are not the same, the
AXP22X PMIC are able to tell if the battery percentage computed by the
PMIC is trustworthy and they have different formulas for computing max
current for battery power supply. The driver is able to give the current
voltage and current of the battery (be it charging or discharging), the
maximal and minimal voltage and maximal current allowed for the battery,
whether the battery is present and usable and its capacity. It will get
the battery current current and voltage by reading the ADC channels. The
PMIC allows maximal voltages (4.36V for AXP20X and 4.22V and 4.24V for
AXP22X) that should not be used with Lithium-based batteries and since
this PMIC is supposed to be used with Lithium-based batteries, they have
been disabled. The values returned by the ADC driver are multipled by
1000 to scale from the mV returned by the ADC to the uV expected by the
power supply framework.
This series of patch adds DT bindings for ACIN power supply, ADC and
battery power supply drivers for AXP20X and AXP22X PMICs and their
documentation. It also enables the supported power supplies for the
Nextthing Co. CHIP and Sinlinx SinA33 boards.
The different drivers are also added to the MFD cells of the AXP20X and
AXP22X cells and the writeable and volatile regs updated to work with
the newly added drivers.
VBUS driver has intentionally not been modified to use the ADC channels
because a DT binding already exists for this driver. Migrating the
driver would mean to add an iio_map to map the ADC channels to the VBUS
driver (so we can use iio_channel_get and iio_read_channel_processed
functions). This slightly complexifies the VBUS driver only for
"cosmetic" changes. Feel free to give your two cents on the matter.
This series of patch is based on a previous upstreaming attempt done by
Bruno Prémont few months ago. It differs in three points: the ADC
driver does not tell the battery temperature (TS_IN) as I do not have a
board to test it with, it does not tell the instantaneous battery power
as it returns crazy values for me and finally no support for OCV curves
for the battery.
[RFC]
I want to take this series of patch as an opportunity to ask what we should
do with the OCV curves.
A battery voltage does not decrease linearly but decreases slowly near
maximum and minimal voltage and quickly most of the time.
By taking raw values without an OCV curve, the battery percentage (or
often wrongly named "capacity") is computed by approximating by a linear
function. This results in battery percentage not lasting the same
depending if the battery is full, almost empty or within those two
states. For example, a decrease of 40 points could take as much time as
a decrease of 5 points when in low battery. Without an OCV curve, the
battery percentage returned by the battery driver (as it is done today)
is absolute non-sense.
When an OCV curve is provided, the percentage is approximated by this
OCV curve and battery percentage are very more likely to last the same
time and thus, being trustworthy.
While I understand the kernel has absolutely nothing to do with OCV
computation, the AXP20X/AXP22X PMICs raise a question due to their
ability to compute the approximated battery percentage if we give them
the OCV curve of the battery in some of their registers. No computing
has to be done in the kernel, we just have to give them the OCV curve of
the battery and the PMIC will return the approximated percentage.
The question is how to do it? IMHO, two different approaches are possible:
- give the OCV curve points in the Device Tree,
This allows the OCV curve to be fixed for boards with a non-removable
battery. However, it also avoids changing batteries without
recompiling the DT, which is definitely not end-user friendly.
The DT is here for hardware definition and battery is hardware
definition I guess, so it makes sense in a way, but it does not work
for removable batteries.
- give the OCV curve points via the POWER_SUPPLY_PROP_VOLTAGE_OCV sysfs
entry in the Power Supply framework,
This allows the OCV curve to be changed when a user switches the
batteries, but it also means that the OCV curve will always have to
be submitted by a small boot script which means it is
rootfs-dependent. Not really cool for a hardware component which in
embedded systems is more than likely not to change (IMHO).
Maybe, the best would be the two approaches at the same time: the
OCV curve of the default battery in the DT and the possibility to modify
the OCV curve via the POWER_SUPPLY_PROP_VOLTAGE_OCV sysfs entry?
Thanks,
Quentin
Quentin Schulz (22):
dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
mfd: axp20x: add ADC data regs to volatile regs for AXP22X
iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
mfd: axp20x: add ADC cells for AXP20X and AXP22X PMICs
ARM: dtsi: axp209: add AXP209 ADC subnode
ARM: dtsi: axp22x: add AXP22X ADC subnode
dt-bindings: power: supply: add AXP20X/AXP22X AC power supply
power: supply: add AC power supply driver for AXP20X and AXP22X PMICs
mfd: axp20x: add AC power supply cells for AXP22X PMICs
ARM: dtsi: axp209: add AC power supply subnode
ARM: dtsi: axp22x: add AC power supply subnode
ARM: dts: sun8i: sina33: enable ACIN power supply subnode
ARM: sun5i: chip: enable ACIN power supply subnode
dt-bindings: power: supply: add AXP20X/AXP22X battery DT binding
mfd: axp20x: add CHRG_CTRL1 to writeable regs for AXP20X/AXP22X
mfd: axp20x: add V_OFF to writeable regs for AXP20X and AXP22X
power: supply: add battery driver for AXP20X and AXP22X PMICs
mfd: axp20x: add MFD cells for AXP20X and AXP22X battery driver
ARM: dtsi: axp209: add battery power supply subnode
ARM: dtsi: axp22x: add battery power supply subnode
ARM: dts: sun8i: sina33: enable battery power supply subnode
ARM: sun5i: chip: enable battery power supply subnode
.../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 +
.../bindings/power/supply/axp20x_ac_power.txt | 27 ++
.../bindings/power/supply/axp20x_battery.txt | 24 +
arch/arm/boot/dts/axp209.dtsi | 19 +
arch/arm/boot/dts/axp22x.dtsi | 17 +
arch/arm/boot/dts/sun5i-r8-chip.dts | 8 +
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 8 +
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axp20x_adc.c | 490 +++++++++++++++++++++
drivers/mfd/axp20x.c | 35 +-
drivers/power/supply/Kconfig | 24 +
drivers/power/supply/Makefile | 2 +
drivers/power/supply/axp20x_ac_power.c | 251 +++++++++++
drivers/power/supply/axp20x_battery.c | 458 +++++++++++++++++++
include/linux/mfd/axp20x.h | 4 +
16 files changed, 1400 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_ac_power.txt
create mode 100644 Documentation/devicetree/bindings/power/supply/axp20x_battery.txt
create mode 100644 drivers/iio/adc/axp20x_adc.c
create mode 100644 drivers/power/supply/axp20x_ac_power.c
create mode 100644 drivers/power/supply/axp20x_battery.c
--
2.9.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 01/22] dt-bindings: iio: adc: add AXP20X/AXP22X ADC DT binding
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-iio, linux-kernel,
Quentin Schulz, bonbons, icenowy, linux-arm-kernel
In-Reply-To: <20170102163723.7939-1-quentin.schulz@free-electrons.com>
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
battery voltage, battery charge and discharge currents, AC-in and VBUS
voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
This adds the device tree binding documentation for the X-Powers AXP20X
and AXP22X PMICs ADCs.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
.../devicetree/bindings/iio/adc/axp20x_adc.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
new file mode 100644
index 0000000..1b60065
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/axp20x_adc.txt
@@ -0,0 +1,24 @@
+X-Powers AXP20X and AXP22X PMIC Analog to Digital Converter (ADC)
+
+The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
+battery voltage, battery charge and discharge currents, AC-in and VBUS
+voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
+
+The AXP22X PMICs do not have all ADCs of the AXP20X though.
+
+Required properties:
+ - compatible, one of:
+ "x-powers,axp209-adc"
+ "x-powers,axp221-adc"
+ - #io-channel-cells = <1>;
+
+This is a subnode of the AXP20X PMIC.
+
+Example:
+
+&axp209 {
+ axp209_adc: axp209_adc {
+ compatible = "x-powers,axp209-adc";
+ #io-channel-cells = <1>;
+ };
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 02/22] mfd: axp20x: add ADC data regs to volatile regs for AXP22X
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-iio, linux-kernel,
Quentin Schulz, bonbons, icenowy, linux-arm-kernel
In-Reply-To: <20170102163723.7939-1-quentin.schulz@free-electrons.com>
The AXP22X PMICs have multiple ADCs, each one exposing data from the
different power supplies connected to the PMIC.
This adds the different ADC data registers to the volatile registers of
the AXP22X PMIC.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/mfd/axp20x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 619a83e..a33db5e 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -100,6 +100,7 @@ static const struct regmap_range axp22x_writeable_ranges[] = {
static const struct regmap_range axp22x_volatile_ranges[] = {
regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_PWR_OP_MODE),
regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
+ regmap_reg_range(AXP22X_TEMP_ADC_H, AXP20X_BATT_DISCHRG_I_L),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
regmap_reg_range(AXP22X_GPIO_STATE, AXP22X_GPIO_STATE),
regmap_reg_range(AXP22X_PMIC_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
--
2.9.3
^ permalink raw reply related
* [PATCH 03/22] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
From: Quentin Schulz @ 2017-01-02 16:37 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, robh+dt, mark.rutland, wens, sre,
linux, maxime.ripard, lee.jones
Cc: thomas.petazzoni, devicetree, linux-pm, linux-iio, linux-kernel,
Quentin Schulz, bonbons, icenowy, linux-arm-kernel
In-Reply-To: <20170102163723.7939-1-quentin.schulz@free-electrons.com>
The X-Powers AXP20X and AXP22X PMICs have multiple ADCs. They expose the
battery voltage, battery charge and discharge currents, AC-in and VBUS
voltages and currents, 2 GPIOs muxable in ADC mode and PMIC temperature.
This adds support for most of AXP20X and AXP22X ADCs.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
drivers/iio/adc/Kconfig | 10 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/axp20x_adc.c | 490 +++++++++++++++++++++++++++++++++++++++++++
include/linux/mfd/axp20x.h | 4 +
4 files changed, 505 insertions(+)
create mode 100644 drivers/iio/adc/axp20x_adc.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 38bc319..5c5b51f 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -154,6 +154,16 @@ config AT91_SAMA5D2_ADC
To compile this driver as a module, choose M here: the module will be
called at91-sama5d2_adc.
+config AXP20X_ADC
+ tristate "X-Powers AXP20X and AXP22X ADC driver"
+ depends on MFD_AXP20X
+ help
+ Say yes here to have support for X-Powers power management IC (PMIC)
+ AXP20X and AXP22X ADC devices.
+
+ To compile this driver as a module, choose M here: the module will be
+ called axp20x_adc.
+
config AXP288_ADC
tristate "X-Powers AXP288 ADC driver"
depends on MFD_AXP20X
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index d36c4be..f5c28a5 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AT91_SAMA5D2_ADC) += at91-sama5d2_adc.o
+obj-$(CONFIG_AXP20X_ADC) += axp20x_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_BCM_IPROC_ADC) += bcm_iproc_adc.o
obj-$(CONFIG_BERLIN2_ADC) += berlin2-adc.o
diff --git a/drivers/iio/adc/axp20x_adc.c b/drivers/iio/adc/axp20x_adc.c
new file mode 100644
index 0000000..8df972a
--- /dev/null
+++ b/drivers/iio/adc/axp20x_adc.c
@@ -0,0 +1,490 @@
+/* ADC driver for AXP20X and AXP22X PMICs
+ *
+ * Copyright (c) 2016 Free Electrons NextThing Co.
+ * Quentin Schulz <quentin.schulz@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ *
+ */
+
+#include <linux/completion.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+
+#include <linux/iio/iio.h>
+#include <linux/mfd/axp20x.h>
+
+#define AXP20X_ADC_EN1_MASK GENMASK(7, 0)
+
+#define AXP20X_ADC_EN2_MASK (GENMASK(3, 2) | BIT(7))
+#define AXP22X_ADC_EN1_MASK (GENMASK(7, 5) | BIT(0))
+#define AXP20X_ADC_EN2_TEMP_ADC BIT(7)
+#define AXP20X_ADC_EN2_GPIO0_ADC BIT(3)
+#define AXP20X_ADC_EN2_GPIO1_ADC BIT(2)
+
+#define AXP20X_GPIO10_IN_RANGE_GPIO0 BIT(0)
+#define AXP20X_GPIO10_IN_RANGE_GPIO1 BIT(1)
+#define AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(x) ((x) & BIT(0))
+#define AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(x) (((x) & BIT(0)) << 1)
+
+#define AXP20X_ADC_RATE_MASK (3 << 6)
+#define AXP20X_ADC_RATE_25HZ (0 << 6)
+#define AXP20X_ADC_RATE_50HZ BIT(6)
+#define AXP20X_ADC_RATE_100HZ (2 << 6)
+#define AXP20X_ADC_RATE_200HZ (3 << 6)
+
+#define AXP22X_ADC_RATE_100HZ (0 << 6)
+#define AXP22X_ADC_RATE_200HZ BIT(6)
+#define AXP22X_ADC_RATE_400HZ (2 << 6)
+#define AXP22X_ADC_RATE_800HZ (3 << 6)
+
+#define AXP20X_ADC_CHANNEL(_channel, _name, _type, _reg) \
+ { \
+ .type = _type, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .address = _reg, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = _name, \
+ }
+
+#define AXP20X_ADC_CHANNEL_OFFSET(_channel, _name, _type, _reg) \
+ { \
+ .type = _type, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .address = _reg, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE) |\
+ BIT(IIO_CHAN_INFO_OFFSET),\
+ .datasheet_name = _name, \
+ }
+
+struct axp20x_adc_iio {
+ struct iio_dev *indio_dev;
+ struct regmap *regmap;
+};
+
+enum axp20x_adc_channel {
+ AXP20X_ACIN_V = 0,
+ AXP20X_ACIN_I,
+ AXP20X_VBUS_V,
+ AXP20X_VBUS_I,
+ AXP20X_TEMP_ADC,
+ AXP20X_GPIO0_V,
+ AXP20X_GPIO1_V,
+ AXP20X_BATT_V,
+ AXP20X_BATT_CHRG_I,
+ AXP20X_BATT_DISCHRG_I,
+ AXP20X_IPSOUT_V,
+};
+
+enum axp22x_adc_channel {
+ AXP22X_TEMP_ADC = 0,
+ AXP22X_BATT_V,
+ AXP22X_BATT_CHRG_I,
+ AXP22X_BATT_DISCHRG_I,
+};
+
+static const struct iio_chan_spec axp20x_adc_channels[] = {
+ AXP20X_ADC_CHANNEL(AXP20X_ACIN_V, "acin_v", IIO_VOLTAGE,
+ AXP20X_ACIN_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_ACIN_I, "acin_i", IIO_CURRENT,
+ AXP20X_ACIN_I_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_VBUS_V, "vbus_v", IIO_VOLTAGE,
+ AXP20X_VBUS_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_VBUS_I, "vbus_i", IIO_CURRENT,
+ AXP20X_VBUS_I_ADC_H),
+ AXP20X_ADC_CHANNEL_OFFSET(AXP20X_TEMP_ADC, "temp_adc", IIO_TEMP,
+ AXP20X_TEMP_ADC_H),
+ AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO0_V, "gpio0_v", IIO_VOLTAGE,
+ AXP20X_GPIO0_V_ADC_H),
+ AXP20X_ADC_CHANNEL_OFFSET(AXP20X_GPIO1_V, "gpio1_v", IIO_VOLTAGE,
+ AXP20X_GPIO1_V_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_V, "batt_v", IIO_VOLTAGE,
+ AXP20X_BATT_V_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
+ AXP20X_BATT_CHRG_I_H),
+ AXP20X_ADC_CHANNEL(AXP20X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
+ AXP20X_BATT_DISCHRG_I_H),
+ AXP20X_ADC_CHANNEL(AXP20X_IPSOUT_V, "ipsout_v", IIO_VOLTAGE,
+ AXP20X_IPSOUT_V_HIGH_H),
+};
+
+static const struct iio_chan_spec axp22x_adc_channels[] = {
+ AXP20X_ADC_CHANNEL_OFFSET(AXP22X_TEMP_ADC, "temp_adc", IIO_TEMP,
+ AXP22X_TEMP_ADC_H),
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_V, "batt_v", IIO_VOLTAGE,
+ AXP20X_BATT_V_H),
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_CHRG_I, "batt_chrg_i", IIO_CURRENT,
+ AXP20X_BATT_CHRG_I_H),
+ AXP20X_ADC_CHANNEL(AXP22X_BATT_DISCHRG_I, "batt_dischrg_i", IIO_CURRENT,
+ AXP20X_BATT_DISCHRG_I_H),
+};
+
+static int axp20x_adc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *channel, int *val,
+ int *val2)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int size = 12, ret;
+
+ switch (channel->channel) {
+ case AXP20X_BATT_DISCHRG_I:
+ size = 13;
+ case AXP20X_ACIN_V:
+ case AXP20X_ACIN_I:
+ case AXP20X_VBUS_V:
+ case AXP20X_VBUS_I:
+ case AXP20X_TEMP_ADC:
+ case AXP20X_BATT_V:
+ case AXP20X_BATT_CHRG_I:
+ case AXP20X_IPSOUT_V:
+ case AXP20X_GPIO0_V:
+ case AXP20X_GPIO1_V:
+ ret = axp20x_read_variable_width(info->regmap, channel->address,
+ size);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp22x_adc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *channel, int *val,
+ int *val2)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int size = 12, ret;
+
+ switch (channel->channel) {
+ case AXP22X_BATT_DISCHRG_I:
+ size = 13;
+ case AXP22X_TEMP_ADC:
+ case AXP22X_BATT_V:
+ case AXP22X_BATT_CHRG_I:
+ ret = axp20x_read_variable_width(info->regmap, channel->address,
+ size);
+ if (ret < 0)
+ return ret;
+ *val = ret;
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_adc_scale(int channel, int *val, int *val2)
+{
+ switch (channel) {
+ case AXP20X_ACIN_V:
+ case AXP20X_VBUS_V:
+ *val = 1;
+ *val2 = 700000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_ACIN_I:
+ *val = 0;
+ *val2 = 625000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_VBUS_I:
+ *val = 0;
+ *val2 = 375000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_TEMP_ADC:
+ *val = 100;
+ return IIO_VAL_INT;
+
+ case AXP20X_GPIO0_V:
+ case AXP20X_GPIO1_V:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_BATT_V:
+ *val = 1;
+ *val2 = 100000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_BATT_DISCHRG_I:
+ case AXP20X_BATT_CHRG_I:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP20X_IPSOUT_V:
+ *val = 1;
+ *val2 = 400000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp22x_adc_scale(int channel, int *val, int *val2)
+{
+ switch (channel) {
+ case AXP22X_TEMP_ADC:
+ *val = 100;
+ return IIO_VAL_INT;
+
+ case AXP22X_BATT_V:
+ *val = 1;
+ *val2 = 100000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ case AXP22X_BATT_DISCHRG_I:
+ case AXP22X_BATT_CHRG_I:
+ *val = 0;
+ *val2 = 500000;
+ return IIO_VAL_INT_PLUS_MICRO;
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_adc_offset(struct iio_dev *indio_dev, int channel, int *val)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+ int ret, reg;
+
+ switch (channel) {
+ case AXP20X_TEMP_ADC:
+ *val = -1447;
+ return IIO_VAL_INT;
+
+ case AXP20X_GPIO0_V:
+ case AXP20X_GPIO1_V:
+ ret = regmap_read(info->regmap, AXP20X_GPIO10_IN_RANGE, ®);
+ if (ret < 0)
+ return ret;
+
+ if (channel == AXP20X_GPIO0_V)
+ *val = reg & AXP20X_GPIO10_IN_RANGE_GPIO0;
+ else
+ *val = reg & AXP20X_GPIO10_IN_RANGE_GPIO1;
+
+ *val = !!(*val) * 700000;
+
+ return IIO_VAL_INT;
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_OFFSET:
+ return axp20x_adc_offset(indio_dev, chan->channel, val);
+
+ case IIO_CHAN_INFO_SCALE:
+ return axp20x_adc_scale(chan->channel, val, val2);
+
+ case IIO_CHAN_INFO_RAW:
+ return axp20x_adc_read_raw(indio_dev, chan, val, val2);
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp22x_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ switch (mask) {
+ case IIO_CHAN_INFO_OFFSET:
+ *val = -2667;
+ return IIO_VAL_INT;
+
+ case IIO_CHAN_INFO_SCALE:
+ return axp22x_adc_scale(chan->channel, val, val2);
+
+ case IIO_CHAN_INFO_RAW:
+ return axp22x_adc_read_raw(indio_dev, chan, val, val2);
+
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static int axp20x_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val, int val2,
+ long mask)
+{
+ struct axp20x_adc_iio *info = iio_priv(indio_dev);
+
+ /*
+ * The AXP20X PMIC allows the user to choose between 0V and 0.7V offsets
+ * for (independently) GPIO0 and GPIO1 when in ADC mode.
+ */
+ if (mask != IIO_CHAN_INFO_OFFSET)
+ return -EINVAL;
+
+ if (chan->channel != AXP20X_GPIO0_V && chan->channel != AXP20X_GPIO1_V)
+ return -EINVAL;
+
+ if (val != 0 && val != 700000)
+ return -EINVAL;
+
+ if (chan->channel == AXP20X_GPIO0_V)
+ return regmap_update_bits(info->regmap, AXP20X_GPIO10_IN_RANGE,
+ AXP20X_GPIO10_IN_RANGE_GPIO0,
+ AXP20X_GPIO10_IN_RANGE_GPIO0_VAL(!!val));
+
+ return regmap_update_bits(info->regmap, AXP20X_GPIO10_IN_RANGE,
+ AXP20X_GPIO10_IN_RANGE_GPIO1,
+ AXP20X_GPIO10_IN_RANGE_GPIO1_VAL(!!val));
+}
+
+static const struct iio_info axp20x_adc_iio_info = {
+ .read_raw = axp20x_read_raw,
+ .write_raw = axp20x_write_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static const struct iio_info axp22x_adc_iio_info = {
+ .read_raw = axp22x_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static const struct of_device_id axp20x_adc_of_match[] = {
+ { .compatible = "x-powers,axp209-adc", .data = (void *)AXP209_ID, },
+ { .compatible = "x-powers,axp221-adc", .data = (void *)AXP221_ID, },
+ { /* sentinel */ },
+};
+
+static int axp20x_probe(struct platform_device *pdev)
+{
+ struct axp20x_adc_iio *info;
+ struct iio_dev *indio_dev;
+ struct axp20x_dev *axp20x_dev;
+ int ret, axp20x_id;
+
+ axp20x_dev = dev_get_drvdata(pdev->dev.parent);
+
+ indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+ platform_set_drvdata(pdev, indio_dev);
+
+ info->regmap = axp20x_dev->regmap;
+ info->indio_dev = indio_dev;
+ indio_dev->name = dev_name(&pdev->dev);
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->dev.of_node = pdev->dev.of_node;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+
+ axp20x_id = (int)of_device_get_match_data(&pdev->dev);
+
+ switch (axp20x_id) {
+ case AXP209_ID:
+ indio_dev->info = &axp20x_adc_iio_info;
+ indio_dev->num_channels = ARRAY_SIZE(axp20x_adc_channels);
+ indio_dev->channels = axp20x_adc_channels;
+
+ /* Enable the ADCs on IP */
+ regmap_write(info->regmap, AXP20X_ADC_EN1, AXP20X_ADC_EN1_MASK);
+
+ /* Enable GPIO0/1 and internal temperature ADCs */
+ regmap_update_bits(info->regmap, AXP20X_ADC_EN2,
+ AXP20X_ADC_EN2_MASK, AXP20X_ADC_EN2_MASK);
+
+ /* Configure ADCs rate */
+ regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
+ AXP20X_ADC_RATE_MASK, AXP20X_ADC_RATE_50HZ);
+ break;
+
+ case AXP221_ID:
+ indio_dev->info = &axp22x_adc_iio_info;
+ indio_dev->num_channels = ARRAY_SIZE(axp22x_adc_channels);
+ indio_dev->channels = axp22x_adc_channels;
+
+ /* Enable the ADCs on IP */
+ regmap_write(info->regmap, AXP20X_ADC_EN1, AXP22X_ADC_EN1_MASK);
+
+ /* Configure ADCs rate */
+ regmap_update_bits(info->regmap, AXP20X_ADC_RATE,
+ AXP20X_ADC_RATE_MASK, AXP22X_ADC_RATE_200HZ);
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ ret = devm_iio_device_register(&pdev->dev, indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not register the device\n");
+ regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
+ regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int axp20x_remove(struct platform_device *pdev)
+{
+ struct axp20x_adc_iio *info;
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+ info = iio_priv(indio_dev);
+ regmap_write(info->regmap, AXP20X_ADC_EN1, 0);
+ regmap_write(info->regmap, AXP20X_ADC_EN2, 0);
+
+ return 0;
+}
+
+static struct platform_driver axp20x_adc_driver = {
+ .driver = {
+ .name = "axp20x-adc",
+ .of_match_table = axp20x_adc_of_match,
+ },
+ .probe = axp20x_probe,
+ .remove = axp20x_remove,
+};
+
+module_platform_driver(axp20x_adc_driver);
+
+MODULE_DESCRIPTION("ADC driver for AXP20X and AXP22X PMICs");
+MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
index a4860bc..650c6f6 100644
--- a/include/linux/mfd/axp20x.h
+++ b/include/linux/mfd/axp20x.h
@@ -150,6 +150,10 @@ enum {
#define AXP20X_VBUS_I_ADC_L 0x5d
#define AXP20X_TEMP_ADC_H 0x5e
#define AXP20X_TEMP_ADC_L 0x5f
+
+#define AXP22X_TEMP_ADC_H 0x56
+#define AXP22X_TEMP_ADC_L 0x57
+
#define AXP20X_TS_IN_H 0x62
#define AXP20X_TS_IN_L 0x63
#define AXP20X_GPIO0_V_ADC_H 0x64
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox