[PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add optional mediatek.power-off-sequence in bindings document.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal HALT or POWER_OFF.
For the other cases, just follow HW immediate off by default.
---
 .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
index a462d99..eaf36e2 100644
--- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
@@ -24,6 +24,16 @@ properties:
   LDO_VIN3-supply:
     description: Input supply phandle(s) for LDO6/7
 
+  mediatek,power-off-sequence:
+    description: |
+      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
+      Cause these regulators are all default-on power. Each value from 0 to 63,
+      and step is 1. Each step means 2 millisecond delay.
+      Therefore, the power off sequence delay time range is from 0ms to 126ms.
+    $ref: "/schemas/types.yaml#/definitions/uint8-array"
+    minItems: 4
+    maxItems: 4
+
 patternProperties:
   "^buck[12]$":
     $ref: "regulator.yaml#"
@@ -42,6 +52,7 @@ examples:
     #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
     regulator {
       compatible = "mediatek,mt6360-regulator";
+      mediatek,power-off-sequence = /bits/ 8 <0 0 0 0>;
       LDO_VIN3-supply = <&BUCK2>;
       buck1 {
         regulator-compatible = "BUCK1";
-- 
2.7.4

[PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add optional mediatek.power-off-sequence in bindings document.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal HALT or POWER_OFF.
For the other cases, just follow HW immediate off by default.
---
 .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
index a462d99..eaf36e2 100644
--- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
@@ -24,6 +24,16 @@ properties:
   LDO_VIN3-supply:
     description: Input supply phandle(s) for LDO6/7
 
+  mediatek,power-off-sequence:
+    description: |
+      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
+      Cause these regulators are all default-on power. Each value from 0 to 63,
+      and step is 1. Each step means 2 millisecond delay.
+      Therefore, the power off sequence delay time range is from 0ms to 126ms.
+    $ref: "/schemas/types.yaml#/definitions/uint8-array"
+    minItems: 4
+    maxItems: 4
+
 patternProperties:
   "^buck[12]$":
     $ref: "regulator.yaml#"
@@ -42,6 +52,7 @@ examples:
     #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
     regulator {
       compatible = "mediatek,mt6360-regulator";
+      mediatek,power-off-sequence = /bits/ 8 <0 0 0 0>;
       LDO_VIN3-supply = <&BUCK2>;
       buck1 {
         regulator-compatible = "BUCK1";
-- 
2.7.4


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

[PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add optional mediatek.power-off-sequence in bindings document.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal HALT or POWER_OFF.
For the other cases, just follow HW immediate off by default.
---
 .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
index a462d99..eaf36e2 100644
--- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
@@ -24,6 +24,16 @@ properties:
   LDO_VIN3-supply:
     description: Input supply phandle(s) for LDO6/7
 
+  mediatek,power-off-sequence:
+    description: |
+      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
+      Cause these regulators are all default-on power. Each value from 0 to 63,
+      and step is 1. Each step means 2 millisecond delay.
+      Therefore, the power off sequence delay time range is from 0ms to 126ms.
+    $ref: "/schemas/types.yaml#/definitions/uint8-array"
+    minItems: 4
+    maxItems: 4
+
 patternProperties:
   "^buck[12]$":
     $ref: "regulator.yaml#"
@@ -42,6 +52,7 @@ examples:
     #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
     regulator {
       compatible = "mediatek,mt6360-regulator";
+      mediatek,power-off-sequence = /bits/ 8 <0 0 0 0>;
       LDO_VIN3-supply = <&BUCK2>;
       buck1 {
         regulator-compatible = "BUCK1";
-- 
2.7.4


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

[PATCH 2/2] regulator: mt6360: Add power off sequence config for default-on power

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add power off sequence config for default-on power.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal halt or power_off.
For the other cases, just follow HW immediate off by default.
---
 drivers/regulator/mt6360-regulator.c | 37 +++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/mt6360-regulator.c b/drivers/regulator/mt6360-regulator.c
index 4d34be9..6625f8f 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -9,12 +9,17 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
 
 #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
 
+#define MT6360_REG_BUCK1_SEQTD	0x117
+#define MT6360_SEQOFF_REGNUM	4
+
 enum {
 	MT6360_REGULATOR_BUCK1 = 0,
 	MT6360_REGULATOR_BUCK2,
@@ -45,6 +50,9 @@ struct mt6360_regulator_desc {
 struct mt6360_regulator_data {
 	struct device *dev;
 	struct regmap *regmap;
+	struct notifier_block reboot_notifier;
+	/* Only for BUCK1/BUCK2/LDO7/LDO6, these are default on power */
+	u8 power_off_seq[MT6360_SEQOFF_REGNUM];
 };
 
 static irqreturn_t mt6360_pgb_event_handler(int irq, void *data)
@@ -394,10 +402,28 @@ static int mt6360_regulator_irq_register(struct platform_device *pdev,
 	return 0;
 }
 
+static int reboot_notify_call(struct notifier_block *nb, unsigned long action, void *data)
+{
+	struct mt6360_regulator_data *mrd = container_of(nb, struct mt6360_regulator_data,
+							 reboot_notifier);
+	int ret;
+
+	if (action != SYS_HALT && action != SYS_POWER_OFF)
+		return NOTIFY_DONE;
+
+	ret = regmap_raw_write(mrd->regmap, MT6360_REG_BUCK1_SEQTD, mrd->power_off_seq,
+			       MT6360_SEQOFF_REGNUM);
+	if (ret)
+		dev_err(mrd->dev, "Failed to apply the power off sequence\n");
+
+	return NOTIFY_DONE;
+}
+
 static int mt6360_regulator_probe(struct platform_device *pdev)
 {
 	struct mt6360_regulator_data *mrd;
 	struct regulator_config config = {};
+	struct fwnode_handle *fwnode;
 	int i, ret;
 
 	mrd = devm_kzalloc(&pdev->dev, sizeof(*mrd), GFP_KERNEL);
@@ -434,7 +460,16 @@ static int mt6360_regulator_probe(struct platform_device *pdev)
 		}
 	}
 
-	return 0;
+	fwnode = device_get_named_child_node(pdev->dev.parent, "regulator");
+	if (fwnode) {
+		ret = fwnode_property_read_u8_array(fwnode, "mediatek,power-off-sequence",
+						    mrd->power_off_seq, MT6360_SEQOFF_REGNUM);
+		if (ret)
+			dev_warn(&pdev->dev, "Use no delay immediate off by default [%d]\n", ret);
+	}
+
+	mrd->reboot_notifier.notifier_call = reboot_notify_call;
+	return devm_register_reboot_notifier(&pdev->dev, &mrd->reboot_notifier);
 }
 
 static const struct platform_device_id mt6360_regulator_id_table[] = {
-- 
2.7.4

[PATCH 2/2] regulator: mt6360: Add power off sequence config for default-on power

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add power off sequence config for default-on power.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal halt or power_off.
For the other cases, just follow HW immediate off by default.
---
 drivers/regulator/mt6360-regulator.c | 37 +++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/mt6360-regulator.c b/drivers/regulator/mt6360-regulator.c
index 4d34be9..6625f8f 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -9,12 +9,17 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
 
 #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
 
+#define MT6360_REG_BUCK1_SEQTD	0x117
+#define MT6360_SEQOFF_REGNUM	4
+
 enum {
 	MT6360_REGULATOR_BUCK1 = 0,
 	MT6360_REGULATOR_BUCK2,
@@ -45,6 +50,9 @@ struct mt6360_regulator_desc {
 struct mt6360_regulator_data {
 	struct device *dev;
 	struct regmap *regmap;
+	struct notifier_block reboot_notifier;
+	/* Only for BUCK1/BUCK2/LDO7/LDO6, these are default on power */
+	u8 power_off_seq[MT6360_SEQOFF_REGNUM];
 };
 
 static irqreturn_t mt6360_pgb_event_handler(int irq, void *data)
@@ -394,10 +402,28 @@ static int mt6360_regulator_irq_register(struct platform_device *pdev,
 	return 0;
 }
 
+static int reboot_notify_call(struct notifier_block *nb, unsigned long action, void *data)
+{
+	struct mt6360_regulator_data *mrd = container_of(nb, struct mt6360_regulator_data,
+							 reboot_notifier);
+	int ret;
+
+	if (action != SYS_HALT && action != SYS_POWER_OFF)
+		return NOTIFY_DONE;
+
+	ret = regmap_raw_write(mrd->regmap, MT6360_REG_BUCK1_SEQTD, mrd->power_off_seq,
+			       MT6360_SEQOFF_REGNUM);
+	if (ret)
+		dev_err(mrd->dev, "Failed to apply the power off sequence\n");
+
+	return NOTIFY_DONE;
+}
+
 static int mt6360_regulator_probe(struct platform_device *pdev)
 {
 	struct mt6360_regulator_data *mrd;
 	struct regulator_config config = {};
+	struct fwnode_handle *fwnode;
 	int i, ret;
 
 	mrd = devm_kzalloc(&pdev->dev, sizeof(*mrd), GFP_KERNEL);
@@ -434,7 +460,16 @@ static int mt6360_regulator_probe(struct platform_device *pdev)
 		}
 	}
 
-	return 0;
+	fwnode = device_get_named_child_node(pdev->dev.parent, "regulator");
+	if (fwnode) {
+		ret = fwnode_property_read_u8_array(fwnode, "mediatek,power-off-sequence",
+						    mrd->power_off_seq, MT6360_SEQOFF_REGNUM);
+		if (ret)
+			dev_warn(&pdev->dev, "Use no delay immediate off by default [%d]\n", ret);
+	}
+
+	mrd->reboot_notifier.notifier_call = reboot_notify_call;
+	return devm_register_reboot_notifier(&pdev->dev, &mrd->reboot_notifier);
 }
 
 static const struct platform_device_id mt6360_regulator_id_table[] = {
-- 
2.7.4


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

[PATCH 2/2] regulator: mt6360: Add power off sequence config for default-on power

[cy_huang]

From: ChiYuan Huang <cy_huang@richtek.com>

Add power off sequence config for default-on power.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
Hi,

Originally, we think it must write in platform dependent code like as bootloader.
But after the evaluation, it must write only when system normal halt or power_off.
For the other cases, just follow HW immediate off by default.
---
 drivers/regulator/mt6360-regulator.c | 37 +++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/mt6360-regulator.c b/drivers/regulator/mt6360-regulator.c
index 4d34be9..6625f8f 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -9,12 +9,17 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
+#include <linux/reboot.h>
 #include <linux/regmap.h>
 #include <linux/regulator/driver.h>
 #include <linux/regulator/machine.h>
 
 #include <dt-bindings/regulator/mediatek,mt6360-regulator.h>
 
+#define MT6360_REG_BUCK1_SEQTD	0x117
+#define MT6360_SEQOFF_REGNUM	4
+
 enum {
 	MT6360_REGULATOR_BUCK1 = 0,
 	MT6360_REGULATOR_BUCK2,
@@ -45,6 +50,9 @@ struct mt6360_regulator_desc {
 struct mt6360_regulator_data {
 	struct device *dev;
 	struct regmap *regmap;
+	struct notifier_block reboot_notifier;
+	/* Only for BUCK1/BUCK2/LDO7/LDO6, these are default on power */
+	u8 power_off_seq[MT6360_SEQOFF_REGNUM];
 };
 
 static irqreturn_t mt6360_pgb_event_handler(int irq, void *data)
@@ -394,10 +402,28 @@ static int mt6360_regulator_irq_register(struct platform_device *pdev,
 	return 0;
 }
 
+static int reboot_notify_call(struct notifier_block *nb, unsigned long action, void *data)
+{
+	struct mt6360_regulator_data *mrd = container_of(nb, struct mt6360_regulator_data,
+							 reboot_notifier);
+	int ret;
+
+	if (action != SYS_HALT && action != SYS_POWER_OFF)
+		return NOTIFY_DONE;
+
+	ret = regmap_raw_write(mrd->regmap, MT6360_REG_BUCK1_SEQTD, mrd->power_off_seq,
+			       MT6360_SEQOFF_REGNUM);
+	if (ret)
+		dev_err(mrd->dev, "Failed to apply the power off sequence\n");
+
+	return NOTIFY_DONE;
+}
+
 static int mt6360_regulator_probe(struct platform_device *pdev)
 {
 	struct mt6360_regulator_data *mrd;
 	struct regulator_config config = {};
+	struct fwnode_handle *fwnode;
 	int i, ret;
 
 	mrd = devm_kzalloc(&pdev->dev, sizeof(*mrd), GFP_KERNEL);
@@ -434,7 +460,16 @@ static int mt6360_regulator_probe(struct platform_device *pdev)
 		}
 	}
 
-	return 0;
+	fwnode = device_get_named_child_node(pdev->dev.parent, "regulator");
+	if (fwnode) {
+		ret = fwnode_property_read_u8_array(fwnode, "mediatek,power-off-sequence",
+						    mrd->power_off_seq, MT6360_SEQOFF_REGNUM);
+		if (ret)
+			dev_warn(&pdev->dev, "Use no delay immediate off by default [%d]\n", ret);
+	}
+
+	mrd->reboot_notifier.notifier_call = reboot_notify_call;
+	return devm_register_reboot_notifier(&pdev->dev, &mrd->reboot_notifier);
 }
 
 static const struct platform_device_id mt6360_regulator_id_table[] = {
-- 
2.7.4


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Rob Herring]

On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> From: ChiYuan Huang <cy_huang@richtek.com>
> 
> Add optional mediatek.power-off-sequence in bindings document.
> 
> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> ---
> Hi,
> 
> Originally, we think it must write in platform dependent code like as bootloader.
> But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> For the other cases, just follow HW immediate off by default.

Wouldn't this be handled by PSCI implementation?

> ---
>  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> index a462d99..eaf36e2 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> @@ -24,6 +24,16 @@ properties:
>    LDO_VIN3-supply:
>      description: Input supply phandle(s) for LDO6/7
>  
> +  mediatek,power-off-sequence:
> +    description: |
> +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> +      Cause these regulators are all default-on power. Each value from 0 to 63,
> +      and step is 1. Each step means 2 millisecond delay.
> +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +    minItems: 4
> +    maxItems: 4

So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
If we wanted to express this in DT, we'd made this generic which would 
need to be more flexible. A poweroff delay in each regulator (similar to 
the existing power on delay) would be sufficient for what you need I 
think.

Rob

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Rob Herring]

On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> From: ChiYuan Huang <cy_huang@richtek.com>
> 
> Add optional mediatek.power-off-sequence in bindings document.
> 
> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> ---
> Hi,
> 
> Originally, we think it must write in platform dependent code like as bootloader.
> But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> For the other cases, just follow HW immediate off by default.

Wouldn't this be handled by PSCI implementation?

> ---
>  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> index a462d99..eaf36e2 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> @@ -24,6 +24,16 @@ properties:
>    LDO_VIN3-supply:
>      description: Input supply phandle(s) for LDO6/7
>  
> +  mediatek,power-off-sequence:
> +    description: |
> +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> +      Cause these regulators are all default-on power. Each value from 0 to 63,
> +      and step is 1. Each step means 2 millisecond delay.
> +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +    minItems: 4
> +    maxItems: 4

So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
If we wanted to express this in DT, we'd made this generic which would 
need to be more flexible. A poweroff delay in each regulator (similar to 
the existing power on delay) would be sufficient for what you need I 
think.

Rob

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

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Rob Herring]

On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> From: ChiYuan Huang <cy_huang@richtek.com>
> 
> Add optional mediatek.power-off-sequence in bindings document.
> 
> Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> ---
> Hi,
> 
> Originally, we think it must write in platform dependent code like as bootloader.
> But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> For the other cases, just follow HW immediate off by default.

Wouldn't this be handled by PSCI implementation?

> ---
>  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> index a462d99..eaf36e2 100644
> --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> @@ -24,6 +24,16 @@ properties:
>    LDO_VIN3-supply:
>      description: Input supply phandle(s) for LDO6/7
>  
> +  mediatek,power-off-sequence:
> +    description: |
> +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> +      Cause these regulators are all default-on power. Each value from 0 to 63,
> +      and step is 1. Each step means 2 millisecond delay.
> +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> +    minItems: 4
> +    maxItems: 4

So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
If we wanted to express this in DT, we'd made this generic which would 
need to be more flexible. A poweroff delay in each regulator (similar to 
the existing power on delay) would be sufficient for what you need I 
think.

Rob

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Hi, Rob:

Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> >
> > Add optional mediatek.power-off-sequence in bindings document.
> >
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> > Hi,
> >
> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.
>
> Wouldn't this be handled by PSCI implementation?
No, the current application default on powers buck1/buck2/ldo7/ldo6
are for Dram power.
It's not the soc core power. It seems not appropriate  to implement
like as PSCI.
MT6360 play the role for the subpmic in the SOC application reference design.
>
> > ---
> >  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > index a462d99..eaf36e2 100644
> > --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > @@ -24,6 +24,16 @@ properties:
> >    LDO_VIN3-supply:
> >      description: Input supply phandle(s) for LDO6/7
> >
> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4
>
> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc?
No. you may misunderstand. there's an external 'Enable' pin that's
connected to the main pmic.
The starting point of delay time are all from  the external 'Enable' H to L.
Not one-by-one delay time,
> If we wanted to express this in DT, we'd made this generic which would
> need to be more flexible. A poweroff delay in each regulator (similar to
> the existing power on delay) would be sufficient for what you need I
> think.
Power on sequence already defined by the part number, It's not decided by SW.
So for the flexibility, I implement it in DT.

Duel to there're many part number MT6360 P/UP/LP, etc.
The difference are the power on sequence.

Do you have any suggestion about this situation?

PS: Due to DRAM power usage , sometimes it also need to customized by
the DRAM that customer choosed.
It may differ from external DRAM part choosen following by JEDEC spec.
>
> Rob

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Hi, Rob:

Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> >
> > Add optional mediatek.power-off-sequence in bindings document.
> >
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> > Hi,
> >
> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.
>
> Wouldn't this be handled by PSCI implementation?
No, the current application default on powers buck1/buck2/ldo7/ldo6
are for Dram power.
It's not the soc core power. It seems not appropriate  to implement
like as PSCI.
MT6360 play the role for the subpmic in the SOC application reference design.
>
> > ---
> >  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > index a462d99..eaf36e2 100644
> > --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > @@ -24,6 +24,16 @@ properties:
> >    LDO_VIN3-supply:
> >      description: Input supply phandle(s) for LDO6/7
> >
> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4
>
> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc?
No. you may misunderstand. there's an external 'Enable' pin that's
connected to the main pmic.
The starting point of delay time are all from  the external 'Enable' H to L.
Not one-by-one delay time,
> If we wanted to express this in DT, we'd made this generic which would
> need to be more flexible. A poweroff delay in each regulator (similar to
> the existing power on delay) would be sufficient for what you need I
> think.
Power on sequence already defined by the part number, It's not decided by SW.
So for the flexibility, I implement it in DT.

Duel to there're many part number MT6360 P/UP/LP, etc.
The difference are the power on sequence.

Do you have any suggestion about this situation?

PS: Due to DRAM power usage , sometimes it also need to customized by
the DRAM that customer choosed.
It may differ from external DRAM part choosen following by JEDEC spec.
>
> Rob

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

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Hi, Rob:

Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:
> > From: ChiYuan Huang <cy_huang@richtek.com>
> >
> > Add optional mediatek.power-off-sequence in bindings document.
> >
> > Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
> > ---
> > Hi,
> >
> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.
>
> Wouldn't this be handled by PSCI implementation?
No, the current application default on powers buck1/buck2/ldo7/ldo6
are for Dram power.
It's not the soc core power. It seems not appropriate  to implement
like as PSCI.
MT6360 play the role for the subpmic in the SOC application reference design.
>
> > ---
> >  .../devicetree/bindings/regulator/mt6360-regulator.yaml       | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > index a462d99..eaf36e2 100644
> > --- a/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > +++ b/Documentation/devicetree/bindings/regulator/mt6360-regulator.yaml
> > @@ -24,6 +24,16 @@ properties:
> >    LDO_VIN3-supply:
> >      description: Input supply phandle(s) for LDO6/7
> >
> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4
>
> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc?
No. you may misunderstand. there's an external 'Enable' pin that's
connected to the main pmic.
The starting point of delay time are all from  the external 'Enable' H to L.
Not one-by-one delay time,
> If we wanted to express this in DT, we'd made this generic which would
> need to be more flexible. A poweroff delay in each regulator (similar to
> the existing power on delay) would be sufficient for what you need I
> think.
Power on sequence already defined by the part number, It's not decided by SW.
So for the flexibility, I implement it in DT.

Duel to there're many part number MT6360 P/UP/LP, etc.
The difference are the power on sequence.

Do you have any suggestion about this situation?

PS: Due to DRAM power usage , sometimes it also need to customized by
the DRAM that customer choosed.
It may differ from external DRAM part choosen following by JEDEC spec.
>
> Rob

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：

> > > Originally, we think it must write in platform dependent code like as bootloader.
> > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > For the other cases, just follow HW immediate off by default.

> > Wouldn't this be handled by PSCI implementation?

> No, the current application default on powers buck1/buck2/ldo7/ldo6
> are for Dram power.
> It's not the soc core power. It seems not appropriate  to implement
> like as PSCI.
> MT6360 play the role for the subpmic in the SOC application reference design.

If this is part of the overall system power off that seems like it fits
well enough into what PSCI is doing - it's got operations like
SYSTEM_OFF which talk about the system as a whole.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 907 bytes --]

On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：

> > > Originally, we think it must write in platform dependent code like as bootloader.
> > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > For the other cases, just follow HW immediate off by default.

> > Wouldn't this be handled by PSCI implementation?

> No, the current application default on powers buck1/buck2/ldo7/ldo6
> are for Dram power.
> It's not the soc core power. It seems not appropriate  to implement
> like as PSCI.
> MT6360 play the role for the subpmic in the SOC application reference design.

If this is part of the overall system power off that seems like it fits
well enough into what PSCI is doing - it's got operations like
SYSTEM_OFF which talk about the system as a whole.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 907 bytes --]

On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：

> > > Originally, we think it must write in platform dependent code like as bootloader.
> > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > For the other cases, just follow HW immediate off by default.

> > Wouldn't this be handled by PSCI implementation?

> No, the current application default on powers buck1/buck2/ldo7/ldo6
> are for Dram power.
> It's not the soc core power. It seems not appropriate  to implement
> like as PSCI.
> MT6360 play the role for the subpmic in the SOC application reference design.

If this is part of the overall system power off that seems like it fits
well enough into what PSCI is doing - it's got operations like
SYSTEM_OFF which talk about the system as a whole.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Mark Brown <broonie@kernel.org> 於 2021年6月18日 週五 上午12:29寫道：
>
> On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> > Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> > > > Originally, we think it must write in platform dependent code like as bootloader.
> > > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > > For the other cases, just follow HW immediate off by default.
>
> > > Wouldn't this be handled by PSCI implementation?
>
> > No, the current application default on powers buck1/buck2/ldo7/ldo6
> > are for Dram power.
> > It's not the soc core power. It seems not appropriate  to implement
> > like as PSCI.
> > MT6360 play the role for the subpmic in the SOC application reference design.
>
> If this is part of the overall system power off that seems like it fits
> well enough into what PSCI is doing - it's got operations like
> SYSTEM_OFF which talk about the system as a whole.

Thanks, I'll check and survey the PSCI about the SYSTEM_OFF.
I think it may work.

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Mark Brown <broonie@kernel.org> 於 2021年6月18日 週五 上午12:29寫道：
>
> On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> > Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> > > > Originally, we think it must write in platform dependent code like as bootloader.
> > > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > > For the other cases, just follow HW immediate off by default.
>
> > > Wouldn't this be handled by PSCI implementation?
>
> > No, the current application default on powers buck1/buck2/ldo7/ldo6
> > are for Dram power.
> > It's not the soc core power. It seems not appropriate  to implement
> > like as PSCI.
> > MT6360 play the role for the subpmic in the SOC application reference design.
>
> If this is part of the overall system power off that seems like it fits
> well enough into what PSCI is doing - it's got operations like
> SYSTEM_OFF which talk about the system as a whole.

Thanks, I'll check and survey the PSCI about the SYSTEM_OFF.
I think it may work.

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

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[ChiYuan Huang]

Mark Brown <broonie@kernel.org> 於 2021年6月18日 週五 上午12:29寫道：
>
> On Mon, Jun 14, 2021 at 11:04:01PM +0800, ChiYuan Huang wrote:
> > Rob Herring <robh@kernel.org> 於 2021年6月12日 週六 上午4:16寫道：
>
> > > > Originally, we think it must write in platform dependent code like as bootloader.
> > > > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > > > For the other cases, just follow HW immediate off by default.
>
> > > Wouldn't this be handled by PSCI implementation?
>
> > No, the current application default on powers buck1/buck2/ldo7/ldo6
> > are for Dram power.
> > It's not the soc core power. It seems not appropriate  to implement
> > like as PSCI.
> > MT6360 play the role for the subpmic in the SOC application reference design.
>
> If this is part of the overall system power off that seems like it fits
> well enough into what PSCI is doing - it's got operations like
> SYSTEM_OFF which talk about the system as a whole.

Thanks, I'll check and survey the PSCI about the SYSTEM_OFF.
I think it may work.

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1955 bytes --]

On Fri, Jun 11, 2021 at 02:16:43PM -0600, Rob Herring wrote:
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:

> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.

> Wouldn't this be handled by PSCI implementation?

Ideally I think...

> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4

> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
> If we wanted to express this in DT, we'd made this generic which would 
> need to be more flexible. A poweroff delay in each regulator (similar to 
> the existing power on delay) would be sufficient for what you need I 
> think.

It's not exactly a delay that's being described there - it's a series of
timeslots, each regulator getting assigned to a timeslot.  You could
possibly do a general binding by specifying a delay from the start of
the power off sequence and then (for this device) having the driver work
out a mapping of those times to timeslots.  That feels genericish, you
might also have things like mode changes but it'd cover a lot of the
cases.

On the other hand this is the sort of thing that is often just not
configurable and where people often make weird and inflexible hardware
so things that do implement it are likely to end up wanting to add a
bunch of constraints which might be a lot of hassle.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1955 bytes --]

On Fri, Jun 11, 2021 at 02:16:43PM -0600, Rob Herring wrote:
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:

> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.

> Wouldn't this be handled by PSCI implementation?

Ideally I think...

> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4

> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
> If we wanted to express this in DT, we'd made this generic which would 
> need to be more flexible. A poweroff delay in each regulator (similar to 
> the existing power on delay) would be sufficient for what you need I 
> think.

It's not exactly a delay that's being described there - it's a series of
timeslots, each regulator getting assigned to a timeslot.  You could
possibly do a general binding by specifying a delay from the start of
the power off sequence and then (for this device) having the driver work
out a mapping of those times to timeslots.  That feels genericish, you
might also have things like mode changes but it'd cover a lot of the
cases.

On the other hand this is the sort of thing that is often just not
configurable and where people often make weird and inflexible hardware
so things that do implement it are likely to end up wanting to add a
bunch of constraints which might be a lot of hassle.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

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

Re: [PATCH 1/2] regulator: mt6360: Add optional mediatek.power-off-sequence in bindings document

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1955 bytes --]

On Fri, Jun 11, 2021 at 02:16:43PM -0600, Rob Herring wrote:
> On Wed, Jun 02, 2021 at 02:54:34PM +0800, cy_huang wrote:

> > Originally, we think it must write in platform dependent code like as bootloader.
> > But after the evaluation, it must write only when system normal HALT or POWER_OFF.
> > For the other cases, just follow HW immediate off by default.

> Wouldn't this be handled by PSCI implementation?

Ideally I think...

> > +  mediatek,power-off-sequence:
> > +    description: |
> > +      Power off sequence time selection for BUCK1/BUCK2/LDO7/LDO6, respetively.
> > +      Cause these regulators are all default-on power. Each value from 0 to 63,
> > +      and step is 1. Each step means 2 millisecond delay.
> > +      Therefore, the power off sequence delay time range is from 0ms to 126ms.
> > +    $ref: "/schemas/types.yaml#/definitions/uint8-array"
> > +    minItems: 4
> > +    maxItems: 4

> So this is the delay between BUCK1 and BUCK2, then BUCK2 to LDO7, etcc? 
> If we wanted to express this in DT, we'd made this generic which would 
> need to be more flexible. A poweroff delay in each regulator (similar to 
> the existing power on delay) would be sufficient for what you need I 
> think.

It's not exactly a delay that's being described there - it's a series of
timeslots, each regulator getting assigned to a timeslot.  You could
possibly do a general binding by specifying a delay from the start of
the power off sequence and then (for this device) having the driver work
out a mapping of those times to timeslots.  That feels genericish, you
might also have things like mode changes but it'd cover a lot of the
cases.

On the other hand this is the sort of thing that is often just not
configurable and where people often make weird and inflexible hardware
so things that do implement it are likely to end up wanting to add a
bunch of constraints which might be a lot of hassle.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek