[RFC v2 0/6] drivers: Boot Constraints core

[RFC v2 0/6] drivers: Boot Constraints core

[Viresh Kumar]

Hi Greg and others,

I am sending the V2 for this series after waiting for just 2 weeks
because this one presents a clearer picture on how is this going to get
used. V2 has gained updates for adding the constraints for platform and
AMBA devices created from DT.

Problem statement:

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up reconfiguring these resources to ranges
satisfying the current users (only device X) and that can make the LCD
screen unstable.

Of course we can have more complex cases where the same resource is
getting used by two devices while the kernel boots and the order in
which devices get probed wouldn't matter as the other device will surely
break then.


Proposed solution:

This patchset introduces the concept of boot-constraints, which are set
by the different parts of the kernel (on behalf of the bootloaders) and
the kernel will satisfy them until the time driver for such a device is
probed (successfully or unsuccessfully). Once the driver's probe()
routine is called, the driver core removes the constraints set for the
particular device. Only the power-supply constraint type is supported
for now.

This can be used across platforms working with DT, ACPI, etc and has no
dependency on those. The last two patches add support to set these
constraints automatically for the devices created via DT.

V1->V2:
- Add support for setting constraints for devices created from DT.
- Allow handling deferred devices earlier then late_init.
- Remove 'default y' line from kconfig.
- Drop '=" after boot_constraints_disable kernel param.
- Dropped the dummy testing patch now.

It is tested on ARM hikey ARM64 platform and compile testing is done for
X86 as well (without enabling boot constraints config option).

--
viresh

Viresh Kumar (6):
  drivers: Add boot constraints core
  drivers: boot_constraint: Add support for supply constraints
  drivers: boot_constraint: Add boot_constraints_disable kernel
    parameter
  drivers: boot_constraint: Add debugfs support
  drivers: boot_constraint: Add initial DT bindings
  drivers: boot_constraint: Add constraints for OF devices

 Documentation/admin-guide/kernel-parameters.txt    |   3 +
 .../devicetree/bindings/boot-constraints.txt       |  68 ++++
 drivers/base/Kconfig                               |  10 +
 drivers/base/Makefile                              |   4 +
 drivers/base/base.h                                |   1 +
 drivers/base/boot_constraint.c                     | 404 +++++++++++++++++++++
 drivers/base/boot_constraint_of.c                  | 122 +++++++
 drivers/base/dd.c                                  |  32 +-
 drivers/of/platform.c                              |   4 +
 include/linux/boot_constraint.h                    |  44 +++
 10 files changed, 685 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
 create mode 100644 drivers/base/boot_constraint.c
 create mode 100644 drivers/base/boot_constraint_of.c
 create mode 100644 include/linux/boot_constraint.h

-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 0/6] drivers: Boot Constraints core

[Viresh Kumar]

Hi Greg and others,

I am sending the V2 for this series after waiting for just 2 weeks
because this one presents a clearer picture on how is this going to get
used. V2 has gained updates for adding the constraints for platform and
AMBA devices created from DT.

Problem statement:

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up reconfiguring these resources to ranges
satisfying the current users (only device X) and that can make the LCD
screen unstable.

Of course we can have more complex cases where the same resource is
getting used by two devices while the kernel boots and the order in
which devices get probed wouldn't matter as the other device will surely
break then.


Proposed solution:

This patchset introduces the concept of boot-constraints, which are set
by the different parts of the kernel (on behalf of the bootloaders) and
the kernel will satisfy them until the time driver for such a device is
probed (successfully or unsuccessfully). Once the driver's probe()
routine is called, the driver core removes the constraints set for the
particular device. Only the power-supply constraint type is supported
for now.

This can be used across platforms working with DT, ACPI, etc and has no
dependency on those. The last two patches add support to set these
constraints automatically for the devices created via DT.

V1->V2:
- Add support for setting constraints for devices created from DT.
- Allow handling deferred devices earlier then late_init.
- Remove 'default y' line from kconfig.
- Drop '=" after boot_constraints_disable kernel param.
- Dropped the dummy testing patch now.

It is tested on ARM hikey ARM64 platform and compile testing is done for
X86 as well (without enabling boot constraints config option).

--
viresh

Viresh Kumar (6):
  drivers: Add boot constraints core
  drivers: boot_constraint: Add support for supply constraints
  drivers: boot_constraint: Add boot_constraints_disable kernel
    parameter
  drivers: boot_constraint: Add debugfs support
  drivers: boot_constraint: Add initial DT bindings
  drivers: boot_constraint: Add constraints for OF devices

 Documentation/admin-guide/kernel-parameters.txt    |   3 +
 .../devicetree/bindings/boot-constraints.txt       |  68 ++++
 drivers/base/Kconfig                               |  10 +
 drivers/base/Makefile                              |   4 +
 drivers/base/base.h                                |   1 +
 drivers/base/boot_constraint.c                     | 404 +++++++++++++++++++++
 drivers/base/boot_constraint_of.c                  | 122 +++++++
 drivers/base/dd.c                                  |  32 +-
 drivers/of/platform.c                              |   4 +
 include/linux/boot_constraint.h                    |  44 +++
 10 files changed, 685 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
 create mode 100644 drivers/base/boot_constraint.c
 create mode 100644 drivers/base/boot_constraint_of.c
 create mode 100644 include/linux/boot_constraint.h

-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 1/6] drivers: Add boot constraints core

[Viresh Kumar]

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up reconfiguring these resources to ranges
satisfying the current users (only device X) and that can make the LCD
screen unstable.

This patch introduces the concept of boot-constraints, which will be set
by the bootloaders and the kernel will satisfy them until the time
driver for such a device is probed (successfully or unsuccessfully).

The list of boot constraint types is empty for now, and will be added by
a later patch.

Only two routines are exposed by the boot constraints core for now:

- boot_constraint_add(): This will be called by parts of the kernel
  (before the device is probed) to set the constraints.

- boot_constraints_remove(): This is called only by the driver core
  after a device is probed successfully or unsuccessfully. Special
  handling is done here for deffered probing.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/Kconfig            |  10 ++
 drivers/base/Makefile           |   1 +
 drivers/base/boot_constraint.c  | 219 ++++++++++++++++++++++++++++++++++++++++
 drivers/base/dd.c               |  20 ++--
 include/linux/boot_constraint.h |  36 +++++++
 5 files changed, 279 insertions(+), 7 deletions(-)
 create mode 100644 drivers/base/boot_constraint.c
 create mode 100644 include/linux/boot_constraint.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d718ae4b907a..0cf7cdd3081e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -339,4 +339,14 @@ config CMA_ALIGNMENT
 
 endif
 
+config BOOT_CONSTRAINTS
+	bool "Boot constraints for devices"
+	help
+	  This enables boot constraints detection for devices. These constraints
+	  are (normally) set by the Bootloader and must be satisfied by the
+	  kernel until the relevant device driver is probed. Once the driver is
+	  probed, the constraint is dropped.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index f2816f6ff76a..6094b3b75184 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,6 +5,7 @@ obj-y			:= component.o core.o bus.o dd.o syscore.o \
 			   cpu.o firmware.o init.o map.o devres.o \
 			   attribute_container.o transport_class.o \
 			   topology.o container.o property.o cacheinfo.o
+obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint.o
 obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
new file mode 100644
index 000000000000..7dc7b6132765
--- /dev/null
+++ b/drivers/base/boot_constraint.c
@@ -0,0 +1,219 @@
+/*
+ * This takes care of boot time constraints, normally set by the Bootloader.
+ *
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#define pr_fmt(fmt) "Boot Constraints: " fmt
+
+#include <linux/boot_constraint.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+
+struct constraint {
+	struct constraint_dev *cdev;
+	struct list_head node;
+	enum boot_constraint_type type;
+	void (*free_resources)(void *data);
+	void *free_resources_data;
+
+	int (*add)(struct constraint *constraint, void *data);
+	void (*remove)(struct constraint *constraint);
+	void *private;
+};
+
+struct constraint_dev {
+	struct device *dev;
+	struct list_head node;
+	struct list_head constraints;
+};
+
+#define for_each_constraint(_constraint, _temp, _cdev)		\
+	list_for_each_entry_safe(_constraint, _temp, &_cdev->constraints, node)
+
+/* Global list of all constraint devices currently registered */
+static LIST_HEAD(constraint_devices);
+static DEFINE_MUTEX(constraint_devices_mutex);
+
+/* Forward declarations of constraints */
+
+
+/* Boot constraints core */
+
+static struct constraint_dev *constraint_device_find(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	list_for_each_entry(cdev, &constraint_devices, node) {
+		if (cdev->dev == dev)
+			return cdev;
+	}
+
+	return NULL;
+}
+
+static struct constraint_dev *constraint_device_allocate(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+	if (!cdev)
+		return ERR_PTR(-ENOMEM);
+
+	cdev->dev = dev;
+	INIT_LIST_HEAD(&cdev->node);
+	INIT_LIST_HEAD(&cdev->constraints);
+
+	list_add(&cdev->node, &constraint_devices);
+
+	return cdev;
+}
+
+static void constraint_device_free(struct constraint_dev *cdev)
+{
+	list_del(&cdev->node);
+	kfree(cdev);
+}
+
+static struct constraint_dev *constraint_device_get(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	cdev = constraint_device_find(dev);
+	if (cdev)
+		return cdev;
+
+	cdev = constraint_device_allocate(dev);
+	if (IS_ERR(cdev)) {
+		dev_err(dev, "Failed to add constraint dev (%ld)\n",
+			PTR_ERR(cdev));
+	}
+
+	return cdev;
+}
+
+static void constraint_device_put(struct constraint_dev *cdev)
+{
+	if (!list_empty(&cdev->constraints))
+		return;
+
+	constraint_device_free(cdev);
+}
+
+static struct constraint *constraint_allocate(struct constraint_dev *cdev,
+					      enum boot_constraint_type type)
+{
+	struct constraint *constraint;
+	int (*add)(struct constraint *constraint, void *data);
+	void (*remove)(struct constraint *constraint);
+
+	switch (type) {
+	default:
+		return ERR_PTR(-EINVAL);
+	}
+
+	constraint = kzalloc(sizeof(*constraint), GFP_KERNEL);
+	if (!constraint)
+		return ERR_PTR(-ENOMEM);
+
+	constraint->cdev = cdev;
+	constraint->type = type;
+	constraint->add = add;
+	constraint->remove = remove;
+	INIT_LIST_HEAD(&constraint->node);
+
+	list_add(&constraint->node, &cdev->constraints);
+
+	return constraint;
+}
+
+static void constraint_free(struct constraint *constraint)
+{
+	list_del(&constraint->node);
+	kfree(constraint);
+}
+
+int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
+			struct boot_constraint_info *info)
+{
+	struct constraint_dev *cdev;
+	struct constraint *constraint;
+	int ret;
+
+	mutex_lock(&constraint_devices_mutex);
+
+	/* Find or add the cdev type first */
+	cdev = constraint_device_get(dev);
+	if (IS_ERR(cdev)) {
+		ret = PTR_ERR(cdev);
+		goto unlock;
+	}
+
+	constraint = constraint_allocate(cdev, type);
+	if (IS_ERR(constraint)) {
+		dev_err(dev, "Failed to add constraint type: %d (%ld)\n", type,
+			PTR_ERR(constraint));
+		ret = PTR_ERR(constraint);
+		goto put_cdev;
+	}
+
+	constraint->free_resources = info->free_resources;
+	constraint->free_resources_data = info->free_resources_data;
+
+	/* Set constraint */
+	ret = constraint->add(constraint, info->constraint_info);
+	if (ret)
+		goto free_constraint;
+
+	dev_dbg(dev, "Added boot constraint-type (%d)\n", type);
+
+	mutex_unlock(&constraint_devices_mutex);
+
+	return 0;
+
+free_constraint:
+	constraint_free(constraint);
+put_cdev:
+	constraint_device_put(cdev);
+unlock:
+	mutex_unlock(&constraint_devices_mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(boot_constraint_add);
+
+static void constraint_remove(struct constraint *constraint)
+{
+	constraint->remove(constraint);
+
+	if (constraint->free_resources)
+		constraint->free_resources(constraint->free_resources_data);
+
+	constraint_free(constraint);
+}
+
+void boot_constraints_remove(struct device *dev)
+{
+	struct constraint_dev *cdev;
+	struct constraint *constraint, *temp;
+
+	mutex_lock(&constraint_devices_mutex);
+
+	cdev = constraint_device_find(dev);
+	if (!cdev)
+		goto unlock;
+
+	for_each_constraint(constraint, temp, cdev)
+		constraint_remove(constraint);
+
+	constraint_device_put(cdev);
+unlock:
+	mutex_unlock(&constraint_devices_mutex);
+}
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..4eb9d183d647 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -17,6 +17,7 @@
  * This file is released under the GPLv2
  */
 
+#include <linux/boot_constraint.h>
 #include <linux/device.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
@@ -381,15 +382,20 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	 */
 	devices_kset_move_last(dev);
 
-	if (dev->bus->probe) {
+	if (dev->bus->probe)
 		ret = dev->bus->probe(dev);
-		if (ret)
-			goto probe_failed;
-	} else if (drv->probe) {
+	else if (drv->probe)
 		ret = drv->probe(dev);
-		if (ret)
-			goto probe_failed;
-	}
+
+	/*
+	 * Remove boot constraints for both successful and unsuccessful probe(),
+	 * except for the case where EPROBE_DEFER is returned by probe().
+	 */
+	if (ret != -EPROBE_DEFER)
+		boot_constraints_remove(dev);
+
+	if (ret)
+		goto probe_failed;
 
 	if (test_remove) {
 		test_remove = false;
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
new file mode 100644
index 000000000000..99f268447f72
--- /dev/null
+++ b/include/linux/boot_constraint.h
@@ -0,0 +1,36 @@
+/*
+ * Boot constraints header.
+ *
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/err.h>
+#include <linux/types.h>
+
+struct device;
+
+enum boot_constraint_type {
+	BOOT_CONSTRAINT_NONE,
+};
+
+struct boot_constraint_info {
+	/* This will be called just before the constraint is removed */
+	void (*free_resources)(void *data);
+	void *free_resources_data;
+	void *constraint_info;
+};
+
+#ifdef CONFIG_BOOT_CONSTRAINTS
+int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
+			struct boot_constraint_info *info);
+void boot_constraints_remove(struct device *dev);
+#else
+static inline int boot_constraint_add(struct device *dev,
+				      enum boot_constraint_type type,
+				      struct boot_constraint_info *info)
+{ return -EINVAL; }
+static inline void boot_constraints_remove(struct device *dev) {}
+#endif
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 1/6] drivers: Add boot constraints core

