Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1410925 > unrolled thread

[PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)

Back to article view | Back to linux.kernel

Contents

  [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix  USB/LAN when TFTP booting) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:10 +0200
    [PATCH v3 02/12] MAINTAINERS: Retain Ulf Hansson as the same  maintainer of pwrseq Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:20 +0200
    [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and  generic property Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:20 +0200
      Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for  regulator and generic property Rob Herring <robh@kernel.org> - 2016-06-03 04:10 +0200
        Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator  and generic property Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-03 14:40 +0200
          Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for  regulator and generic property Peter Chen <hzpeterchen@gmail.com> - 2016-06-06 05:30 +0200
        Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator  and generic property Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-07 11:30 +0200
          Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for  regulator and generic property Rob Herring <robh@kernel.org> - 2016-06-08 21:10 +0200
            Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator  and generic property Chen-Yu Tsai <wens@csie.org> - 2016-06-09 04:40 +0200
              Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator  and generic property Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-09 07:20 +0200
    [PATCH v3 10/12] EXAMPLE CODE: usb: hub: Power sequence the ports on  activation Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:20 +0200
    [PATCH v3 04/12] power: pwrseq: Remove mmc prefix from mmc_pwrseq Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:20 +0200
    [PATCH v3 03/12] power: pwrseq: Enable COMPILE_TEST for drivers Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-01 10:20 +0200
    Re: [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting) Heiko Stübner <heiko@sntech.de> - 2016-06-06 22:50 +0200
      Re: [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix  USB/LAN when TFTP booting) Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2016-06-07 08:10 +0200

#1410925 — [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)

Hi,


My third approach for a USB power sequence which fixes usb3503+lan
on Odroid U3 board if it was initialized by bootloader
(e.g. for TFTP boot).


Changes since v2
================
1. Add Javier's reviewed-by tags. Address some comments.
2. Re-use existing properties for GPIOs etc by pwrseq-simple
   driver.  New property is still added: "power-sequence".
   I tried to address and do according to Rob's comments.

   Please look at patch 6/12 ("power: pwrseq: simple: Add support
   for regulator and generic property") for bindings and the
   new code around matching "power-sequence" property.

3. I marked the usb code as "EXAMPLE" because that part
   is left to Peter Chen.


Problem
=======
When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
is required, e.g. by suspend to RAM. The actual TFTP boot does
not have to happen. Just "usb start" from U-Boot is sufficient.

From the schematics, the regulator is a supply only to LAN, however
without toggling it off/on, the usb3503 hub won appear neither.


Solution
========
This is very similar to the MMC pwrseq behavior so the idea is to:
1. Move MMC pwrseq drivers to generic place,
2. Extend the pwrseq-simple with regulator toggling,
3. Add support to USB hub and port core for pwrseq,
4. Toggle the regulator when needed.

Best regards,
Krzysztof

Krzysztof Kozlowski (12):
  power/mmc: Move pwrseq drivers to power/pwrseq
  MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq
  power: pwrseq: Enable COMPILE_TEST for drivers
  power: pwrseq: Remove mmc prefix from mmc_pwrseq
  power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
  power: pwrseq: simple: Add support for regulator and generic property
  power: pwrseq: Add support for USB hubs with external power
  usb: hub: Handle deferred probe
  EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
  EXAMPLE CODE: usb: hub: Power sequence the ports on activation
  ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
  ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on
    Odroid U3

 .../pwrseq/pwrseq-emmc.txt}                        |   0
 .../pwrseq/pwrseq-simple.txt}                      |  29 +++-
 MAINTAINERS                                        |   9 ++
 arch/arm/boot/dts/exynos4412-odroidu3.dts          |   5 +
 drivers/mmc/Kconfig                                |   2 -
 drivers/mmc/core/Makefile                          |   3 -
 drivers/mmc/core/core.c                            |   8 +-
 drivers/mmc/core/host.c                            |   2 +-
 drivers/mmc/core/pwrseq.c                          | 110 ---------------
 drivers/mmc/core/pwrseq.h                          |  52 -------
 drivers/power/Kconfig                              |   1 +
 drivers/power/Makefile                             |   1 +
 drivers/{mmc/core => power/pwrseq}/Kconfig         |  22 ++-
 drivers/power/pwrseq/Makefile                      |   3 +
 drivers/power/pwrseq/pwrseq.c                      | 153 +++++++++++++++++++++
 drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c   |  17 +--
 drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 110 ++++++++++++---
 drivers/usb/core/hub.c                             |  16 ++-
 drivers/usb/core/hub.h                             |   3 +
 drivers/usb/core/port.c                            |  15 ++
 include/linux/mmc/host.h                           |   4 +-
 include/linux/pwrseq.h                             |  63 +++++++++
 22 files changed, 414 insertions(+), 214 deletions(-)
 rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-emmc.txt => power/pwrseq/pwrseq-emmc.txt} (100%)
 rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-simple.txt => power/pwrseq/pwrseq-simple.txt} (53%)
 delete mode 100644 drivers/mmc/core/pwrseq.c
 delete mode 100644 drivers/mmc/core/pwrseq.h
 rename drivers/{mmc/core => power/pwrseq}/Kconfig (60%)
 create mode 100644 drivers/power/pwrseq/Makefile
 create mode 100644 drivers/power/pwrseq/pwrseq.c
 rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (88%)
 rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (52%)
 create mode 100644 include/linux/pwrseq.h

-- 
1.9.1

[toc] | [next] | [standalone]

#1410926 — [PATCH v3 02/12] MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq

Before moving pwrseq drivers from drivers/mmc/core/ to drivers/power/,
they were maintained by Ulf Hansson.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
 MAINTAINERS | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4f2a75ce5442..71114607502a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9083,6 +9083,15 @@ F:	include/linux/power_supply.h
 F:	drivers/power/
 X:	drivers/power/avs/
 
