[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

These two patches add support for automatically configuring the IO
voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
new notification types to the regulator code.  It's used by the second
patch which actually implements the IO voltage domain driver.

These two patches were co-developed by Heiko Stübner and Doug Anderson
(proof of concept patches were written by Heiko).  They were tested in
a private branch on an rk3288 board using rk808 instead of mainline
since rk808 support isn't finalized in mainline yet.


Heiko Stübner (2):
  regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
  soc/rockchip: io-domain: add driver handling io domains

 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/regulator/core.c                           |  63 +++-
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 include/linux/regulator/consumer.h                 |  20 ++
 8 files changed, 482 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

-- 
2.1.0.rc2.206.gedb03e5

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

These two patches add support for automatically configuring the IO
voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
new notification types to the regulator code.  It's used by the second
patch which actually implements the IO voltage domain driver.

These two patches were co-developed by Heiko Stübner and Doug Anderson
(proof of concept patches were written by Heiko).  They were tested in
a private branch on an rk3288 board using rk808 instead of mainline
since rk808 support isn't finalized in mainline yet.


Heiko Stübner (2):
  regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
  soc/rockchip: io-domain: add driver handling io domains

 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/regulator/core.c                           |  63 +++-
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 include/linux/regulator/consumer.h                 |  20 ++
 8 files changed, 482 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

-- 
2.1.0.rc2.206.gedb03e5

--
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

[PATCH 1/2] regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)

[Doug Anderson]

From: Heiko Stübner <heiko@sntech.de>

In some cases we need to know when a regulator is about to be changed.
Add a way for clients to be notified.  Note that for set_voltage() we
don't necessarily know what voltage we'll end up with, so we tell the
client what the range will be so they can prepare.

Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 drivers/regulator/core.c           | 63 +++++++++++++++++++++++++++++++++-----
 include/linux/regulator/consumer.h | 20 ++++++++++++
 2 files changed, 76 insertions(+), 7 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7bce715..b31d706 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -102,7 +102,7 @@ static int _regulator_disable(struct regulator_dev *rdev);
 static int _regulator_get_voltage(struct regulator_dev *rdev);
 static int _regulator_get_current_limit(struct regulator_dev *rdev);
 static unsigned int _regulator_get_mode(struct regulator_dev *rdev);
-static void _notifier_call_chain(struct regulator_dev *rdev,
+static int _notifier_call_chain(struct regulator_dev *rdev,
 				  unsigned long event, void *data);
 static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 				     int min_uV, int max_uV);
@@ -2406,6 +2406,55 @@ int regulator_is_supported_voltage(struct regulator *regulator,
 }
 EXPORT_SYMBOL_GPL(regulator_is_supported_voltage);
 