[Viresh Kumar]

Some devices are powered ON by the bootloader before the bootloader
handovers control to Linux. It maybe important for those devices to keep
working until the time a Linux device driver probes the device and
reconfigure its resources.

A typical example of that can be the LCD controller, which is used by
the bootloaders to show image(s) while the platform is booting into
Linux.  The LCD controller can be using some resources, like clk,
regulators, etc, that are shared between several devices. These shared
resources should be configured to satisfy need of all the users.  If
another device's (X) driver gets probed before the LCD controller driver
in this case, then it may end up reconfiguring these resources to ranges
satisfying the current users (only device X) and that can make the LCD
screen unstable.

This patch introduces the concept of boot-constraints, which will be set
by the bootloaders and the kernel will satisfy them until the time
driver for such a device is probed (successfully or unsuccessfully).

The list of boot constraint types is empty for now, and will be added by
a later patch.

Only two routines are exposed by the boot constraints core for now:

- boot_constraint_add(): This will be called by parts of the kernel
  (before the device is probed) to set the constraints.

- boot_constraints_remove(): This is called only by the driver core
  after a device is probed successfully or unsuccessfully. Special
  handling is done here for deffered probing.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/Kconfig            |  10 ++
 drivers/base/Makefile           |   1 +
 drivers/base/boot_constraint.c  | 219 ++++++++++++++++++++++++++++++++++++++++
 drivers/base/dd.c               |  20 ++--
 include/linux/boot_constraint.h |  36 +++++++
 5 files changed, 279 insertions(+), 7 deletions(-)
 create mode 100644 drivers/base/boot_constraint.c
 create mode 100644 include/linux/boot_constraint.h

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index d718ae4b907a..0cf7cdd3081e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -339,4 +339,14 @@ config CMA_ALIGNMENT
 
 endif
 
+config BOOT_CONSTRAINTS
+	bool "Boot constraints for devices"
+	help
+	  This enables boot constraints detection for devices. These constraints
+	  are (normally) set by the Bootloader and must be satisfied by the
+	  kernel until the relevant device driver is probed. Once the driver is
+	  probed, the constraint is dropped.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index f2816f6ff76a..6094b3b75184 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,6 +5,7 @@ obj-y			:= component.o core.o bus.o dd.o syscore.o \
 			   cpu.o firmware.o init.o map.o devres.o \
 			   attribute_container.o transport_class.o \
 			   topology.o container.o property.o cacheinfo.o
+obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint.o
 obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
new file mode 100644
index 000000000000..7dc7b6132765
--- /dev/null
+++ b/drivers/base/boot_constraint.c
@@ -0,0 +1,219 @@
+/*
+ * This takes care of boot time constraints, normally set by the Bootloader.
+ *
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#define pr_fmt(fmt) "Boot Constraints: " fmt
+
+#include <linux/boot_constraint.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/export.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/slab.h>
+
+struct constraint {
+	struct constraint_dev *cdev;
+	struct list_head node;
+	enum boot_constraint_type type;
+	void (*free_resources)(void *data);
+	void *free_resources_data;
+
+	int (*add)(struct constraint *constraint, void *data);
+	void (*remove)(struct constraint *constraint);
+	void *private;
+};
+
+struct constraint_dev {
+	struct device *dev;
+	struct list_head node;
+	struct list_head constraints;
+};
+
+#define for_each_constraint(_constraint, _temp, _cdev)		\
+	list_for_each_entry_safe(_constraint, _temp, &_cdev->constraints, node)
+
+/* Global list of all constraint devices currently registered */
+static LIST_HEAD(constraint_devices);
+static DEFINE_MUTEX(constraint_devices_mutex);
+
+/* Forward declarations of constraints */
+
+
+/* Boot constraints core */
+
+static struct constraint_dev *constraint_device_find(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	list_for_each_entry(cdev, &constraint_devices, node) {
+		if (cdev->dev == dev)
+			return cdev;
+	}
+
+	return NULL;
+}
+
+static struct constraint_dev *constraint_device_allocate(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+	if (!cdev)
+		return ERR_PTR(-ENOMEM);
+
+	cdev->dev = dev;
+	INIT_LIST_HEAD(&cdev->node);
+	INIT_LIST_HEAD(&cdev->constraints);
+
+	list_add(&cdev->node, &constraint_devices);
+
+	return cdev;
+}
+
+static void constraint_device_free(struct constraint_dev *cdev)
+{
+	list_del(&cdev->node);
+	kfree(cdev);
+}
+
+static struct constraint_dev *constraint_device_get(struct device *dev)
+{
+	struct constraint_dev *cdev;
+
+	cdev = constraint_device_find(dev);
+	if (cdev)
+		return cdev;
+
+	cdev = constraint_device_allocate(dev);
+	if (IS_ERR(cdev)) {
+		dev_err(dev, "Failed to add constraint dev (%ld)\n",
+			PTR_ERR(cdev));
+	}
+
+	return cdev;
+}
+
+static void constraint_device_put(struct constraint_dev *cdev)
+{
+	if (!list_empty(&cdev->constraints))
+		return;
+
+	constraint_device_free(cdev);
+}
+
+static struct constraint *constraint_allocate(struct constraint_dev *cdev,
+					      enum boot_constraint_type type)
+{
+	struct constraint *constraint;
+	int (*add)(struct constraint *constraint, void *data);
+	void (*remove)(struct constraint *constraint);
+
+	switch (type) {
+	default:
+		return ERR_PTR(-EINVAL);
+	}
+
+	constraint = kzalloc(sizeof(*constraint), GFP_KERNEL);
+	if (!constraint)
+		return ERR_PTR(-ENOMEM);
+
+	constraint->cdev = cdev;
+	constraint->type = type;
+	constraint->add = add;
+	constraint->remove = remove;
+	INIT_LIST_HEAD(&constraint->node);
+
+	list_add(&constraint->node, &cdev->constraints);
+
+	return constraint;
+}
+
+static void constraint_free(struct constraint *constraint)
+{
+	list_del(&constraint->node);
+	kfree(constraint);
+}
+
+int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
+			struct boot_constraint_info *info)
+{
+	struct constraint_dev *cdev;
+	struct constraint *constraint;
+	int ret;
+
+	mutex_lock(&constraint_devices_mutex);
+
+	/* Find or add the cdev type first */
+	cdev = constraint_device_get(dev);
+	if (IS_ERR(cdev)) {
+		ret = PTR_ERR(cdev);
+		goto unlock;
+	}
+
+	constraint = constraint_allocate(cdev, type);
+	if (IS_ERR(constraint)) {
+		dev_err(dev, "Failed to add constraint type: %d (%ld)\n", type,
+			PTR_ERR(constraint));
+		ret = PTR_ERR(constraint);
+		goto put_cdev;
+	}
+
+	constraint->free_resources = info->free_resources;
+	constraint->free_resources_data = info->free_resources_data;
+
+	/* Set constraint */
+	ret = constraint->add(constraint, info->constraint_info);
+	if (ret)
+		goto free_constraint;
+
+	dev_dbg(dev, "Added boot constraint-type (%d)\n", type);
+
+	mutex_unlock(&constraint_devices_mutex);
+
+	return 0;
+
+free_constraint:
+	constraint_free(constraint);
+put_cdev:
+	constraint_device_put(cdev);
+unlock:
+	mutex_unlock(&constraint_devices_mutex);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(boot_constraint_add);
+
+static void constraint_remove(struct constraint *constraint)
+{
+	constraint->remove(constraint);
+
+	if (constraint->free_resources)
+		constraint->free_resources(constraint->free_resources_data);
+
+	constraint_free(constraint);
+}
+
+void boot_constraints_remove(struct device *dev)
+{
+	struct constraint_dev *cdev;
+	struct constraint *constraint, *temp;
+
+	mutex_lock(&constraint_devices_mutex);
+
+	cdev = constraint_device_find(dev);
+	if (!cdev)
+		goto unlock;
+
+	for_each_constraint(constraint, temp, cdev)
+		constraint_remove(constraint);
+
+	constraint_device_put(cdev);
+unlock:
+	mutex_unlock(&constraint_devices_mutex);
+}
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..4eb9d183d647 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -17,6 +17,7 @@
  * This file is released under the GPLv2
  */
 
+#include <linux/boot_constraint.h>
 #include <linux/device.h>
 #include <linux/delay.h>
 #include <linux/dma-mapping.h>
@@ -381,15 +382,20 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	 */
 	devices_kset_move_last(dev);
 
-	if (dev->bus->probe) {
+	if (dev->bus->probe)
 		ret = dev->bus->probe(dev);
-		if (ret)
-			goto probe_failed;
-	} else if (drv->probe) {
+	else if (drv->probe)
 		ret = drv->probe(dev);
-		if (ret)
-			goto probe_failed;
-	}
+
+	/*
+	 * Remove boot constraints for both successful and unsuccessful probe(),
+	 * except for the case where EPROBE_DEFER is returned by probe().
+	 */
+	if (ret != -EPROBE_DEFER)
+		boot_constraints_remove(dev);
+
+	if (ret)
+		goto probe_failed;
 
 	if (test_remove) {
 		test_remove = false;
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
new file mode 100644
index 000000000000..99f268447f72
--- /dev/null
+++ b/include/linux/boot_constraint.h
@@ -0,0 +1,36 @@
+/*
+ * Boot constraints header.
+ *
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2
+ */
+
+#include <linux/err.h>
+#include <linux/types.h>
+
+struct device;
+
+enum boot_constraint_type {
+	BOOT_CONSTRAINT_NONE,
+};
+
+struct boot_constraint_info {
+	/* This will be called just before the constraint is removed */
+	void (*free_resources)(void *data);
+	void *free_resources_data;
+	void *constraint_info;
+};
+
+#ifdef CONFIG_BOOT_CONSTRAINTS
+int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
+			struct boot_constraint_info *info);
+void boot_constraints_remove(struct device *dev);
+#else
+static inline int boot_constraint_add(struct device *dev,
+				      enum boot_constraint_type type,
+				      struct boot_constraint_info *info)
+{ return -EINVAL; }
+static inline void boot_constraints_remove(struct device *dev) {}
+#endif
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 2/6] drivers: boot_constraint: Add support for supply constraints

[Viresh Kumar]

This patch adds the first constraint type: power-supply.

The constraint is set by setting a voltage range for the respective
regulator device, which will be honored by the regulator core even if
more users turn up. Once the device is probed, the regulator is
released and the constraint is removed.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/boot_constraint.c  | 88 +++++++++++++++++++++++++++++++++++++++++
 include/linux/boot_constraint.h |  8 +++-
 2 files changed, 95 insertions(+), 1 deletion(-)

diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 7dc7b6132765..4e4332751c5f 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -15,6 +15,7 @@
 #include <linux/export.h>
 #include <linux/list.h>
 #include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
 struct constraint {
@@ -43,6 +44,8 @@ static LIST_HEAD(constraint_devices);
 static DEFINE_MUTEX(constraint_devices_mutex);
 
 /* Forward declarations of constraints */
+static int constraint_supply_add(struct constraint *constraint, void *data);
+static void constraint_supply_remove(struct constraint *constraint);
 
 
 /* Boot constraints core */
@@ -115,6 +118,10 @@ static struct constraint *constraint_allocate(struct constraint_dev *cdev,
 	void (*remove)(struct constraint *constraint);
 
 	switch (type) {
+	case BOOT_CONSTRAINT_SUPPLY:
+		add = constraint_supply_add;
+		remove = constraint_supply_remove;
+		break;
 	default:
 		return ERR_PTR(-EINVAL);
 	}
@@ -217,3 +224,84 @@ void boot_constraints_remove(struct device *dev)
 unlock:
 	mutex_unlock(&constraint_devices_mutex);
 }
+
+
+/* Boot constraints */
+
+/* Boot constraint - Supply */
+
+struct constraint_supply {
+	struct boot_constraint_supply_info supply;
+	struct regulator *reg;
+};
+
+static int constraint_supply_add(struct constraint *constraint, void *data)
+{
+	struct boot_constraint_supply_info *supply = data;
+	struct constraint_supply *csupply;
+	struct device *dev = constraint->cdev->dev;
+	int ret;
+
+	csupply = kzalloc(sizeof(*csupply), GFP_KERNEL);
+	if (!csupply)
+		return -ENOMEM;
+
+	csupply->reg = regulator_get(dev, supply->name);
+	if (IS_ERR(csupply->reg)) {
+		ret = PTR_ERR(csupply->reg);
+		if (ret != -EPROBE_DEFER) {
+			dev_err(dev, "regulator_get() failed for %s (%d)\n",
+				supply->name, ret);
+		}
+		goto free;
+	}
+
+	ret = regulator_set_voltage(csupply->reg, supply->u_volt_min,
+				    supply->u_volt_max);
+	if (ret) {
+		dev_err(dev, "regulator_set_voltage %s failed (%d)\n",
+			supply->name, ret);
+		goto free_regulator;
+	}
+
+	ret = regulator_enable(csupply->reg);
+	if (ret) {
+		dev_err(dev, "regulator_enable %s failed (%d)\n",
+			supply->name, ret);
+		goto remove_voltage;
+	}
+
+	memcpy(&csupply->supply, supply, sizeof(*supply));
+	csupply->supply.name = kstrdup_const(supply->name, GFP_KERNEL);
+	constraint->private = csupply;
+
+	return 0;
+
+remove_voltage:
+	regulator_set_voltage(csupply->reg, 0, INT_MAX);
+free_regulator:
+	regulator_put(csupply->reg);
+free:
+	kfree(csupply);
+
+	return ret;
+}
+
+static void constraint_supply_remove(struct constraint *constraint)
+{
+	struct constraint_supply *csupply = constraint->private;
+	struct device *dev = constraint->cdev->dev;
+	int ret;
+
+	ret = regulator_disable(csupply->reg);
+	if (ret)
+		dev_err(dev, "regulator_disable failed (%d)\n", ret);
+
+	ret = regulator_set_voltage(csupply->reg, 0, INT_MAX);
+	if (ret)
+		dev_err(dev, "regulator_set_voltage failed (%d)\n", ret);
+
+	regulator_put(csupply->reg);
+	kfree_const(csupply->supply.name);
+	kfree(csupply);
+}
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
index 99f268447f72..110e5eca36c6 100644
--- a/include/linux/boot_constraint.h
+++ b/include/linux/boot_constraint.h
@@ -13,7 +13,13 @@
 struct device;
 
 enum boot_constraint_type {
-	BOOT_CONSTRAINT_NONE,
+	BOOT_CONSTRAINT_SUPPLY,
+};
+
+struct boot_constraint_supply_info {
+	const char *name;
+	unsigned int u_volt_min;
+	unsigned int u_volt_max;
 };
 
 struct boot_constraint_info {
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 2/6] drivers: boot_constraint: Add support for supply constraints

[Viresh Kumar]

This patch adds the first constraint type: power-supply.

The constraint is set by setting a voltage range for the respective
regulator device, which will be honored by the regulator core even if
more users turn up. Once the device is probed, the regulator is
released and the constraint is removed.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/boot_constraint.c  | 88 +++++++++++++++++++++++++++++++++++++++++
 include/linux/boot_constraint.h |  8 +++-
 2 files changed, 95 insertions(+), 1 deletion(-)

diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 7dc7b6132765..4e4332751c5f 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -15,6 +15,7 @@
 #include <linux/export.h>
 #include <linux/list.h>
 #include <linux/mutex.h>
+#include <linux/regulator/consumer.h>
 #include <linux/slab.h>
 
 struct constraint {
@@ -43,6 +44,8 @@ static LIST_HEAD(constraint_devices);
 static DEFINE_MUTEX(constraint_devices_mutex);
 
 /* Forward declarations of constraints */
+static int constraint_supply_add(struct constraint *constraint, void *data);
+static void constraint_supply_remove(struct constraint *constraint);
 
 
 /* Boot constraints core */
@@ -115,6 +118,10 @@ static struct constraint *constraint_allocate(struct constraint_dev *cdev,
 	void (*remove)(struct constraint *constraint);
 
 	switch (type) {
+	case BOOT_CONSTRAINT_SUPPLY:
+		add = constraint_supply_add;
+		remove = constraint_supply_remove;
+		break;
 	default:
 		return ERR_PTR(-EINVAL);
 	}
@@ -217,3 +224,84 @@ void boot_constraints_remove(struct device *dev)
 unlock:
 	mutex_unlock(&constraint_devices_mutex);
 }
+
+
+/* Boot constraints */
+
+/* Boot constraint - Supply */
+
+struct constraint_supply {
+	struct boot_constraint_supply_info supply;
+	struct regulator *reg;
+};
+
+static int constraint_supply_add(struct constraint *constraint, void *data)
+{
+	struct boot_constraint_supply_info *supply = data;
+	struct constraint_supply *csupply;
+	struct device *dev = constraint->cdev->dev;
+	int ret;
+
+	csupply = kzalloc(sizeof(*csupply), GFP_KERNEL);
+	if (!csupply)
+		return -ENOMEM;
+
+	csupply->reg = regulator_get(dev, supply->name);
+	if (IS_ERR(csupply->reg)) {
+		ret = PTR_ERR(csupply->reg);
+		if (ret != -EPROBE_DEFER) {
+			dev_err(dev, "regulator_get() failed for %s (%d)\n",
+				supply->name, ret);
+		}
+		goto free;
+	}
+
+	ret = regulator_set_voltage(csupply->reg, supply->u_volt_min,
+				    supply->u_volt_max);
+	if (ret) {
+		dev_err(dev, "regulator_set_voltage %s failed (%d)\n",
+			supply->name, ret);
+		goto free_regulator;
+	}
+
+	ret = regulator_enable(csupply->reg);
+	if (ret) {
+		dev_err(dev, "regulator_enable %s failed (%d)\n",
+			supply->name, ret);
+		goto remove_voltage;
+	}
+
+	memcpy(&csupply->supply, supply, sizeof(*supply));
+	csupply->supply.name = kstrdup_const(supply->name, GFP_KERNEL);
+	constraint->private = csupply;
+
+	return 0;
+
+remove_voltage:
+	regulator_set_voltage(csupply->reg, 0, INT_MAX);
+free_regulator:
+	regulator_put(csupply->reg);
+free:
+	kfree(csupply);
+
+	return ret;
+}
+
+static void constraint_supply_remove(struct constraint *constraint)
+{
+	struct constraint_supply *csupply = constraint->private;
+	struct device *dev = constraint->cdev->dev;
+	int ret;
+
+	ret = regulator_disable(csupply->reg);
+	if (ret)
+		dev_err(dev, "regulator_disable failed (%d)\n", ret);
+
+	ret = regulator_set_voltage(csupply->reg, 0, INT_MAX);
+	if (ret)
+		dev_err(dev, "regulator_set_voltage failed (%d)\n", ret);
+
+	regulator_put(csupply->reg);
+	kfree_const(csupply->supply.name);
+	kfree(csupply);
+}
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
index 99f268447f72..110e5eca36c6 100644
--- a/include/linux/boot_constraint.h
+++ b/include/linux/boot_constraint.h
@@ -13,7 +13,13 @@
 struct device;
 
 enum boot_constraint_type {
-	BOOT_CONSTRAINT_NONE,
+	BOOT_CONSTRAINT_SUPPLY,
+};
+
+struct boot_constraint_supply_info {
+	const char *name;
+	unsigned int u_volt_min;
+	unsigned int u_volt_max;
 };
 
 struct boot_constraint_info {
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 3/6] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constraint.

We can also think about finer control of such constraints with help of
some sysfs files, but a kernel parameter is fine to begin with.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/base/boot_constraint.c                  | 17 +++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7737ab5d04b2..59ad24822d10 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -426,6 +426,9 @@
 			embedded devices based on command line input.
 			See Documentation/block/cmdline-partition.txt
 
+	boot_constraints_disable
+			Do not set any boot constraints for devices.
+
 	boot_delay=	Milliseconds to delay each printk during boot.
 			Values larger than 10 seconds (10000) are changed to
 			no delay (0).
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 4e4332751c5f..d372ddfe1264 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -47,6 +47,17 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
+static bool boot_constraints_disabled;
+
+static int __init constraints_disable(char *str)
+{
+	boot_constraints_disabled = true;
+	pr_debug("disabled\n");
+
+	return 0;
+}
+early_param("boot_constraints_disable", constraints_disable);
+
 
 /* Boot constraints core */
 
@@ -154,6 +165,9 @@ int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
 	struct constraint *constraint;
 	int ret;
 
+	if (boot_constraints_disabled)
+		return -ENODEV;
+
 	mutex_lock(&constraint_devices_mutex);
 
 	/* Find or add the cdev type first */
@@ -211,6 +225,9 @@ void boot_constraints_remove(struct device *dev)
 	struct constraint_dev *cdev;
 	struct constraint *constraint, *temp;
 
+	if (boot_constraints_disabled)
+		return;
+
 	mutex_lock(&constraint_devices_mutex);
 
 	cdev = constraint_device_find(dev);
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 3/6] drivers: boot_constraint: Add boot_constraints_disable kernel parameter

[Viresh Kumar]

Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constraint.

We can also think about finer control of such constraints with help of
some sysfs files, but a kernel parameter is fine to begin with.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  3 +++
 drivers/base/boot_constraint.c                  | 17 +++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 7737ab5d04b2..59ad24822d10 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -426,6 +426,9 @@
 			embedded devices based on command line input.
 			See Documentation/block/cmdline-partition.txt
 
+	boot_constraints_disable
+			Do not set any boot constraints for devices.
+
 	boot_delay=	Milliseconds to delay each printk during boot.
 			Values larger than 10 seconds (10000) are changed to
 			no delay (0).
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 4e4332751c5f..d372ddfe1264 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -47,6 +47,17 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
+static bool boot_constraints_disabled;
+
+static int __init constraints_disable(char *str)
+{
+	boot_constraints_disabled = true;
+	pr_debug("disabled\n");
+
+	return 0;
+}
+early_param("boot_constraints_disable", constraints_disable);
+
 
 /* Boot constraints core */
 
@@ -154,6 +165,9 @@ int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
 	struct constraint *constraint;
 	int ret;
 
+	if (boot_constraints_disabled)
+		return -ENODEV;
+
 	mutex_lock(&constraint_devices_mutex);
 
 	/* Find or add the cdev type first */
@@ -211,6 +225,9 @@ void boot_constraints_remove(struct device *dev)
 	struct constraint_dev *cdev;
 	struct constraint *constraint, *temp;
 
+	if (boot_constraints_disabled)
+		return;
+
 	mutex_lock(&constraint_devices_mutex);
 
 	cdev = constraint_device_find(dev);
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 4/6] drivers: boot_constraint: Add debugfs support

[Viresh Kumar]

This patch adds debugfs support for boot constraints. This is how it
looks for a "vmmc-supply" constraint for the MMC device.

$ ls -R /sys/kernel/debug/boot_constraints/
/sys/kernel/debug/boot_constraints/:
f723d000.dwmmc0

/sys/kernel/debug/boot_constraints/f723d000.dwmmc0:
supply-vmmc

/sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmc:
u_volt_max  u_volt_min

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/boot_constraint.c | 80 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index d372ddfe1264..4e3b5e1aec7c 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -10,6 +10,7 @@
 #define pr_fmt(fmt) "Boot Constraints: " fmt
 
 #include <linux/boot_constraint.h>
+#include <linux/debugfs.h>
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/export.h>
@@ -24,6 +25,7 @@ struct constraint {
 	enum boot_constraint_type type;
 	void (*free_resources)(void *data);
 	void *free_resources_data;
+	struct dentry *dentry;
 
 	int (*add)(struct constraint *constraint, void *data);
 	void (*remove)(struct constraint *constraint);
@@ -34,6 +36,7 @@ struct constraint_dev {
 	struct device *dev;
 	struct list_head node;
 	struct list_head constraints;
+	struct dentry *dentry;
 };
 
 #define for_each_constraint(_constraint, _temp, _cdev)		\
@@ -59,6 +62,71 @@ static int __init constraints_disable(char *str)
 early_param("boot_constraints_disable", constraints_disable);
 
 
+/* Debugfs */
+
+static struct dentry *rootdir;
+
+static void constraint_device_add_debugfs(struct constraint_dev *cdev)
+{
+	struct device *dev = cdev->dev;
+
+	cdev->dentry = debugfs_create_dir(dev_name(dev), rootdir);
+	if (!cdev->dentry)
+		dev_err(dev, "Failed to create constraint dev debugfs dir\n");
+}
+
+static void constraint_device_remove_debugfs(struct constraint_dev *cdev)
+{
+	debugfs_remove_recursive(cdev->dentry);
+}
+
+static void constraint_add_debugfs(struct constraint *constraint,
+				   const char *suffix)
+{
+	struct device *dev = constraint->cdev->dev;
+	const char *prefix;
+	char name[NAME_MAX];
+
+	switch (constraint->type) {
+	case BOOT_CONSTRAINT_SUPPLY:
+		prefix = "supply";
+		break;
+	default:
+		dev_err(dev, "%s: Constraint type (%d) not supported\n",
+			__func__, constraint->type);
+		return;
+	}
+
+	snprintf(name, NAME_MAX, "%s-%s", prefix, suffix);
+
+	constraint->dentry = debugfs_create_dir(name, constraint->cdev->dentry);
+	if (!constraint->dentry)
+		dev_err(dev, "Failed to create constraint (%s) debugfs dir\n",
+			name);
+}
+
+static void constraint_remove_debugfs(struct constraint *constraint)
+{
+	debugfs_remove_recursive(constraint->dentry);
+}
+
+static int __init constraint_debugfs_init(void)
+{
+	if (boot_constraints_disabled)
+		return -ENODEV;
+
+	/* Create /sys/kernel/debug/opp directory */
+	rootdir = debugfs_create_dir("boot_constraints", NULL);
+	if (!rootdir) {
+		pr_err("Failed to create root directory\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+core_initcall(constraint_debugfs_init);
+
+
 /* Boot constraints core */
 
 static struct constraint_dev *constraint_device_find(struct device *dev)
@@ -86,12 +154,14 @@ static struct constraint_dev *constraint_device_allocate(struct device *dev)
 	INIT_LIST_HEAD(&cdev->constraints);
 
 	list_add(&cdev->node, &constraint_devices);
+	constraint_device_add_debugfs(cdev);
 
 	return cdev;
 }
 
 static void constraint_device_free(struct constraint_dev *cdev)
 {
+	constraint_device_remove_debugfs(cdev);
 	list_del(&cdev->node);
 	kfree(cdev);
 }
@@ -292,6 +362,15 @@ static int constraint_supply_add(struct constraint *constraint, void *data)
 	csupply->supply.name = kstrdup_const(supply->name, GFP_KERNEL);
 	constraint->private = csupply;
 
+	/* Debugfs */
+	constraint_add_debugfs(constraint, supply->name);
+
+	debugfs_create_u32("u_volt_min", 0444, constraint->dentry,
+			   &csupply->supply.u_volt_min);
+
+	debugfs_create_u32("u_volt_max", 0444, constraint->dentry,
+			   &csupply->supply.u_volt_max);
+
 	return 0;
 
 remove_voltage:
@@ -319,6 +398,7 @@ static void constraint_supply_remove(struct constraint *constraint)
 		dev_err(dev, "regulator_set_voltage failed (%d)\n", ret);
 
 	regulator_put(csupply->reg);
+	constraint_remove_debugfs(constraint);
 	kfree_const(csupply->supply.name);
 	kfree(csupply);
 }
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 4/6] drivers: boot_constraint: Add debugfs support

[Viresh Kumar]

This patch adds debugfs support for boot constraints. This is how it
looks for a "vmmc-supply" constraint for the MMC device.

$ ls -R /sys/kernel/debug/boot_constraints/
/sys/kernel/debug/boot_constraints/:
f723d000.dwmmc0

/sys/kernel/debug/boot_constraints/f723d000.dwmmc0:
supply-vmmc

/sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmc:
u_volt_max  u_volt_min

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/boot_constraint.c | 80 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 80 insertions(+)

diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index d372ddfe1264..4e3b5e1aec7c 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -10,6 +10,7 @@
 #define pr_fmt(fmt) "Boot Constraints: " fmt
 
 #include <linux/boot_constraint.h>
+#include <linux/debugfs.h>
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/export.h>
@@ -24,6 +25,7 @@ struct constraint {
 	enum boot_constraint_type type;
 	void (*free_resources)(void *data);
 	void *free_resources_data;
+	struct dentry *dentry;
 
 	int (*add)(struct constraint *constraint, void *data);
 	void (*remove)(struct constraint *constraint);
@@ -34,6 +36,7 @@ struct constraint_dev {
 	struct device *dev;
 	struct list_head node;
 	struct list_head constraints;
+	struct dentry *dentry;
 };
 
 #define for_each_constraint(_constraint, _temp, _cdev)		\
@@ -59,6 +62,71 @@ static int __init constraints_disable(char *str)
 early_param("boot_constraints_disable", constraints_disable);
 
 
+/* Debugfs */
+
+static struct dentry *rootdir;
+
+static void constraint_device_add_debugfs(struct constraint_dev *cdev)
+{
+	struct device *dev = cdev->dev;
+
+	cdev->dentry = debugfs_create_dir(dev_name(dev), rootdir);
+	if (!cdev->dentry)
+		dev_err(dev, "Failed to create constraint dev debugfs dir\n");
+}
+
+static void constraint_device_remove_debugfs(struct constraint_dev *cdev)
+{
+	debugfs_remove_recursive(cdev->dentry);
+}
+
+static void constraint_add_debugfs(struct constraint *constraint,
+				   const char *suffix)
+{
+	struct device *dev = constraint->cdev->dev;
+	const char *prefix;
+	char name[NAME_MAX];
+
+	switch (constraint->type) {
+	case BOOT_CONSTRAINT_SUPPLY:
+		prefix = "supply";
+		break;
+	default:
+		dev_err(dev, "%s: Constraint type (%d) not supported\n",
+			__func__, constraint->type);
+		return;
+	}
+
+	snprintf(name, NAME_MAX, "%s-%s", prefix, suffix);
+
+	constraint->dentry = debugfs_create_dir(name, constraint->cdev->dentry);
+	if (!constraint->dentry)
+		dev_err(dev, "Failed to create constraint (%s) debugfs dir\n",
+			name);
+}
+
+static void constraint_remove_debugfs(struct constraint *constraint)
+{
+	debugfs_remove_recursive(constraint->dentry);
+}
+
+static int __init constraint_debugfs_init(void)
+{
+	if (boot_constraints_disabled)
+		return -ENODEV;
+
+	/* Create /sys/kernel/debug/opp directory */
+	rootdir = debugfs_create_dir("boot_constraints", NULL);
+	if (!rootdir) {
+		pr_err("Failed to create root directory\n");
+		return -ENOMEM;
+	}
+
+	return 0;
+}
+core_initcall(constraint_debugfs_init);
+
+
 /* Boot constraints core */
 
 static struct constraint_dev *constraint_device_find(struct device *dev)
@@ -86,12 +154,14 @@ static struct constraint_dev *constraint_device_allocate(struct device *dev)
 	INIT_LIST_HEAD(&cdev->constraints);
 
 	list_add(&cdev->node, &constraint_devices);
+	constraint_device_add_debugfs(cdev);
 
 	return cdev;
 }
 
 static void constraint_device_free(struct constraint_dev *cdev)
 {
+	constraint_device_remove_debugfs(cdev);
 	list_del(&cdev->node);
 	kfree(cdev);
 }
@@ -292,6 +362,15 @@ static int constraint_supply_add(struct constraint *constraint, void *data)
 	csupply->supply.name = kstrdup_const(supply->name, GFP_KERNEL);
 	constraint->private = csupply;
 
+	/* Debugfs */
+	constraint_add_debugfs(constraint, supply->name);
+
+	debugfs_create_u32("u_volt_min", 0444, constraint->dentry,
+			   &csupply->supply.u_volt_min);
+
+	debugfs_create_u32("u_volt_max", 0444, constraint->dentry,
+			   &csupply->supply.u_volt_max);
+
 	return 0;
 
 remove_voltage:
@@ -319,6 +398,7 @@ static void constraint_supply_remove(struct constraint *constraint)
 		dev_err(dev, "regulator_set_voltage failed (%d)\n", ret);
 
 	regulator_put(csupply->reg);
+	constraint_remove_debugfs(constraint);
 	kfree_const(csupply->supply.name);
 	kfree(csupply);
 }
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

This adds device tree bindings for boot constraints. Only power supply
constraint types are supported currently.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt

diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
new file mode 100644
index 000000000000..9a01ea1e6e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/boot-constraints.txt
@@ -0,0 +1,68 @@
+BOOT CONSTRAINTS
+================
+
+Some devices are powered ON by the bootloader before the bootloader handovers
+control to the Operating System (OS). It maybe important for those devices to
+keep working until the time the OS takes over and starts configuring the devices
+again.
+
+A typical example of that can be the LCD controller, which is used by the
+bootloaders to show image(s) while the platform is booting into the Operating
+System. The LCD controller can be using some resources, like clk, supplies, etc,
+that are shared between several devices. These shared resources should be
+configured to satisfy need of all the users. If another device's (X) driver gets
+probed before the LCD controller driver in this case, then it may end up
+reconfiguring these resources to ranges satisfying the current users (only
+device X) and that can make the LCD screen unstable.
+
+This document describes the binding used to specify such boot constraints to the
+OS.
+
+Power Supply Constraints:
+-------------------------
+
+This describes the binding of constraints for the power supply resources. These
+must be present directly in the consumer device's node.
+
+Required properties:
+- boot-constraint-supplies:
+
+  This contains an array of (one or more) strings, each of which must match with
+  the <name> of a corresponding <name>-supply property in the same device node.
+  This is required for the OS to know about the power supplies that are
+  configured (and enabled) by the bootloader for the consumer device.
+
+  It is assumed that the power supply is already enabled by the bootloader.
+
+- boot-constraint-uV:
+
+  This contains an array of {min max} microvolt tuples for the power supplies in
+  the same order in which they are present in "boot-constraint-supplies"
+  property. Here, min is the smallest and max is the largest voltage that the
+  consumer (corresponding to the device node where this property is present) may
+  set.
+
+Example of a consumer device node (mmc) referencing two regulators and setting
+their boot constraints (twl_reg1 and twl_reg2):
+
+	twl_reg1: regulator@0 {
+		...
+		...
+		...
+	};
+
+	twl_reg2: regulator@1 {
+		...
+		...
+		...
+	};
+
+	mmc: mmc@0x0 {
+		...
+		...
+		vmmc-supply = <&twl_reg1>;
+		vmmcaux-supply = <&twl_reg2>;
+		boot-constraint-supplies = "vmmc", "vmmcaux";
+		boot-constraint-uV = <1800000 2000000>, /* vmmc */
+				     <2000000 2000000>; /* vmmcaux */
+	};
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

This adds device tree bindings for boot constraints. Only power supply
constraint types are supported currently.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt

diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
new file mode 100644
index 000000000000..9a01ea1e6e72
--- /dev/null
+++ b/Documentation/devicetree/bindings/boot-constraints.txt
@@ -0,0 +1,68 @@
+BOOT CONSTRAINTS
+================
+
+Some devices are powered ON by the bootloader before the bootloader handovers
+control to the Operating System (OS). It maybe important for those devices to
+keep working until the time the OS takes over and starts configuring the devices
+again.
+
+A typical example of that can be the LCD controller, which is used by the
+bootloaders to show image(s) while the platform is booting into the Operating
+System. The LCD controller can be using some resources, like clk, supplies, etc,
+that are shared between several devices. These shared resources should be
+configured to satisfy need of all the users. If another device's (X) driver gets
+probed before the LCD controller driver in this case, then it may end up
+reconfiguring these resources to ranges satisfying the current users (only
+device X) and that can make the LCD screen unstable.
+
+This document describes the binding used to specify such boot constraints to the
+OS.
+
+Power Supply Constraints:
+-------------------------
+
+This describes the binding of constraints for the power supply resources. These
+must be present directly in the consumer device's node.
+
+Required properties:
+- boot-constraint-supplies:
+
+  This contains an array of (one or more) strings, each of which must match with
+  the <name> of a corresponding <name>-supply property in the same device node.
+  This is required for the OS to know about the power supplies that are
+  configured (and enabled) by the bootloader for the consumer device.
+
+  It is assumed that the power supply is already enabled by the bootloader.
+
+- boot-constraint-uV:
+
+  This contains an array of {min max} microvolt tuples for the power supplies in
+  the same order in which they are present in "boot-constraint-supplies"
+  property. Here, min is the smallest and max is the largest voltage that the
+  consumer (corresponding to the device node where this property is present) may
+  set.
+
+Example of a consumer device node (mmc) referencing two regulators and setting
+their boot constraints (twl_reg1 and twl_reg2):
+
+	twl_reg1: regulator at 0 {
+		...
+		...
+		...
+	};
+
+	twl_reg2: regulator at 1 {
+		...
+		...
+		...
+	};
+
+	mmc: mmc at 0x0 {
+		...
+		...
+		vmmc-supply = <&twl_reg1>;
+		vmmcaux-supply = <&twl_reg2>;
+		boot-constraint-supplies = "vmmc", "vmmcaux";
+		boot-constraint-uV = <1800000 2000000>, /* vmmc */
+				     <2000000 2000000>; /* vmmcaux */
+	};
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 6/6] drivers: boot_constraint: Add constraints for OF devices

[Viresh Kumar]

This implements the device tree dependent part of the boot constraints.

The supply constraints are added automatically for the platform and AMBA
devices created from DT and will be removed after the driver is
registered for the devices.

It is possible that some of the resources aren't available at the time
when the devices are added and so the boot constraints core will return
-EPROBE_DEFER for them. In order to retry adding the constraints at a
later point of time (after the resource is added and before any of its
users come up), this patch proposes two things:

- Each constraint is represented by a virtual platform device, so that
  it is re-probed again until the time all the dependencies aren't met.
  The platform device is removed along with the constraint, with help of
  the free_resources() callback.

- Enable early defer probing support by calling
  driver_enable_deferred_probe(), so that the core retries probing
  deferred devices every time any device is bound to a driver. This
  makes sure that the constraint is set before any of the users of the
  resources come up.

This is tested on ARM64 Hikey board where probe was deferred for a
device.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/Makefile             |   3 +
 drivers/base/base.h               |   1 +
 drivers/base/boot_constraint.c    |   2 +-
 drivers/base/boot_constraint_of.c | 122 ++++++++++++++++++++++++++++++++++++++
 drivers/base/dd.c                 |  12 ++++
 drivers/of/platform.c             |   4 ++
 include/linux/boot_constraint.h   |   2 +
 7 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/boot_constraint_of.c

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6094b3b75184..0f47a5de585a 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -6,6 +6,9 @@ obj-y			:= component.o core.o bus.o dd.o syscore.o \
 			   attribute_container.o transport_class.o \
 			   topology.o container.o property.o cacheinfo.o
 obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint.o
+ifeq ($(CONFIG_OF),y)
+obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint_of.o
+endif
 obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
diff --git a/drivers/base/base.h b/drivers/base/base.h
index e19b1008e5fb..9d6910cdbc8e 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -136,6 +136,7 @@ extern char *make_class_name(const char *name, struct kobject *kobj);
 extern int devres_release_all(struct device *dev);
 extern void device_block_probing(void);
 extern void device_unblock_probing(void);
+extern void driver_enable_deferred_probe(void);
 
 /* /sys/devices directory */
 extern struct kset *devices_kset;
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 4e3b5e1aec7c..80ac3f9aaa72 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -50,7 +50,7 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
-static bool boot_constraints_disabled;
+bool boot_constraints_disabled;
 
 static int __init constraints_disable(char *str)
 {
diff --git a/drivers/base/boot_constraint_of.c b/drivers/base/boot_constraint_of.c
new file mode 100644
index 000000000000..671241b3d3a3
--- /dev/null
+++ b/drivers/base/boot_constraint_of.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#define pr_fmt(fmt) "Boot Constraints: " fmt
+
+#include <linux/boot_constraint.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "base.h"
+
+extern bool boot_constraints_disabled;
+
+struct boot_constraint_of_pdata {
+	struct device *dev;
+	enum boot_constraint_type type;
+	struct boot_constraint_supply_info info;
+};
+
+static void boot_constraint_add_supply(struct device *dev, int index)
+{
+	struct boot_constraint_of_pdata pdata = {
+		.dev = dev,
+		.type = BOOT_CONSTRAINT_SUPPLY,
+	};
+	struct boot_constraint_supply_info *info;
+	struct device_node *np = dev->of_node;
+	struct platform_device *pdev;
+	int ret;
+
+	info = &pdata.info;
+
+	ret = of_property_read_string_index(np, "boot-constraint-supplies",
+					    index, &info->name);
+	if (ret < 0) {
+		dev_err(dev, "%s: Failed to read supply at index %d (%d)\n",
+			__func__, index, ret);
+		return;
+	}
+
+	of_property_read_u32_index(np, "boot-constraint-uV", 2 * index,
+				   &info->u_volt_min);
+
+	of_property_read_u32_index(np, "boot-constraint-uV", 2 * index + 1,
+				   &info->u_volt_max);
+
+	pdev = platform_device_register_data(NULL, "boot-constraints-of", index,
+					     &pdata, sizeof(pdata));
+	if (IS_ERR(pdev)) {
+		dev_err(dev, "%s: Failed to create pdev for index %d (%d)\n",
+			__func__, index, ret);
+	}
+}
+
+static void boot_constraint_add_supplies(struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	int i, count;
+
+	count = of_property_count_strings(np, "boot-constraint-supplies");
+	if (count <= 0)
+		return;
+
+	for (i = 0; i < count; i++)
+		boot_constraint_add_supply(dev, i);
+}
+
+void of_boot_constraint_init(struct device *dev)
+{
+	if (boot_constraints_disabled)
+		return;
+
+	BUG_ON(!dev->of_node);
+
+	boot_constraint_add_supplies(dev);
+}
+
+static void boot_constraint_remove_of(void *data)
+{
+	platform_device_unregister(data);
+}
+
+/*
+ * A platform device is added for each and every constraint, to handle
+ * -EPROBE_DEFER properly.
+ */
+static int boot_constraint_of_probe(struct platform_device *pdev)
+{
+	struct boot_constraint_of_pdata *pdata = dev_get_platdata(&pdev->dev);
+	struct boot_constraint_info info;
+	int ret;
+
+	BUG_ON(!pdata);
+
+	info.free_resources = boot_constraint_remove_of;
+	info.free_resources_data = pdev;
+	info.constraint_info = &pdata->info;
+
+	ret = boot_constraint_add(pdata->dev, pdata->type, &info);
+	if (ret == -EPROBE_DEFER)
+		driver_enable_deferred_probe();
+
+	return ret;
+}
+
+static struct platform_driver boot_constraint_of_driver = {
+	.driver = {
+		.name = "boot-constraints-of",
+	},
+	.probe = boot_constraint_of_probe,
+};
+
+static int __init boot_constraint_of_init(void)
+{
+	return platform_driver_register(&boot_constraint_of_driver);
+}
+core_initcall(boot_constraint_of_init);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4eb9d183d647..aa761e13d8a7 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -204,6 +204,18 @@ void device_unblock_probing(void)
 }
 
 /**
+ * driver_enable_deferred_probe() - Enable probing of deferred devices
+ *
+ * We don't want to get in the way when the bulk of drivers are getting probed
+ * and so deferred probe is disabled in the beginning. Enable it now because we
+ * need it.
+ */
+void driver_enable_deferred_probe(void)
+{
+	driver_deferred_probe_enable = true;
+}
+
+/**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *
  * We don't want to get in the way when the bulk of drivers are getting probed.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 703a42118ffc..b88a1bf3e7fb 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,6 +17,7 @@
 #include <linux/errno.h>
 #include <linux/module.h>
 #include <linux/amba/bus.h>
+#include <linux/boot_constraint.h>
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/slab.h>
@@ -194,6 +195,8 @@ static struct platform_device *of_platform_device_create_pdata(
 		goto err_clear_flag;
 	}
 
+	of_boot_constraint_init(&dev->dev);
+
 	return dev;
 
 err_clear_flag:
@@ -271,6 +274,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
 		goto err_free;
 	}
 
+	of_boot_constraint_init(&dev->dev);
 	return dev;
 
 err_free:
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
index 110e5eca36c6..17bec71df228 100644
--- a/include/linux/boot_constraint.h
+++ b/include/linux/boot_constraint.h
@@ -33,10 +33,12 @@ struct boot_constraint_info {
 int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
 			struct boot_constraint_info *info);
 void boot_constraints_remove(struct device *dev);
+void of_boot_constraint_init(struct device *dev);
 #else
 static inline int boot_constraint_add(struct device *dev,
 				      enum boot_constraint_type type,
 				      struct boot_constraint_info *info)
 { return -EINVAL; }
 static inline void boot_constraints_remove(struct device *dev) {}
+static inline void of_boot_constraint_init(struct device *dev) {}
 #endif
-- 
2.13.0.71.gd7076ec9c9cb

[RFC v2 6/6] drivers: boot_constraint: Add constraints for OF devices

[Viresh Kumar]

This implements the device tree dependent part of the boot constraints.

The supply constraints are added automatically for the platform and AMBA
devices created from DT and will be removed after the driver is
registered for the devices.

It is possible that some of the resources aren't available at the time
when the devices are added and so the boot constraints core will return
-EPROBE_DEFER for them. In order to retry adding the constraints at a
later point of time (after the resource is added and before any of its
users come up), this patch proposes two things:

- Each constraint is represented by a virtual platform device, so that
  it is re-probed again until the time all the dependencies aren't met.
  The platform device is removed along with the constraint, with help of
  the free_resources() callback.

- Enable early defer probing support by calling
  driver_enable_deferred_probe(), so that the core retries probing
  deferred devices every time any device is bound to a driver. This
  makes sure that the constraint is set before any of the users of the
  resources come up.

This is tested on ARM64 Hikey board where probe was deferred for a
device.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
 drivers/base/Makefile             |   3 +
 drivers/base/base.h               |   1 +
 drivers/base/boot_constraint.c    |   2 +-
 drivers/base/boot_constraint_of.c | 122 ++++++++++++++++++++++++++++++++++++++
 drivers/base/dd.c                 |  12 ++++
 drivers/of/platform.c             |   4 ++
 include/linux/boot_constraint.h   |   2 +
 7 files changed, 145 insertions(+), 1 deletion(-)
 create mode 100644 drivers/base/boot_constraint_of.c

diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6094b3b75184..0f47a5de585a 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -6,6 +6,9 @@ obj-y			:= component.o core.o bus.o dd.o syscore.o \
 			   attribute_container.o transport_class.o \
 			   topology.o container.o property.o cacheinfo.o
 obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint.o
+ifeq ($(CONFIG_OF),y)
+obj-$(CONFIG_BOOT_CONSTRAINTS) += boot_constraint_of.o
+endif
 obj-$(CONFIG_DEVTMPFS)	+= devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y			+= power/
diff --git a/drivers/base/base.h b/drivers/base/base.h
index e19b1008e5fb..9d6910cdbc8e 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -136,6 +136,7 @@ extern char *make_class_name(const char *name, struct kobject *kobj);
 extern int devres_release_all(struct device *dev);
 extern void device_block_probing(void);
 extern void device_unblock_probing(void);
+extern void driver_enable_deferred_probe(void);
 
 /* /sys/devices directory */
 extern struct kset *devices_kset;