+POWER SEQ CORE and DRIVERS
+M:	Ulf Hansson <ulf.hansson@linaro.org>
+L:	linux-mmc@vger.kernel.org
+T:	git git://git.linaro.org/people/ulf.hansson/mmc.git
+S:	Maintained
+F:	drivers/power/pwrseq/
+F:	include/linux/pwrseq.h
+F:	Documentation/devicetree/bindings/power/pwrseq/
+
 POWER STATE COORDINATION INTERFACE (PSCI)
 M:	Mark Rutland <mark.rutland@arm.com>
 M:	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1410927 — [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

Some devices need real hard-reset by cutting the power.  During power
sequence turn off and on the regulator, if it is provided.

Additionally add support for instantiating the pwrseq-simple device on a
generic property 'power-sequence'.  The device will attach itself to the
node containing the property and parse the node's properties like
reset-gpios, ext-supply etc.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
 .../bindings/power/pwrseq/pwrseq-simple.txt        | 29 +++++++-
 drivers/power/pwrseq/pwrseq_simple.c               | 85 +++++++++++++++++++++-
 2 files changed, 107 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
index ce0e76749671..a8c3f13ee83f 100644
--- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
@@ -1,11 +1,17 @@
-* The simple MMC power sequence provider
+* The simple power sequence provider
 
-The purpose of the simple MMC power sequence provider is to supports a set of
+The purpose of the simple power sequence provider is to supports a set of
 common properties between various SOC designs. It thus enables us to use the
 same provider for several SOC designs.
 
-Required properties:
-- compatible : contains "mmc-pwrseq-simple".
+The driver supports two types of bindings:
+1. Separate node
+   Required properties:
+   - compatible : contains "mmc-pwrseq-simple".
+
+2. Property for any node
+   Required properties:
+   - power-sequence
 
 Optional properties:
 - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
@@ -16,6 +22,7 @@ Optional properties:
   See ../clocks/clock-bindings.txt for details.
 - clock-names : Must include the following entry:
   "ext_clock" (External clock provided to the card).
+- ext-supply : External regulator supply
 
 Example:
 
@@ -24,4 +31,18 @@ Example:
 		reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
 		clocks = <&clk_32768_ck>;
 		clock-names = "ext_clock";
+		ext-supply = <&buck8>;
 	}
+
+	usb3503@08 {
+		compatible = "smsc,usb3503";
+		reg = <0x08>;
+
+		intn-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
+		connect-gpios = <&gpx3 4 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
+		initial-mode = <1>;
+
+		power-sequence;
+		ext-supply = <&buck8_reg>;
+	};
diff --git a/drivers/power/pwrseq/pwrseq_simple.c b/drivers/power/pwrseq/pwrseq_simple.c
index 93807a6ef162..4096261b16a4 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -1,12 +1,15 @@
 /*
- *  Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2016 Samsung Electronics
  *
  * Author: Ulf Hansson <ulf.hansson@linaro.org>
+ *         Krzysztof Kozlowski <k.kozlowski@samsung.com>
  *
  * License terms: GNU General Public License (GPL) version 2
  *
  *  Simple MMC power sequence management
  */
+#include <linux/of.h>
 #include <linux/clk.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
@@ -16,13 +19,16 @@
 #include <linux/device.h>
 #include <linux/err.h>
 #include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
 #include <linux/pwrseq.h>
+#include <linux/delay.h>
 
 struct mmc_pwrseq_simple {
 	struct pwrseq pwrseq;
 	bool clk_enabled;
 	struct clk *ext_clk;
 	struct gpio_descs *reset_gpios;
+	struct regulator *ext_reg;
 };
 
 #define to_pwrseq_simple(p) container_of(p, struct mmc_pwrseq_simple, pwrseq)
@@ -60,6 +66,13 @@ static void mmc_pwrseq_simple_post_power_on(struct pwrseq *_pwrseq)
 {
 	struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
 
+	if (pwrseq->ext_reg) {
+		int err;
+
+		err = regulator_enable(pwrseq->ext_reg);
+		WARN_ON_ONCE(err);
+	}
+
 	mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
 }
 
@@ -73,6 +86,13 @@ static void mmc_pwrseq_simple_power_off(struct pwrseq *_pwrseq)
 		clk_disable_unprepare(pwrseq->ext_clk);
 		pwrseq->clk_enabled = false;
 	}
+
+	if (pwrseq->ext_reg) {
+		int err;
+
+		err = regulator_disable(pwrseq->ext_reg);
+		WARN_ON_ONCE(err);
+	}
 }
 
 static const struct pwrseq_ops mmc_pwrseq_simple_ops = {
@@ -100,12 +120,40 @@ static int mmc_pwrseq_simple_probe(struct platform_device *pdev)
 	if (IS_ERR(pwrseq->ext_clk) && PTR_ERR(pwrseq->ext_clk) != -ENOENT)
 		return PTR_ERR(pwrseq->ext_clk);
 
+	pwrseq->ext_reg = devm_regulator_get_optional(dev, "ext");
+	if (IS_ERR(pwrseq->ext_reg)) {
+		if (PTR_ERR(pwrseq->ext_reg) == -ENODEV)
+			pwrseq->ext_reg = NULL;
+		else
+			return PTR_ERR(pwrseq->ext_reg);
+	} else {
+		int err;
+		/*
+		 * Be sure that regulator is off, before the driver will start
+		 * power sequence. It is likely that regulator is on by default
+		 * and it without toggling it here, it would be disabled much
+		 * later by the core.
+		 */
+
+		err = regulator_enable(pwrseq->ext_reg);
+		WARN_ON_ONCE(err);
+
+		err = regulator_disable(pwrseq->ext_reg);
+		WARN_ON_ONCE(err);
+	}
+
 	pwrseq->reset_gpios = devm_gpiod_get_array(dev, "reset",
 							GPIOD_OUT_HIGH);
 	if (IS_ERR(pwrseq->reset_gpios) &&
 	    PTR_ERR(pwrseq->reset_gpios) != -ENOENT &&
 	    PTR_ERR(pwrseq->reset_gpios) != -ENOSYS) {
-		return PTR_ERR(pwrseq->reset_gpios);
+		/*
+		 * Don't care about errors. If this pwrseq device was added
+		 * to node with existing reset-gpios, then the GPIO reset will
+		 * be handled by other device.
+		 */
+		dev_warn(dev, "Cannot get reset gpio: %ld\n",
+			 PTR_ERR(pwrseq->reset_gpios));
 	}
 
 	pwrseq->pwrseq.dev = dev;
@@ -122,6 +170,13 @@ static int mmc_pwrseq_simple_remove(struct platform_device *pdev)
 
 	pwrseq_unregister(&pwrseq->pwrseq);
 
+	if (pwrseq->ext_reg) {
+		int err;
+
+		err = regulator_disable(pwrseq->ext_reg);
+		WARN_ON_ONCE(err);
+	}
+
 	return 0;
 }
 