+static int _regulator_call_set_voltage(struct regulator_dev *rdev,
+				       int min_uV, int max_uV,
+				       unsigned *selector)
+{
+	struct pre_voltage_change_data data;
+	int ret;
+
+	data.old_uV = _regulator_get_voltage(rdev);
+	data.min_uV = min_uV;
+	data.max_uV = max_uV;
+	ret = _notifier_call_chain(rdev, REGULATOR_EVENT_PRE_VOLTAGE_CHANGE,
+				   &data);
+	if (ret & NOTIFY_STOP_MASK)
+		return -EINVAL;
+
+	ret = rdev->desc->ops->set_voltage(rdev, min_uV, max_uV, selector);
+	if (ret >= 0)
+		return ret;
+
+	_notifier_call_chain(rdev, REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE,
+			     (void *)data.old_uV);
+
+	return ret;
+}
+
+static int _regulator_call_set_voltage_sel(struct regulator_dev *rdev,
+					   int uV, unsigned selector)
+{
+	struct pre_voltage_change_data data;
+	int ret;
+
+	data.old_uV = _regulator_get_voltage(rdev);
+	data.min_uV = uV;
+	data.max_uV = uV;
+	ret = _notifier_call_chain(rdev, REGULATOR_EVENT_PRE_VOLTAGE_CHANGE,
+				   &data);
+	if (ret & NOTIFY_STOP_MASK)
+		return -EINVAL;
+
+	ret = rdev->desc->ops->set_voltage_sel(rdev, selector);
+	if (ret >= 0)
+		return ret;
+
+	_notifier_call_chain(rdev, REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE,
+			     (void *)data.old_uV);
+
+	return ret;
+}
+
 static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 				     int min_uV, int max_uV)
 {
@@ -2433,8 +2482,8 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 	}
 
 	if (rdev->desc->ops->set_voltage) {
-		ret = rdev->desc->ops->set_voltage(rdev, min_uV, max_uV,
-						   &selector);
+		ret = _regulator_call_set_voltage(rdev, min_uV, max_uV,
+						  &selector);
 
 		if (ret >= 0) {
 			if (rdev->desc->ops->list_voltage)
@@ -2469,8 +2518,8 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 				if (old_selector == selector)
 					ret = 0;
 				else
-					ret = rdev->desc->ops->set_voltage_sel(
-								rdev, ret);
+					ret = _regulator_call_set_voltage_sel(
+						rdev, best_val, selector);
 			} else {
 				ret = -EINVAL;
 			}
@@ -3116,11 +3165,11 @@ EXPORT_SYMBOL_GPL(regulator_unregister_notifier);
 /* notify regulator consumers and downstream regulator consumers.
  * Note mutex must be held by caller.
  */
-static void _notifier_call_chain(struct regulator_dev *rdev,
+static int _notifier_call_chain(struct regulator_dev *rdev,
 				  unsigned long event, void *data)
 {
 	/* call rdev chain first */
-	blocking_notifier_call_chain(&rdev->notifier, event, data);
+	return blocking_notifier_call_chain(&rdev->notifier, event, data);
 }
 
 /**
diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index f8a8733..d347c80 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -93,7 +93,12 @@ struct regmap;
  * OVER_TEMP      Regulator over temp.
  * FORCE_DISABLE  Regulator forcibly shut down by software.
  * VOLTAGE_CHANGE Regulator voltage changed.
+ *                Data passed is old voltage cast to (void *).
  * DISABLE        Regulator was disabled.
+ * PRE_VOLTAGE_CHANGE   Regulator is about to have voltage changed.
+ *                      Data passed is "struct pre_voltage_change_data"
+ * ABORT_VOLTAGE_CHANGE Regulator voltage change failed for some reason.
+ *                      Data passed is old voltage cast to (void *).
  *
  * NOTE: These events can be OR'ed together when passed into handler.
  */
@@ -106,6 +111,21 @@ struct regmap;
 #define REGULATOR_EVENT_FORCE_DISABLE		0x20
 #define REGULATOR_EVENT_VOLTAGE_CHANGE		0x40
 #define REGULATOR_EVENT_DISABLE 		0x80
+#define REGULATOR_EVENT_PRE_VOLTAGE_CHANGE	0x100
+#define REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE	0x200
+
+/**
+ * struct pre_voltage_change_data - Data sent with PRE_VOLTAGE_CHANGE event
+ *
+ * @old_uV: Current voltage before change.
+ * @min_uV: Min voltage we'll change to.
+ * @max_uV: Max voltage we'll change to.
+ */
+struct pre_voltage_change_data {
+	unsigned long old_uV;
+	unsigned long min_uV;
+	unsigned long max_uV;
+};
 
 struct regulator;
 
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 2/2] soc/rockchip: io-domain: add driver handling io domains

[Doug Anderson]

From: Heiko Stübner <heiko@sntech.de>

IO domain voltages on some Rockchip SoCs are variable but need to be
kept in sync between the regulators and a special register.

Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
---
 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 6 files changed, 406 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

diff --git a/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt b/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
new file mode 100644
index 0000000..20b4965
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
@@ -0,0 +1,60 @@
+Rockchip SRAM for IO Voltage Domains:
+-------------------------------------
+
+IO domain voltages on some Rockchip SoCs are variable but need to be
+kept in sync between the regulators and a special register.
+
+We can specify which regulator is associated with which IO Voltage
+Domain and then we can automatically adjust the register to match
+what's actually being provided on the rails.
+
+Required properties:
+- compatible: should be one of:
+  - "rockchip,rk3188-iodomain" for rk3188
+  - "rockchip,rk3288-iodomain" for rk3288
+
+You specify supplies using the standard regulator bindings by including
+a phandle the the relevant regulator.  All specified supplies must be able
+to report their voltage.  The IO Voltage Domain for any non-specified
+supplies will be not be touched.
+
+Possible supplies for rk3188:
+- ap0-supply:    The supply connected to AP0_VCC.
+- ap1-supply:    The supply connected to AP1_VCC.
+- cif-supply:    The supply connected to CIF_VCC.
+- flash-supply:  The supply connected to FLASH_VCC.
+- lcdc0-supply:  The supply connected to LCD0_VCC.
+- lcdc1-supply:  The supply connected to LCD1_VCC.
+- vccio0-supply: The supply connected to VCCIO0.
+- vccio1-supply: The supply connected to VCCIO1.
+                 Sometimes also labeled VCCIO1 and VCCIO2.
+
+Possible supplies for rk3288:
+- audio-supply:  The supply connected to APIO4_VDD.
+- bb-supply:     The supply connected to APIO5_VDD.
+- dvp-supply:    The supply connected to DVPIO_VDD.
+- flash0-supply: The supply connected to FLASH0_VDD.  Typically for eMMC
+- flash1-supply: The supply connected to FLASH1_VDD.  Also known as SDIO1.
+- gpio30-supply: The supply connected to APIO1_VDD.
+- gpio1830       The supply connected to APIO2_VDD.
+- lcdc-supply:   The supply connected to LCDC_VDD.
+- sdcard-supply: The supply connected to SDMMC0_VDD.
+- wifi-supply:   The supply connected to APIO3_VDD.  Also known as SDIO0.
+
+
+Example:
+
+	io-domains {
+		compatible = "rockchip,rk3288-iodomain";
+		rockchip,grf = <&grf>;
+
+		audio-supply = <&vcc18_codec>;
+		bb-supply = <&vcc33_io>;
+		dvp-supply = <&vcc_18>;
+		flash0-supply = <&vcc18_flashio>;
+		gpio1830-supply = <&vcc33_io>;
+		gpio30-supply = <&vcc33_pmuio>;
+		lcdc-supply = <&vcc33_lcd>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vcc18_wl>;
+	};
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c854385..443d946 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/rockchip/Kconfig"
 
 endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 3b1b95d..52808bf 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,4 +3,5 @@
 #
 
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
new file mode 100644
index 0000000..d25cb53
--- /dev/null
+++ b/drivers/soc/rockchip/Kconfig
@@ -0,0 +1,10 @@
+#
+# Rockchip Soc drivers
+#
+config ROCKCHIP_IODOMAIN
+        tristate "Rockchip IO domain support"
+        depends on ARCH_ROCKCHIP && OF
+        help
+          Say y here to enable support io domains on Rockchip SoCs. It is
+          necessary for the io domain setting of the SoC to match the
+          voltage supplied by the regulators.
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
new file mode 100644
index 0000000..dbf6da9
--- /dev/null
+++ b/drivers/soc/rockchip/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ROCKCHIP_IODOMAIN)	+=	io-domain.o
diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
new file mode 100644
index 0000000..f4e0ebc
--- /dev/null
+++ b/drivers/soc/rockchip/io-domain.c
@@ -0,0 +1,333 @@
+/*
+ * Rockchip IO Voltage Domain driver
+ *
+ * Copyright 2014 MundoReader S.L.
+ * Copyright 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define MAX_SUPPLIES		16
+
+#define MAX_VOLTAGE_1_8		1980000
+#define MAX_VOLTAGE_3_3		3600000
+
+struct rockchip_iodomain;
+
+/**
+ * @supplies: voltage settings matching the register bits.
+ */
+struct rockchip_iodomain_soc_data {
+	int grf_offset;
+	const char *supply_names[MAX_SUPPLIES];
+	void (*init)(struct rockchip_iodomain *iod);
+};
+
+struct rockchip_iodomain_supply {
+	struct rockchip_iodomain *iod;
+	struct regulator *reg;
+	struct notifier_block nb;
+	int idx;
+};
+
+struct rockchip_iodomain {
+	struct device *dev;
+	struct regmap *grf;
+	struct rockchip_iodomain_soc_data *soc_data;
+	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
+};
+
+static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
+				   int uV)
+{
+	struct rockchip_iodomain *iod = supply->iod;
+	u32 val;
+	int ret;
+
+	/* set value bit */
+	val = (uV > MAX_VOLTAGE_1_8) ? 0 : 1;
+	val <<= supply->idx;
+
+	/* apply hiword-mask */
+	val |= (BIT(supply->idx) << 16);
+
+	ret = regmap_write(iod->grf, iod->soc_data->grf_offset, val);
+	if (ret)
+		dev_err(iod->dev, "Couldn't write to GRF\n");
+
+	return ret;
+}
+
+static int rockchip_iodomain_notify(struct notifier_block *nb,
+				    unsigned long event,
+				    void *data)
+{
+	struct rockchip_iodomain_supply *supply =
+			container_of(nb, struct rockchip_iodomain_supply, nb);
+	int uV;
+	int ret;
+
+	/*
+	 * According to Rockchip it's important to keep the SoC IO domain
+	 * higher than (or equal to) the external voltage.  That means we need
+	 * to change it before external voltage changes happen in the case
+	 * of an increase.
+	 */
+	if (event & REGULATOR_EVENT_PRE_VOLTAGE_CHANGE) {
+		struct pre_voltage_change_data *pvc_data = data;
+
+		uV = max_t(unsigned long, pvc_data->old_uV, pvc_data->max_uV);
+	} else if (event & (REGULATOR_EVENT_VOLTAGE_CHANGE |
+			    REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE)) {
+		uV = (unsigned long)data;
+	} else {
+		return NOTIFY_OK;
+	}
+
+	dev_dbg(supply->iod->dev, "Setting to %d\n", uV);
+
+	if (uV > MAX_VOLTAGE_3_3) {
+		dev_err(supply->iod->dev, "Voltage too high: %d\n", uV);
+
+		if (event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
+			return NOTIFY_BAD;
+	}
+
+	ret = rockchip_iodomain_write(supply, uV);
+	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
+		return NOTIFY_BAD;
+
+	dev_info(supply->iod->dev, "Setting to %d done\n", uV);
+	return NOTIFY_OK;
+}
+
+#define RK3288_SOC_CON2			0x24c
+#define RK3288_SOC_CON2_FLASH0		BIT(7)
+#define RK3288_SOC_FLASH_SUPPLY_NUM	2
+
+static void rk3288_iodomain_init(struct rockchip_iodomain *iod)
+{
+	int ret;
+	u32 val;
+
+	/* if no flash supply we should leave things alone */
+	if (!iod->supplies[RK3288_SOC_FLASH_SUPPLY_NUM].reg)
+		return;
+
+	/*
+	 * set flash0 iodomain to also use this framework
+	 * instead of a special gpio.
+	 */
+	val = RK3288_SOC_CON2_FLASH0 | (RK3288_SOC_CON2_FLASH0 << 16);
+	ret = regmap_write(iod->grf, RK3288_SOC_CON2, val);
+	if (ret < 0)
+		dev_warn(iod->dev, "couldn't update flash0 ctrl\n");
+}
+
+/*
+ * On the rk3188 the io-domains are handled by a shared register with the
+ * lower 8 bits being still being continuing drive-strength settings.
+ */
+static const struct rockchip_iodomain_soc_data soc_data_rk3188 = {
+	.grf_offset = 0x104,
+	.supply_names = {
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		"ap0",
+		"ap1",
+		"cif",
+		"flash",
+		"vccio0",
+		"vccio1",
+		"lcdc0",
+		"lcdc1",
+	},
+};
+
+static const struct rockchip_iodomain_soc_data soc_data_rk3288 = {
+	.grf_offset = 0x380,
+	.supply_names = {
+		"lcdc",		/* LCDC_VDD */
+		"dvp",		/* DVPIO_VDD */
+		"flash0",	/* FLASH0_VDD (emmc) */
+		"flash1",	/* FLASH1_VDD (sdio1) */
+		"wifi",		/* APIO3_VDD  (sdio0) */
+		"bb",		/* APIO5_VDD */
+		"audio",	/* APIO4_VDD */
+		"sdcard",	/* SDMMC0_VDD (sdmmc) */
+		"gpio30",	/* APIO1_VDD */
+		"gpio1830",	/* APIO2_VDD */
+	},
+	.init = rk3288_iodomain_init,
+};
+
+static const struct of_device_id rockchip_iodomain_match[] = {
+	{
+		.compatible = "rockchip,rk3188-iodomain",
+		.data = (void *)&soc_data_rk3188
+	},
+	{
+		.compatible = "rockchip,rk3288-iodomain",
+		.data = (void *)&soc_data_rk3288
+	},
+	{ /* sentinel */ },
+};
+
+static int rockchip_iodomain_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match;
+	struct rockchip_iodomain *iod;
+	int i, ret;
+
+	if (!np)
+		return -ENODEV;
+
+	iod = devm_kzalloc(&pdev->dev, sizeof(*iod), GFP_KERNEL);
+	if (!iod)
+		return -ENOMEM;
+
+	iod->dev = &pdev->dev;
+	platform_set_drvdata(pdev, iod);
+
+	match = of_match_node(rockchip_iodomain_match, np);
+	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
+
+	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(iod->grf)) {
+		dev_err(&pdev->dev, "couldn't find grf regmap\n");
+		return PTR_ERR(iod->grf);
+	}
+
+	for (i = 0; i < MAX_SUPPLIES; i++) {
+		const char *supply_name = iod->soc_data->supply_names[i];
+		struct rockchip_iodomain_supply *supply = &iod->supplies[i];
+		struct regulator *reg;
+		int uV;
+
+		if (!supply_name)
+			continue;
+
+		reg = devm_regulator_get_optional(iod->dev, supply_name);
+		if (IS_ERR(reg)) {
+			ret = PTR_ERR(reg);
+
+			/* If a supply wasn't specified, that's OK */
+			if (ret == -ENODEV)
+				continue;
+			else if (ret != -EPROBE_DEFER)
+				dev_err(iod->dev, "couldn't get regulator %s\n",
+					supply_name);
+			goto unreg_notify;
+		}
+
+		/* set initial correct value */
+		uV = regulator_get_voltage(reg);
+
+		/* must be a regulator we can get the voltage of */
+		if (uV < 0) {
+			dev_err(iod->dev, "Can't determine voltage: %s\n",
+				supply_name);
+			goto unreg_notify;
+		}
+
+		if (uV > MAX_VOLTAGE_3_3) {
+			dev_crit(iod->dev,
+				 "%d uV is too high. May damage SoC!\n",
+				 uV);
+			ret = -EINVAL;
+			goto unreg_notify;
+		}
+
+		/* setup our supply */
+		supply->idx = i;
+		supply->iod = iod;
+		supply->reg = reg;
+		supply->nb.notifier_call = rockchip_iodomain_notify;
+
+		ret = rockchip_iodomain_write(supply, uV);
+		if (ret) {
+			supply->reg = NULL;
+			goto unreg_notify;
+		}
+
+		/* register regulator notifier */
+		ret = regulator_register_notifier(reg, &supply->nb);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"regulator notifier request failed\n");
+			supply->reg = NULL;
+			goto unreg_notify;
+		}
+	}
+
+	if (iod->soc_data->init)
+		iod->soc_data->init(iod);
+
+	return 0;
+
+unreg_notify:
+	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
+		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+
+		if (io_supply->reg)
+			regulator_unregister_notifier(io_supply->reg,
+						      &io_supply->nb);
+	}
+
+	return ret;
+}
+
+static int rockchip_iodomain_remove(struct platform_device *pdev)
+{
+	struct rockchip_iodomain *iod = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
+		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+
+		if (io_supply->reg)
+			regulator_unregister_notifier(io_supply->reg,
+						      &io_supply->nb);
+	}
+
+	return 0;
+}
+
+static struct platform_driver rockchip_iodomain_driver = {
+	.probe   = rockchip_iodomain_probe,
+	.remove  = rockchip_iodomain_remove,
+	.driver  = {
+		.name  = "rockchip-iodomain",
+		.of_match_table = rockchip_iodomain_match,
+	},
+};
+
+module_platform_driver(rockchip_iodomain_driver);
+
+MODULE_DESCRIPTION("Rockchip IO-domain driver");
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_AUTHOR("Doug Anderson <dianders@chromium.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.1.0.rc2.206.gedb03e5

[PATCH 2/2] soc/rockchip: io-domain: add driver handling io domains

[Doug Anderson]

From: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>

IO domain voltages on some Rockchip SoCs are variable but need to be
kept in sync between the regulators and a special register.

Signed-off-by: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 6 files changed, 406 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

diff --git a/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt b/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
new file mode 100644
index 0000000..20b4965
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
@@ -0,0 +1,60 @@
+Rockchip SRAM for IO Voltage Domains:
+-------------------------------------
+
+IO domain voltages on some Rockchip SoCs are variable but need to be
+kept in sync between the regulators and a special register.
+
+We can specify which regulator is associated with which IO Voltage
+Domain and then we can automatically adjust the register to match
+what's actually being provided on the rails.
+
+Required properties:
+- compatible: should be one of:
+  - "rockchip,rk3188-iodomain" for rk3188
+  - "rockchip,rk3288-iodomain" for rk3288
+
+You specify supplies using the standard regulator bindings by including
+a phandle the the relevant regulator.  All specified supplies must be able
+to report their voltage.  The IO Voltage Domain for any non-specified
+supplies will be not be touched.
+
+Possible supplies for rk3188:
+- ap0-supply:    The supply connected to AP0_VCC.
+- ap1-supply:    The supply connected to AP1_VCC.
+- cif-supply:    The supply connected to CIF_VCC.
+- flash-supply:  The supply connected to FLASH_VCC.
+- lcdc0-supply:  The supply connected to LCD0_VCC.
+- lcdc1-supply:  The supply connected to LCD1_VCC.
+- vccio0-supply: The supply connected to VCCIO0.
+- vccio1-supply: The supply connected to VCCIO1.
+                 Sometimes also labeled VCCIO1 and VCCIO2.
+
+Possible supplies for rk3288:
+- audio-supply:  The supply connected to APIO4_VDD.
+- bb-supply:     The supply connected to APIO5_VDD.
+- dvp-supply:    The supply connected to DVPIO_VDD.
+- flash0-supply: The supply connected to FLASH0_VDD.  Typically for eMMC
+- flash1-supply: The supply connected to FLASH1_VDD.  Also known as SDIO1.
+- gpio30-supply: The supply connected to APIO1_VDD.
+- gpio1830       The supply connected to APIO2_VDD.
+- lcdc-supply:   The supply connected to LCDC_VDD.
+- sdcard-supply: The supply connected to SDMMC0_VDD.
+- wifi-supply:   The supply connected to APIO3_VDD.  Also known as SDIO0.
+
+
+Example:
+
+	io-domains {
+		compatible = "rockchip,rk3288-iodomain";
+		rockchip,grf = <&grf>;
+
+		audio-supply = <&vcc18_codec>;
+		bb-supply = <&vcc33_io>;
+		dvp-supply = <&vcc_18>;
+		flash0-supply = <&vcc18_flashio>;
+		gpio1830-supply = <&vcc33_io>;
+		gpio30-supply = <&vcc33_pmuio>;
+		lcdc-supply = <&vcc33_lcd>;
+		sdcard-supply = <&vccio_sd>;
+		wifi-supply = <&vcc18_wl>;
+	};
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index c854385..443d946 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,6 @@
 menu "SOC (System On Chip) specific Drivers"
 
 source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/rockchip/Kconfig"
 
 endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 3b1b95d..52808bf 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,4 +3,5 @@
 #
 
 obj-$(CONFIG_ARCH_QCOM)		+= qcom/
+obj-$(CONFIG_ARCH_ROCKCHIP)	+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)	+= tegra/
diff --git a/drivers/soc/rockchip/Kconfig b/drivers/soc/rockchip/Kconfig
new file mode 100644
index 0000000..d25cb53
--- /dev/null
+++ b/drivers/soc/rockchip/Kconfig
@@ -0,0 +1,10 @@
+#
+# Rockchip Soc drivers
+#
+config ROCKCHIP_IODOMAIN
+        tristate "Rockchip IO domain support"
+        depends on ARCH_ROCKCHIP && OF
+        help
+          Say y here to enable support io domains on Rockchip SoCs. It is
+          necessary for the io domain setting of the SoC to match the
+          voltage supplied by the regulators.
diff --git a/drivers/soc/rockchip/Makefile b/drivers/soc/rockchip/Makefile
new file mode 100644
index 0000000..dbf6da9
--- /dev/null
+++ b/drivers/soc/rockchip/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ROCKCHIP_IODOMAIN)	+=	io-domain.o
diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
new file mode 100644
index 0000000..f4e0ebc
--- /dev/null
+++ b/drivers/soc/rockchip/io-domain.c
@@ -0,0 +1,333 @@
+/*
+ * Rockchip IO Voltage Domain driver
+ *
+ * Copyright 2014 MundoReader S.L.
+ * Copyright 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/err.h>
+#include <linux/mfd/syscon.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+
+#define MAX_SUPPLIES		16
+
+#define MAX_VOLTAGE_1_8		1980000
+#define MAX_VOLTAGE_3_3		3600000
+
+struct rockchip_iodomain;
+
+/**
+ * @supplies: voltage settings matching the register bits.
+ */
+struct rockchip_iodomain_soc_data {
+	int grf_offset;
+	const char *supply_names[MAX_SUPPLIES];
+	void (*init)(struct rockchip_iodomain *iod);
+};
+
+struct rockchip_iodomain_supply {
+	struct rockchip_iodomain *iod;
+	struct regulator *reg;
+	struct notifier_block nb;
+	int idx;
+};
+
+struct rockchip_iodomain {
+	struct device *dev;
+	struct regmap *grf;
+	struct rockchip_iodomain_soc_data *soc_data;
+	struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
+};
+
+static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
+				   int uV)
+{
+	struct rockchip_iodomain *iod = supply->iod;
+	u32 val;
+	int ret;
+
+	/* set value bit */
+	val = (uV > MAX_VOLTAGE_1_8) ? 0 : 1;
+	val <<= supply->idx;
+
+	/* apply hiword-mask */
+	val |= (BIT(supply->idx) << 16);
+
+	ret = regmap_write(iod->grf, iod->soc_data->grf_offset, val);
+	if (ret)
+		dev_err(iod->dev, "Couldn't write to GRF\n");
+
+	return ret;
+}
+
+static int rockchip_iodomain_notify(struct notifier_block *nb,
+				    unsigned long event,
+				    void *data)
+{
+	struct rockchip_iodomain_supply *supply =
+			container_of(nb, struct rockchip_iodomain_supply, nb);
+	int uV;
+	int ret;
+
+	/*
+	 * According to Rockchip it's important to keep the SoC IO domain
+	 * higher than (or equal to) the external voltage.  That means we need
+	 * to change it before external voltage changes happen in the case
+	 * of an increase.
+	 */
+	if (event & REGULATOR_EVENT_PRE_VOLTAGE_CHANGE) {
+		struct pre_voltage_change_data *pvc_data = data;
+
+		uV = max_t(unsigned long, pvc_data->old_uV, pvc_data->max_uV);
+	} else if (event & (REGULATOR_EVENT_VOLTAGE_CHANGE |
+			    REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE)) {
+		uV = (unsigned long)data;
+	} else {
+		return NOTIFY_OK;
+	}
+
+	dev_dbg(supply->iod->dev, "Setting to %d\n", uV);
+
+	if (uV > MAX_VOLTAGE_3_3) {
+		dev_err(supply->iod->dev, "Voltage too high: %d\n", uV);
+
+		if (event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
+			return NOTIFY_BAD;
+	}
+
+	ret = rockchip_iodomain_write(supply, uV);
+	if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
+		return NOTIFY_BAD;
+
+	dev_info(supply->iod->dev, "Setting to %d done\n", uV);
+	return NOTIFY_OK;
+}
+
+#define RK3288_SOC_CON2			0x24c
+#define RK3288_SOC_CON2_FLASH0		BIT(7)
+#define RK3288_SOC_FLASH_SUPPLY_NUM	2
+
+static void rk3288_iodomain_init(struct rockchip_iodomain *iod)
+{
+	int ret;
+	u32 val;
+
+	/* if no flash supply we should leave things alone */
+	if (!iod->supplies[RK3288_SOC_FLASH_SUPPLY_NUM].reg)
+		return;
+
+	/*
+	 * set flash0 iodomain to also use this framework
+	 * instead of a special gpio.
+	 */
+	val = RK3288_SOC_CON2_FLASH0 | (RK3288_SOC_CON2_FLASH0 << 16);
+	ret = regmap_write(iod->grf, RK3288_SOC_CON2, val);
+	if (ret < 0)
+		dev_warn(iod->dev, "couldn't update flash0 ctrl\n");
+}
+
+/*
+ * On the rk3188 the io-domains are handled by a shared register with the
+ * lower 8 bits being still being continuing drive-strength settings.
+ */
+static const struct rockchip_iodomain_soc_data soc_data_rk3188 = {
+	.grf_offset = 0x104,
+	.supply_names = {
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		NULL,
+		"ap0",
+		"ap1",
+		"cif",
+		"flash",
+		"vccio0",
+		"vccio1",
+		"lcdc0",
+		"lcdc1",
+	},
+};
+
+static const struct rockchip_iodomain_soc_data soc_data_rk3288 = {
+	.grf_offset = 0x380,
+	.supply_names = {
+		"lcdc",		/* LCDC_VDD */
+		"dvp",		/* DVPIO_VDD */
+		"flash0",	/* FLASH0_VDD (emmc) */
+		"flash1",	/* FLASH1_VDD (sdio1) */
+		"wifi",		/* APIO3_VDD  (sdio0) */
+		"bb",		/* APIO5_VDD */
+		"audio",	/* APIO4_VDD */
+		"sdcard",	/* SDMMC0_VDD (sdmmc) */
+		"gpio30",	/* APIO1_VDD */
+		"gpio1830",	/* APIO2_VDD */
+	},
+	.init = rk3288_iodomain_init,
+};
+
+static const struct of_device_id rockchip_iodomain_match[] = {
+	{
+		.compatible = "rockchip,rk3188-iodomain",
+		.data = (void *)&soc_data_rk3188
+	},
+	{
+		.compatible = "rockchip,rk3288-iodomain",
+		.data = (void *)&soc_data_rk3288
+	},
+	{ /* sentinel */ },
+};
+
+static int rockchip_iodomain_probe(struct platform_device *pdev)
+{
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match;
+	struct rockchip_iodomain *iod;
+	int i, ret;
+
+	if (!np)
+		return -ENODEV;
+
+	iod = devm_kzalloc(&pdev->dev, sizeof(*iod), GFP_KERNEL);
+	if (!iod)
+		return -ENOMEM;
+
+	iod->dev = &pdev->dev;
+	platform_set_drvdata(pdev, iod);
+
+	match = of_match_node(rockchip_iodomain_match, np);
+	iod->soc_data = (struct rockchip_iodomain_soc_data *)match->data;
+
+	iod->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
+	if (IS_ERR(iod->grf)) {
+		dev_err(&pdev->dev, "couldn't find grf regmap\n");
+		return PTR_ERR(iod->grf);
+	}
+
+	for (i = 0; i < MAX_SUPPLIES; i++) {
+		const char *supply_name = iod->soc_data->supply_names[i];
+		struct rockchip_iodomain_supply *supply = &iod->supplies[i];
+		struct regulator *reg;
+		int uV;
+
+		if (!supply_name)
+			continue;
+
+		reg = devm_regulator_get_optional(iod->dev, supply_name);
+		if (IS_ERR(reg)) {
+			ret = PTR_ERR(reg);
+
+			/* If a supply wasn't specified, that's OK */
+			if (ret == -ENODEV)
+				continue;
+			else if (ret != -EPROBE_DEFER)
+				dev_err(iod->dev, "couldn't get regulator %s\n",
+					supply_name);
+			goto unreg_notify;
+		}
+
+		/* set initial correct value */
+		uV = regulator_get_voltage(reg);
+
+		/* must be a regulator we can get the voltage of */
+		if (uV < 0) {
+			dev_err(iod->dev, "Can't determine voltage: %s\n",
+				supply_name);
+			goto unreg_notify;
+		}
+
+		if (uV > MAX_VOLTAGE_3_3) {
+			dev_crit(iod->dev,
+				 "%d uV is too high. May damage SoC!\n",
+				 uV);
+			ret = -EINVAL;
+			goto unreg_notify;
+		}
+
+		/* setup our supply */
+		supply->idx = i;
+		supply->iod = iod;
+		supply->reg = reg;
+		supply->nb.notifier_call = rockchip_iodomain_notify;
+
+		ret = rockchip_iodomain_write(supply, uV);
+		if (ret) {
+			supply->reg = NULL;
+			goto unreg_notify;
+		}
+
+		/* register regulator notifier */
+		ret = regulator_register_notifier(reg, &supply->nb);
+		if (ret) {
+			dev_err(&pdev->dev,
+				"regulator notifier request failed\n");
+			supply->reg = NULL;
+			goto unreg_notify;
+		}
+	}
+
+	if (iod->soc_data->init)
+		iod->soc_data->init(iod);
+
+	return 0;
+
+unreg_notify:
+	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
+		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+
+		if (io_supply->reg)
+			regulator_unregister_notifier(io_supply->reg,
+						      &io_supply->nb);
+	}
+
+	return ret;
+}
+
+static int rockchip_iodomain_remove(struct platform_device *pdev)
+{
+	struct rockchip_iodomain *iod = platform_get_drvdata(pdev);
+	int i;
+
+	for (i = MAX_SUPPLIES - 1; i >= 0; i--) {
+		struct rockchip_iodomain_supply *io_supply = &iod->supplies[i];
+
+		if (io_supply->reg)
+			regulator_unregister_notifier(io_supply->reg,
+						      &io_supply->nb);
+	}
+
+	return 0;
+}
+
+static struct platform_driver rockchip_iodomain_driver = {
+	.probe   = rockchip_iodomain_probe,
+	.remove  = rockchip_iodomain_remove,
+	.driver  = {
+		.name  = "rockchip-iodomain",
+		.of_match_table = rockchip_iodomain_match,
+	},
+};
+
+module_platform_driver(rockchip_iodomain_driver);
+
+MODULE_DESCRIPTION("Rockchip IO-domain driver");
+MODULE_AUTHOR("Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>");
+MODULE_AUTHOR("Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
-- 
2.1.0.rc2.206.gedb03e5

--
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

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Sat, Aug 30, 2014 at 1:27 PM, Heiko Stübner <heiko@sntech.de> wrote:
>> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>>
>>> <santosh.shilimkar@ti.com> wrote:
>>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>>> >> These two patches add support for automatically configuring the IO
>>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>>> >> new notification types to the regulator code.  It's used by the second
>>> >> patch which actually implements the IO voltage domain driver.
>>> >>
>>> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
>>> >> (proof of concept patches were written by Heiko).  They were tested in
>>> >> a private branch on an rk3288 board using rk808 instead of mainline
>>> >> since rk808 support isn't finalized in mainline yet.
>>> >>
>>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>>> >>
>>> >> Heiko Stübner (2):
>>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>> >>   soc/rockchip: io-domain: add driver handling io domains
>>> >
>>> > Sorry to shot down but your IO domains are nothing but voltage domains
>>> > and you should really build something in the drivers/power/*
>>>
>>> If everyone agrees that this belongs in drivers/power that's totally
>>> OK.  Neither Heiko nor I was confident that it should be in
>>> drivers/soc.  I had even though that the code wouldn't be totally out
>>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>>
>> a bit of context for Linus ...
>>
>> This is essentially the continuation of  the thread "io-domain voltages as
>> regulators?" from the beginning of august. After more discussions we found out
>> that the io voltage selection I asked about is not an independent supply, but
>> instead has to reflect the voltage of the real supplying regulator.
>>
>> And setting the io-voltage setting to 1.8V while the regulator is supplying
>> 3.3V for example may actually damage the chip.
>>
>>
>> So in our current approach here, we added a driver that tracks voltage changes
>> of the supplying regulator via a notifier and sets the register bits
>> accordingly.
>
> I feel I'm not smart enough for this. You need the PM people to look
> at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

I think the best fit for this is along with the Adaptive Voltage Scaling
(AVS) stuff we currently have in drivers/power/avs.  It's not exactly
adaptive in the same sense as the TI/SmartReflex is because there's no
hardware being configured to dynamically make micro-adjustments to the
regulators.  But, it is adaptive in the sense that there's SoC-specific
"stuff" to do right around the same time the voltage is scaled.

So I would suggest drivers/power/avs.

Kevin

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Sat, Aug 30, 2014 at 1:27 PM, Heiko Stübner <heiko@sntech.de> wrote:
>> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>>
>>> <santosh.shilimkar@ti.com> wrote:
>>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>>> >> These two patches add support for automatically configuring the IO
>>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>>> >> new notification types to the regulator code.  It's used by the second
>>> >> patch which actually implements the IO voltage domain driver.
>>> >>
>>> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
>>> >> (proof of concept patches were written by Heiko).  They were tested in
>>> >> a private branch on an rk3288 board using rk808 instead of mainline
>>> >> since rk808 support isn't finalized in mainline yet.
>>> >>
>>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>>> >>
>>> >> Heiko Stübner (2):
>>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>> >>   soc/rockchip: io-domain: add driver handling io domains
>>> >
>>> > Sorry to shot down but your IO domains are nothing but voltage domains
>>> > and you should really build something in the drivers/power/*
>>>
>>> If everyone agrees that this belongs in drivers/power that's totally
>>> OK.  Neither Heiko nor I was confident that it should be in
>>> drivers/soc.  I had even though that the code wouldn't be totally out
>>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>>
>> a bit of context for Linus ...
>>
>> This is essentially the continuation of  the thread "io-domain voltages as
>> regulators?" from the beginning of august. After more discussions we found out
>> that the io voltage selection I asked about is not an independent supply, but
>> instead has to reflect the voltage of the real supplying regulator.
>>
>> And setting the io-voltage setting to 1.8V while the regulator is supplying
>> 3.3V for example may actually damage the chip.
>>
>>
>> So in our current approach here, we added a driver that tracks voltage changes
>> of the supplying regulator via a notifier and sets the register bits
>> accordingly.
>
> I feel I'm not smart enough for this. You need the PM people to look
> at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

I think the best fit for this is along with the Adaptive Voltage Scaling
(AVS) stuff we currently have in drivers/power/avs.  It's not exactly
adaptive in the same sense as the TI/SmartReflex is because there's no
hardware being configured to dynamically make micro-adjustments to the
regulators.  But, it is adaptive in the sense that there's SoC-specific
"stuff" to do right around the same time the voltage is scaled.

So I would suggest drivers/power/avs.

Kevin

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Kevin Hilman]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Sat, Aug 30, 2014 at 1:27 PM, Heiko St?bner <heiko@sntech.de> wrote:
>> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>>
>>> <santosh.shilimkar@ti.com> wrote:
>>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>>> >> These two patches add support for automatically configuring the IO
>>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>>> >> new notification types to the regulator code.  It's used by the second
>>> >> patch which actually implements the IO voltage domain driver.
>>> >>
>>> >> These two patches were co-developed by Heiko St?bner and Doug Anderson
>>> >> (proof of concept patches were written by Heiko).  They were tested in
>>> >> a private branch on an rk3288 board using rk808 instead of mainline
>>> >> since rk808 support isn't finalized in mainline yet.
>>> >>
>>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>>> >>
>>> >> Heiko St?bner (2):
>>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>> >>   soc/rockchip: io-domain: add driver handling io domains
>>> >
>>> > Sorry to shot down but your IO domains are nothing but voltage domains
>>> > and you should really build something in the drivers/power/*
>>>
>>> If everyone agrees that this belongs in drivers/power that's totally
>>> OK.  Neither Heiko nor I was confident that it should be in
>>> drivers/soc.  I had even though that the code wouldn't be totally out
>>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>>
>> a bit of context for Linus ...
>>
>> This is essentially the continuation of  the thread "io-domain voltages as
>> regulators?" from the beginning of august. After more discussions we found out
>> that the io voltage selection I asked about is not an independent supply, but
>> instead has to reflect the voltage of the real supplying regulator.
>>
>> And setting the io-voltage setting to 1.8V while the regulator is supplying
>> 3.3V for example may actually damage the chip.
>>
>>
>> So in our current approach here, we added a driver that tracks voltage changes
>> of the supplying regulator via a notifier and sets the register bits
>> accordingly.
>
> I feel I'm not smart enough for this. You need the PM people to look
> at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

I think the best fit for this is along with the Adaptive Voltage Scaling
(AVS) stuff we currently have in drivers/power/avs.  It's not exactly
adaptive in the same sense as the TI/SmartReflex is because there's no
hardware being configured to dynamically make micro-adjustments to the
regulators.  But, it is adaptive in the sense that there's SoC-specific
"stuff" to do right around the same time the voltage is scaled.

So I would suggest drivers/power/avs.

Kevin

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Linus Walleij]

On Sat, Aug 30, 2014 at 1:27 PM, Heiko Stübner <heiko@sntech.de> wrote:
> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>
>> <santosh.shilimkar@ti.com> wrote:
>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> >> These two patches add support for automatically configuring the IO
>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> >> new notification types to the regulator code.  It's used by the second
>> >> patch which actually implements the IO voltage domain driver.
>> >>
>> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
>> >> (proof of concept patches were written by Heiko).  They were tested in
>> >> a private branch on an rk3288 board using rk808 instead of mainline
>> >> since rk808 support isn't finalized in mainline yet.
>> >>
>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>> >>
>> >> Heiko Stübner (2):
>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>> >>   soc/rockchip: io-domain: add driver handling io domains
>> >
>> > Sorry to shot down but your IO domains are nothing but voltage domains
>> > and you should really build something in the drivers/power/*
>>
>> If everyone agrees that this belongs in drivers/power that's totally
>> OK.  Neither Heiko nor I was confident that it should be in
>> drivers/soc.  I had even though that the code wouldn't be totally out
>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>
> a bit of context for Linus ...
>
> This is essentially the continuation of  the thread "io-domain voltages as
> regulators?" from the beginning of august. After more discussions we found out
> that the io voltage selection I asked about is not an independent supply, but
> instead has to reflect the voltage of the real supplying regulator.
>
> And setting the io-voltage setting to 1.8V while the regulator is supplying
> 3.3V for example may actually damage the chip.
>
>
> So in our current approach here, we added a driver that tracks voltage changes
> of the supplying regulator via a notifier and sets the register bits
> accordingly.

I feel I'm not smart enough for this. You need the PM people to look
at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

Since it is also MMC/SD UHS-related, Ulf should know better than
most what is needed, plus he's working on generic power domains
right now.

Yours,
Linus Walleij

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Linus Walleij]

On Sat, Aug 30, 2014 at 1:27 PM, Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org> wrote:
> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>
>> <santosh.shilimkar-l0cyMroinI0@public.gmane.org> wrote:
>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> >> These two patches add support for automatically configuring the IO
>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> >> new notification types to the regulator code.  It's used by the second
>> >> patch which actually implements the IO voltage domain driver.
>> >>
>> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
>> >> (proof of concept patches were written by Heiko).  They were tested in
>> >> a private branch on an rk3288 board using rk808 instead of mainline
>> >> since rk808 support isn't finalized in mainline yet.
>> >>
>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>> >>
>> >> Heiko Stübner (2):
>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>> >>   soc/rockchip: io-domain: add driver handling io domains
>> >
>> > Sorry to shot down but your IO domains are nothing but voltage domains
>> > and you should really build something in the drivers/power/*
>>
>> If everyone agrees that this belongs in drivers/power that's totally
>> OK.  Neither Heiko nor I was confident that it should be in
>> drivers/soc.  I had even though that the code wouldn't be totally out
>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>
> a bit of context for Linus ...
>
> This is essentially the continuation of  the thread "io-domain voltages as
> regulators?" from the beginning of august. After more discussions we found out
> that the io voltage selection I asked about is not an independent supply, but
> instead has to reflect the voltage of the real supplying regulator.
>
> And setting the io-voltage setting to 1.8V while the regulator is supplying
> 3.3V for example may actually damage the chip.
>
>
> So in our current approach here, we added a driver that tracks voltage changes
> of the supplying regulator via a notifier and sets the register bits
> accordingly.

I feel I'm not smart enough for this. You need the PM people to look
at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

Since it is also MMC/SD UHS-related, Ulf should know better than
most what is needed, plus he's working on generic power domains
right now.

Yours,
Linus Walleij
--
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

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Linus Walleij]

On Sat, Aug 30, 2014 at 1:27 PM, Heiko St?bner <heiko@sntech.de> wrote:
> Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
>> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
>>
>> <santosh.shilimkar@ti.com> wrote:
>> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> >> These two patches add support for automatically configuring the IO
>> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> >> new notification types to the regulator code.  It's used by the second
>> >> patch which actually implements the IO voltage domain driver.
>> >>
>> >> These two patches were co-developed by Heiko St?bner and Doug Anderson
>> >> (proof of concept patches were written by Heiko).  They were tested in
>> >> a private branch on an rk3288 board using rk808 instead of mainline
>> >> since rk808 support isn't finalized in mainline yet.
>> >>
>> >> (sorry if you got this series twice; my mailer seems unhappy with me)
>> >>
>> >> Heiko St?bner (2):
>> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>> >>   soc/rockchip: io-domain: add driver handling io domains
>> >
>> > Sorry to shot down but your IO domains are nothing but voltage domains
>> > and you should really build something in the drivers/power/*
>>
>> If everyone agrees that this belongs in drivers/power that's totally
>> OK.  Neither Heiko nor I was confident that it should be in
>> drivers/soc.  I had even though that the code wouldn't be totally out
>> of place in the Rockchip pinctrl driver (adding Linus W since I think
>> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).
>
> a bit of context for Linus ...
>
> This is essentially the continuation of  the thread "io-domain voltages as
> regulators?" from the beginning of august. After more discussions we found out
> that the io voltage selection I asked about is not an independent supply, but
> instead has to reflect the voltage of the real supplying regulator.
>
> And setting the io-voltage setting to 1.8V while the regulator is supplying
> 3.3V for example may actually damage the chip.
>
>
> So in our current approach here, we added a driver that tracks voltage changes
> of the supplying regulator via a notifier and sets the register bits
> accordingly.

I feel I'm not smart enough for this. You need the PM people to look
at this stuff, like Rafael Wysocki, Kevin Hilman and Ulf Hansson.

Since it is also MMC/SD UHS-related, Ulf should know better than
most what is needed, plus he's working on generic power domains
right now.

Yours,
Linus Walleij

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Heiko Stübner]

Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
> Santosh,
> 
> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
> 
> <santosh.shilimkar@ti.com> wrote:
> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> >> These two patches add support for automatically configuring the IO
> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> >> new notification types to the regulator code.  It's used by the second
> >> patch which actually implements the IO voltage domain driver.
> >> 
> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
> >> (proof of concept patches were written by Heiko).  They were tested in
> >> a private branch on an rk3288 board using rk808 instead of mainline
> >> since rk808 support isn't finalized in mainline yet.
> >> 
> >> (sorry if you got this series twice; my mailer seems unhappy with me)
> >> 
> >> Heiko Stübner (2):
> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
> >>   soc/rockchip: io-domain: add driver handling io domains
> > 
> > Sorry to shot down but your IO domains are nothing but voltage domains
> > and you should really build something in the drivers/power/*
> 
> If everyone agrees that this belongs in drivers/power that's totally
> OK.  Neither Heiko nor I was confident that it should be in
> drivers/soc.  I had even though that the code wouldn't be totally out
> of place in the Rockchip pinctrl driver (adding Linus W since I think
> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).

a bit of context for Linus ...

This is essentially the continuation of  the thread "io-domain voltages as 
regulators?" from the beginning of august. After more discussions we found out 
that the io voltage selection I asked about is not an independent supply, but 
instead has to reflect the voltage of the real supplying regulator.

And setting the io-voltage setting to 1.8V while the regulator is supplying 
3.3V for example may actually damage the chip.


So in our current approach here, we added a driver that tracks voltage changes  
of the supplying regulator via a notifier and sets the register bits 
accordingly.


> 
> > Please have a look at the RFC [1]. You should really go on those
> > lines and collaborate to make a generic voltage domain layer instead of
> > throwing the driver under drivers/soc.
> 
> Trying to base things on a 7-month old RFC that hasn't been touched is
> not something I'm going to do.  Maybe that makes me a bad person...
> 
> I would also say that I'm not convinced that we really need a
> complicated framework here.  Maybe when we're talking about things
> like ABB and DevFreq and the like then having a nice framework is a
> good idea.  Really here we're just setting properties associated with
> IO pins.  There's no decisions about latency, power tradeoffs, etc.
> If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
> connected to 3.3V we need to set the 3.3V bit.  The end.
> 
> The only remotely complicated thing (and why this isn't just a pinctrl
> property) is what happens with dynamic voltages.  SD Card IO lines can
> change voltage depending on UHS negotiation.  In that case the SD Card
> Driver will request that its regulator change from 3.3V to 1.8V.  The
> bit in the IO domain register needs to update in tandem.
> 
> 
> The driver is really quite tiny (333 lines).  If we find that lots of
> people copy it and they have code that's nearly the same then we
> should try to abstract things out then.
> 
> 
> I'd be interested in hearing other opinions, though.
> 
> -Doug

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Heiko Stübner]

Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
> Santosh,
> 
> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
> 
> <santosh.shilimkar-l0cyMroinI0@public.gmane.org> wrote:
> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> >> These two patches add support for automatically configuring the IO
> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> >> new notification types to the regulator code.  It's used by the second
> >> patch which actually implements the IO voltage domain driver.
> >> 
> >> These two patches were co-developed by Heiko Stübner and Doug Anderson
> >> (proof of concept patches were written by Heiko).  They were tested in
> >> a private branch on an rk3288 board using rk808 instead of mainline
> >> since rk808 support isn't finalized in mainline yet.
> >> 
> >> (sorry if you got this series twice; my mailer seems unhappy with me)
> >> 
> >> Heiko Stübner (2):
> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
> >>   soc/rockchip: io-domain: add driver handling io domains
> > 
> > Sorry to shot down but your IO domains are nothing but voltage domains
> > and you should really build something in the drivers/power/*
> 
> If everyone agrees that this belongs in drivers/power that's totally
> OK.  Neither Heiko nor I was confident that it should be in
> drivers/soc.  I had even though that the code wouldn't be totally out
> of place in the Rockchip pinctrl driver (adding Linus W since I think
> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).

a bit of context for Linus ...

This is essentially the continuation of  the thread "io-domain voltages as 
regulators?" from the beginning of august. After more discussions we found out 
that the io voltage selection I asked about is not an independent supply, but 
instead has to reflect the voltage of the real supplying regulator.

And setting the io-voltage setting to 1.8V while the regulator is supplying 
3.3V for example may actually damage the chip.


So in our current approach here, we added a driver that tracks voltage changes  
of the supplying regulator via a notifier and sets the register bits 
accordingly.


> 
> > Please have a look at the RFC [1]. You should really go on those
> > lines and collaborate to make a generic voltage domain layer instead of
> > throwing the driver under drivers/soc.
> 
> Trying to base things on a 7-month old RFC that hasn't been touched is
> not something I'm going to do.  Maybe that makes me a bad person...
> 
> I would also say that I'm not convinced that we really need a
> complicated framework here.  Maybe when we're talking about things
> like ABB and DevFreq and the like then having a nice framework is a
> good idea.  Really here we're just setting properties associated with
> IO pins.  There's no decisions about latency, power tradeoffs, etc.
> If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
> connected to 3.3V we need to set the 3.3V bit.  The end.
> 
> The only remotely complicated thing (and why this isn't just a pinctrl
> property) is what happens with dynamic voltages.  SD Card IO lines can
> change voltage depending on UHS negotiation.  In that case the SD Card
> Driver will request that its regulator change from 3.3V to 1.8V.  The
> bit in the IO domain register needs to update in tandem.
> 
> 
> The driver is really quite tiny (333 lines).  If we find that lots of
> people copy it and they have code that's nearly the same then we
> should try to abstract things out then.
> 
> 
> I'd be interested in hearing other opinions, though.
> 
> -Doug

--
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

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Heiko Stübner]

Am Freitag, 29. August 2014, 21:51:46 schrieb Doug Anderson:
> Santosh,
> 
> On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
> 
> <santosh.shilimkar@ti.com> wrote:
> > On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> >> These two patches add support for automatically configuring the IO
> >> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> >> new notification types to the regulator code.  It's used by the second
> >> patch which actually implements the IO voltage domain driver.
> >> 
> >> These two patches were co-developed by Heiko St?bner and Doug Anderson
> >> (proof of concept patches were written by Heiko).  They were tested in
> >> a private branch on an rk3288 board using rk808 instead of mainline
> >> since rk808 support isn't finalized in mainline yet.
> >> 
> >> (sorry if you got this series twice; my mailer seems unhappy with me)
> >> 
> >> Heiko St?bner (2):
> >>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
> >>   soc/rockchip: io-domain: add driver handling io domains
> > 
> > Sorry to shot down but your IO domains are nothing but voltage domains
> > and you should really build something in the drivers/power/*
> 
> If everyone agrees that this belongs in drivers/power that's totally
> OK.  Neither Heiko nor I was confident that it should be in
> drivers/soc.  I had even though that the code wouldn't be totally out
> of place in the Rockchip pinctrl driver (adding Linus W since I think
> some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).

a bit of context for Linus ...

This is essentially the continuation of  the thread "io-domain voltages as 
regulators?" from the beginning of august. After more discussions we found out 
that the io voltage selection I asked about is not an independent supply, but 
instead has to reflect the voltage of the real supplying regulator.

And setting the io-voltage setting to 1.8V while the regulator is supplying 
3.3V for example may actually damage the chip.


So in our current approach here, we added a driver that tracks voltage changes  
of the supplying regulator via a notifier and sets the register bits 
accordingly.


> 
> > Please have a look at the RFC [1]. You should really go on those
> > lines and collaborate to make a generic voltage domain layer instead of
> > throwing the driver under drivers/soc.
> 
> Trying to base things on a 7-month old RFC that hasn't been touched is
> not something I'm going to do.  Maybe that makes me a bad person...
> 
> I would also say that I'm not convinced that we really need a
> complicated framework here.  Maybe when we're talking about things
> like ABB and DevFreq and the like then having a nice framework is a
> good idea.  Really here we're just setting properties associated with
> IO pins.  There's no decisions about latency, power tradeoffs, etc.
> If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
> connected to 3.3V we need to set the 3.3V bit.  The end.
> 
> The only remotely complicated thing (and why this isn't just a pinctrl
> property) is what happens with dynamic voltages.  SD Card IO lines can
> change voltage depending on UHS negotiation.  In that case the SD Card
> Driver will request that its regulator change from 3.3V to 1.8V.  The
> bit in the IO domain register needs to update in tandem.
> 
> 
> The driver is really quite tiny (333 lines).  If we find that lots of
> people copy it and they have code that's nearly the same then we
> should try to abstract things out then.
> 
> 
> I'd be interested in hearing other opinions, though.
> 
> -Doug

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

Santosh,

On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> These two patches add support for automatically configuring the IO
>> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> new notification types to the regulator code.  It's used by the second
>> patch which actually implements the IO voltage domain driver.
>>
>> These two patches were co-developed by Heiko Stübner and Doug Anderson
>> (proof of concept patches were written by Heiko).  They were tested in
>> a private branch on an rk3288 board using rk808 instead of mainline
>> since rk808 support isn't finalized in mainline yet.
>>
>> (sorry if you got this series twice; my mailer seems unhappy with me)
>>
>> Heiko Stübner (2):
>>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>   soc/rockchip: io-domain: add driver handling io domains
>>
> Sorry to shot down but your IO domains are nothing but voltage domains
> and you should really build something in the drivers/power/*

If everyone agrees that this belongs in drivers/power that's totally
OK.  Neither Heiko nor I was confident that it should be in
drivers/soc.  I had even though that the code wouldn't be totally out
of place in the Rockchip pinctrl driver (adding Linus W since I think
some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).


> Please have a look at the RFC [1]. You should really go on those
> lines and collaborate to make a generic voltage domain layer instead of throwing
> the driver under drivers/soc.

Trying to base things on a 7-month old RFC that hasn't been touched is
not something I'm going to do.  Maybe that makes me a bad person...

I would also say that I'm not convinced that we really need a
complicated framework here.  Maybe when we're talking about things
like ABB and DevFreq and the like then having a nice framework is a
good idea.  Really here we're just setting properties associated with
IO pins.  There's no decisions about latency, power tradeoffs, etc.
If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
connected to 3.3V we need to set the 3.3V bit.  The end.

The only remotely complicated thing (and why this isn't just a pinctrl
property) is what happens with dynamic voltages.  SD Card IO lines can
change voltage depending on UHS negotiation.  In that case the SD Card
Driver will request that its regulator change from 3.3V to 1.8V.  The
bit in the IO domain register needs to update in tandem.


The driver is really quite tiny (333 lines).  If we find that lots of
people copy it and they have code that's nearly the same then we
should try to abstract things out then.


I'd be interested in hearing other opinions, though.

-Doug

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

Santosh,

On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> These two patches add support for automatically configuring the IO
>> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> new notification types to the regulator code.  It's used by the second
>> patch which actually implements the IO voltage domain driver.
>>
>> These two patches were co-developed by Heiko Stübner and Doug Anderson
>> (proof of concept patches were written by Heiko).  They were tested in
>> a private branch on an rk3288 board using rk808 instead of mainline
>> since rk808 support isn't finalized in mainline yet.
>>
>> (sorry if you got this series twice; my mailer seems unhappy with me)
>>
>> Heiko Stübner (2):
>>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>   soc/rockchip: io-domain: add driver handling io domains
>>
> Sorry to shot down but your IO domains are nothing but voltage domains
> and you should really build something in the drivers/power/*

If everyone agrees that this belongs in drivers/power that's totally
OK.  Neither Heiko nor I was confident that it should be in
drivers/soc.  I had even though that the code wouldn't be totally out
of place in the Rockchip pinctrl driver (adding Linus W since I think
some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).


> Please have a look at the RFC [1]. You should really go on those
> lines and collaborate to make a generic voltage domain layer instead of throwing
> the driver under drivers/soc.

Trying to base things on a 7-month old RFC that hasn't been touched is
not something I'm going to do.  Maybe that makes me a bad person...

I would also say that I'm not convinced that we really need a
complicated framework here.  Maybe when we're talking about things
like ABB and DevFreq and the like then having a nice framework is a
good idea.  Really here we're just setting properties associated with
IO pins.  There's no decisions about latency, power tradeoffs, etc.
If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
connected to 3.3V we need to set the 3.3V bit.  The end.

The only remotely complicated thing (and why this isn't just a pinctrl
property) is what happens with dynamic voltages.  SD Card IO lines can
change voltage depending on UHS negotiation.  In that case the SD Card
Driver will request that its regulator change from 3.3V to 1.8V.  The
bit in the IO domain register needs to update in tandem.


The driver is really quite tiny (333 lines).  If we find that lots of
people copy it and they have code that's nearly the same then we
should try to abstract things out then.


I'd be interested in hearing other opinions, though.

-Doug

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

Santosh,

On Thu, Aug 28, 2014 at 2:26 PM, Santosh Shilimkar
<santosh.shilimkar@ti.com> wrote:
> On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
>> These two patches add support for automatically configuring the IO
>> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
>> new notification types to the regulator code.  It's used by the second
>> patch which actually implements the IO voltage domain driver.
>>
>> These two patches were co-developed by Heiko St?bner and Doug Anderson
>> (proof of concept patches were written by Heiko).  They were tested in
>> a private branch on an rk3288 board using rk808 instead of mainline
>> since rk808 support isn't finalized in mainline yet.
>>
>> (sorry if you got this series twice; my mailer seems unhappy with me)
>>
>> Heiko St?bner (2):
>>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>>   soc/rockchip: io-domain: add driver handling io domains
>>
> Sorry to shot down but your IO domains are nothing but voltage domains
> and you should really build something in the drivers/power/*

If everyone agrees that this belongs in drivers/power that's totally
OK.  Neither Heiko nor I was confident that it should be in
drivers/soc.  I had even though that the code wouldn't be totally out
of place in the Rockchip pinctrl driver (adding Linus W since I think
some SoCs did add code to handle 3.3V vs. 1.8V in pinctrl).


> Please have a look at the RFC [1]. You should really go on those
> lines and collaborate to make a generic voltage domain layer instead of throwing
> the driver under drivers/soc.

Trying to base things on a 7-month old RFC that hasn't been touched is
not something I'm going to do.  Maybe that makes me a bad person...

I would also say that I'm not convinced that we really need a
complicated framework here.  Maybe when we're talking about things
like ABB and DevFreq and the like then having a nice framework is a
good idea.  Really here we're just setting properties associated with
IO pins.  There's no decisions about latency, power tradeoffs, etc.
If the pin is connected to 1.8V we need to set the 1.8V bit.  If it's
connected to 3.3V we need to set the 3.3V bit.  The end.

The only remotely complicated thing (and why this isn't just a pinctrl
property) is what happens with dynamic voltages.  SD Card IO lines can
change voltage depending on UHS negotiation.  In that case the SD Card
Driver will request that its regulator change from 3.3V to 1.8V.  The
bit in the IO domain register needs to update in tandem.


The driver is really quite tiny (333 lines).  If we find that lots of
people copy it and they have code that's nearly the same then we
should try to abstract things out then.


I'd be interested in hearing other opinions, though.

-Doug

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Santosh Shilimkar]

On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> These two patches add support for automatically configuring the IO
> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> new notification types to the regulator code.  It's used by the second
> patch which actually implements the IO voltage domain driver.
> 
> These two patches were co-developed by Heiko Stübner and Doug Anderson
> (proof of concept patches were written by Heiko).  They were tested in
> a private branch on an rk3288 board using rk808 instead of mainline
> since rk808 support isn't finalized in mainline yet.
> 
> (sorry if you got this series twice; my mailer seems unhappy with me)
> 
> Heiko Stübner (2):
>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>   soc/rockchip: io-domain: add driver handling io domains
> 
Sorry to shot down but your IO domains are nothing but voltage domains
and you should really build something in the drivers/power/*

Please have a look at the RFC [1]. You should really go on those
lines and collaborate to make a generic voltage domain layer instead of throwing
the driver under drivers/soc. 

>  .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
>  drivers/regulator/core.c                           |  63 +++-
>  drivers/soc/Kconfig                                |   1 +
>  drivers/soc/Makefile                               |   1 +
>  drivers/soc/rockchip/Kconfig                       |  10 +
>  drivers/soc/rockchip/Makefile                      |   1 +
>  drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
>  include/linux/regulator/consumer.h                 |  20 ++
>  8 files changed, 482 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
>  create mode 100644 drivers/soc/rockchip/Kconfig
>  create mode 100644 drivers/soc/rockchip/Makefile
>  create mode 100644 drivers/soc/rockchip/io-domain.c
> 

Regards,
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/233819.html

Re: [PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Santosh Shilimkar]

On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> These two patches add support for automatically configuring the IO
> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> new notification types to the regulator code.  It's used by the second
> patch which actually implements the IO voltage domain driver.
> 
> These two patches were co-developed by Heiko Stübner and Doug Anderson
> (proof of concept patches were written by Heiko).  They were tested in
> a private branch on an rk3288 board using rk808 instead of mainline
> since rk808 support isn't finalized in mainline yet.
> 
> (sorry if you got this series twice; my mailer seems unhappy with me)
> 
> Heiko Stübner (2):
>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>   soc/rockchip: io-domain: add driver handling io domains
> 
Sorry to shot down but your IO domains are nothing but voltage domains
and you should really build something in the drivers/power/*

Please have a look at the RFC [1]. You should really go on those
lines and collaborate to make a generic voltage domain layer instead of throwing
the driver under drivers/soc. 

>  .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
>  drivers/regulator/core.c                           |  63 +++-
>  drivers/soc/Kconfig                                |   1 +
>  drivers/soc/Makefile                               |   1 +
>  drivers/soc/rockchip/Kconfig                       |  10 +
>  drivers/soc/rockchip/Makefile                      |   1 +
>  drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
>  include/linux/regulator/consumer.h                 |  20 ++
>  8 files changed, 482 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
>  create mode 100644 drivers/soc/rockchip/Kconfig
>  create mode 100644 drivers/soc/rockchip/Makefile
>  create mode 100644 drivers/soc/rockchip/io-domain.c
> 

Regards,
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/233819.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Santosh Shilimkar]

On Thursday 28 August 2014 03:36 PM, Doug Anderson wrote:
> These two patches add support for automatically configuring the IO
> voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
> new notification types to the regulator code.  It's used by the second
> patch which actually implements the IO voltage domain driver.
> 
> These two patches were co-developed by Heiko St?bner and Doug Anderson
> (proof of concept patches were written by Heiko).  They were tested in
> a private branch on an rk3288 board using rk808 instead of mainline
> since rk808 support isn't finalized in mainline yet.
> 
> (sorry if you got this series twice; my mailer seems unhappy with me)
> 
> Heiko St?bner (2):
>   regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
>   soc/rockchip: io-domain: add driver handling io domains
> 
Sorry to shot down but your IO domains are nothing but voltage domains
and you should really build something in the drivers/power/*

Please have a look at the RFC [1]. You should really go on those
lines and collaborate to make a generic voltage domain layer instead of throwing
the driver under drivers/soc. 

>  .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
>  drivers/regulator/core.c                           |  63 +++-
>  drivers/soc/Kconfig                                |   1 +
>  drivers/soc/Makefile                               |   1 +
>  drivers/soc/rockchip/Kconfig                       |  10 +
>  drivers/soc/rockchip/Makefile                      |   1 +
>  drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
>  include/linux/regulator/consumer.h                 |  20 ++
>  8 files changed, 482 insertions(+), 7 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
>  create mode 100644 drivers/soc/rockchip/Kconfig
>  create mode 100644 drivers/soc/rockchip/Makefile
>  create mode 100644 drivers/soc/rockchip/io-domain.c
> 

Regards,
Santosh
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/233819.html

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

These two patches add support for automatically configuring the IO
voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
new notification types to the regulator code.  It's used by the second
patch which actually implements the IO voltage domain driver.

These two patches were co-developed by Heiko Stübner and Doug Anderson
(proof of concept patches were written by Heiko).  They were tested in
a private branch on an rk3288 board using rk808 instead of mainline
since rk808 support isn't finalized in mainline yet.

(sorry if you got this series twice; my mailer seems unhappy with me)

Heiko Stübner (2):
  regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
  soc/rockchip: io-domain: add driver handling io domains

 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/regulator/core.c                           |  63 +++-
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 include/linux/regulator/consumer.h                 |  20 ++
 8 files changed, 482 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

-- 
2.1.0.rc2.206.gedb03e5

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

These two patches add support for automatically configuring the IO
voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
new notification types to the regulator code.  It's used by the second
patch which actually implements the IO voltage domain driver.

These two patches were co-developed by Heiko Stübner and Doug Anderson
(proof of concept patches were written by Heiko).  They were tested in
a private branch on an rk3288 board using rk808 instead of mainline
since rk808 support isn't finalized in mainline yet.

(sorry if you got this series twice; my mailer seems unhappy with me)

Heiko Stübner (2):
  regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
  soc/rockchip: io-domain: add driver handling io domains

 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/regulator/core.c                           |  63 +++-
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 include/linux/regulator/consumer.h                 |  20 ++
 8 files changed, 482 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

-- 
2.1.0.rc2.206.gedb03e5

--
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

[PATCH 0/2] IO voltage domain support for rk3188 and rk3288

[Doug Anderson]

These two patches add support for automatically configuring the IO
voltage domains on rk3188 and rk3288 SoCs.  The first patch adds some
new notification types to the regulator code.  It's used by the second
patch which actually implements the IO voltage domain driver.

These two patches were co-developed by Heiko St?bner and Doug Anderson
(proof of concept patches were written by Heiko).  They were tested in
a private branch on an rk3288 board using rk808 instead of mainline
since rk808 support isn't finalized in mainline yet.

(sorry if you got this series twice; my mailer seems unhappy with me)

Heiko St?bner (2):
  regulator: core: Add REGULATOR_EVENT_PRE_VOLTAGE_CHANGE (and ABORT)
  soc/rockchip: io-domain: add driver handling io domains

 .../devicetree/bindings/arm/rockchip/io-domain.txt |  60 ++++
 drivers/regulator/core.c                           |  63 +++-
 drivers/soc/Kconfig                                |   1 +
 drivers/soc/Makefile                               |   1 +
 drivers/soc/rockchip/Kconfig                       |  10 +
 drivers/soc/rockchip/Makefile                      |   1 +
 drivers/soc/rockchip/io-domain.c                   | 333 +++++++++++++++++++++
 include/linux/regulator/consumer.h                 |  20 ++
 8 files changed, 482 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/rockchip/io-domain.txt
 create mode 100644 drivers/soc/rockchip/Kconfig
 create mode 100644 drivers/soc/rockchip/Makefile
 create mode 100644 drivers/soc/rockchip/io-domain.c

-- 
2.1.0.rc2.206.gedb03e5