diff --git a/drivers/base/boot_constraint.c b/drivers/base/boot_constraint.c
index 4e3b5e1aec7c..80ac3f9aaa72 100644
--- a/drivers/base/boot_constraint.c
+++ b/drivers/base/boot_constraint.c
@@ -50,7 +50,7 @@ static DEFINE_MUTEX(constraint_devices_mutex);
 static int constraint_supply_add(struct constraint *constraint, void *data);
 static void constraint_supply_remove(struct constraint *constraint);
 
-static bool boot_constraints_disabled;
+bool boot_constraints_disabled;
 
 static int __init constraints_disable(char *str)
 {
diff --git a/drivers/base/boot_constraint_of.c b/drivers/base/boot_constraint_of.c
new file mode 100644
index 000000000000..671241b3d3a3
--- /dev/null
+++ b/drivers/base/boot_constraint_of.c
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2017 Linaro.
+ * Viresh Kumar <viresh.kumar@linaro.org>
+ *
+ * This file is released under the GPLv2.
+ */
+
+#define pr_fmt(fmt) "Boot Constraints: " fmt
+
+#include <linux/boot_constraint.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#include "base.h"
+
+extern bool boot_constraints_disabled;
+
+struct boot_constraint_of_pdata {
+	struct device *dev;
+	enum boot_constraint_type type;
+	struct boot_constraint_supply_info info;
+};
+
+static void boot_constraint_add_supply(struct device *dev, int index)
+{
+	struct boot_constraint_of_pdata pdata = {
+		.dev = dev,
+		.type = BOOT_CONSTRAINT_SUPPLY,
+	};
+	struct boot_constraint_supply_info *info;
+	struct device_node *np = dev->of_node;
+	struct platform_device *pdev;
+	int ret;
+
+	info = &pdata.info;
+
+	ret = of_property_read_string_index(np, "boot-constraint-supplies",
+					    index, &info->name);
+	if (ret < 0) {
+		dev_err(dev, "%s: Failed to read supply@index %d (%d)\n",
+			__func__, index, ret);
+		return;
+	}
+
+	of_property_read_u32_index(np, "boot-constraint-uV", 2 * index,
+				   &info->u_volt_min);
+
+	of_property_read_u32_index(np, "boot-constraint-uV", 2 * index + 1,
+				   &info->u_volt_max);
+
+	pdev = platform_device_register_data(NULL, "boot-constraints-of", index,
+					     &pdata, sizeof(pdata));
+	if (IS_ERR(pdev)) {
+		dev_err(dev, "%s: Failed to create pdev for index %d (%d)\n",
+			__func__, index, ret);
+	}
+}
+
+static void boot_constraint_add_supplies(struct device *dev)
+{
+	struct device_node *np = dev->of_node;
+	int i, count;
+
+	count = of_property_count_strings(np, "boot-constraint-supplies");
+	if (count <= 0)
+		return;
+
+	for (i = 0; i < count; i++)
+		boot_constraint_add_supply(dev, i);
+}
+
+void of_boot_constraint_init(struct device *dev)
+{
+	if (boot_constraints_disabled)
+		return;
+
+	BUG_ON(!dev->of_node);
+
+	boot_constraint_add_supplies(dev);
+}
+
+static void boot_constraint_remove_of(void *data)
+{
+	platform_device_unregister(data);
+}
+
+/*
+ * A platform device is added for each and every constraint, to handle
+ * -EPROBE_DEFER properly.
+ */
+static int boot_constraint_of_probe(struct platform_device *pdev)
+{
+	struct boot_constraint_of_pdata *pdata = dev_get_platdata(&pdev->dev);
+	struct boot_constraint_info info;
+	int ret;
+
+	BUG_ON(!pdata);
+
+	info.free_resources = boot_constraint_remove_of;
+	info.free_resources_data = pdev;
+	info.constraint_info = &pdata->info;
+
+	ret = boot_constraint_add(pdata->dev, pdata->type, &info);
+	if (ret == -EPROBE_DEFER)
+		driver_enable_deferred_probe();
+
+	return ret;
+}
+
+static struct platform_driver boot_constraint_of_driver = {
+	.driver = {
+		.name = "boot-constraints-of",
+	},
+	.probe = boot_constraint_of_probe,
+};
+
+static int __init boot_constraint_of_init(void)
+{
+	return platform_driver_register(&boot_constraint_of_driver);
+}
+core_initcall(boot_constraint_of_init);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4eb9d183d647..aa761e13d8a7 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -204,6 +204,18 @@ void device_unblock_probing(void)
 }
 
 /**
+ * driver_enable_deferred_probe() - Enable probing of deferred devices
+ *
+ * We don't want to get in the way when the bulk of drivers are getting probed
+ * and so deferred probe is disabled in the beginning. Enable it now because we
+ * need it.
+ */
+void driver_enable_deferred_probe(void)
+{
+	driver_deferred_probe_enable = true;
+}
+
+/**
  * deferred_probe_initcall() - Enable probing of deferred devices
  *
  * We don't want to get in the way when the bulk of drivers are getting probed.
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 703a42118ffc..b88a1bf3e7fb 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -17,6 +17,7 @@
 #include <linux/errno.h>
 #include <linux/module.h>
 #include <linux/amba/bus.h>
+#include <linux/boot_constraint.h>
 #include <linux/device.h>
 #include <linux/dma-mapping.h>
 #include <linux/slab.h>
@@ -194,6 +195,8 @@ static struct platform_device *of_platform_device_create_pdata(
 		goto err_clear_flag;
 	}
 
+	of_boot_constraint_init(&dev->dev);
+
 	return dev;
 
 err_clear_flag:
@@ -271,6 +274,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
 		goto err_free;
 	}
 
+	of_boot_constraint_init(&dev->dev);
 	return dev;
 
 err_free:
diff --git a/include/linux/boot_constraint.h b/include/linux/boot_constraint.h
index 110e5eca36c6..17bec71df228 100644
--- a/include/linux/boot_constraint.h
+++ b/include/linux/boot_constraint.h
@@ -33,10 +33,12 @@ struct boot_constraint_info {
 int boot_constraint_add(struct device *dev, enum boot_constraint_type type,
 			struct boot_constraint_info *info);
 void boot_constraints_remove(struct device *dev);
+void of_boot_constraint_init(struct device *dev);
 #else
 static inline int boot_constraint_add(struct device *dev,
 				      enum boot_constraint_type type,
 				      struct boot_constraint_info *info)
 { return -EINVAL; }
 static inline void boot_constraints_remove(struct device *dev) {}
+static inline void of_boot_constraint_init(struct device *dev) {}
 #endif
-- 
2.13.0.71.gd7076ec9c9cb

Re: [RFC v2 4/6] drivers: boot_constraint: Add debugfs support

[Viresh Kumar]

On 12-07-17, 12:04, Viresh Kumar wrote:
> This patch adds debugfs support for boot constraints. This is how it
> looks for a "vmmc-supply" constraint for the MMC device.
> 
> $ ls -R /sys/kernel/debug/boot_constraints/
> /sys/kernel/debug/boot_constraints/:
> f723d000.dwmmc0
> 
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0:
> supply-vmmc
> 
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmc:
> u_volt_max  u_volt_min
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  drivers/base/boot_constraint.c | 80 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)

Forgot to mention that this one depends on
https://marc.info/?l=linux-kernel&m=149870936319587 for compilation
without CONFIG_DEBUG_FS.

--
viresh

[RFC v2 4/6] drivers: boot_constraint: Add debugfs support

[Viresh Kumar]

On 12-07-17, 12:04, Viresh Kumar wrote:
> This patch adds debugfs support for boot constraints. This is how it
> looks for a "vmmc-supply" constraint for the MMC device.
> 
> $ ls -R /sys/kernel/debug/boot_constraints/
> /sys/kernel/debug/boot_constraints/:
> f723d000.dwmmc0
> 
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0:
> supply-vmmc
> 
> /sys/kernel/debug/boot_constraints/f723d000.dwmmc0/supply-vmmc:
> u_volt_max  u_volt_min
> 
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  drivers/base/boot_constraint.c | 80 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 80 insertions(+)

Forgot to mention that this one depends on
https://marc.info/?l=linux-kernel&m=149870936319587 for compilation
without CONFIG_DEBUG_FS.

--
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> This adds device tree bindings for boot constraints. Only power supply
> constraint types are supported currently.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>
> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
> new file mode 100644
> index 000000000000..9a01ea1e6e72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
> @@ -0,0 +1,68 @@
> +BOOT CONSTRAINTS
> +================
> +
> +Some devices are powered ON by the bootloader before the bootloader handovers
> +control to the Operating System (OS). It maybe important for those devices to
> +keep working until the time the OS takes over and starts configuring the devices
> +again.
> +
> +A typical example of that can be the LCD controller, which is used by the
> +bootloaders to show image(s) while the platform is booting into the Operating
> +System. The LCD controller can be using some resources, like clk, supplies, etc,
> +that are shared between several devices. These shared resources should be
> +configured to satisfy need of all the users. If another device's (X) driver gets
> +probed before the LCD controller driver in this case, then it may end up
> +reconfiguring these resources to ranges satisfying the current users (only
> +device X) and that can make the LCD screen unstable.

Display is a pretty well known use case here. Do you have other
examples in mind? Other cases I've seen are automotive with keeping
the backup camera going and CAN bus handling. Though my new car has a
flicker shortly after coming on, so I guess the handoff doesn't have
to be completely seemless. :)

[...]

> +       mmc: mmc@0x0 {
> +               ...
> +               ...
> +               vmmc-supply = <&twl_reg1>;
> +               vmmcaux-supply = <&twl_reg2>;
> +               boot-constraint-supplies = "vmmc", "vmmcaux";
> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> +                                    <2000000 2000000>; /* vmmcaux */

No. I don't like how this is going to extend to all the other bindings
people are going to want constraints for. We don't need a parallel set
of properties for each type of binding.

I'm not convinced that we need a general solution for what's probably
a handful of things that need a handoff versus just re-initialize.

Rob

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> This adds device tree bindings for boot constraints. Only power supply
> constraint types are supported currently.
>
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>
> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
> new file mode 100644
> index 000000000000..9a01ea1e6e72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
> @@ -0,0 +1,68 @@
> +BOOT CONSTRAINTS
> +================
> +
> +Some devices are powered ON by the bootloader before the bootloader handovers
> +control to the Operating System (OS). It maybe important for those devices to
> +keep working until the time the OS takes over and starts configuring the devices
> +again.
> +
> +A typical example of that can be the LCD controller, which is used by the
> +bootloaders to show image(s) while the platform is booting into the Operating
> +System. The LCD controller can be using some resources, like clk, supplies, etc,
> +that are shared between several devices. These shared resources should be
> +configured to satisfy need of all the users. If another device's (X) driver gets
> +probed before the LCD controller driver in this case, then it may end up
> +reconfiguring these resources to ranges satisfying the current users (only
> +device X) and that can make the LCD screen unstable.

Display is a pretty well known use case here. Do you have other
examples in mind? Other cases I've seen are automotive with keeping
the backup camera going and CAN bus handling. Though my new car has a
flicker shortly after coming on, so I guess the handoff doesn't have
to be completely seemless. :)

[...]

> +       mmc: mmc@0x0 {
> +               ...
> +               ...
> +               vmmc-supply = <&twl_reg1>;
> +               vmmcaux-supply = <&twl_reg2>;
> +               boot-constraint-supplies = "vmmc", "vmmcaux";
> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> +                                    <2000000 2000000>; /* vmmcaux */

No. I don't like how this is going to extend to all the other bindings
people are going to want constraints for. We don't need a parallel set
of properties for each type of binding.

I'm not convinced that we need a general solution for what's probably
a handful of things that need a handoff versus just re-initialize.

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

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> This adds device tree bindings for boot constraints. Only power supply
> constraint types are supported currently.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>  1 file changed, 68 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>
> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
> new file mode 100644
> index 000000000000..9a01ea1e6e72
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
> @@ -0,0 +1,68 @@
> +BOOT CONSTRAINTS
> +================
> +
> +Some devices are powered ON by the bootloader before the bootloader handovers
> +control to the Operating System (OS). It maybe important for those devices to
> +keep working until the time the OS takes over and starts configuring the devices
> +again.
> +
> +A typical example of that can be the LCD controller, which is used by the
> +bootloaders to show image(s) while the platform is booting into the Operating
> +System. The LCD controller can be using some resources, like clk, supplies, etc,
> +that are shared between several devices. These shared resources should be
> +configured to satisfy need of all the users. If another device's (X) driver gets
> +probed before the LCD controller driver in this case, then it may end up
> +reconfiguring these resources to ranges satisfying the current users (only
> +device X) and that can make the LCD screen unstable.

Display is a pretty well known use case here. Do you have other
examples in mind? Other cases I've seen are automotive with keeping
the backup camera going and CAN bus handling. Though my new car has a
flicker shortly after coming on, so I guess the handoff doesn't have
to be completely seemless. :)

[...]

> +       mmc: mmc at 0x0 {
> +               ...
> +               ...
> +               vmmc-supply = <&twl_reg1>;
> +               vmmcaux-supply = <&twl_reg2>;
> +               boot-constraint-supplies = "vmmc", "vmmcaux";
> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> +                                    <2000000 2000000>; /* vmmcaux */

No. I don't like how this is going to extend to all the other bindings
people are going to want constraints for. We don't need a parallel set
of properties for each type of binding.

I'm not convinced that we need a general solution for what's probably
a handful of things that need a handoff versus just re-initialize.

Rob

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 5:28 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> This adds device tree bindings for boot constraints. Only power supply
>> constraint types are supported currently.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> ---
>>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>>
>> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
>> new file mode 100644
>> index 000000000000..9a01ea1e6e72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
>> @@ -0,0 +1,68 @@
>> +BOOT CONSTRAINTS
>> +================
>> +
>> +Some devices are powered ON by the bootloader before the bootloader handovers
>> +control to the Operating System (OS). It maybe important for those devices to
>> +keep working until the time the OS takes over and starts configuring the devices
>> +again.
>> +
>> +A typical example of that can be the LCD controller, which is used by the
>> +bootloaders to show image(s) while the platform is booting into the Operating
>> +System. The LCD controller can be using some resources, like clk, supplies, etc,
>> +that are shared between several devices. These shared resources should be
>> +configured to satisfy need of all the users. If another device's (X) driver gets
>> +probed before the LCD controller driver in this case, then it may end up
>> +reconfiguring these resources to ranges satisfying the current users (only
>> +device X) and that can make the LCD screen unstable.
>
> Display is a pretty well known use case here. Do you have other
> examples in mind? Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)
>
> [...]
>
>> +       mmc: mmc@0x0 {
>> +               ...
>> +               ...
>> +               vmmc-supply = <&twl_reg1>;
>> +               vmmcaux-supply = <&twl_reg2>;
>> +               boot-constraint-supplies = "vmmc", "vmmcaux";
>> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
>> +                                    <2000000 2000000>; /* vmmcaux */
>
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.
>
> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

I'm afraid the regulator case still doesn't make sense. The voltage
constraints should be set within each supplies device node. This was
explained in the discussion in v1 [1].

ChenYu

[1] https://www.spinics.net/lists/arm-kernel/msg591692.html

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 5:28 AM, Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> This adds device tree bindings for boot constraints. Only power supply
>> constraint types are supported currently.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>>
>> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
>> new file mode 100644
>> index 000000000000..9a01ea1e6e72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
>> @@ -0,0 +1,68 @@
>> +BOOT CONSTRAINTS
>> +================
>> +
>> +Some devices are powered ON by the bootloader before the bootloader handovers
>> +control to the Operating System (OS). It maybe important for those devices to
>> +keep working until the time the OS takes over and starts configuring the devices
>> +again.
>> +
>> +A typical example of that can be the LCD controller, which is used by the
>> +bootloaders to show image(s) while the platform is booting into the Operating
>> +System. The LCD controller can be using some resources, like clk, supplies, etc,
>> +that are shared between several devices. These shared resources should be
>> +configured to satisfy need of all the users. If another device's (X) driver gets
>> +probed before the LCD controller driver in this case, then it may end up
>> +reconfiguring these resources to ranges satisfying the current users (only
>> +device X) and that can make the LCD screen unstable.
>
> Display is a pretty well known use case here. Do you have other
> examples in mind? Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)
>
> [...]
>
>> +       mmc: mmc@0x0 {
>> +               ...
>> +               ...
>> +               vmmc-supply = <&twl_reg1>;
>> +               vmmcaux-supply = <&twl_reg2>;
>> +               boot-constraint-supplies = "vmmc", "vmmcaux";
>> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
>> +                                    <2000000 2000000>; /* vmmcaux */
>
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.
>
> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

I'm afraid the regulator case still doesn't make sense. The voltage
constraints should be set within each supplies device node. This was
explained in the discussion in v1 [1].

ChenYu

[1] https://www.spinics.net/lists/arm-kernel/msg591692.html
--
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

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 5:28 AM, Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Jul 12, 2017 at 1:34 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
>> This adds device tree bindings for boot constraints. Only power supply
>> constraint types are supported currently.
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>> ---
>>  .../devicetree/bindings/boot-constraints.txt       | 68 ++++++++++++++++++++++
>>  1 file changed, 68 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/boot-constraints.txt
>>
>> diff --git a/Documentation/devicetree/bindings/boot-constraints.txt b/Documentation/devicetree/bindings/boot-constraints.txt
>> new file mode 100644
>> index 000000000000..9a01ea1e6e72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/boot-constraints.txt
>> @@ -0,0 +1,68 @@
>> +BOOT CONSTRAINTS
>> +================
>> +
>> +Some devices are powered ON by the bootloader before the bootloader handovers
>> +control to the Operating System (OS). It maybe important for those devices to
>> +keep working until the time the OS takes over and starts configuring the devices
>> +again.
>> +
>> +A typical example of that can be the LCD controller, which is used by the
>> +bootloaders to show image(s) while the platform is booting into the Operating
>> +System. The LCD controller can be using some resources, like clk, supplies, etc,
>> +that are shared between several devices. These shared resources should be
>> +configured to satisfy need of all the users. If another device's (X) driver gets
>> +probed before the LCD controller driver in this case, then it may end up
>> +reconfiguring these resources to ranges satisfying the current users (only
>> +device X) and that can make the LCD screen unstable.
>
> Display is a pretty well known use case here. Do you have other
> examples in mind? Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)
>
> [...]
>
>> +       mmc: mmc at 0x0 {
>> +               ...
>> +               ...
>> +               vmmc-supply = <&twl_reg1>;
>> +               vmmcaux-supply = <&twl_reg2>;
>> +               boot-constraint-supplies = "vmmc", "vmmcaux";
>> +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
>> +                                    <2000000 2000000>; /* vmmcaux */
>
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.
>
> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

I'm afraid the regulator case still doesn't make sense. The voltage
constraints should be set within each supplies device node. This was
explained in the discussion in v1 [1].

ChenYu

[1] https://www.spinics.net/lists/arm-kernel/msg591692.html

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 10:52, Chen-Yu Tsai wrote:
> I'm afraid the regulator case still doesn't make sense. The voltage
> constraints should be set within each supplies device node. This was
> explained in the discussion in v1 [1].

I thought we were discussing about something I mentioned in one of my example
but never to a point that the regulator problem doesn't exist at all. Perhaps I
misunderstood your concerns. Anyway, lemme try once more with a better example.

Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
3 V.

The bootloader has programmed the LCD to work at the highest pixel frequency,
which needs the voltage to be in range from 2.5 - 3 V.

Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
frequency.

Does that sound like a valid problem?

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 10:52, Chen-Yu Tsai wrote:
> I'm afraid the regulator case still doesn't make sense. The voltage
> constraints should be set within each supplies device node. This was
> explained in the discussion in v1 [1].

I thought we were discussing about something I mentioned in one of my example
but never to a point that the regulator problem doesn't exist at all. Perhaps I
misunderstood your concerns. Anyway, lemme try once more with a better example.

Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
3 V.

The bootloader has programmed the LCD to work at the highest pixel frequency,
which needs the voltage to be in range from 2.5 - 3 V.

Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
frequency.

Does that sound like a valid problem?

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

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 10:52, Chen-Yu Tsai wrote:
> I'm afraid the regulator case still doesn't make sense. The voltage
> constraints should be set within each supplies device node. This was
> explained in the discussion in v1 [1].

I thought we were discussing about something I mentioned in one of my example
but never to a point that the regulator problem doesn't exist at all. Perhaps I
misunderstood your concerns. Anyway, lemme try once more with a better example.

Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
3 V.

The bootloader has programmed the LCD to work at the highest pixel frequency,
which needs the voltage to be in range from 2.5 - 3 V.

Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
frequency.

Does that sound like a valid problem?

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 12-07-17, 16:28, Rob Herring wrote:
> Display is a pretty well known use case here. Do you have other
> examples in mind?

No, I don't.

@Stephen: Do you have more cases like this for your Qcom products ?

> Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)

:)

> [...]
> 
> > +       mmc: mmc@0x0 {
> > +               ...
> > +               ...
> > +               vmmc-supply = <&twl_reg1>;
> > +               vmmcaux-supply = <&twl_reg2>;
> > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > +                                    <2000000 2000000>; /* vmmcaux */
> 
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.

Fair enough.

> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

What about keeping the first four patches (mostly) as it is and adding
these constraints from a platform specific constraints driver ?

Will that be acceptable ?

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 12-07-17, 16:28, Rob Herring wrote:
> Display is a pretty well known use case here. Do you have other
> examples in mind?

No, I don't.

@Stephen: Do you have more cases like this for your Qcom products ?

> Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)

:)

> [...]
> 
> > +       mmc: mmc@0x0 {
> > +               ...
> > +               ...
> > +               vmmc-supply = <&twl_reg1>;
> > +               vmmcaux-supply = <&twl_reg2>;
> > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > +                                    <2000000 2000000>; /* vmmcaux */
> 
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.

Fair enough.

> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

What about keeping the first four patches (mostly) as it is and adding
these constraints from a platform specific constraints driver ?

Will that be acceptable ?

-- 
viresh

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 12-07-17, 16:28, Rob Herring wrote:
> Display is a pretty well known use case here. Do you have other
> examples in mind?

No, I don't.

@Stephen: Do you have more cases like this for your Qcom products ?

> Other cases I've seen are automotive with keeping
> the backup camera going and CAN bus handling. Though my new car has a
> flicker shortly after coming on, so I guess the handoff doesn't have
> to be completely seemless. :)

