* [PATCH v3 1/2] Doc: devicetree: bindings: Add vendor prefix entry - lwn
From: Lukasz Majewski @ 2017-01-03 10:46 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Shawn Guo, Fabio Estevam,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Vladimir Zapolskiy
Cc: Sascha Hauer, Zerlauth Karl (LWN), Lukasz Majewski,
Lukasz Majewski
This patch adds entry for LWN - the Liebherr-Werk Nenzing GmbH company to
vendor-prefixes.txt file.
Signed-off-by: Lukasz Majewski <lukma-ynQEQJNshbs@public.gmane.org>
---
Changes for v3:
- Update to v4.10-rc2
Changes for v2:
- New patch
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 16d3b5e..8e2abcb 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -164,6 +164,7 @@ lg LG Corporation
linux Linux-specific binding
lltc Linear Technology Corporation
lsi LSI Corp. (LSI Logic)
+lwn Liebherr-Werk Nenzing GmbH
macnica Macnica Americas
marvell Marvell Technology Group Ltd.
maxim Maxim Integrated Products
--
2.1.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 v3 2/2] ARM: dts: imx6q: Add mccmon6 board support
From: Lukasz Majewski @ 2017-01-03 10:46 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Russell King, Shawn Guo, Fabio Estevam,
linux-kernel, devicetree, linux-arm-kernel, Vladimir Zapolskiy
Cc: Sascha Hauer, Zerlauth Karl (LWN), Lukasz Majewski,
Lukasz Majewski
In-Reply-To: <1483440381-24268-1-git-send-email-lukma@denx.de>
From: Lukasz Majewski <l.majewski@majess.pl>
This patch provides support for Liebherr's Monitor 6 board (abverrated as
mccmon6) to Linux kernel.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v3:
- Reorganize the dts file according to Shawn Guo's comments
Changes for v2:
- Reorganize the dts file according to Valdimir Zapolskiy's comments
---
MCCMON6 board support depends on following patches:
1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()"
http://patchwork.ozlabs.org/patch/708844/
2. "pwm: imx: Provide atomic operation for IMX PWM driver"
http://patchwork.ozlabs.org/patch/708847/ - http://patchwork.ozlabs.org/patch/708843/
The patch applies to v4.10-rc2
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-mccmon6.dts | 473 ++++++++++++++++++++++++++++++++++++
2 files changed, 474 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cccdbcb..316c178 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -393,6 +393,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
+ imx6q-mccmon6.dtb \
imx6q-nitrogen6x.dtb \
imx6q-nitrogen6_max.dtb \
imx6q-nitrogen6_som2.dtb \
diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts b/arch/arm/boot/dts/imx6q-mccmon6.dts
new file mode 100644
index 0000000..eedbe73
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
@@ -0,0 +1,473 @@
+/*
+ * Copyright 2016-2017
+ * Lukasz Majewski, DENX Software Engineering, lukma@denx.de
+ *
+ * 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.
+ *
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pwm/pwm.h>
+
+/ {
+ model = "Liebherr (LWN) monitor6 i.MX6 Quad Board";
+ compatible = "lwn,mccmon6", "fsl,imx6q";
+
+ memory {
+ reg = <0x10000000 0x80000000>;
+ };
+
+ backlight_lvds: backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight>;
+ pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
+ brightness-levels = < 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100 101 102 103 104 105 106 107 108 109
+ 110 111 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127 128 129
+ 130 131 132 133 134 135 136 137 138 139
+ 140 141 142 143 144 145 146 147 148 149
+ 150 151 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167 168 169
+ 170 171 172 173 174 175 176 177 178 179
+ 180 181 182 183 184 185 186 187 188 189
+ 190 191 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207 208 209
+ 210 211 212 213 214 215 216 217 218 219
+ 220 221 222 223 224 225 226 227 228 229
+ 230 231 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247 248 249
+ 250 251 252 253 254 255>;
+ default-brightness-level = <50>;
+ enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
+ };
+
+ reg_lvds: regulator-lvds {
+ compatible = "regulator-fixed";
+ regulator-name = "lvds_ppen";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lvds>;
+ gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel-lvds0 {
+ compatible = "innolux,g121x1-l03";
+ backlight = <&backlight_lvds>;
+ power-supply = <®_lvds>;
+
+ port {
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+ };
+};
+
+&ecspi3 {
+ cs-gpios = <&gpio4 24 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs &pinctrl_ecspi3_flwp>;
+ status = "okay";
+
+ s25sl032p: flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <40000000>;
+ reg = <0>;
+ };
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii";
+ phy-reset-gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
+ interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pfuze100: pmic@08 {
+ compatible = "fsl,pfuze100";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1ab {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw1c_reg: sw1c {
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1875000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3a {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3b_reg: sw3b {
+ regulator-min-microvolt = <400000>;
+ regulator-max-microvolt = <1975000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw4_reg: sw4 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vgen1_reg: vgen1 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen2_reg: vgen2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vgen3_reg: vgen3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vgen4_reg: vgen4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen5_reg: vgen5 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vgen6_reg: vgen6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ port@4 {
+ reg = <4>;
+
+ lvds0_out: endpoint {
+ remote-endpoint = <&panel_in_lvds0>;
+ };
+ };
+ };
+};
+
+&pwm2 {
+ #pwm-cells = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&weim {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
+ ranges = <0 0 0x08000000 0x08000000>;
+ status = "okay";
+
+ nor@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x02000000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <2>;
+ use-advanced-sector-protection;
+ fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
+ 0x0000c000 0x1404a38e 0x00000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+
+ pinctrl_backlight: dispgrp {
+ fsl,pins = <
+ /* BLEN_OUT */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
+ >;
+ };
+
+ pinctrl_ecspi3: ecspi3grp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
+ MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
+ MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
+ >;
+ };
+
+ pinctrl_ecspi3_cs: ecspi3csgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000
+ >;
+ };
+
+ pinctrl_ecspi3_flwp: ecspi3flwpgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x80000000
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
+ MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
+ MX6QDL_PAD_ENET_RXD0__GPIO1_IO27 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_reg_lvds: reqlvdsgrp {
+ fsl,pins = <
+ /* LVDS_PPEN_OUT */
+ MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
+ >;
+ };
+
+ pinctrl_weim_cs0: weimcs0grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
+ >;
+ };
+
+ pinctrl_weim_nor: weimnorgrp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
+ MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
+ MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
+ MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
+ MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
+ MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
+ MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
+ MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
+ MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
+ MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
+ MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
+ MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
+ MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
+ MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
+ MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
+ MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
+ MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
+ MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
+ MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
+ MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
+ MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
+ MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
+ MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
+ MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
+ MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
+ MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
+ MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
+ MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
+ MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
+ MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
+ MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
+ MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
+ MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
+ MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
+ MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
+ MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
+ MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
+ MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
+ MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
+ MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
+ MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
+ MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
+ MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
+ >;
+ };
+};
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: André Przywara @ 2017-01-03 10:48 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Ulf Hansson, Hans De Goede, Icenowy Zheng,
Mark Rutland, Rob Herring, devicetree,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <CAGb2v65GJFTnQZtWHCS7CAtA+Dry94o77aakPLr938BpQksLog-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 03/01/17 02:52, Chen-Yu Tsai wrote:
Hi,
> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
>
> A commit message explaining the mmc controllers would be nice.
OK.
>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
>> ---
>> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index e0dcab8..c680566 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -150,6 +150,32 @@
>> pins = "PB8", "PB9";
>> function = "uart0";
>> };
>> +
>> + mmc0_pins: mmc0@0 {
>> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
>> + function = "mmc0";
>> + drive-strength = <30>;
>> + };
>> +
>> + mmc0_default_cd_pin: mmc0_cd_pin@0 {
>> + pins = "PF6";
>> + function = "gpio_in";
>> + bias-pull-up;
>> + };
>
> We are starting to drop pinmux nodes for gpio usage.
And replacing them with what?
Or do you mean they go in the individual board .dts files?
In this case I believe having a default pin defined here would help to
define it in every .dts.
>> +
>> + mmc1_pins: mmc1@0 {
>> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
>> + function = "mmc1";
>> + drive-strength = <30>;
>> + };
>> +
>> + mmc2_pins: mmc2@0 {
>> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>> + "PC10", "PC11", "PC12", "PC13", "PC14",
>> + "PC15", "PC16";
>> + function = "mmc2";
>> + drive-strength = <30>;
>> + };
>
> Moreover I think you should split out the pinmux nodes to a separate patch.
I can surely do, just wondering what's the rationale is behind that?
>
>> };
>>
>> uart0: serial@1c28000 {
>> @@ -240,6 +266,47 @@
>> #size-cells = <0>;
>> };
>>
>> + mmc0: mmc@1c0f000 {
>> + compatible = "allwinner,sun50i-a64-mmc",
>> + "allwinner,sun5i-a13-mmc";
>
> Given that sun5i doesn't support mmc delay timings, and the A64 has
> calibration and delay timings, I wouldn't call them compatible.
>
> Or are you claiming that for the A64 has a delay of 0 for the
> currently supported speeds, so the calibration doesn't really
> matter? If so this should be mentioned in the commit message.
Yes, that's my observation: Driving it with sun5-a13-mmc just works.
This sun5i driver version does not (and will never) support higher
transfer modes anyway, so for that subset they are compatible. This
opens up the door to other operating systems not having a particular
driver for the A64, for instance, also older Linux kernels.
I know that sunxi doesn't use this compatible feature much, but IMHO we
should really start thinking about the DT not just being Linux specific
- or even being specific to a certain Linux version. And this case here
is a good example: An A13 MMC driver can drive this device - if there is
no better driver (an A64 one) available.
>
>> + reg = <0x01c0f000 0x1000>;
>> + clocks = <&ccu 31>, <&ccu 75>;
>
> The clock / reset index macros are in the tree now.
> Please switch to them.
The include file is in the tree, but it isn't used in the current HEAD
(as in #included and the actual macros being used in the .dtsi).
So I was wondering if there is a patch pending for that?
Cheers,
Andre
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 8>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> + mmc1: mmc@1c10000 {
>> + compatible = "allwinner,sun50i-a64-mmc",
>> + "allwinner,sun5i-a13-mmc";
>> + reg = <0x01c10000 0x1000>;
>> + clocks = <&ccu 32>, <&ccu 76>;
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 9>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> + mmc2: mmc@1c11000 {
>> + compatible = "allwinner,sun50i-a64-emmc";
>> + reg = <0x01c11000 0x1000>;
>> + clocks = <&ccu 33>, <&ccu 77>;
>> + clock-names = "ahb", "mmc";
>> + resets = <&ccu 10>;
>> + reset-names = "ahb";
>> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> +
>> gic: interrupt-controller@1c81000 {
>> compatible = "arm,gic-400";
>> reg = <0x01c81000 0x1000>,
>> --
>> 2.8.2
>>
^ permalink raw reply
* [PATCH V4 1/2] dt-bindings: document common IEEE 802.11 frequency limit property
From: Rafał Miłecki @ 2017-01-03 11:03 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
^ permalink raw reply related
* [PATCH V4 2/2] cfg80211: support ieee80211-freq-limit DT property
From: Rafał Miłecki @ 2017-01-03 11:03 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: <20170103110340.23249-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This patch adds a helper for reading that new property and applying
limitations or supported channels specified this way.
It may be useful for specifying single band devices or devices that
support only some part of the whole band. It's common that tri-band
routers 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.
V4: Move code to of.c
Use one helper called at init time (no runtime hooks)
Modify orig_flags
---
include/net/cfg80211.h | 26 ++++++++++
net/wireless/Makefile | 1 +
net/wireless/of.c | 137 +++++++++++++++++++++++++++++++++++++++++++++++++
net/wireless/reg.c | 4 +-
net/wireless/reg.h | 2 +
5 files changed, 168 insertions(+), 2 deletions(-)
create mode 100644 net/wireless/of.c
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ca2ac1c..d7723a8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -311,6 +311,32 @@ struct ieee80211_supported_band {
struct ieee80211_sta_vht_cap vht_cap;
};
+/**
+ * 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). 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.
+ * It also modifies channels so they have to be set first.
+ */
+#ifdef CONFIG_OF
+int wiphy_read_of_freq_limits(struct wiphy *wiphy);
+#else /* CONFIG_OF */
+static inline int wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ return 0;
+}
+#endif /* !CONFIG_OF */
+
+
/*
* Wireless hardware/device configuration structures and methods
*/
diff --git a/net/wireless/Makefile b/net/wireless/Makefile
index 4c9e39f..95b4c09 100644
--- a/net/wireless/Makefile
+++ b/net/wireless/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_WEXT_PRIV) += wext-priv.o
cfg80211-y += core.o sysfs.o radiotap.o util.o reg.o scan.o nl80211.o
cfg80211-y += mlme.o ibss.o sme.o chan.o ethtool.o mesh.o ap.o trace.o ocb.o
+cfg80211-$(CONFIG_OF) += of.o
cfg80211-$(CONFIG_CFG80211_DEBUGFS) += debugfs.o
cfg80211-$(CONFIG_CFG80211_WEXT) += wext-compat.o wext-sme.o
cfg80211-$(CONFIG_CFG80211_INTERNAL_REGDB) += regdb.o
diff --git a/net/wireless/of.c b/net/wireless/of.c
new file mode 100644
index 0000000..d5791c8
--- /dev/null
+++ b/net/wireless/of.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <linux/of.h>
+#include <net/cfg80211.h>
+#include "reg.h"
+
+static bool wiphy_freq_limits_valid_chan(struct wiphy *wiphy,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits,
+ struct ieee80211_channel *chan)
+{
+ u32 bw = MHZ_TO_KHZ(20);
+ int i;
+
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &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,
+ struct ieee80211_freq_range *freq_limits,
+ unsigned int n_freq_limits)
+{
+ enum nl80211_band band;
+ int i;
+
+ if (WARN_ON(!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->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
+ if (!wiphy_freq_limits_valid_chan(wiphy, freq_limits,
+ n_freq_limits,
+ chan)) {
+ pr_debug("Disabling freq %d MHz as it's out of OF limits\n",
+ chan->center_freq);
+ chan->orig_flags |= IEEE80211_CHAN_DISABLED;
+ }
+ }
+ }
+}
+
+int wiphy_read_of_freq_limits(struct wiphy *wiphy)
+{
+ struct device *dev = wiphy_dev(wiphy);
+ struct device_node *np;
+ struct property *prop;
+ struct ieee80211_freq_range *freq_limits;
+ unsigned int n_freq_limits;
+ const __be32 *p;
+ int len, i, err;
+
+ 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;
+ }
+ n_freq_limits = len / sizeof(u32) / 2;
+
+ freq_limits = kcalloc(n_freq_limits, sizeof(*freq_limits), GFP_KERNEL);
+ if (!freq_limits) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ p = NULL;
+ for (i = 0; i < n_freq_limits; i++) {
+ struct ieee80211_freq_range *limit = &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;
+ }
+ }
+
+ wiphy_freq_limits_apply(wiphy, freq_limits, n_freq_limits);
+
+ return 0;
+
+out:
+ dev_err(dev, "Failed to get limits: %d\n", err);
+ kfree(freq_limits);
+ return err;
+}
+EXPORT_SYMBOL(wiphy_read_of_freq_limits);
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5dbac37..bda0e9e 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -748,8 +748,8 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
return true;
}
-static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
- u32 center_freq_khz, u32 bw_khz)
+bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz)
{
u32 start_freq_khz, end_freq_khz;
diff --git a/net/wireless/reg.h b/net/wireless/reg.h
index f6ced31..b8e44ef 100644
--- a/net/wireless/reg.h
+++ b/net/wireless/reg.h
@@ -54,6 +54,8 @@ void regulatory_exit(void);
int set_regdom(const struct ieee80211_regdomain *rd,
enum ieee80211_regd_source regd_src);
+bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
+ u32 center_freq_khz, u32 bw_khz);
unsigned int reg_get_max_bandwidth(const struct ieee80211_regdomain *rd,
const struct ieee80211_reg_rule *rule);
--
2.10.1
^ permalink raw reply related
* [PATCH V4 3/2] brcmfmac: use wiphy_read_of_freq_limits to respect extra limits
From: Rafał Miłecki @ 2017-01-03 11:03 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: <20170103110340.23249-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.
This patch adds check for channel being disabled with orig_flags which
is how this wiphy helper works.
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.
V4: Respect IEEE80211_CHAN_DISABLED in orig_flags
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index ccae3bb..f95e316 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -5886,6 +5886,9 @@ static int brcmf_construct_chaninfo(struct brcmf_cfg80211_info *cfg,
band->band);
channel[index].hw_value = ch.control_ch_num;
+ if (channel->orig_flags & IEEE80211_CHAN_DISABLED)
+ continue;
+
/* assuming the chanspecs order is HT20,
* HT40 upper, HT40 lower, and VHT80.
*/
@@ -6477,6 +6480,7 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp)
wiphy->bands[NL80211_BAND_5GHZ] = band;
}
}
+ wiphy_read_of_freq_limits(wiphy);
err = brcmf_setup_wiphybands(wiphy);
return err;
}
--
2.10.1
^ permalink raw reply related
* Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding
From: Viresh Kumar @ 2017-01-03 11:07 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Nishanth Menon,
Vincent Guittot, Mark Rutland, Kevin Hilman, Ulf Hansson,
Lina Iyer, devicetree-u79uwXL29TY76Z2rM5mHXA, Nayak Rajendra
In-Reply-To: <20161222181422.2cpmdfzeyxdi6vpa@rob-hp-laptop>
On 22-12-16, 12:14, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> > Hello,
> >
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower performance state.
> >
> > We had some discussions about it in the past on the PM list [1], which is
> > followed by discussions during the LPC. The outcome of all that was that we
> > should extend Power Domain framework to support active state power management
> > as well.
> >
> > The power-domains until now were only concentrating on the idle state
> > management of the device and this needs to change in order to reuse the
> > infrastructure of power domains for active state management.
>
> >From a h/w perspective, are idle states really different from
> performance states?
>
> >
> > To get a complete picture of the proposed plan, following is what we
> > need to do:
> > - Create DT bindings to get domain performance state information for the
> > platforms.
>
> I would do this last so you can evolve things if you're not certain
> about what the bindings should look like. You can always start with
> things in the kernel and add to DT later.
Okay, I have just posted some code for this:
lkml.kernel.org/r/cover.1483439894.git.viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Thanks for your inputs.
--
viresh
--
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 0/2] ARM: dts: boundary: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
Hi Shawn, all,
While testing other features, I realized that the sound card wouldn't
probe on Nitrogen6_MAX. This is because the pinctrl node was under the
sound driver node whereas it should be under the codec one.
This caused GPIO_0 not to be set as CLKO1 and therefore the codec probing
was failing. The pinctrl node is just moved around to fix it.
Also making the same patch for our SOM2 although it was working, the
reason is that U-Boot is setting GPIO_0 in U-Boot for SOM2 and not MAX.
Regards,
Gary
Gary Bisson (2):
ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
ARM: dts: imx6qdl-nitrogen6_som2: fix sgtl5000 pinctrl init
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--
2.11.0
--
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/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
In-Reply-To: <20170103112247.4563-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
This patch fixes the following error:
sgtl5000 0-000a: Error reading chip id -6
imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
imx-sgtl5000 sound: snd_soc_register_card failed (-517)
The problem was that the pinctrl group was linked to the sound driver
instead of the codec node. Since the codec is probed first, the sys_mclk
was missing and it would therefore fail to initialize.
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 34887a10c5f1..47ba97229a48 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -319,8 +319,6 @@
compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
"fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_max-sgtl5000";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sgtl5000>;
ssi-controller = <&ssi1>;
audio-codec = <&codec>;
audio-routing =
@@ -402,6 +400,8 @@
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgtl5000>;
reg = <0x0a>;
clocks = <&clks IMX6QDL_CLK_CKO>;
VDDA-supply = <®_2p5v>;
--
2.11.0
--
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/2] ARM: dts: imx6qdl-nitrogen6_som2: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:22 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson
In-Reply-To: <20170103112247.4563-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Since the codec is probed first, the pinctrl node should be
under the codec node.
The codec init was working for this board since U-Boot was
already setting GPIO_0 as CLKO1 but better fix it anyway.
Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
index d80f21abea62..31d4cc62dbc7 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_som2.dtsi
@@ -250,8 +250,6 @@
compatible = "fsl,imx6q-nitrogen6_som2-sgtl5000",
"fsl,imx-audio-sgtl5000";
model = "imx6q-nitrogen6_som2-sgtl5000";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_sgtl5000>;
ssi-controller = <&ssi1>;
audio-codec = <&codec>;
audio-routing =
@@ -320,6 +318,8 @@
codec: sgtl5000@0a {
compatible = "fsl,sgtl5000";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sgtl5000>;
reg = <0x0a>;
clocks = <&clks IMX6QDL_CLK_CKO>;
VDDA-supply = <®_2p5v>;
--
2.11.0
--
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 v3] soc: zte: Add header for PM domains specifiers
From: Shawn Guo @ 2017-01-03 11:37 UTC (permalink / raw)
To: Baoyou Xie
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
jun.nie-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
In-Reply-To: <1483434911-29421-1-git-send-email-baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Jan 03, 2017 at 05:15:11PM +0800, Baoyou Xie wrote:
> This patch adds header with values used for zx96718
> SoC's power domain driver.
>
> Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
There is a hard dependency between this patch and the following one:
[PATCH v4 2/3] soc: zte: pm_domains: Add support for zx296718 board
For example, you renamed the header in this patch, and above one will
not compile. So you should either add this patch into power domain
patch series before the one using the header, or you can just merge it
into its user.
Shawn
> ---
> include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
>
> diff --git a/include/dt-bindings/soc/zte,pm_domains.h b/include/dt-bindings/soc/zte,pm_domains.h
> new file mode 100644
> index 0000000..a64cfb8
> --- /dev/null
> +++ b/include/dt-bindings/soc/zte,pm_domains.h
> @@ -0,0 +1,23 @@
> +/*
> + * Copyright (C) 2015 Linaro Ltd.
> + *
> + * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> + * License terms: GNU General Public License (GPL) version 2
> + */
> +#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> +#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> +
> +#define DM_ZX296718_SAPPU 0
> +#define DM_ZX296718_VDE 1 /* g1v6 */
> +#define DM_ZX296718_VCE 2 /* h1v6 */
> +#define DM_ZX296718_HDE 3 /* g2v2 */
> +#define DM_ZX296718_VIU 4
> +#define DM_ZX296718_USB20 5
> +#define DM_ZX296718_USB21 6
> +#define DM_ZX296718_USB30 7
> +#define DM_ZX296718_HSIC 8
> +#define DM_ZX296718_GMAC 9
> +#define DM_ZX296718_TS 10
> +#define DM_ZX296718_VOU 11
> +
> +#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
> --
> 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
* Re: [PATCH v3] soc: zte: Add header for PM domains specifiers
From: Baoyou Xie @ 2017-01-03 11:42 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, mark.rutland, Jun Nie, Linux Kernel Mailing List,
devicetree, xie.baoyou, chen.chaokai, wang.qiang01
In-Reply-To: <20170103113706.GB20956@dragon>
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On 3 January 2017 at 19:37, Shawn Guo <shawnguo@kernel.org> wrote:
> On Tue, Jan 03, 2017 at 05:15:11PM +0800, Baoyou Xie wrote:
> > This patch adds header with values used for zx96718
> > SoC's power domain driver.
> >
> > Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
>
> There is a hard dependency between this patch and the following one:
>
> [PATCH v4 2/3] soc: zte: pm_domains: Add support for zx296718 board
>
> For example, you renamed the header in this patch, and above one will
> not compile. So you should either add this patch into power domain
> patch series before the one using the header, or you can just merge it
> into its user.
>
> I will make out a new version of above patch. And modify its dependency.
> Shawn
>
> > ---
> > include/dt-bindings/soc/zte,pm_domains.h | 23 +++++++++++++++++++++++
> > 1 file changed, 23 insertions(+)
> > create mode 100644 include/dt-bindings/soc/zte,pm_domains.h
> >
> > diff --git a/include/dt-bindings/soc/zte,pm_domains.h
> b/include/dt-bindings/soc/zte,pm_domains.h
> > new file mode 100644
> > index 0000000..a64cfb8
> > --- /dev/null
> > +++ b/include/dt-bindings/soc/zte,pm_domains.h
> > @@ -0,0 +1,23 @@
> > +/*
> > + * Copyright (C) 2015 Linaro Ltd.
> > + *
> > + * Author: Baoyou Xie <baoyou.xie@linaro.org>
> > + * License terms: GNU General Public License (GPL) version 2
> > + */
> > +#ifndef _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> > +#define _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H
> > +
> > +#define DM_ZX296718_SAPPU 0
> > +#define DM_ZX296718_VDE 1 /* g1v6 */
> > +#define DM_ZX296718_VCE 2 /* h1v6 */
> > +#define DM_ZX296718_HDE 3 /* g2v2 */
> > +#define DM_ZX296718_VIU 4
> > +#define DM_ZX296718_USB20 5
> > +#define DM_ZX296718_USB21 6
> > +#define DM_ZX296718_USB30 7
> > +#define DM_ZX296718_HSIC 8
> > +#define DM_ZX296718_GMAC 9
> > +#define DM_ZX296718_TS 10
> > +#define DM_ZX296718_VOU 11
> > +
> > +#endif /* _DT_BINDINGS_SOC_ZTE_PM_DOMAINS_H */
> > --
> > 2.7.4
> >
>
[-- Attachment #2: Type: text/html, Size: 3240 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Shawn Guo @ 2017-01-03 11:43 UTC (permalink / raw)
To: Gary Bisson
Cc: fabio.estevam-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170103112247.4563-2-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> This patch fixes the following error:
> sgtl5000 0-000a: Error reading chip id -6
> imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> imx-sgtl5000 sound: snd_soc_register_card failed (-517)
>
> The problem was that the pinctrl group was linked to the sound driver
> instead of the codec node. Since the codec is probed first, the sys_mclk
> was missing and it would therefore fail to initialize.
>
> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Should we have it go as a fix for v4.10-rc cycles? In that case, please
add a Fixes: tag. Also, do we need to apply it for stable kernel?
Shawn
> ---
> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> index 34887a10c5f1..47ba97229a48 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
> @@ -319,8 +319,6 @@
> compatible = "fsl,imx6q-nitrogen6_max-sgtl5000",
> "fsl,imx-audio-sgtl5000";
> model = "imx6q-nitrogen6_max-sgtl5000";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_sgtl5000>;
> ssi-controller = <&ssi1>;
> audio-codec = <&codec>;
> audio-routing =
> @@ -402,6 +400,8 @@
>
> codec: sgtl5000@0a {
> compatible = "fsl,sgtl5000";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_sgtl5000>;
> reg = <0x0a>;
> clocks = <&clks IMX6QDL_CLK_CKO>;
> VDDA-supply = <®_2p5v>;
> --
> 2.11.0
>
--
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 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Chanwoo Choi @ 2017-01-03 11:47 UTC (permalink / raw)
To: Andi Shyti
Cc: Krzysztof Kozlowski, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Javier Martinez Canillas, Chanwoo Choi, beomho.seo, galaxyra,
linux-arm-kernel, linux-input, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <20170103102548.73jg6qddlcthe2mu@gangnam.samsung>
Dear all,
2017-01-03 19:25 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
>> >> > Currently tm2e dts includes tm2 but there are some differences
>> >> > between the two boards and tm2 has some properties that tm2e
>> >> > doesn't have.
>> >> >
>> >> > That's why it's important to keep the two dts files independent
>> >> > and put all the commonalities in a tm2-common.dtsi file.
>> >> >
>> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>> >> > Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>> >> > ---
>> >> > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
>> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
>> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
>> >> > 3 files changed, 1049 insertions(+), 1032 deletions(-)
>> >> > create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>> >>
>> >> I would like to see here the rename and diff from it. Not entire delta
>> >> (deletions and addons). It is not possible to compare it... I think
>> >> git supports it by default with similarity of 50%.
>> >
>> > I understand, it's indeed quite cryptic to understand. But all
>> > the diff algorithms (patience, minimal, histogram, myers) give
>> > the same result. I don't know how to make it better.
>> >
>> > I could split this patch, but this also means breaking tm2's
>> > functionality, which looks worse.
>> >
>> > Please tell me if you know a better way for generating the patch.
>>
>> git format-patch -M95%?
>
> Same thing with all M values.
>
> Because exynos5433-tm2.dts results modified, while
> exynos5433-tm2-common.dtsi is new. Even though I did:
>
> 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
> 2. copied pieces from exynos5433-tm2-common.dtsi to a new
> exynos5433-tm2.dts
I think that exynos5433-tm2-common.dtsi is not necessary because there
is small difference between TM2 and TM2E.
I explain the detailed difference between TM2 and TM2E and then reply
how to support the TM2E board with existing exynos5433-tm2.dts file
without exynos5433-tm2-common.dtsi.
Difference and the way to support TM2E with existing
exynos5433-tm2.dts file as following:
- hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
touchkey. but TM2E do not use the hsi2c_9.
: We can just disable the hsi2c_9 node on tm2e.dts as following:
&hsi2c_9 {
status = "disable";
};
- The difference name and voltage of regulators.
: Already modified on tm2e.dts.
- The size of touchscreen between tm2 and tm2e ('x-size', 'y-size')
: We can update the x/y size on tm2e.dts.
- The timing value of display-timing between tm2 and tm2e
('clock-frequency', 'hactive')
: We can update the 'clock-frequency' and 'hactive' on tm2e.dts.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-03 11:55 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Krzysztof Kozlowski, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Javier Martinez Canillas, Chanwoo Choi,
beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
galaxyra-Re5JQEeQqe8AvxtiuMwx3w, linux-arm-kernel,
linux-input-u79uwXL29TY76Z2rM5mHXA, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <CAGTfZH3ez4DPTE7-bDeayjhSGxJ_8Mj1MQz1M7O1qhwOGOnmMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Chanwoo,
> >> >> > Currently tm2e dts includes tm2 but there are some differences
> >> >> > between the two boards and tm2 has some properties that tm2e
> >> >> > doesn't have.
> >> >> >
> >> >> > That's why it's important to keep the two dts files independent
> >> >> > and put all the commonalities in a tm2-common.dtsi file.
> >> >> >
> >> >> > Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> >> > Signed-off-by: Jaechul Lee <jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> >> >> > ---
> >> >> > .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
> >> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
> >> >> > arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
> >> >> > 3 files changed, 1049 insertions(+), 1032 deletions(-)
> >> >> > create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> >> >>
[...]
> > Because exynos5433-tm2.dts results modified, while
> > exynos5433-tm2-common.dtsi is new. Even though I did:
> >
> > 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
> > 2. copied pieces from exynos5433-tm2-common.dtsi to a new
> > exynos5433-tm2.dts
>
> I think that exynos5433-tm2-common.dtsi is not necessary because there
> is small difference between TM2 and TM2E.
>
> I explain the detailed difference between TM2 and TM2E and then reply
> how to support the TM2E board with existing exynos5433-tm2.dts file
> without exynos5433-tm2-common.dtsi.
>
> Difference and the way to support TM2E with existing
> exynos5433-tm2.dts file as following:
> - hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
> touchkey. but TM2E do not use the hsi2c_9.
> : We can just disable the hsi2c_9 node on tm2e.dts as following:
>
> &hsi2c_9 {
> status = "disable";
> };
I thought about this alternative too, it just looked cleaner to
me to have a tm2-common.dtsi file.
Anyway, as you guys wish. If for you and Krzysztof is better this
way, we can drop this patch and add the above lines in the current
Jaechul's patch 4/4.
Thanks,
Andi
--
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 1/2] ARM: dts: imx6qdl-nitrogen6_max: fix sgtl5000 pinctrl init
From: Gary Bisson @ 2017-01-03 11:55 UTC (permalink / raw)
To: Shawn Guo; +Cc: fabio.estevam, devicetree, linux-arm-kernel
In-Reply-To: <20170103114316.GC20956@dragon>
Hi Shawn,
On Tue, Jan 03, 2017 at 07:43:17PM +0800, Shawn Guo wrote:
> On Tue, Jan 03, 2017 at 12:22:46PM +0100, Gary Bisson wrote:
> > This patch fixes the following error:
> > sgtl5000 0-000a: Error reading chip id -6
> > imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
> > imx-sgtl5000 sound: snd_soc_register_card failed (-517)
> >
> > The problem was that the pinctrl group was linked to the sound driver
> > instead of the codec node. Since the codec is probed first, the sys_mclk
> > was missing and it would therefore fail to initialize.
> >
> > Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
>
> Should we have it go as a fix for v4.10-rc cycles? In that case, please
> add a Fixes: tag. Also, do we need to apply it for stable kernel?
Sure it'd be great if it could be in v4.10.
Fixes: b32e700256bc ("ARM: dts: imx: add Boundary Devices Nitrogen6_Max board")
As for stable kernel, I guess it wouldn't hurt but it's not mandatory in
my opinion.
Do you want me to re-send with the Fixes line? What about the SOM2
patch, should it include a Fixes line although it works thanks to
U-Boot?
Thanks,
Gary
^ permalink raw reply
* Re: [PATCH V4 2/2] cfg80211: support ieee80211-freq-limit DT property
From: Arend Van Spriel @ 2017-01-03 12:10 UTC (permalink / raw)
To: Rafał Miłecki, Johannes Berg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: Martin Blumenstingl, Felix Fietkau, Arend van Spriel,
Arnd Bergmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rafał Miłecki
In-Reply-To: <20170103110340.23249-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 3-1-2017 12:03, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This patch adds a helper for reading that new property and applying
> limitations or supported channels specified this way.
> It may be useful for specifying single band devices or devices that
> support only some part of the whole band. It's common that tri-band
> routers 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.
> V4: Move code to of.c
> Use one helper called at init time (no runtime hooks)
> Modify orig_flags
> ---
> include/net/cfg80211.h | 26 ++++++++++
> net/wireless/Makefile | 1 +
> net/wireless/of.c | 137 +++++++++++++++++++++++++++++++++++++++++++++++++
> net/wireless/reg.c | 4 +-
> net/wireless/reg.h | 2 +
> 5 files changed, 168 insertions(+), 2 deletions(-)
> create mode 100644 net/wireless/of.c
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index ca2ac1c..d7723a8 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -311,6 +311,32 @@ struct ieee80211_supported_band {
> struct ieee80211_sta_vht_cap vht_cap;
> };
>
> +/**
> + * 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). 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.
You are aware that you need to modify this description with earlier
patch "cfg80211: allow passing struct device in the wiphy_new call",
right? :-p
> + * It also modifies channels so they have to be set first.
> + */
> +#ifdef CONFIG_OF
> +int wiphy_read_of_freq_limits(struct wiphy *wiphy);
> +#else /* CONFIG_OF */
> +static inline int wiphy_read_of_freq_limits(struct wiphy *wiphy)
> +{
> + return 0;
> +}
> +#endif /* !CONFIG_OF */
> +
> +
[...]
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5dbac37..bda0e9e 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -748,8 +748,8 @@ static bool is_valid_rd(const struct ieee80211_regdomain *rd)
> return true;
> }
>
> -static bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
> - u32 center_freq_khz, u32 bw_khz)
> +bool reg_does_bw_fit(const struct ieee80211_freq_range *freq_range,
> + u32 center_freq_khz, u32 bw_khz)
> {
> u32 start_freq_khz, end_freq_khz;
would it be more appropriate to move this function to util.c?
Regards,
Arend
--
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 0/4 v2] of/overlay: sysfs based ABI for dt overlays
From: Pantelis Antoniou @ 2017-01-03 12:11 UTC (permalink / raw)
To: Frank Rowand
Cc: Heinrich Schuchardt, Rob Herring, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <585C22BB.3080403-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank, Heinrich,
> On Dec 22, 2016, at 21:00 , Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Hi Heinrich,
>
> On 12/20/16 11:04, Heinrich Schuchardt wrote:
>> Currently the kernel only supplies an internal API for creating
>> and destroying device tree overlays.
>>
>> For some boards vendor specific kernel modules exist for
>> managing device tree overlays but they have not been
>> upstreamed or upstreaming stalled.
>> https://lkml.org/lkml/2015/6/12/624
>> https://lkml.org/lkml/2013/1/7/366
>>
>> This patch series provides a sysfs based ABI for creation and
>> destruction of dt overlays in /sys/firmware/devicetree/overlays.
>>
>> The following files are provided:
>>
>> load: This is a write only file.
>> A string written to it is interpreted as the path to a
>> flattened device tree overlay file. It is used to create
>> and apply the contained overlays.
>>
>> loaded: This is a read only file.
>> It provides the count of loaded overlays as a decimal
>> number.
>>
>> unload: This is a write only file.
>> If a positive number n is wrtten to this file the n
>> most recent overlays are destroyed.
>> If a negative number is written to this file all
>> overlays are destroyed.
>
> This patch series follows a _somewhat_ similar approach to what
> was first proposed two years ago, and does not address the
> issues that were brought up at that time. See:
>
> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> Date: Wed, 3 Dec 2014 13:23:28 +0200
> Subject: [PATCH] OF: DT-Overlay configfs interface (v3)
>
> But just responding directly to the two year old issues would not
> be a productive approach, since there has been a lot of subsequent
> discussion on how to load overlays (you point to two of the many
> threads above). The latest discussions are based on the concept
> of describing the overlay attachment points as connectors.
>
> Please join in pushing the connectors discussion along to make
> sure that it meets your needs.
>
I think it would be best if we focus on getting the configfs based loader
to work. It is pretty similar to what Heinrich is proposing.
> -Frank
>
Regards
— Pantelis
>
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
>>
>> version 2:
>> change sysfs path to
>> /sys/firmware/devicetree/overlays
>>
>> Fix errors indicated by kbuild robot:
>> Add missing inline attribute to of_overlay_count
>> in patch 1.
>> Add 'select CONFIG_OF_EARLY_FLATTREE' to Kconfig
>> in patch 2.
>>
>> Change unit test cases to check new functions
>> of_overlay_count and of_overlay_destroy_last.
>>
>> Heinrich Schuchardt (4):
>> of/overlay: add API function to count and pop last
>> of/overlay: sysfs based ABI for dt overlays
>> of/overlay: documentation for sysfs ABI
>> of/overlay: test count and destroy_last
>>
>> .../ABI/testing/sysfs-firmware-devicetree-overlays | 24 +++
>> Documentation/devicetree/overlay-notes.txt | 7 +-
>> drivers/of/Kconfig | 15 ++
>> drivers/of/Makefile | 2 +
>> drivers/of/base.c | 1 +
>> drivers/of/ov_sysfs.c | 223 +++++++++++++++++++++
>> drivers/of/overlay.c | 50 +++++
>> drivers/of/unittest.c | 15 +-
>> include/linux/of.h | 12 ++
>> 9 files changed, 346 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/ABI/testing/sysfs-firmware-devicetree-overlays
>> create mode 100644 drivers/of/ov_sysfs.c
--
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: [RFC PATCH 0/5] overlay: tool to convert old overlay style dts to new style
From: Pantelis Antoniou @ 2017-01-03 12:13 UTC (permalink / raw)
To: frowand.list-Re5JQEeQqe8AvxtiuMwx3w
Cc: David Gibson, jdl-CYoMK+44s/E,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
glikely-s3s/WqlpOiPyB63q8FvJNQ, jlu-bIcnvbaLZ9MEGnE8C9+IrQ,
s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ, phil-FnsA7b+Nu9XbIbC87yuRow,
sjg-F7+t8E8rja9g9hUCZPvPmw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
stephen.boyd-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1482909617-31950-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Frank,
> On Dec 28, 2016, at 09:20 , frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>
> From: Frank Rowand <frank.rowand-mEdOJwZ7QcZBDgjK7y7TUQ@public.gmane.org>
>
> In response to "Subject: Re: [PATCH v11 5/7] overlay: Documentation for the
> overlay sugar syntax" I suggested a tool to convert the old style of dts
> overlay files to use the new syntactic sugar [1]:
>
>>>> I can imagine some reasons to support the fully written out version,
>>>> but can we document what those reasons are?
>>>
>>> I believe the main one is the dts files in this format out in the
>>> field. Mind you, I guess we're already requiring them to tweak how
>>> they declare the /plugin/ option.
>>
>> It might be easy to write a program that transforms the expanded
>> format to the simple format. I'll try to make some time to see
>> how difficult it is. The transformation is relatively easy to
>> do manually, but I don't know how many dts files would need to
>> be converted.
>
> My goal is to minimize legacy issues of dts files that expose the
> internal implementation of overlays, such as the fragment and
> __overlay__ nodes. Pantelis has submitted the dtc patches to add
> the necessary syntactic sugar, and these appear to be moving toward
> acceptance.
>
> I have created a perl script to create a new style dts overlay file
> from an old style dts overlay file. I have also created a shell
> script to provide some error checking and to validate that the
> new dts file compiles to the same result as the old dts file.
>
> I treat the issue as a simplistic text processing exercise instead
> of using a more complex approach with the hope that this is
> sufficient to process the bulk of the existing in the wild overlay
> dts files.
>
> I do not think it is worth cluttering the dtc git repo with these
> tools, but have no objection to them being hosted there if David
> prefers. I can host them on github, elinux.org, or anywhere else
> that makes sense for a (hopefully) short lived tool.
>
> Patches 3, 4, and 5 are sample old style dts overlay files and
> are not intended to be committed.
>
> Following are several examples of use. One example that converts
> properly and two that show how convsersion a malformed old style
> dts is reported.
>
> ----- example 1
>
> $ export PATH="$PATH:/home/frowand/nobackup/src/github_pantelis/dtc/"
> $ ./overlay_convert_old_to_new a.dts b.dts
>
> $ cat a.dts
> /dts-v1/;
> /plugin/;
>
> / {
> fragment@0 {
> target = <&am3353x_pinmux>;
>
> __overlay__ {
>
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0x158 0x72
> 0x15c 0x72
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&i2c1>;
>
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> clock-frequency = <400000>;
> status = "okay";
>
> at24@50 {
> compatible = "at,24c256";
> pagesize = <64>;
> reg = <0x50>;
> };
> };
> };
> };
> $ cat b.dts
> /dts-v1/;
> /plugin/;
>
> &am3353x_pinmux {
>
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0x158 0x72
> 0x15c 0x72
> >;
> };
> };
>
> &i2c1 {
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> clock-frequency = <400000>;
> status = "okay";
>
> at24@50 {
> compatible = "at,24c256";
> pagesize = <64>;
> reg = <0x50>;
> };
> };
> $ diff -u a.dts b.dts
> --- a.dts 2016-12-27 15:51:36.433101164 -0800
> +++ b.dts 2016-12-27 22:01:28.541530464 -0800
> @@ -1,11 +1,7 @@
> /dts-v1/;
> /plugin/;
>
> -/ {
> - fragment@0 {
> - target = <&am3353x_pinmux>;
> -
> - __overlay__ {
> + &am3353x_pinmux {
>
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> @@ -14,12 +10,8 @@
> >;
> };
> };
> - };
> -
> - fragment@1 {
> - target = <&i2c1>;
>
> - __overlay__ {
> + &i2c1 {
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> @@ -33,5 +25,3 @@
> reg = <0x50>;
> };
> };
> - };
> -};
>
>
> ----- example 2
>
> $ export PATH="$PATH:/home/frowand/nobackup/src/github_pantelis/dtc/"
> $ ./overlay_convert_old_to_new bad_a_1.dts bad_b_1.dts
> No 'target' property in node fragment@0
>
> ERROR: unable to convert bad_a_1.dts
>
> $ cat bad_a_1.dts
> /dts-v1/;
> /plugin/;
>
> / {
> fragment@0 {
>
> __overlay__ {
>
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0x158 0x72
> 0x15c 0x72
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&i2c1>;
>
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> clock-frequency = <400000>;
> status = "okay";
>
> at24@50 {
> compatible = "at,24c256";
> pagesize = <64>;
> reg = <0x50>;
> };
> };
> };
> };
>
>
> ----- example 3
>
> $ export PATH="$PATH:/home/frowand/nobackup/src/github_pantelis/dtc/"
> $ ./overlay_convert_old_to_new bad_a_2.dts bad_b_2.dts
> No 'target' property in node fragment@1
>
> ERROR: unable to convert bad_a_2.dts
>
> $ cat bad_a_2.dts
> /dts-v1/;
> /plugin/;
>
> / {
> fragment@0 {
> target = <&am3353x_pinmux>;
>
> __overlay__ {
>
> i2c1_pins: pinmux_i2c1_pins {
> pinctrl-single,pins = <
> 0x158 0x72
> 0x15c 0x72
> >;
> };
> };
> };
>
> fragment@1 {
>
> __overlay__ {
> #address-cells = <1>;
> #size-cells = <0>;
> pinctrl-names = "default";
> pinctrl-0 = <&i2c1_pins>;
> clock-frequency = <400000>;
> status = "okay";
>
> at24@50 {
> compatible = "at,24c256";
> pagesize = <64>;
> reg = <0x50>;
> };
> };
> };
> };
>
>
>
> [1] http://www.spinics.net/lists/devicetree/msg152891.html
>
Very interesting and helpful.
Thanks for the good work. I would support converting all overlays in the wild
to the new format to get going on the connector problem.
> Frank Rowand (5):
> perl script to convert dts from old overlay style to new overlay style
> shell script to make overlay_convert easier to use
> a.dts: example of an old style dts file to be converted
> bad_a_1.dts: example of an old style dts file unable to be converted
> bad_a_2.dts: example of an old style dts file to be converted
>
Regards
— Pantelis
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Javier Martinez Canillas @ 2017-01-03 12:15 UTC (permalink / raw)
To: Andi Shyti, Chanwoo Choi
Cc: Krzysztof Kozlowski, Jaechul Lee, Dmitry Torokhov, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Kukjin Kim,
Chanwoo Choi, beomho.seo-Sze3O3UU22JBDgjK7y7TUQ,
galaxyra-Re5JQEeQqe8AvxtiuMwx3w, linux-arm-kernel,
linux-input-u79uwXL29TY76Z2rM5mHXA, devicetree, linux-kernel,
linux-samsung-soc
In-Reply-To: <20170103115530.zhjwn7bzmqmumy23-8vUhnHFVuGn35fTxX1Dczw@public.gmane.org>
Hello Andi,
On 01/03/2017 08:55 AM, Andi Shyti wrote:
> Hi Chanwoo,
>
>>>>>>> Currently tm2e dts includes tm2 but there are some differences
>>>>>>> between the two boards and tm2 has some properties that tm2e
>>>>>>> doesn't have.
>>>>>>>
>>>>>>> That's why it's important to keep the two dts files independent
>>>>>>> and put all the commonalities in a tm2-common.dtsi file.
>>>>>>>
>>>>>>> Signed-off-by: Andi Shyti <andi.shyti-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>>> Signed-off-by: Jaechul Lee <jcsing.lee-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>>>>>>> ---
>>>>>>> .../boot/dts/exynos/exynos5433-tm2-common.dtsi | 1046 ++++++++++++++++++++
>>>>>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1033 +------------------
>>>>>>> arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
>>>>>>> 3 files changed, 1049 insertions(+), 1032 deletions(-)
>>>>>>> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
>>>>>>
>
> [...]
>
>>> Because exynos5433-tm2.dts results modified, while
>>> exynos5433-tm2-common.dtsi is new. Even though I did:
>>>
>>> 1. mv exynos5433-tm2.dts exynos5433-tm2-common.dtsi
>>> 2. copied pieces from exynos5433-tm2-common.dtsi to a new
>>> exynos5433-tm2.dts
>>
>> I think that exynos5433-tm2-common.dtsi is not necessary because there
>> is small difference between TM2 and TM2E.
>>
>> I explain the detailed difference between TM2 and TM2E and then reply
>> how to support the TM2E board with existing exynos5433-tm2.dts file
>> without exynos5433-tm2-common.dtsi.
>>
>> Difference and the way to support TM2E with existing
>> exynos5433-tm2.dts file as following:
>> - hsi2c_9 is either used or not. TM2 uses the hsi2c_9 node for
>> touchkey. but TM2E do not use the hsi2c_9.
>> : We can just disable the hsi2c_9 node on tm2e.dts as following:
>>
>> &hsi2c_9 {
>> status = "disable";
>> };
>
> I thought about this alternative too, it just looked cleaner to
> me to have a tm2-common.dtsi file.
>
> Anyway, as you guys wish. If for you and Krzysztof is better this
> way, we can drop this patch and add the above lines in the current
> Jaechul's patch 4/4.
>
FWIW, I also agree with Chanwoo that the difference is too small to
need a common .dtsi file.
> Thanks,
> Andi
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v4 0/5] mfd: dt: Add bindings for the Aspeed MFDs
From: Lee Jones @ 2017-01-03 12:17 UTC (permalink / raw)
To: Corey Minyard
Cc: Andrew Jeffery, Rob Herring, Mark Rutland, Linus Walleij,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4e69b379-299f-ebf3-3a61-9ac1bcaba7b3-HInyCGIudOg@public.gmane.org>
On Thu, 22 Dec 2016, Corey Minyard wrote:
> It looks like this is ready. Should I take this in the IPMI tree, or is
> there a better tree for it?
Please refrain from top posting.
Judging by the diff, it looks like the MFD tree would be the most
appropriate place to merge these into.
> On 12/20/2016 01:15 AM, Andrew Jeffery wrote:
> > Hi Lee,
> >
> > Here's v4 of the Aspeed LPC MFD devicetree bindings series. v3 can be found at:
> >
> > https://lkml.org/lkml/2016/12/5/835
> >
> > Changes since v3:
> >
> > * Based on Arnd's argument[1], drop the addition of the mfd/syscon bindings
> > directory as well as the the last patch in v3, which moved a number of
> > existing bindings. Eventually the Aspeed display controller will have a
> > device-specific driver so it doesn't belong there either.
> >
> > * Add a compatible string for the AST2400 in the LPC Host Controller bindings
> > as requested by Joel and slightly tweak the reg description for Rob.
> >
> > [1] https://lkml.org/lkml/2016/12/13/202
> >
> > Andrew Jeffery (5):
> > mfd: dt: Fix "indicates" typo in mfd bindings document
> > mfd: dt: ranges, #address-cells and #size-cells as optional properties
> > mfd: dt: Add Aspeed Low Pin Count Controller bindings
> > mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
> > mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
> >
> > .../devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++
> > .../devicetree/bindings/mfd/aspeed-lpc.txt | 137 +++++++++++++++++++++
> > Documentation/devicetree/bindings/mfd/mfd.txt | 12 +-
> > 3 files changed, 165 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> >
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 1/4] input: Add support for the tm2 touchkey device driver
From: Javier Martinez Canillas @ 2017-01-03 12:26 UTC (permalink / raw)
To: Jaechul Lee, Dmitry Torokhov, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Kukjin Kim, Krzysztof Kozlowski
Cc: Andi Shyti, Chanwoo Choi, beomho.seo, galaxyra, linux-arm-kernel,
linux-input, devicetree, linux-kernel, linux-samsung-soc
In-Reply-To: <1483430237-26823-2-git-send-email-jcsing.lee@samsung.com>
Hello Jaechul,
On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> This patch adds the binding description of the tm2 touchkey
> device driver.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v6 6/8] IIO: add STM32 timer trigger driver
From: Benjamin Gaignard @ 2017-01-03 12:59 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lee Jones, robh+dt, Mark Rutland, Alexandre Torgue, devicetree,
Linux Kernel Mailing List, Thierry Reding, Linux PWM List,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
linux-iio, linux-arm-kernel, Fabrice Gasnier, Gerald Baeza,
Arnaud Pouliquen, Linus Walleij, Linaro Kernel Mailman List,
Benjamin Gaignard
In-Reply-To: <CA+M3ks6jshX-rEsi7Qfo-65awzWcHsEMVBjm-baYy979V9187Q@mail.gmail.com>
2017-01-03 10:23 GMT+01:00 Benjamin Gaignard <benjamin.gaignard@linaro.org>:
> 2017-01-02 19:22 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>> On 02/01/17 08:46, Benjamin Gaignard wrote:
>>> 2016-12-30 22:12 GMT+01:00 Jonathan Cameron <jic23@kernel.org>:
>>>> On 09/12/16 14:15, Benjamin Gaignard wrote:
>>>>> Timers IPs can be used to generate triggers for other IPs like
>>>>> DAC, ADC or other timers.
>>>>> Each trigger may result of timer internals signals like counter enable,
>>>>> reset or edge, this configuration could be done through "master_mode"
>>>>> device attribute.
>>>>>
>>>>> A timer device could be triggered by other timers, we use the trigger
>>>>> name and is_stm32_iio_timer_trigger() function to distinguish them
>>>>> and configure IP input switch.
>>>>>
>>>>> Timer may also decide on which event (edge, level) they could
>>>>> be activated by a trigger, this configuration is done by writing in
>>>>> "slave_mode" device attribute.
>>>>>
>>>>> Since triggers could also be used by DAC or ADC their names are defined
>>>>> in include/ nux/iio/timer/stm32-timer-trigger.h so those IPs will be able
>>>>> to configure themselves in valid_trigger function
>>>>>
>>>>> Trigger have a "sampling_frequency" attribute which allow to configure
>>>>> timer sampling frequency without using PWM interface
>>>>>
>>>>> version 5:
>>>>> - simplify tables of triggers
>>>>> - only create an IIO device when needed
>>>>>
>>>>> version 4:
>>>>> - get triggers configuration from "reg" in DT
>>>>> - add tables of triggers
>>>>> - sampling frequency is enable/disable when writing in trigger
>>>>> sampling_frequency attribute
>>>>> - no more use of interruptions
>>>>>
>>>>> version 3:
>>>>> - change compatible to "st,stm32-timer-trigger"
>>>>> - fix attributes access right
>>>>> - use string instead of int for master_mode and slave_mode
>>>>> - document device attributes in sysfs-bus-iio-timer-stm32
>>>>>
>>>>> version 2:
>>>>> - keep only one compatible
>>>>> - use st,input-triggers-names and st,output-triggers-names
>>>>> to know which triggers are accepted and/or create by the device
>>>> Firstly, sorry it has taken me so long to get back to this.
>>>>
>>>> I'm still not keen on this use of iio_device elements just to act as
>>>> glue between triggers. I think we need to work out a more light weight
>>>> way to do this. As you are only using them for validation and to provide
>>>> somewhere to hang the control attibutes off, there is nothing stopping us
>>>> moving that over to the iio_trigger instead which would avoid the messy
>>>> duality going on here.
>>>
>>> I have add an iio_device because each hardware can generate multiple
>>> triggers (up to 5: trgo, ch 1...4) and slave_mode attribute will impact all the
>>> triggers of a device. For me it was making sense to centralize that in an
>>> iio_device rather than having an attribute "shared" (from hardware
>>> point of view)
>>> on multiple triggers.
>>> Since master_mode attribute is only used by trgo and not impact ch1...4
>>> triggers I will move it to trigger instead of the iio_device.
>>>
>>> I also wanted to be able to connect triggers on a iio_device as I
>>> could do for an
>>> ADC with a command like 'echo "tim1_trgo" > iio_deviceX/trigger/current_trigger'
>> This is interesting, but with a bit of refactoring I would think it would
>> be possible to share some of that code thus allowing non IIO devices to
>> bind to triggers. Ultimately I want to be able to bind a trigger to
>> a trigger - I appreciate here the topology is more limited than that
>> so some complexity comes in.
>>
>> My gut feeling is that representing that topology explicitly is hard
>> to do in a remotely general way, but lets try it and see.
>> We run into this sort of interdependency issue between different bits of
>> the hardware all the time. Setting a value somewhere effects the configuration
>> elsewhere - often the best plan is to just let that happen and leave it up to
>> userspace to check for changes if it cares.
>
> okay
>
>>> If I change that to parent_trigger attribute it change this behavior
>>> and I will have to
>>> duplicated what is done in iio_trigger_write_current() to find and
>>> validate triggers.
>> I get the reasoning, but we still end up with something represented
>> by an IIO device that isn't providing any channels at all. It's simply
>> using some of the infrastructure. To my mind it is 'something else'
>> and should be represented as such. I have no problem at all with
>> you registering additional elements in /sysfs/bus/iio/ to represent
>> these shared elements - we already have drivers that do that to
>> provide some centralized infrastructure (e.g. the sysfs-trigger)
>
> My hardware block are timers maybe I can add a channel type "IIO_TIMER"
> and declare a channel with info_mask_separate = BIT(IIO_CHAN_INFO_SAMP_FREQ)
> so I will be able to write/read sampling frequency on IIO device.
>
If it isn't possible to implement IIO_TIMER I will simply drop device part of
my driver until we find a solution because I would like to upstream at
least what is
need to ADC/DAC.
>> I'm worried about the scope spread we get for an IIO device otherwise.
>> They serve a well defined purpose at the moment, and that isn't what
>> is happening here.
>>
>> So my gut feeling is we are better deliberately not representing the
>> inter dependence and claiming all triggers we are creating are
>> independent. That way we can have a nice generic infrastructure
>> that will work in all cases (be it pushing the sanity checking to
>> userspace).
>>
>> So each trigger has direct access to what controls it. Changing anything
>> can effect other triggers in weird ways.
>>
>> I'm finding it hard to see anything else generalizing sufficiently
>> as we'll always get cases where we can't represent the topology without
>> diving into the complexity of something like the media controller
>> framework.
>>
>> Jonathan
>>>
>>>> I might still be missing something though!
>>>>
>>>> You would only I think need 3 attributes
>>>>
>>>> parrent_trigger
>>>> and something like your master_mode and slave_mode attributes.
>>>>
>>>> The parrent_trigger would need some validation etc, but if we keep it
>>>> within this driver initially that won't be hard to do. Checking the device
>>>> parent matches will do most of it.
>>>>
>>>> Jonathan
>>>>>
>>>>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> ---
>>>>> .../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
>>>>> drivers/iio/Kconfig | 2 +-
>>>>> drivers/iio/Makefile | 1 +
>>>>> drivers/iio/timer/Kconfig | 13 +
>>>>> drivers/iio/timer/Makefile | 1 +
>>>>> drivers/iio/timer/stm32-timer-trigger.c | 466 +++++++++++++++++++++
>>>>> drivers/iio/trigger/Kconfig | 1 -
>>>>> include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
>>>>> 8 files changed, 599 insertions(+), 2 deletions(-)
>>>>> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> create mode 100644 drivers/iio/timer/Kconfig
>>>>> create mode 100644 drivers/iio/timer/Makefile
>>>>> create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
>>>>> create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
>>>>>
>>>>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> new file mode 100644
>>>>> index 0000000..26583dd
>>>>> --- /dev/null
>>>>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
>>>>> @@ -0,0 +1,55 @@
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode_available
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard@st.com
>>>>> +Description:
>>>>> + Reading returns the list possible master modes which are:
>>>>> + - "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO).
>>>>> + - "enable" : The Counter Enable signal CNT_EN is used as trigger output.
>>>>> + - "update" : The update event is selected as trigger output.
>>>>> + For instance a master timer can then be used as a prescaler for a slave timer.
>>>>> + - "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set.
>>>>> + - "OC1REF" : OC1REF signal is used as trigger output.
>>>>> + - "OC2REF" : OC2REF signal is used as trigger output.
>>>>> + - "OC3REF" : OC3REF signal is used as trigger output.
>>>>> + - "OC4REF" : OC4REF signal is used as trigger output.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/master_mode
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard@st.com
>>>>> +Description:
>>>>> + Reading returns the current master modes.
>>>>> + Writing set the master mode
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode_available
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard@st.com
>>>>> +Description:
>>>>> + Reading returns the list possible slave modes which are:
>>>>> + - "disabled" : The prescaler is clocked directly by the internal clock.
>>>>> + - "encoder_1" : Counter counts up/down on TI2FP1 edge depending on TI1FP2 level.
>>>>> + - "encoder_2" : Counter counts up/down on TI1FP2 edge depending on TI2FP1 level.
>>>>> + - "encoder_3" : Counter counts up/down on both TI1FP1 and TI2FP2 edges depending
>>>>> + on the level of the other input.
>>>>> + - "reset" : Rising edge of the selected trigger input reinitializes the counter
>>>>> + and generates an update of the registers.
>>>>> + - "gated" : The counter clock is enabled when the trigger input is high.
>>>>> + The counter stops (but is not reset) as soon as the trigger becomes low.
>>>>> + Both start and stop of the counter are controlled.
>>>>> + - "trigger" : The counter starts at a rising edge of the trigger TRGI (but it is not
>>>>> + reset). Only the start of the counter is controlled.
>>>>> + - "external_clock": Rising edges of the selected trigger (TRGI) clock the counter.
>>>>> +
>>>>> +What: /sys/bus/iio/devices/iio:deviceX/slave_mode
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard@st.com
>>>>> +Description:
>>>>> + Reading returns the current slave mode.
>>>>> + Writing set the slave mode
>>>>> +
>>>>> +What: /sys/bus/iio/devices/triggerX/sampling_frequency
>>>>> +KernelVersion: 4.10
>>>>> +Contact: benjamin.gaignard@st.com
>>>>> +Description:
>>>>> + Reading returns the current sampling frequency.
>>>>> + Writing an value different of 0 set and start sampling.
>>>>> + Writing 0 stop sampling.
>>>>> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
>>>>> index 6743b18..2de2a80 100644
>>>>> --- a/drivers/iio/Kconfig
>>>>> +++ b/drivers/iio/Kconfig
>>>>> @@ -90,5 +90,5 @@ source "drivers/iio/potentiometer/Kconfig"
>>>>> source "drivers/iio/pressure/Kconfig"
>>>>> source "drivers/iio/proximity/Kconfig"
>>>>> source "drivers/iio/temperature/Kconfig"
>>>>> -
>>>>> +source "drivers/iio/timer/Kconfig"
>>>>> endif # IIO
>>>>> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
>>>>> index 87e4c43..b797c08 100644
>>>>> --- a/drivers/iio/Makefile
>>>>> +++ b/drivers/iio/Makefile
>>>>> @@ -32,4 +32,5 @@ obj-y += potentiometer/
>>>>> obj-y += pressure/
>>>>> obj-y += proximity/
>>>>> obj-y += temperature/
>>>>> +obj-y += timer/
>>>>> obj-y += trigger/
>>>>> diff --git a/drivers/iio/timer/Kconfig b/drivers/iio/timer/Kconfig
>>>>> new file mode 100644
>>>>> index 0000000..e3c21f2
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/Kconfig
>>>>> @@ -0,0 +1,13 @@
>>>>> +#
>>>>> +# Timers drivers
>>>>> +
>>>>> +menu "Timers"
>>>>> +
>>>>> +config IIO_STM32_TIMER_TRIGGER
>>>>> + tristate "STM32 Timer Trigger"
>>>>> + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST
>>>>> + select IIO_TRIGGERED_EVENT
>>>>> + help
>>>>> + Select this option to enable STM32 Timer Trigger
>>>>> +
>>>>> +endmenu
>>>>> diff --git a/drivers/iio/timer/Makefile b/drivers/iio/timer/Makefile
>>>>> new file mode 100644
>>>>> index 0000000..4ad95ec9
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/Makefile
>>>>> @@ -0,0 +1 @@
>>>>> +obj-$(CONFIG_IIO_STM32_TIMER_TRIGGER) += stm32-timer-trigger.o
>>>>> diff --git a/drivers/iio/timer/stm32-timer-trigger.c b/drivers/iio/timer/stm32-timer-trigger.c
>>>>> new file mode 100644
>>>>> index 0000000..8d16e8f
>>>>> --- /dev/null
>>>>> +++ b/drivers/iio/timer/stm32-timer-trigger.c
>>>>> @@ -0,0 +1,466 @@
>>>>> +/*
>>>>> + * Copyright (C) STMicroelectronics 2016
>>>>> + *
>>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> + *
>>>>> + * License terms: GNU General Public License (GPL), version 2
>>>>> + */
>>>>> +
>>>>> +#include <linux/iio/iio.h>
>>>>> +#include <linux/iio/sysfs.h>
>>>>> +#include <linux/iio/timer/stm32-timer-trigger.h>
>>>>> +#include <linux/iio/trigger.h>
>>>>> +#include <linux/iio/triggered_event.h>
>>>>> +#include <linux/interrupt.h>
>>>>> +#include <linux/mfd/stm32-timers.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/platform_device.h>
>>>>> +
>>>>> +#define MAX_TRIGGERS 6
>>>>> +#define MAX_VALIDS 5
>>>>> +
>>>>> +/* List the triggers created by each timer */
>>>>> +static const void *triggers_table[][MAX_TRIGGERS] = {
>>>>> + { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4,},
>>>>> + { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4,},
>>>>> + { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4,},
>>>>> + { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4,},
>>>>> + { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4,},
>>>>> + { TIM6_TRGO,},
>>>>> + { TIM7_TRGO,},
>>>>> + { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4,},
>>>>> + { TIM9_TRGO, TIM9_CH1, TIM9_CH2,},
>>>>> + { TIM12_TRGO, TIM12_CH1, TIM12_CH2,},
>>>>> +};
>>>>> +
>>>>> +/* List the triggers accepted by each timer */
>>>>> +static const void *valids_table[][MAX_VALIDS] = {
>>>>> + { TIM5_TRGO, TIM2_TRGO, TIM4_TRGO, TIM3_TRGO,},
>>>>> + { TIM1_TRGO, TIM8_TRGO, TIM3_TRGO, TIM4_TRGO,},
>>>>> + { TIM1_TRGO, TIM8_TRGO, TIM5_TRGO, TIM4_TRGO,},
>>>>> + { TIM1_TRGO, TIM2_TRGO, TIM3_TRGO, TIM8_TRGO,},
>>>>> + { TIM2_TRGO, TIM3_TRGO, TIM4_TRGO, TIM8_TRGO,},
>>>>> + { }, /* timer 6 */
>>>>> + { }, /* timer 7 */
>>>>> + { TIM1_TRGO, TIM2_TRGO, TIM4_TRGO, TIM5_TRGO,},
>>>>> + { TIM2_TRGO, TIM3_TRGO,},
>>>>> + { TIM4_TRGO, TIM5_TRGO,},
>>>>> +};
>>>>> +
>>>>> +struct stm32_timer_trigger {
>>>>> + struct device *dev;
>>>>> + struct regmap *regmap;
>>>>> + struct clk *clk;
>>>>> + u32 max_arr;
>>>>> + const void *triggers;
>>>>> + const void *valids;
>>>>> +};
>>>>> +
>>>>> +static int stm32_timer_start(struct stm32_timer_trigger *priv,
>>>>> + unsigned int frequency)
>>>>> +{
>>>>> + unsigned long long prd, div;
>>>>> + int prescaler = 0;
>>>>> + u32 ccer, cr1;
>>>>> +
>>>>> + /* Period and prescaler values depends of clock rate */
>>>>> + div = (unsigned long long)clk_get_rate(priv->clk);
>>>>> +
>>>>> + do_div(div, frequency);
>>>>> +
>>>>> + prd = div;
>>>>> +
>>>>> + /*
>>>>> + * Increase prescaler value until we get a result that fit
>>>>> + * with auto reload register maximum value.
>>>>> + */
>>>>> + while (div > priv->max_arr) {
>>>>> + prescaler++;
>>>>> + div = prd;
>>>>> + do_div(div, (prescaler + 1));
>>>>> + }
>>>>> + prd = div;
>>>>> +
>>>>> + if (prescaler > MAX_TIM_PSC) {
>>>>> + dev_err(priv->dev, "prescaler exceeds the maximum value\n");
>>>>> + return -EINVAL;
>>>>> + }
>>>>> +
>>>>> + /* Check if nobody else use the timer */
>>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>>> + if (ccer & TIM_CCER_CCXE)
>>>>> + return -EBUSY;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + if (!(cr1 & TIM_CR1_CEN))
>>>>> + clk_enable(priv->clk);
>>>>> +
>>>>> + regmap_write(priv->regmap, TIM_PSC, prescaler);
>>>>> + regmap_write(priv->regmap, TIM_ARR, prd - 1);
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_ARPE, TIM_CR1_ARPE);
>>>>> +
>>>>> + /* Force master mode to update mode */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR2, TIM_CR2_MMS, 0x20);
>>>>> +
>>>>> + /* Make sure that registers are updated */
>>>>> + regmap_update_bits(priv->regmap, TIM_EGR, TIM_EGR_UG, TIM_EGR_UG);
>>>>> +
>>>>> + /* Enable controller */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, TIM_CR1_CEN);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static void stm32_timer_stop(struct stm32_timer_trigger *priv)
>>>>> +{
>>>>> + u32 ccer, cr1;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CCER, &ccer);
>>>>> + if (ccer & TIM_CCER_CCXE)
>>>>> + return;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + if (cr1 & TIM_CR1_CEN)
>>>>> + clk_disable(priv->clk);
>>>>> +
>>>>> + /* Stop timer */
>>>>> + regmap_update_bits(priv->regmap, TIM_CR1, TIM_CR1_CEN, 0);
>>>>> + regmap_write(priv->regmap, TIM_PSC, 0);
>>>>> + regmap_write(priv->regmap, TIM_ARR, 0);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_frequency(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>>> + unsigned int freq;
>>>>> + int ret;
>>>>> +
>>>>> + ret = kstrtouint(buf, 10, &freq);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + if (freq == 0) {
>>>>> + stm32_timer_stop(priv);
>>>>> + } else {
>>>>> + ret = stm32_timer_start(priv, freq);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + }
>>>>> +
>>>>> + return len;
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_read_frequency(struct device *dev,
>>>>> + struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> + struct iio_trigger *trig = to_iio_trigger(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_trigger_get_drvdata(trig);
>>>>> + u32 psc, arr, cr1;
>>>>> + unsigned long long freq = 0;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR1, &cr1);
>>>>> + regmap_read(priv->regmap, TIM_PSC, &psc);
>>>>> + regmap_read(priv->regmap, TIM_ARR, &arr);
>>>>> +
>>>>> + if (psc && arr && (cr1 & TIM_CR1_CEN)) {
>>>>> + freq = (unsigned long long)clk_get_rate(priv->clk);
>>>>> + do_div(freq, psc);
>>>>> + do_div(freq, arr);
>>>>> + }
>>>>> +
>>>>> + return sprintf(buf, "%d\n", (unsigned int)freq);
>>>>> +}
>>>>> +
>>>>> +static IIO_DEV_ATTR_SAMP_FREQ(0660,
>>>>> + stm32_tt_read_frequency,
>>>>> + stm32_tt_store_frequency);
>>>>> +
>>>>> +static struct attribute *stm32_trigger_attrs[] = {
>>>>> + &iio_dev_attr_sampling_frequency.dev_attr.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group stm32_trigger_attr_group = {
>>>>> + .attrs = stm32_trigger_attrs,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group *stm32_trigger_attr_groups[] = {
>>>>> + &stm32_trigger_attr_group,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static char *master_mode_table[] = {
>>>>> + "reset",
>>>>> + "enable",
>>>>> + "update",
>>>>> + "compare_pulse",
>>>>> + "OC1REF",
>>>>> + "OC2REF",
>>>>> + "OC3REF",
>>>>> + "OC4REF"
>>>>> +};
>>>>> +
>>>>> +static ssize_t stm32_tt_show_master_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *buf)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + u32 cr2;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_CR2, &cr2);
>>>>> + cr2 = (cr2 & TIM_CR2_MMS) >> TIM_CR2_MMS_SHIFT;
>>>>> +
>>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", master_mode_table[cr2]);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_master_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + int i;
>>>>> +
>>>>> + for (i = 0; i < ARRAY_SIZE(master_mode_table); i++) {
>>>>> + if (!strncmp(master_mode_table[i], buf,
>>>>> + strlen(master_mode_table[i]))) {
>>>>> + regmap_update_bits(priv->regmap, TIM_CR2,
>>>>> + TIM_CR2_MMS, i << TIM_CR2_MMS_SHIFT);
>>>>> + return len;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static IIO_CONST_ATTR(master_mode_available,
>>>>> + "reset enable update compare_pulse OC1REF OC2REF OC3REF OC4REF");
>>>>> +
>>>>> +static IIO_DEVICE_ATTR(master_mode, 0660,
>>>>> + stm32_tt_show_master_mode,
>>>>> + stm32_tt_store_master_mode,
>>>>> + 0);
>>>>> +
>>>>> +static char *slave_mode_table[] = {
>>>>> + "disabled",
>>>>> + "encoder_1",
>>>>> + "encoder_2",
>>>>> + "encoder_3",
>>>>> + "reset",
>>>>> + "gated",
>>>>> + "trigger",
>>>>> + "external_clock",
>>>>> +};
>>>>> +
>>>>> +static ssize_t stm32_tt_show_slave_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *buf)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + u32 smcr;
>>>>> +
>>>>> + regmap_read(priv->regmap, TIM_SMCR, &smcr);
>>>>> + smcr &= TIM_SMCR_SMS;
>>>>> +
>>>>> + return snprintf(buf, PAGE_SIZE, "%s\n", slave_mode_table[smcr]);
>>>>> +}
>>>>> +
>>>>> +static ssize_t stm32_tt_store_slave_mode(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + const char *buf, size_t len)
>>>>> +{
>>>>> + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + int i;
>>>>> +
>>>>> + for (i = 0; i < ARRAY_SIZE(slave_mode_table); i++) {
>>>>> + if (!strncmp(slave_mode_table[i], buf,
>>>>> + strlen(slave_mode_table[i]))) {
>>>>> + regmap_update_bits(priv->regmap,
>>>>> + TIM_SMCR, TIM_SMCR_SMS, i);
>>>>> + return len;
>>>>> + }
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static IIO_CONST_ATTR(slave_mode_available,
>>>>> +"disabled encoder_1 encoder_2 encoder_3 reset gated trigger external_clock");
>>>>> +
>>>>> +static IIO_DEVICE_ATTR(slave_mode, 0660,
>>>>> + stm32_tt_show_slave_mode,
>>>>> + stm32_tt_store_slave_mode,
>>>>> + 0);
>>>>> +
>>>>> +static struct attribute *stm32_timer_attrs[] = {
>>>>> + &iio_dev_attr_master_mode.dev_attr.attr,
>>>>> + &iio_const_attr_master_mode_available.dev_attr.attr,
>>>>> + &iio_dev_attr_slave_mode.dev_attr.attr,
>>>>> + &iio_const_attr_slave_mode_available.dev_attr.attr,
>>>>> + NULL,
>>>>> +};
>>>>> +
>>>>> +static const struct attribute_group stm32_timer_attr_group = {
>>>>> + .attrs = stm32_timer_attrs,
>>>>> +};
>>>>> +
>>>>> +static const struct iio_trigger_ops timer_trigger_ops = {
>>>>> + .owner = THIS_MODULE,
>>>>> +};
>>>>> +
>>>>> +static int stm32_setup_iio_triggers(struct stm32_timer_trigger *priv)
>>>>> +{
>>>>> + int ret;
>>>>> + const char * const *cur = priv->triggers;
>>>>> +
>>>>> + while (cur && *cur) {
>>>>> + struct iio_trigger *trig;
>>>>> +
>>>>> + trig = devm_iio_trigger_alloc(priv->dev, "%s", *cur);
>>>>> + if (!trig)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + trig->dev.parent = priv->dev->parent;
>>>>> + trig->ops = &timer_trigger_ops;
>>>>> + trig->dev.groups = stm32_trigger_attr_groups;
>>>>> + iio_trigger_set_drvdata(trig, priv);
>>>>> +
>>>>> + ret = devm_iio_trigger_register(priv->dev, trig);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + cur++;
>>>>> + }
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +/**
>>>>> + * is_stm32_timer_trigger
>>>>> + * @trig: trigger to be checked
>>>>> + *
>>>>> + * return true if the trigger is a valid stm32 iio timer trigger
>>>>> + * either return false
>>>>> + */
>>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig)
>>>>> +{
>>>>> + return (trig->ops == &timer_trigger_ops);
>>>>> +}
>>>>> +EXPORT_SYMBOL(is_stm32_timer_trigger);
>>>>> +
>>>>> +static int stm32_validate_trigger(struct iio_dev *indio_dev,
>>>>> + struct iio_trigger *trig)
>>>>> +{
>>>>> + struct stm32_timer_trigger *priv = iio_priv(indio_dev);
>>>>> + const char * const *cur = priv->valids;
>>>>> + unsigned int i = 0;
>>>>> +
>>>>> + if (!is_stm32_timer_trigger(trig))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + while (cur && *cur) {
>>>>> + if (!strncmp(trig->name, *cur, strlen(trig->name))) {
>>>>> + regmap_update_bits(priv->regmap,
>>>>> + TIM_SMCR, TIM_SMCR_TS,
>>>>> + i << TIM_SMCR_TS_SHIFT);
>>>>> + return 0;
>>>>> + }
>>>>> + cur++;
>>>>> + i++;
>>>>> + }
>>>>> +
>>>>> + return -EINVAL;
>>>>> +}
>>>>> +
>>>>> +static const struct iio_info stm32_trigger_info = {
>>>>> + .driver_module = THIS_MODULE,
>>>>> + .validate_trigger = stm32_validate_trigger,
>>>>> + .attrs = &stm32_timer_attr_group,
>>>>> +};
>>>>> +
>>>>> +static struct stm32_timer_trigger *stm32_setup_iio_device(struct device *dev)
>>>>> +{
>>>>> + struct iio_dev *indio_dev;
>>>>> + int ret;
>>>>> +
>>>>> + indio_dev = devm_iio_device_alloc(dev,
>>>>> + sizeof(struct stm32_timer_trigger));
>>>>> + if (!indio_dev)
>>>>> + return NULL;
>>>>> +
>>>>> + indio_dev->name = dev_name(dev);
>>>>> + indio_dev->dev.parent = dev;
>>>>> + indio_dev->info = &stm32_trigger_info;
>>>>> + indio_dev->modes = INDIO_EVENT_TRIGGERED;
>>>>> + indio_dev->num_channels = 0;
>>>>> + indio_dev->dev.of_node = dev->of_node;
>>>>> +
>>>>> + ret = devm_iio_device_register(dev, indio_dev);
>>>>> + if (ret)
>>>>> + return NULL;
>>>>> +
>>>>> + return iio_priv(indio_dev);
>>>>> +}
>>>>> +
>>>>> +static int stm32_timer_trigger_probe(struct platform_device *pdev)
>>>>> +{
>>>>> + struct device *dev = &pdev->dev;
>>>>> + struct stm32_timer_trigger *priv;
>>>>> + struct stm32_timers *ddata = dev_get_drvdata(pdev->dev.parent);
>>>>> + unsigned int index;
>>>>> + int ret;
>>>>> +
>>>>> + if (of_property_read_u32(dev->of_node, "reg", &index))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + if (index >= ARRAY_SIZE(triggers_table))
>>>>> + return -EINVAL;
>>>>> +
>>>>> + /* Create an IIO device only if we have triggers to be validated */
>>>>> + if (*valids_table[index])
>>>>> + priv = stm32_setup_iio_device(dev);
>>>>
>>>> I still don't like this. Really feels like we shouldn't be creating an
>>>> iio device with all the bagage that carries just to allow us to do the
>>>> trigger trees. We ought to have a much more light weight solution for this
>>>> functionality - we aren't typically even using the interrupt tree stuff
>>>> that the triggers for devices are all really about.
>>>>
>>>> A simpler approach of allowing each trigger the option of a parent seems like
>>>> it would be cleaner. Could be done entirely within this driver in the first
>>>> instance. Basically it would just look like your master and slave attributes
>>>> but have those under triggerX not iio:deviceX.
>>>>
>>>> We can work out how to make it more generic later - including perhaps the
>>>> option to trigger from triggers outside this driver, using some parallel
>>>> infrastructure to the device triggering.
>>>>
>>>>
>>>>> + else
>>>>> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>>>>> +
>>>>> + if (!priv)
>>>>> + return -ENOMEM;
>>>>> +
>>>>> + priv->dev = dev;
>>>>> + priv->regmap = ddata->regmap;
>>>>> + priv->clk = ddata->clk;
>>>>> + priv->max_arr = ddata->max_arr;
>>>>> + priv->triggers = triggers_table[index];
>>>>> + priv->valids = valids_table[index];
>>>>> +
>>>>> + ret = stm32_setup_iio_triggers(priv);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + platform_set_drvdata(pdev, priv);
>>>>> +
>>>>> + return 0;
>>>>> +}
>>>>> +
>>>>> +static const struct of_device_id stm32_trig_of_match[] = {
>>>>> + { .compatible = "st,stm32-timer-trigger", },
>>>>> + { /* end node */ },
>>>>> +};
>>>>> +MODULE_DEVICE_TABLE(of, stm32_trig_of_match);
>>>>> +
>>>>> +static struct platform_driver stm32_timer_trigger_driver = {
>>>>> + .probe = stm32_timer_trigger_probe,
>>>>> + .driver = {
>>>>> + .name = "stm32-timer-trigger",
>>>>> + .of_match_table = stm32_trig_of_match,
>>>>> + },
>>>>> +};
>>>>> +module_platform_driver(stm32_timer_trigger_driver);
>>>>> +
>>>>> +MODULE_ALIAS("platform: stm32-timer-trigger");
>>>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 Timer Trigger driver");
>>>>> +MODULE_LICENSE("GPL v2");
>>>>> diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
>>>>> index 809b2e7..f2af4fe 100644
>>>>> --- a/drivers/iio/trigger/Kconfig
>>>>> +++ b/drivers/iio/trigger/Kconfig
>>>>> @@ -46,5 +46,4 @@ config IIO_SYSFS_TRIGGER
>>>>>
>>>>> To compile this driver as a module, choose M here: the
>>>>> module will be called iio-trig-sysfs.
>>>>> -
>>>> Clean this up.
>>>
>>> ok
>>>
>>>>> endmenu
>>>>> diff --git a/include/linux/iio/timer/stm32-timer-trigger.h b/include/linux/iio/timer/stm32-timer-trigger.h
>>>>> new file mode 100644
>>>>> index 0000000..55535ae
>>>>> --- /dev/null
>>>>> +++ b/include/linux/iio/timer/stm32-timer-trigger.h
>>>>> @@ -0,0 +1,62 @@
>>>>> +/*
>>>>> + * Copyright (C) STMicroelectronics 2016
>>>>> + *
>>>>> + * Author: Benjamin Gaignard <benjamin.gaignard@st.com>
>>>>> + *
>>>>> + * License terms: GNU General Public License (GPL), version 2
>>>>> + */
>>>>> +
>>>>> +#ifndef _STM32_TIMER_TRIGGER_H_
>>>>> +#define _STM32_TIMER_TRIGGER_H_
>>>>> +
>>>>> +#define TIM1_TRGO "tim1_trgo"
>>>>> +#define TIM1_CH1 "tim1_ch1"
>>>>> +#define TIM1_CH2 "tim1_ch2"
>>>>> +#define TIM1_CH3 "tim1_ch3"
>>>>> +#define TIM1_CH4 "tim1_ch4"
>>>>> +
>>>>> +#define TIM2_TRGO "tim2_trgo"
>>>>> +#define TIM2_CH1 "tim2_ch1"
>>>>> +#define TIM2_CH2 "tim2_ch2"
>>>>> +#define TIM2_CH3 "tim2_ch3"
>>>>> +#define TIM2_CH4 "tim2_ch4"
>>>>> +
>>>>> +#define TIM3_TRGO "tim3_trgo"
>>>>> +#define TIM3_CH1 "tim3_ch1"
>>>>> +#define TIM3_CH2 "tim3_ch2"
>>>>> +#define TIM3_CH3 "tim3_ch3"
>>>>> +#define TIM3_CH4 "tim3_ch4"
>>>>> +
>>>>> +#define TIM4_TRGO "tim4_trgo"
>>>>> +#define TIM4_CH1 "tim4_ch1"
>>>>> +#define TIM4_CH2 "tim4_ch2"
>>>>> +#define TIM4_CH3 "tim4_ch3"
>>>>> +#define TIM4_CH4 "tim4_ch4"
>>>>> +
>>>>> +#define TIM5_TRGO "tim5_trgo"
>>>>> +#define TIM5_CH1 "tim5_ch1"
>>>>> +#define TIM5_CH2 "tim5_ch2"
>>>>> +#define TIM5_CH3 "tim5_ch3"
>>>>> +#define TIM5_CH4 "tim5_ch4"
>>>>> +
>>>>> +#define TIM6_TRGO "tim6_trgo"
>>>>> +
>>>>> +#define TIM7_TRGO "tim7_trgo"
>>>>> +
>>>>> +#define TIM8_TRGO "tim8_trgo"
>>>>> +#define TIM8_CH1 "tim8_ch1"
>>>>> +#define TIM8_CH2 "tim8_ch2"
>>>>> +#define TIM8_CH3 "tim8_ch3"
>>>>> +#define TIM8_CH4 "tim8_ch4"
>>>>> +
>>>>> +#define TIM9_TRGO "tim9_trgo"
>>>>> +#define TIM9_CH1 "tim9_ch1"
>>>>> +#define TIM9_CH2 "tim9_ch2"
>>>>> +
>>>>> +#define TIM12_TRGO "tim12_trgo"
>>>>> +#define TIM12_CH1 "tim12_ch1"
>>>>> +#define TIM12_CH2 "tim12_ch2"
>>>>> +
>>>>> +bool is_stm32_timer_trigger(struct iio_trigger *trig);
>>>>> +
>>>>> +#endif
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Benjamin Gaignard
>
> Graphic Study Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 1/3] power: reset: add linkstation-reset driver
From: Andrew Lunn @ 2017-01-03 13:09 UTC (permalink / raw)
To: Florian Fainelli
Cc: devicetree, Ryan Tandy, linux-pm, Sebastian Reichel,
Roger Shimizu, Herbert Valerio Riedel, Martin Michlmayr,
linux-arm-kernel, Sylver Bruneau
In-Reply-To: <fff132e9-a178-6948-676e-6a4d24b6c4d6@gmail.com>
> > +
> > + /* Check that nothing else has already setup a handler */
> > + if (pm_power_off) {
> > + lookup_symbol_name((ulong)pm_power_off, symname);
> > + dev_err(&pdev->dev,
> > + "pm_power_off already claimed %p %s",
> > + pm_power_off, symname);
> > + return -EBUSY;
> > + }
> > + pm_power_off = linkstation_reset;
>
> That seems a bit complicated, why not just assume that there will be
> either this driver used, or not at all?
That is probably my fault. This is a copy from code i wrote many years
ago for the QNAP. I guess at the time i was battling with two
different pm_power_off handlers, so put in this code.
> Also, you are supposed to register a reboot notifier to which you can
> pass private context:
At the time i wrote the QNAP code, this did not exist. So maybe my
code is no longer a good example to copy.
Andrew
^ permalink raw reply
* Re: [PATCH 2/4] input: tm2-touchkey: Add touchkey driver support for TM2
From: Javier Martinez Canillas @ 2017-01-03 13:11 UTC (permalink / raw)
To: Jaechul Lee, Dmitry Torokhov, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Kukjin Kim, Krzysztof Kozlowski
Cc: devicetree, linux-samsung-soc, linux-kernel, Andi Shyti,
Chanwoo Choi, beomho.seo, linux-input, galaxyra, linux-arm-kernel
In-Reply-To: <1483430237-26823-3-git-send-email-jcsing.lee@samsung.com>
Hello Jaechul,
On 01/03/2017 04:57 AM, Jaechul Lee wrote:
> This patch adds support for the TM2 touch key and led
> functionlity.
>
s/functionlity/functionality
> The driver interfaces with userspace through an input device and
> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/tm2-touchkey.c | 326 ++++++++++++++++++++++++++++++++++
> 3 files changed, 338 insertions(+)
> create mode 100644 drivers/input/keyboard/tm2-touchkey.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index cbd75cf..72c0ba1 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
> To compile this driver as a module, choose M here: the
> module will be called tc3589x-keypad.
>
> +config KEYBOARD_TM2_TOUCHKEY
> + tristate "tm2-touchkey support"
> + depends on I2C
> + help
> + Say Y here to enable the tm2-touchkey.
> + touchkey driver for tm2. This driver can enable
> + the interrupt and make input events and control led brightness.
> +
> + To compile this driver as a module, choose M here.
> + module will be called tm2-touchkey
> +
> config KEYBOARD_TWL4030
> tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
> depends on TWL4030_CORE
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index d9f4cfc..7d9acff 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
> obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
> obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> +obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
> new file mode 100644
> index 0000000..d9575d8
> --- /dev/null
> +++ b/drivers/input/keyboard/tm2-touchkey.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for keys on GPIO lines capable of generating interrupts.
> + *
> + * Copyright 2005 Phil Blundell
> + * Copyright 2016 Samsung Electronics Co., Ltd.
> + *
> + * Author: Beomho Seo <beomho.seo@samsung.com>
> + * Author: Jaechul Lee <jcsing.lee@samsung.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/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/workqueue.h>
> +
> +#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
> +#define TM2_TOUCHKEY_KEYCODE_REG 0x03
> +#define TM2_TOUCHKEY_BASE_REG 0x00
> +#define TM2_TOUCHKEY_CMD_LED_ON 0x10
> +#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
> +#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
> +#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
> +
> +enum {
> + TM2_TOUCHKEY_KEY_MENU = 0x1,
> + TM2_TOUCHKEY_KEY_BACK,
> +};
> +
> +#define tm2_touchkey_power_enable(x) __tm2_touchkey_power_onoff(x, 1)
> +#define tm2_touchkey_power_disable(x) __tm2_touchkey_power_onoff(x, 0)
> +
> +struct tm2_touchkey_data {
> + struct i2c_client *client;
> + struct input_dev *input_dev;
> + struct led_classdev led_dev;
> +
> + u8 keycode_type;
> + u8 pressed;
> + struct work_struct irq_work;
> +
> + bool power_onoff;
> + struct regulator *regulator_vcc; /* 1.8V */
> + struct regulator *regulator_vdd; /* 3.3V */
> +};
> +
> +static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
> + enum led_brightness brightness)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + container_of(led_dev, struct tm2_touchkey_data, led_dev);
> + u32 volt;
> + u8 data;
> +
> + if (brightness == LED_OFF) {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
> + data = TM2_TOUCHKEY_CMD_LED_OFF;
> + } else {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
> + data = TM2_TOUCHKEY_CMD_LED_ON;
> + }
> +
> + regulator_set_voltage(samsung_touchkey->regulator_vdd, volt, volt);
> + i2c_smbus_write_byte_data(samsung_touchkey->client,
> + TM2_TOUCHKEY_BASE_REG, data);
> +}
> +
> +static int __tm2_touchkey_power_onoff(struct tm2_touchkey_data
> + *samsung_touchkey, bool onoff)
> +{
> + int ret = 0;
> +
> + if (samsung_touchkey->power_onoff == onoff)
> + return ret;
> +
> + if (onoff) {
> + ret = regulator_enable(samsung_touchkey->regulator_vcc);
> + if (ret)
> + return ret;
> +
> + ret = regulator_enable(samsung_touchkey->regulator_vdd);
> + if (ret) {
> + regulator_disable(samsung_touchkey->regulator_vcc);
> + return ret;
> + }
I would add a comment about the sleep here.
> + msleep(150);
> + } else {
> + int err;
> +
> + err = regulator_disable(samsung_touchkey->regulator_vcc);
> + if (err)
> + ret = err;
> +
> + err = regulator_disable(samsung_touchkey->regulator_vdd);
> + if (err && !ret)
> + ret = err;
> + }
> + samsung_touchkey->power_onoff = onoff;
> +
> + return ret;
> +}
> +
> +static void tm2_touchkey_irq_work(struct work_struct *irq_work)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + container_of(irq_work, struct tm2_touchkey_data, irq_work);
> +
> + if (!samsung_touchkey->pressed) {
> + input_report_key(samsung_touchkey->input_dev, KEY_PHONE, 0);
> + input_report_key(samsung_touchkey->input_dev, KEY_BACK, 0);
> + } else {
> + if (samsung_touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
> + input_report_key(samsung_touchkey->input_dev,
> + KEY_PHONE, 1);
> + else
> + input_report_key(samsung_touchkey->input_dev,
> + KEY_BACK, 1);
> + }
> + input_sync(samsung_touchkey->input_dev);
> +}
> +
> +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = devid;
> + u32 data;
> +
> + data = i2c_smbus_read_byte_data(samsung_touchkey->client,
> + TM2_TOUCHKEY_KEYCODE_REG);
> +
> + if (data < 0) {
> + dev_err(&samsung_touchkey->client->dev, "Failed to read i2c data\n");
> + return IRQ_HANDLED;
> + }
> +
> + samsung_touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
> + samsung_touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
> +
> + if (samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
> + samsung_touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK)
Shouldn't at least a debug message be printed here so the user can
know that an error occurred and a correct keycode was not received?
> + return IRQ_HANDLED;
> +
> + schedule_work(&samsung_touchkey->irq_work);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int tm2_touchkey_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct tm2_touchkey_data *samsung_touchkey;
> + int ret;
> +
> + ret = i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_BYTE |
> + I2C_FUNC_SMBUS_BYTE_DATA);
> + if (!ret) {
> + dev_err(&client->dev, "No I2C functionality found\n");
> + return -ENODEV;
> + }
> +
> + samsung_touchkey = devm_kzalloc(&client->dev,
> + sizeof(struct tm2_touchkey_data), GFP_KERNEL);
> +
> + if (!samsung_touchkey) {
> + dev_err(&client->dev, "Failed to allocate memory.\n");
> + return -ENOMEM;
> + }
> +
> + samsung_touchkey->client = client;
> + i2c_set_clientdata(client, samsung_touchkey);
> + INIT_WORK(&samsung_touchkey->irq_work, tm2_touchkey_irq_work);
> +
> + /* regulator */
> + samsung_touchkey->regulator_vcc =
> + devm_regulator_get(&client->dev, "vcc");
> + if (IS_ERR(samsung_touchkey->regulator_vcc)) {
> + dev_err(&client->dev, "Failed to get vcc regulator\n");
> + return PTR_ERR(samsung_touchkey->regulator_vcc);
> + }
> +
> + samsung_touchkey->regulator_vdd =
> + devm_regulator_get(&client->dev, "vdd");
> + if (IS_ERR(samsung_touchkey->regulator_vdd)) {
> + dev_err(&client->dev, "Failed to get vdd regulator\n");
> + return PTR_ERR(samsung_touchkey->regulator_vcc);
> + }
> +
> + /* power */
> + ret = tm2_touchkey_power_enable(samsung_touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to enable power\n");
> + return ret;
> + }
> +
> + /* irq */
> + ret = devm_request_threaded_irq(&client->dev,
> + client->irq, NULL,
> + tm2_touchkey_irq_handler,
> + IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
> + TM2_TOUCHKEY_DEV_NAME,
> + samsung_touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to request threaded irq\n");
> + return ret;
> + }
> +
> + /* input device */
> + samsung_touchkey->input_dev = devm_input_allocate_device(&client->dev);
> + if (!samsung_touchkey->input_dev) {
> + dev_err(&client->dev, "Failed to alloc input device.\n");
> + return -ENOMEM;
> + }
> + samsung_touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
> + samsung_touchkey->input_dev->id.bustype = BUS_I2C;
> + samsung_touchkey->input_dev->dev.parent = &client->dev;
> +
> + set_bit(EV_KEY, samsung_touchkey->input_dev->evbit);
> + set_bit(KEY_PHONE, samsung_touchkey->input_dev->keybit);
> + set_bit(KEY_BACK, samsung_touchkey->input_dev->keybit);
> + input_set_drvdata(samsung_touchkey->input_dev, samsung_touchkey);
> +
> + ret = input_register_device(samsung_touchkey->input_dev);
> + if (ret) {
> + dev_err(&client->dev, "Failed to register input device.\n");
> + return ret;
> + }
> +
> + /* led device */
> + samsung_touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
> + samsung_touchkey->led_dev.brightness = LED_FULL;
> + samsung_touchkey->led_dev.max_brightness = LED_FULL;
> + samsung_touchkey->led_dev.brightness_set =
> + tm2_touchkey_led_brightness_set;
> +
> + ret = devm_led_classdev_register(&client->dev,
> + &samsung_touchkey->led_dev);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to register touchkey led\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void tm2_touchkey_shutdown(struct i2c_client *client)
> +{
> + struct tm2_touchkey_data *samsung_touchkey =
> + i2c_get_clientdata(client);
> + int ret;
> +
> + disable_irq(client->irq);
> + ret = tm2_touchkey_power_disable(samsung_touchkey);
> + if (ret)
> + dev_err(&client->dev, "Failed to disable power\n");
> +}
> +
> +static int tm2_touchkey_suspend(struct device *dev)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> + int ret;
> +
> + disable_irq(samsung_touchkey->client->irq);
> + ret = tm2_touchkey_power_disable(samsung_touchkey);
> + if (ret)
> + dev_err(dev, "Failed to disable power\n");
> +
> + return ret;
> +}
These two functions are basically the same, can you factor it out?
> +
> +static int tm2_touchkey_resume(struct device *dev)
> +{
> + struct tm2_touchkey_data *samsung_touchkey = dev_get_drvdata(dev);
> + int ret;
> +
> + enable_irq(samsung_touchkey->client->irq);
> + ret = tm2_touchkey_power_enable(samsung_touchkey);
> + if (ret)
> + dev_err(dev, "Failed to enable power\n");
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
> + tm2_touchkey_resume);
> +
> +static const struct i2c_device_id tm2_touchkey_id_table[] = {
> + {TM2_TOUCHKEY_DEV_NAME, 0},
> + {},
> +};
> +
You need a MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table) here so the
module can be autoloaded when the device is registered.
> +static const struct of_device_id tm2_touchkey_of_match[] = {
> + {.compatible = "samsung,tm2-touchkey",},
> + {},
> +};
> +
Here a MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match) is not strictly
needed since the I2C core always reports MODALIAS of the form i2c:<dev>
but still is good to have so the I2C core can be fixed at some point.
> +static struct i2c_driver tm2_touchkey_driver = {
> + .driver = {
> + .name = TM2_TOUCHKEY_DEV_NAME,
> + .pm = &tm2_touchkey_pm_ops,
> + .of_match_table = of_match_ptr(tm2_touchkey_of_match),
> + },
> + .probe = tm2_touchkey_probe,
> + .shutdown = tm2_touchkey_shutdown,
> + .id_table = tm2_touchkey_id_table,
> +};
> +
> +module_i2c_driver(tm2_touchkey_driver);
> +
> +MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
> +MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
> +MODULE_DESCRIPTION("Samsung touchkey driver");
> +MODULE_LICENSE("GPL v2");
>
The rest looks good to me, so after the changes I suggested:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
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