@@ -134,5 +189,29 @@ static struct platform_driver mmc_pwrseq_simple_driver = {
 	},
 };
 
-module_platform_driver(mmc_pwrseq_simple_driver);
+static int __init mmc_pwrseq_simple_driver_init(void)
+{
+	struct platform_device *pdev;
+	struct device_node *np;
+
+	for_each_node_with_property(np, "power-sequence") {
+		pdev = platform_device_register_simple("pwrseq_simple",
+						       PLATFORM_DEVID_AUTO,
+						       NULL, 0);
+		if (!IS_ERR(pdev)) {
+			of_node_get(np);
+			pdev->dev.of_node = np;
+		}
+	}
+
+	return platform_driver_register(&mmc_pwrseq_simple_driver);
+}
+module_init(mmc_pwrseq_simple_driver_init);
+
+static void __exit mmc_pwrseq_simple_driver_exit(void)
+{
+	/* FIXME: of_node_put? */
+	platform_driver_unregister(&mmc_pwrseq_simple_driver);
+}
+module_exit(mmc_pwrseq_simple_driver_exit);
 MODULE_LICENSE("GPL v2");
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1412695 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
> Some devices need real hard-reset by cutting the power.  During power
> sequence turn off and on the regulator, if it is provided.
> 
> Additionally add support for instantiating the pwrseq-simple device on a
> generic property 'power-sequence'.  The device will attach itself to the
> node containing the property and parse the node's properties like
> reset-gpios, ext-supply etc.
> 
> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> ---
>  .../bindings/power/pwrseq/pwrseq-simple.txt        | 29 +++++++-
>  drivers/power/pwrseq/pwrseq_simple.c               | 85 +++++++++++++++++++++-
>  2 files changed, 107 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> index ce0e76749671..a8c3f13ee83f 100644
> --- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> @@ -1,11 +1,17 @@
> -* The simple MMC power sequence provider
> +* The simple power sequence provider
>  
> -The purpose of the simple MMC power sequence provider is to supports a set of
> +The purpose of the simple power sequence provider is to supports a set of
>  common properties between various SOC designs. It thus enables us to use the
>  same provider for several SOC designs.
>  
> -Required properties:
> -- compatible : contains "mmc-pwrseq-simple".
> +The driver supports two types of bindings:
> +1. Separate node
> +   Required properties:
> +   - compatible : contains "mmc-pwrseq-simple".

Please note that this is not recommended for new users.

> +
> +2. Property for any node
> +   Required properties:
> +   - power-sequence
>  
>  Optional properties:
>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
> @@ -16,6 +22,7 @@ Optional properties:
>    See ../clocks/clock-bindings.txt for details.
>  - clock-names : Must include the following entry:
>    "ext_clock" (External clock provided to the card).
> +- ext-supply : External regulator supply

What happens when there are 2 supplies?

I'd prefer the name not be genericish and use the real supply names. 
Then the power seq code should just turn on all supplies it finds. If 
the order or timing to turn on matters, then sorry, no generic sequence.

>  
>  Example:
>  
> @@ -24,4 +31,18 @@ Example:
>  		reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
>  		clocks = <&clk_32768_ck>;
>  		clock-names = "ext_clock";
> +		ext-supply = <&buck8>;
>  	}
> +
> +	usb3503@08 {
> +		compatible = "smsc,usb3503";
> +		reg = <0x08>;
> +
> +		intn-gpios = <&gpx3 0 GPIO_ACTIVE_HIGH>;
> +		connect-gpios = <&gpx3 4 GPIO_ACTIVE_HIGH>;
> +		reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
> +		initial-mode = <1>;
> +
> +		power-sequence;
> +		ext-supply = <&buck8_reg>;
> +	};

[toc] | [prev] | [next] | [standalone]

#1413197 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On 06/03/2016 04:02 AM, Rob Herring wrote:
> On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
>> Some devices need real hard-reset by cutting the power.  During power
>> sequence turn off and on the regulator, if it is provided.
>>
>> Additionally add support for instantiating the pwrseq-simple device on a
>> generic property 'power-sequence'.  The device will attach itself to the
>> node containing the property and parse the node's properties like
>> reset-gpios, ext-supply etc.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>> ---
>>  .../bindings/power/pwrseq/pwrseq-simple.txt        | 29 +++++++-
>>  drivers/power/pwrseq/pwrseq_simple.c               | 85 +++++++++++++++++++++-
>>  2 files changed, 107 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
>> index ce0e76749671..a8c3f13ee83f 100644
>> --- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
>> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
>> @@ -1,11 +1,17 @@
>> -* The simple MMC power sequence provider
>> +* The simple power sequence provider
>>  
>> -The purpose of the simple MMC power sequence provider is to supports a set of
>> +The purpose of the simple power sequence provider is to supports a set of
>>  common properties between various SOC designs. It thus enables us to use the
>>  same provider for several SOC designs.
>>  
>> -Required properties:
>> -- compatible : contains "mmc-pwrseq-simple".
>> +The driver supports two types of bindings:
>> +1. Separate node
>> +   Required properties:
>> +   - compatible : contains "mmc-pwrseq-simple".
> 
> Please note that this is not recommended for new users.

Sure.

> 
>> +
>> +2. Property for any node
>> +   Required properties:
>> +   - power-sequence
>>  
>>  Optional properties:
>>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
>> @@ -16,6 +22,7 @@ Optional properties:
>>    See ../clocks/clock-bindings.txt for details.
>>  - clock-names : Must include the following entry:
>>    "ext_clock" (External clock provided to the card).
>> +- ext-supply : External regulator supply
> 
> What happens when there are 2 supplies?
> 
> I'd prefer the name not be genericish and use the real supply names. 
> Then the power seq code should just turn on all supplies it finds. If 
> the order or timing to turn on matters, then sorry, no generic sequence.

Understood. I'll change the code to use any supply.

As for the genericness of this approach, Sylwester Nawrocki pointed an
old thread:
[PATCH v6 0/4] Runtime Interpreted Power Sequences
https://lkml.org/lkml/2012/9/12/127

How do you like that approach?

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1414581 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On Fri, Jun 03, 2016 at 02:35:08PM +0200, Krzysztof Kozlowski wrote:
> On 06/03/2016 04:02 AM, Rob Herring wrote:
> > On Wed, Jun 01, 2016 at 10:02:15AM +0200, Krzysztof Kozlowski wrote:
> >> Some devices need real hard-reset by cutting the power.  During power
> >> sequence turn off and on the regulator, if it is provided.
> >>
> >> Additionally add support for instantiating the pwrseq-simple device on a
> >> generic property 'power-sequence'.  The device will attach itself to the
> >> node containing the property and parse the node's properties like
> >> reset-gpios, ext-supply etc.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> >> ---
> >>  .../bindings/power/pwrseq/pwrseq-simple.txt        | 29 +++++++-
> >>  drivers/power/pwrseq/pwrseq_simple.c               | 85 +++++++++++++++++++++-
> >>  2 files changed, 107 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> index ce0e76749671..a8c3f13ee83f 100644
> >> --- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> +++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> >> @@ -1,11 +1,17 @@
> >> -* The simple MMC power sequence provider
> >> +* The simple power sequence provider
> >>  
> >> -The purpose of the simple MMC power sequence provider is to supports a set of
> >> +The purpose of the simple power sequence provider is to supports a set of
> >>  common properties between various SOC designs. It thus enables us to use the
> >>  same provider for several SOC designs.
> >>  
> >> -Required properties:
> >> -- compatible : contains "mmc-pwrseq-simple".
> >> +The driver supports two types of bindings:
> >> +1. Separate node
> >> +   Required properties:
> >> +   - compatible : contains "mmc-pwrseq-simple".
> > 
> > Please note that this is not recommended for new users.
> 
> Sure.
> 
> > 
> >> +
> >> +2. Property for any node
> >> +   Required properties:
> >> +   - power-sequence
> >>  
> >>  Optional properties:
> >>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
> >> @@ -16,6 +22,7 @@ Optional properties:
> >>    See ../clocks/clock-bindings.txt for details.
> >>  - clock-names : Must include the following entry:
> >>    "ext_clock" (External clock provided to the card).
> >> +- ext-supply : External regulator supply
> > 
> > What happens when there are 2 supplies?
> > 
> > I'd prefer the name not be genericish and use the real supply names. 
> > Then the power seq code should just turn on all supplies it finds. If 
> > the order or timing to turn on matters, then sorry, no generic sequence.
> 
> Understood. I'll change the code to use any supply.
> 
> As for the genericness of this approach, Sylwester Nawrocki pointed an
> old thread:
> [PATCH v6 0/4] Runtime Interpreted Power Sequences
> https://lkml.org/lkml/2012/9/12/127
> 
> How do you like that approach?
> 

Rob, I am trying to implement the dts layout you suggested (see below),
but I find it is very hard to it due to the device is still not created,
without device, it is hard to manage the resources under this device (
Eg, de-initialization for probe deferral case). So, a common driver
is suitable for this power sequence case.

&usbotg1 {
        vbus-supply = <&reg_usb_otg1_vbus>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_usb_otg1_id>;
        status = "okay";

        #address-cells = <1>;
        #size-cells = <0>;
        hub: genesys@1 {
                compatible = "usb5e3,608";
                reg = <1>;
                reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* hub reset pin */
                reset-duration-us = <10>;
                clocks = <&clks IMX6SX_CLK_CKO>;
        };
};

-- 

Best Regards,
Peter Chen

[toc] | [prev] | [next] | [standalone]

#1415926 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On 06/03/2016 04:02 AM, Rob Herring wrote:
>>  Optional properties:
>>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
>> @@ -16,6 +22,7 @@ Optional properties:
>>    See ../clocks/clock-bindings.txt for details.
>>  - clock-names : Must include the following entry:
>>    "ext_clock" (External clock provided to the card).
>> +- ext-supply : External regulator supply
> 
> What happens when there are 2 supplies?
> 
> I'd prefer the name not be genericish and use the real supply names. 
> Then the power seq code should just turn on all supplies it finds. If 
> the order or timing to turn on matters, then sorry, no generic sequence.

I think the generic part for regulators might be a problem. Regulator
API requires a name for the supply... it cannot get "something" or
"everything".

The driver could attach itself to any kind of node (where power-sequence
property exists) so the supply name depends on the bindings of device
(not bindings of power sequence driver).

