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

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

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

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

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

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

[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

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

[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

[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