:)

> [...]
> 
> > +       mmc: mmc at 0x0 {
> > +               ...
> > +               ...
> > +               vmmc-supply = <&twl_reg1>;
> > +               vmmcaux-supply = <&twl_reg2>;
> > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > +                                    <2000000 2000000>; /* vmmcaux */
> 
> No. I don't like how this is going to extend to all the other bindings
> people are going to want constraints for. We don't need a parallel set
> of properties for each type of binding.

Fair enough.

> I'm not convinced that we need a general solution for what's probably
> a handful of things that need a handoff versus just re-initialize.

What about keeping the first four patches (mostly) as it is and adding
these constraints from a platform specific constraints driver ?

Will that be acceptable ?

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 1:09 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 13-07-17, 10:52, Chen-Yu Tsai wrote:
>> I'm afraid the regulator case still doesn't make sense. The voltage
>> constraints should be set within each supplies device node. This was
>> explained in the discussion in v1 [1].
>
> I thought we were discussing about something I mentioned in one of my example
> but never to a point that the regulator problem doesn't exist at all. Perhaps I
> misunderstood your concerns. Anyway, lemme try once more with a better example.
>
> Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
> that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
> 3 V.
>
> The bootloader has programmed the LCD to work at the highest pixel frequency,
> which needs the voltage to be in range from 2.5 - 3 V.
>
> Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
> Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
> frequency.
>
> Does that sound like a valid problem?

This makes more sense. The LCD being able to do DVFS was missing from the last
discussion. I assume this is for power saving purposes? Otherwise one could just
say you should not use the lower part of the voltage range. And DVFS is for the
controller's core logic and not I/O?

ChenYu

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 1:09 PM, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 13-07-17, 10:52, Chen-Yu Tsai wrote:
>> I'm afraid the regulator case still doesn't make sense. The voltage
>> constraints should be set within each supplies device node. This was
>> explained in the discussion in v1 [1].
>
> I thought we were discussing about something I mentioned in one of my example
> but never to a point that the regulator problem doesn't exist at all. Perhaps I
> misunderstood your concerns. Anyway, lemme try once more with a better example.
>
> Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
> that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
> 3 V.
>
> The bootloader has programmed the LCD to work at the highest pixel frequency,
> which needs the voltage to be in range from 2.5 - 3 V.
>
> Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
> Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
> frequency.
>
> Does that sound like a valid problem?

This makes more sense. The LCD being able to do DVFS was missing from the last
discussion. I assume this is for power saving purposes? Otherwise one could just
say you should not use the lower part of the voltage range. And DVFS is for the
controller's core logic and not I/O?

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

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Chen-Yu Tsai]

On Thu, Jul 13, 2017 at 1:09 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 13-07-17, 10:52, Chen-Yu Tsai wrote:
>> I'm afraid the regulator case still doesn't make sense. The voltage
>> constraints should be set within each supplies device node. This was
>> explained in the discussion in v1 [1].
>
> I thought we were discussing about something I mentioned in one of my example
> but never to a point that the regulator problem doesn't exist at all. Perhaps I
> misunderstood your concerns. Anyway, lemme try once more with a better example.
>
> Regulator shared by: LCD and MMC (both can do DVFS) and the min/max constraint
> that can be set by the consumers of the regulator (both LCD/MMC) are: 1.5 V to
> 3 V.
>
> The bootloader has programmed the LCD to work at the highest pixel frequency,
> which needs the voltage to be in range from 2.5 - 3 V.
>
> Now MMC can get probed first and it can try to bring the voltages below 2.5 V.
> Though, 1.5 - 2.5 is a valid range for the LCD, but not at the current pixel
> frequency.
>
> Does that sound like a valid problem?

This makes more sense. The LCD being able to do DVFS was missing from the last
discussion. I assume this is for power saving purposes? Otherwise one could just
say you should not use the lower part of the voltage range. And DVFS is for the
controller's core logic and not I/O?

ChenYu

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 17:46, Chen-Yu Tsai wrote:
> This makes more sense. The LCD being able to do DVFS was missing from the last
> discussion. I assume this is for power saving purposes?

Yeah.

> Otherwise one could just
> say you should not use the lower part of the voltage range. And DVFS is for the
> controller's core logic and not I/O?

Yeah.

But for many such cases in different platforms, the LCD controller may
not do DVFS. But we still need to make sure its clk, regulator and
power domain are enabled until the time the driver comes up. This
series would also help in doing proxy-voting for all such resources,
so that they don't get disabled while being used.

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 17:46, Chen-Yu Tsai wrote:
> This makes more sense. The LCD being able to do DVFS was missing from the last
> discussion. I assume this is for power saving purposes?

Yeah.

> Otherwise one could just
> say you should not use the lower part of the voltage range. And DVFS is for the
> controller's core logic and not I/O?

Yeah.

But for many such cases in different platforms, the LCD controller may
not do DVFS. But we still need to make sure its clk, regulator and
power domain are enabled until the time the driver comes up. This
series would also help in doing proxy-voting for all such resources,
so that they don't get disabled while being used.

-- 
viresh

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 13-07-17, 17:46, Chen-Yu Tsai wrote:
> This makes more sense. The LCD being able to do DVFS was missing from the last
> discussion. I assume this is for power saving purposes?

Yeah.

> Otherwise one could just
> say you should not use the lower part of the voltage range. And DVFS is for the
> controller's core logic and not I/O?

Yeah.

But for many such cases in different platforms, the LCD controller may
not do DVFS. But we still need to make sure its clk, regulator and
power domain are enabled until the time the driver comes up. This
series would also help in doing proxy-voting for all such resources,
so that they don't get disabled while being used.

-- 
viresh

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> On 12-07-17, 16:28, Rob Herring wrote:
> > Display is a pretty well known use case here. Do you have other
> > examples in mind?
> 
> No, I don't.
> 
> @Stephen: Do you have more cases like this for your Qcom products ?
> 
> > Other cases I've seen are automotive with keeping
> > the backup camera going and CAN bus handling. Though my new car has a
> > flicker shortly after coming on, so I guess the handoff doesn't have
> > to be completely seemless. :)
> 
> :)
> 
> > [...]
> > 
> > > +       mmc: mmc@0x0 {
> > > +               ...
> > > +               ...
> > > +               vmmc-supply = <&twl_reg1>;
> > > +               vmmcaux-supply = <&twl_reg2>;
> > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > +                                    <2000000 2000000>; /* vmmcaux */
> > 
> > No. I don't like how this is going to extend to all the other bindings
> > people are going to want constraints for. We don't need a parallel set
> > of properties for each type of binding.
> 
> Fair enough.
> 
> > I'm not convinced that we need a general solution for what's probably
> > a handful of things that need a handoff versus just re-initialize.
> 
> What about keeping the first four patches (mostly) as it is and adding
> these constraints from a platform specific constraints driver ?
> 
> Will that be acceptable ?

Meaning no DT binding? Then I don't care (from a DT perspective).

Rob

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> On 12-07-17, 16:28, Rob Herring wrote:
> > Display is a pretty well known use case here. Do you have other
> > examples in mind?
> 
> No, I don't.
> 
> @Stephen: Do you have more cases like this for your Qcom products ?
> 
> > Other cases I've seen are automotive with keeping
> > the backup camera going and CAN bus handling. Though my new car has a
> > flicker shortly after coming on, so I guess the handoff doesn't have
> > to be completely seemless. :)
> 
> :)
> 
> > [...]
> > 
> > > +       mmc: mmc@0x0 {
> > > +               ...
> > > +               ...
> > > +               vmmc-supply = <&twl_reg1>;
> > > +               vmmcaux-supply = <&twl_reg2>;
> > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > +                                    <2000000 2000000>; /* vmmcaux */
> > 
> > No. I don't like how this is going to extend to all the other bindings
> > people are going to want constraints for. We don't need a parallel set
> > of properties for each type of binding.
> 
> Fair enough.
> 
> > I'm not convinced that we need a general solution for what's probably
> > a handful of things that need a handoff versus just re-initialize.
> 
> What about keeping the first four patches (mostly) as it is and adding
> these constraints from a platform specific constraints driver ?
> 
> Will that be acceptable ?

Meaning no DT binding? Then I don't care (from a DT perspective).

Rob

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Rob Herring]

On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> On 12-07-17, 16:28, Rob Herring wrote:
> > Display is a pretty well known use case here. Do you have other
> > examples in mind?
> 
> No, I don't.
> 
> @Stephen: Do you have more cases like this for your Qcom products ?
> 
> > Other cases I've seen are automotive with keeping
> > the backup camera going and CAN bus handling. Though my new car has a
> > flicker shortly after coming on, so I guess the handoff doesn't have
> > to be completely seemless. :)
> 
> :)
> 
> > [...]
> > 
> > > +       mmc: mmc at 0x0 {
> > > +               ...
> > > +               ...
> > > +               vmmc-supply = <&twl_reg1>;
> > > +               vmmcaux-supply = <&twl_reg2>;
> > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > +                                    <2000000 2000000>; /* vmmcaux */
> > 
> > No. I don't like how this is going to extend to all the other bindings
> > people are going to want constraints for. We don't need a parallel set
> > of properties for each type of binding.
> 
> Fair enough.
> 
> > I'm not convinced that we need a general solution for what's probably
> > a handful of things that need a handoff versus just re-initialize.
> 
> What about keeping the first four patches (mostly) as it is and adding
> these constraints from a platform specific constraints driver ?
> 
> Will that be acceptable ?

Meaning no DT binding? Then I don't care (from a DT perspective).

Rob

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +       mmc: mmc@0x0 {
> > > > +               ...
> > > > +               ...
> > > > +               vmmc-supply = <&twl_reg1>;
> > > > +               vmmcaux-supply = <&twl_reg2>;
> > > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > > +                                    <2000000 2000000>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +       mmc: mmc@0x0 {
> > > > +               ...
> > > > +               ...
> > > > +               vmmc-supply = <&twl_reg1>;
> > > > +               vmmcaux-supply = <&twl_reg2>;
> > > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > > +                                    <2000000 2000000>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2

[RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

[Viresh Kumar]

On 17-07-17, 12:34, Rob Herring wrote:
> On Thu, Jul 13, 2017 at 03:06:08PM +0530, Viresh Kumar wrote:
> > On 12-07-17, 16:28, Rob Herring wrote:
> > > Display is a pretty well known use case here. Do you have other
> > > examples in mind?
> > 
> > No, I don't.
> > 
> > @Stephen: Do you have more cases like this for your Qcom products ?
> > 
> > > Other cases I've seen are automotive with keeping
> > > the backup camera going and CAN bus handling. Though my new car has a
> > > flicker shortly after coming on, so I guess the handoff doesn't have
> > > to be completely seemless. :)
> > 
> > :)
> > 
> > > [...]
> > > 
> > > > +       mmc: mmc at 0x0 {
> > > > +               ...
> > > > +               ...
> > > > +               vmmc-supply = <&twl_reg1>;
> > > > +               vmmcaux-supply = <&twl_reg2>;
> > > > +               boot-constraint-supplies = "vmmc", "vmmcaux";
> > > > +               boot-constraint-uV = <1800000 2000000>, /* vmmc */
> > > > +                                    <2000000 2000000>; /* vmmcaux */
> > > 
> > > No. I don't like how this is going to extend to all the other bindings
> > > people are going to want constraints for. We don't need a parallel set
> > > of properties for each type of binding.
> > 
> > Fair enough.
> > 
> > > I'm not convinced that we need a general solution for what's probably
> > > a handful of things that need a handoff versus just re-initialize.
> > 
> > What about keeping the first four patches (mostly) as it is and adding
> > these constraints from a platform specific constraints driver ?
> > 
> > Will that be acceptable ?
> 
> Meaning no DT binding? Then I don't care (from a DT perspective).

Yeah, kind of the way we decided to do the first step in the
power domain performance state series [1].

And then later on we can see how to get such information from DT, as
the kernel needs this information irrespective of the way we solve
this problem in the kernel.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=149802907711074&w=2