The power sequence driver could however iterate over child properties
and get the names of all supplies. It is a little bit ugly...

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1417780 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote:
> On 06/03/2016 04:02 AM, Rob Herring wrote:
> >>  Optional properties:
> >>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
> >> @@ -16,6 +22,7 @@ Optional properties:
> >>    See ../clocks/clock-bindings.txt for details.
> >>  - clock-names : Must include the following entry:
> >>    "ext_clock" (External clock provided to the card).
> >> +- ext-supply : External regulator supply
> > 
> > What happens when there are 2 supplies?
> > 
> > I'd prefer the name not be genericish and use the real supply names. 
> > Then the power seq code should just turn on all supplies it finds. If 
> > the order or timing to turn on matters, then sorry, no generic sequence.
> 
> I think the generic part for regulators might be a problem. Regulator
> API requires a name for the supply... it cannot get "something" or
> "everything".

That's the downside of variable property names...

> The driver could attach itself to any kind of node (where power-sequence
> property exists) so the supply name depends on the bindings of device
> (not bindings of power sequence driver).
> 
> The power sequence driver could however iterate over child properties
> and get the names of all supplies. It is a little bit ugly...

Yes. Like this, right?

for_each_property_of_node(np, pp) {
	if (!strstr(pp->name, "-supply"))
		continue;
	// found supply
}

The uglyness can always be improved with a function to do this parsing.

Rob

[toc] | [prev] | [next] | [standalone]

#1418021 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

Hi

On Thu, Jun 9, 2016 at 3:03 AM, Rob Herring <robh@kernel.org> wrote:
> On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote:
>> On 06/03/2016 04:02 AM, Rob Herring wrote:
>> >>  Optional properties:
>> >>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
>> >> @@ -16,6 +22,7 @@ Optional properties:
>> >>    See ../clocks/clock-bindings.txt for details.
>> >>  - clock-names : Must include the following entry:
>> >>    "ext_clock" (External clock provided to the card).
>> >> +- ext-supply : External regulator supply
>> >
>> > What happens when there are 2 supplies?
>> >
>> > I'd prefer the name not be genericish and use the real supply names.
>> > Then the power seq code should just turn on all supplies it finds. If
>> > the order or timing to turn on matters, then sorry, no generic sequence.
>>
>> I think the generic part for regulators might be a problem. Regulator
>> API requires a name for the supply... it cannot get "something" or
>> "everything".
>
> That's the downside of variable property names...
>
>> The driver could attach itself to any kind of node (where power-sequence
>> property exists) so the supply name depends on the bindings of device
>> (not bindings of power sequence driver).
>>
>> The power sequence driver could however iterate over child properties
>> and get the names of all supplies. It is a little bit ugly...
>
> Yes. Like this, right?
>
> for_each_property_of_node(np, pp) {
>         if (!strstr(pp->name, "-supply"))
>                 continue;
>         // found supply
> }
>
> The uglyness can always be improved with a function to do this parsing.

There's already a version of this in simplefb. Maybe it's time to move
this to a common function?

ChenYu

[toc] | [prev] | [next] | [standalone]

#1418087 — Re: [PATCH v3 06/12] power: pwrseq: simple: Add support for regulator and generic property

On 06/09/2016 04:34 AM, Chen-Yu Tsai wrote:
> Hi
> 
> On Thu, Jun 9, 2016 at 3:03 AM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Jun 07, 2016 at 11:29:02AM +0200, Krzysztof Kozlowski wrote:
>>> On 06/03/2016 04:02 AM, Rob Herring wrote:
>>>>>  Optional properties:
>>>>>  - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
>>>>> @@ -16,6 +22,7 @@ Optional properties:
>>>>>    See ../clocks/clock-bindings.txt for details.
>>>>>  - clock-names : Must include the following entry:
>>>>>    "ext_clock" (External clock provided to the card).
>>>>> +- ext-supply : External regulator supply
>>>>
>>>> What happens when there are 2 supplies?
>>>>
>>>> I'd prefer the name not be genericish and use the real supply names.
>>>> Then the power seq code should just turn on all supplies it finds. If
>>>> the order or timing to turn on matters, then sorry, no generic sequence.
>>>
>>> I think the generic part for regulators might be a problem. Regulator
>>> API requires a name for the supply... it cannot get "something" or
>>> "everything".
>>
>> That's the downside of variable property names...
>>
>>> The driver could attach itself to any kind of node (where power-sequence
>>> property exists) so the supply name depends on the bindings of device
>>> (not bindings of power sequence driver).
>>>
>>> The power sequence driver could however iterate over child properties
>>> and get the names of all supplies. It is a little bit ugly...
>>
>> Yes. Like this, right?
>>
>> for_each_property_of_node(np, pp) {
>>         if (!strstr(pp->name, "-supply"))
>>                 continue;
>>         // found supply
>> }
>>
>> The uglyness can always be improved with a function to do this parsing.
> 
> There's already a version of this in simplefb. Maybe it's time to move
> this to a common function?

Thanks, I'll make a generic one and let's see how Mark will respond to it.

Best regards,
Krzysztof

[toc] | [prev] | [next] | [standalone]

#1410929 — [PATCH v3 10/12] EXAMPLE CODE: usb: hub: Power sequence the ports on activation

The autodetection of attached USB device might not work on certain
boards where the power is delivered externally.  These devices also might
require a hard reset.  Use pwrseq for that in USB hub.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
 drivers/usb/core/hub.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c421745b84aa..46d9f9aedacc 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
 #include <linux/mutex.h>
 #include <linux/random.h>
 #include <linux/pm_qos.h>
+#include <linux/pwrseq.h>
 
 #include <asm/uaccess.h>
 #include <asm/byteorder.h>
@@ -1663,6 +1664,15 @@ static int hub_configure(struct usb_hub *hub,
 
 	usb_hub_adjust_deviceremovable(hdev, hub->descriptor);
 
+	/* FIXME: When do the pre-power-on? */
+	/*
+	for (i = 0; i < maxchild; i++)
+		pwrseq_pre_power_on(hub->ports[i]->pwrseq);
+	*/
+
+	for (i = 0; i < maxchild; i++)
+		pwrseq_post_power_on(hub->ports[i]->pwrseq);
+
 	hub_activate(hub, HUB_INIT);
 	return 0;
 
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1410931 — [PATCH v3 04/12] power: pwrseq: Remove mmc prefix from mmc_pwrseq

The "mmc" prefix is no longer needed after moving the pwrseq core code
from mmc/ to power/.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
 drivers/power/pwrseq/pwrseq.c        | 18 +++++++++---------
 drivers/power/pwrseq/pwrseq_emmc.c   |  8 ++++----
 drivers/power/pwrseq/pwrseq_simple.c |  8 ++++----
 include/linux/mmc/host.h             |  4 ++--
 include/linux/pwrseq.h               | 20 ++++++++++----------
 5 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 66310d7643cc..9c665821f890 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -21,7 +21,7 @@ static LIST_HEAD(pwrseq_list);
 int mmc_pwrseq_alloc(struct mmc_host *host)
 {
 	struct device_node *np;
-	struct mmc_pwrseq *p;
+	struct pwrseq *p;
 
 	np = of_parse_phandle(host->parent->of_node, "mmc-pwrseq", 0);
 	if (!np)
@@ -54,7 +54,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
 
 void mmc_pwrseq_pre_power_on(struct mmc_host *host)
 {
-	struct mmc_pwrseq *pwrseq = host->pwrseq;
+	struct pwrseq *pwrseq = host->pwrseq;
 
 	if (pwrseq && pwrseq->ops->pre_power_on)
 		pwrseq->ops->pre_power_on(host);
@@ -63,7 +63,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
 
 void mmc_pwrseq_post_power_on(struct mmc_host *host)
 {
-	struct mmc_pwrseq *pwrseq = host->pwrseq;
+	struct pwrseq *pwrseq = host->pwrseq;
 
 	if (pwrseq && pwrseq->ops->post_power_on)
 		pwrseq->ops->post_power_on(host);
@@ -72,7 +72,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
 
 void mmc_pwrseq_power_off(struct mmc_host *host)
 {
-	struct mmc_pwrseq *pwrseq = host->pwrseq;
+	struct pwrseq *pwrseq = host->pwrseq;
 
 	if (pwrseq && pwrseq->ops->power_off)
 		pwrseq->ops->power_off(host);
@@ -81,7 +81,7 @@ EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
 
 void mmc_pwrseq_free(struct mmc_host *host)
 {
-	struct mmc_pwrseq *pwrseq = host->pwrseq;
+	struct pwrseq *pwrseq = host->pwrseq;
 
 	if (pwrseq) {
 		module_put(pwrseq->owner);
@@ -90,7 +90,7 @@ void mmc_pwrseq_free(struct mmc_host *host)
 }
 EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
 
-int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq)
+int pwrseq_register(struct pwrseq *pwrseq)
 {
 	if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
 		return -EINVAL;
@@ -101,9 +101,9 @@ int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq)
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(mmc_pwrseq_register);
+EXPORT_SYMBOL_GPL(pwrseq_register);
 
-void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq)
+void pwrseq_unregister(struct pwrseq *pwrseq)
 {
 	if (pwrseq) {
 		mutex_lock(&pwrseq_list_mutex);
@@ -111,4 +111,4 @@ void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq)
 		mutex_unlock(&pwrseq_list_mutex);
 	}
 }
-EXPORT_SYMBOL_GPL(mmc_pwrseq_unregister);
+EXPORT_SYMBOL_GPL(pwrseq_unregister);
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c b/drivers/power/pwrseq/pwrseq_emmc.c
index a0583ed46d7f..a68ac9a68e04 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -22,7 +22,7 @@
 #include <linux/mmc/host.h>
 
 struct mmc_pwrseq_emmc {
-	struct mmc_pwrseq pwrseq;
+	struct pwrseq pwrseq;
 	struct notifier_block reset_nb;
 	struct gpio_desc *reset_gpio;
 };
@@ -54,7 +54,7 @@ static int mmc_pwrseq_emmc_reset_nb(struct notifier_block *this,
 	return NOTIFY_DONE;
 }
 
-static const struct mmc_pwrseq_ops mmc_pwrseq_emmc_ops = {
+static const struct pwrseq_ops mmc_pwrseq_emmc_ops = {
 	.post_power_on = mmc_pwrseq_emmc_reset,
 };
 
@@ -85,7 +85,7 @@ static int mmc_pwrseq_emmc_probe(struct platform_device *pdev)
 	pwrseq->pwrseq.owner = THIS_MODULE;
 	platform_set_drvdata(pdev, pwrseq);
 
-	return mmc_pwrseq_register(&pwrseq->pwrseq);
+	return pwrseq_register(&pwrseq->pwrseq);
 }
 
 static int mmc_pwrseq_emmc_remove(struct platform_device *pdev)
@@ -93,7 +93,7 @@ static int mmc_pwrseq_emmc_remove(struct platform_device *pdev)
 	struct mmc_pwrseq_emmc *pwrseq = platform_get_drvdata(pdev);
 
 	unregister_restart_handler(&pwrseq->reset_nb);
-	mmc_pwrseq_unregister(&pwrseq->pwrseq);
+	pwrseq_unregister(&pwrseq->pwrseq);
 
 	return 0;
 }
diff --git a/drivers/power/pwrseq/pwrseq_simple.c b/drivers/power/pwrseq/pwrseq_simple.c
index 786f1db53a3f..d5fbd653153e 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -21,7 +21,7 @@
 #include <linux/mmc/host.h>
 
 struct mmc_pwrseq_simple {
-	struct mmc_pwrseq pwrseq;
+	struct pwrseq pwrseq;
 	bool clk_enabled;
 	struct clk *ext_clk;
 	struct gpio_descs *reset_gpios;
@@ -77,7 +77,7 @@ static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
 	}
 }
 
-static const struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
+static const struct pwrseq_ops mmc_pwrseq_simple_ops = {
 	.pre_power_on = mmc_pwrseq_simple_pre_power_on,
 	.post_power_on = mmc_pwrseq_simple_post_power_on,
 	.power_off = mmc_pwrseq_simple_power_off,
@@ -115,14 +115,14 @@ static int mmc_pwrseq_simple_probe(struct platform_device *pdev)
 	pwrseq->pwrseq.owner = THIS_MODULE;
 	platform_set_drvdata(pdev, pwrseq);
 
-	return mmc_pwrseq_register(&pwrseq->pwrseq);
+	return pwrseq_register(&pwrseq->pwrseq);
 }
 
 static int mmc_pwrseq_simple_remove(struct platform_device *pdev)
 {
 	struct mmc_pwrseq_simple *pwrseq = platform_get_drvdata(pdev);
 
-	mmc_pwrseq_unregister(&pwrseq->pwrseq);
+	pwrseq_unregister(&pwrseq->pwrseq);
 
 	return 0;
 }
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 45cde8cd39f2..f3e29f4b7f30 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -203,7 +203,7 @@ struct mmc_context_info {
 };
 
 struct regulator;
-struct mmc_pwrseq;
+struct pwrseq;
 
 struct mmc_supply {
 	struct regulator *vmmc;		/* Card power supply */
@@ -215,7 +215,7 @@ struct mmc_host {
 	struct device		class_dev;
 	int			index;
 	const struct mmc_host_ops *ops;
-	struct mmc_pwrseq	*pwrseq;
+	struct pwrseq		*pwrseq;
 	unsigned int		f_min;
 	unsigned int		f_max;
 	unsigned int		f_init;
diff --git a/include/linux/pwrseq.h b/include/linux/pwrseq.h
index e230670c1d8d..6d2d2a44ad35 100644
--- a/include/linux/pwrseq.h
+++ b/include/linux/pwrseq.h
@@ -5,19 +5,19 @@
  *
  * License terms: GNU General Public License (GPL) version 2
  */
-#ifndef _MMC_CORE_PWRSEQ_H
-#define _MMC_CORE_PWRSEQ_H
+#ifndef _LINUX_PWRSEQ_H
+#define _LINUX_PWRSEQ_H
 
 #include <linux/mmc/host.h>
 
-struct mmc_pwrseq_ops {
+struct pwrseq_ops {
 	void (*pre_power_on)(struct mmc_host *host);
 	void (*post_power_on)(struct mmc_host *host);
 	void (*power_off)(struct mmc_host *host);
 };
 
-struct mmc_pwrseq {
-	const struct mmc_pwrseq_ops *ops;
+struct pwrseq {
+	const struct pwrseq_ops *ops;
 	struct device *dev;
 	struct list_head pwrseq_node;
 	struct module *owner;
@@ -25,8 +25,8 @@ struct mmc_pwrseq {
 
 #ifdef CONFIG_POWER_SEQ
 
-int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq);
-void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq);
+int pwrseq_register(struct pwrseq *pwrseq);
+void pwrseq_unregister(struct pwrseq *pwrseq);
 
 int mmc_pwrseq_alloc(struct mmc_host *host);
 void mmc_pwrseq_pre_power_on(struct mmc_host *host);
@@ -36,11 +36,11 @@ void mmc_pwrseq_free(struct mmc_host *host);
 
 #else /* CONFIG_POWER_SEQ */
 
-static inline int mmc_pwrseq_register(struct mmc_pwrseq *pwrseq)
+static inline int pwrseq_register(struct pwrseq *pwrseq)
 {
 	return -ENOSYS;
 }
-static inline void mmc_pwrseq_unregister(struct mmc_pwrseq *pwrseq) {}
+static inline void pwrseq_unregister(struct pwrseq *pwrseq) {}
 static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
 static inline void mmc_pwrseq_pre_power_on(struct mmc_host *host) {}
 static inline void mmc_pwrseq_post_power_on(struct mmc_host *host) {}
@@ -49,4 +49,4 @@ static inline void mmc_pwrseq_free(struct mmc_host *host) {}
 
 #endif /* CONFIG_POWER_SEQ */
 
-#endif
+#endif /* _LINUX_PWRSEQ_H */
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1410932 — [PATCH v3 03/12] power: pwrseq: Enable COMPILE_TEST for drivers

Allow build testing for power sequence drivers.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
 drivers/power/pwrseq/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
index 7ecd66ab61f3..c7e9271fd94f 100644
--- a/drivers/power/pwrseq/Kconfig
+++ b/drivers/power/pwrseq/Kconfig
@@ -10,7 +10,7 @@ if POWER_SEQ
 config POWER_SEQ_EMMC
 	tristate "HW reset support for eMMC"
 	default y
-	depends on OF
+	depends on OF || COMPILE_TEST
 	help
 	  This selects Hardware reset support aka pwrseq-emmc for eMMC
 	  devices. By default this option is set to y.
@@ -21,7 +21,7 @@ config POWER_SEQ_EMMC
 config POWER_SEQ_SIMPLE
 	tristate "Simple HW reset support for MMC"
 	default y
-	depends on OF
+	depends on OF || COMPILE_TEST
 	help
 	  This selects simple hardware reset support aka pwrseq-simple for MMC
 	  devices. By default this option is set to y.
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1415431 — Re: [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)

Hi,

Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski:
> My third approach for a USB power sequence which fixes usb3503+lan
> on Odroid U3 board if it was initialized by bootloader
> (e.g. for TFTP boot).

I was just tackling a similar bringup problem regarding an embedded usb hub 
and usb-sata bridge and stumbled upon this series.

While on my (rockchip-)boards it's always "just" a reset pin that needs 
handling, this series looks like it would solve exactly that problem in a very 
nice way.

So while I cannot provide any meaningful insight right now, it would be cool 
if you could keep me in the loop, as I'm really looking forward to this series 
progressing.


Thanks
Heiko


> Changes since v2
> ================
> 1. Add Javier's reviewed-by tags. Address some comments.
> 2. Re-use existing properties for GPIOs etc by pwrseq-simple
>    driver.  New property is still added: "power-sequence".
>    I tried to address and do according to Rob's comments.
> 
>    Please look at patch 6/12 ("power: pwrseq: simple: Add support
>    for regulator and generic property") for bindings and the
>    new code around matching "power-sequence" property.
> 
> 3. I marked the usb code as "EXAMPLE" because that part
>    is left to Peter Chen.
> 
> 
> Problem
> =======
> When Odroid U3 (usb3503 + smsc95xx + max77686) boots from network (TFTP),
> the usb3503 and LAN smsc95xx do not show up in "lsusb". Hard-reset
> is required, e.g. by suspend to RAM. The actual TFTP boot does
> not have to happen. Just "usb start" from U-Boot is sufficient.
> 
> From the schematics, the regulator is a supply only to LAN, however
> without toggling it off/on, the usb3503 hub won appear neither.
> 
> 
> Solution
> ========
> This is very similar to the MMC pwrseq behavior so the idea is to:
> 1. Move MMC pwrseq drivers to generic place,
> 2. Extend the pwrseq-simple with regulator toggling,
> 3. Add support to USB hub and port core for pwrseq,
> 4. Toggle the regulator when needed.
> 
> Best regards,
> Krzysztof
> 
> Krzysztof Kozlowski (12):
>   power/mmc: Move pwrseq drivers to power/pwrseq
>   MAINTAINERS: Retain Ulf Hansson as the same maintainer of pwrseq
>   power: pwrseq: Enable COMPILE_TEST for drivers
>   power: pwrseq: Remove mmc prefix from mmc_pwrseq
>   power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
>   power: pwrseq: simple: Add support for regulator and generic property
>   power: pwrseq: Add support for USB hubs with external power
>   usb: hub: Handle deferred probe
>   EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
>   EXAMPLE CODE: usb: hub: Power sequence the ports on activation
>   ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
>   ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on
>     Odroid U3
> 
>  .../pwrseq/pwrseq-emmc.txt}                        |   0
>  .../pwrseq/pwrseq-simple.txt}                      |  29 +++-
>  MAINTAINERS                                        |   9 ++
>  arch/arm/boot/dts/exynos4412-odroidu3.dts          |   5 +
>  drivers/mmc/Kconfig                                |   2 -
>  drivers/mmc/core/Makefile                          |   3 -
>  drivers/mmc/core/core.c                            |   8 +-
>  drivers/mmc/core/host.c                            |   2 +-
>  drivers/mmc/core/pwrseq.c                          | 110 ---------------
>  drivers/mmc/core/pwrseq.h                          |  52 -------
>  drivers/power/Kconfig                              |   1 +
>  drivers/power/Makefile                             |   1 +
>  drivers/{mmc/core => power/pwrseq}/Kconfig         |  22 ++-
>  drivers/power/pwrseq/Makefile                      |   3 +
>  drivers/power/pwrseq/pwrseq.c                      | 153
> +++++++++++++++++++++ drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c   | 
> 17 +--
>  drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 110 ++++++++++++---
>  drivers/usb/core/hub.c                             |  16 ++-
>  drivers/usb/core/hub.h                             |   3 +
>  drivers/usb/core/port.c                            |  15 ++
>  include/linux/mmc/host.h                           |   4 +-
>  include/linux/pwrseq.h                             |  63 +++++++++
>  22 files changed, 414 insertions(+), 214 deletions(-)
>  rename Documentation/devicetree/bindings/{mmc/mmc-pwrseq-emmc.txt =>
> power/pwrseq/pwrseq-emmc.txt} (100%) rename
> Documentation/devicetree/bindings/{mmc/mmc-pwrseq-simple.txt =>
> power/pwrseq/pwrseq-simple.txt} (53%) delete mode 100644
> drivers/mmc/core/pwrseq.c
>  delete mode 100644 drivers/mmc/core/pwrseq.h
>  rename drivers/{mmc/core => power/pwrseq}/Kconfig (60%)
>  create mode 100644 drivers/power/pwrseq/Makefile
>  create mode 100644 drivers/power/pwrseq/pwrseq.c
>  rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (88%)
>  rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (52%)
>  create mode 100644 include/linux/pwrseq.h

[toc] | [prev] | [next] | [standalone]

#1415722

On 06/06/2016 10:43 PM, Heiko Stübner wrote:
> Hi,
> 
> Am Mittwoch, 1. Juni 2016, 10:02:09 schrieb Krzysztof Kozlowski:
>> My third approach for a USB power sequence which fixes usb3503+lan
>> on Odroid U3 board if it was initialized by bootloader
>> (e.g. for TFTP boot).
> 
> I was just tackling a similar bringup problem regarding an embedded usb hub 
> and usb-sata bridge and stumbled upon this series.
> 
> While on my (rockchip-)boards it's always "just" a reset pin that needs 
> handling, this series looks like it would solve exactly that problem in a very 
> nice way.
> 
> So while I cannot provide any meaningful insight right now, it would be cool 
> if you could keep me in the loop, as I'm really looking forward to this series 
> progressing.
> 

Sure, good to know that this problem affects more people. I do not feel
such alone anymore. ;)

Best regards,
Krzysztof

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web