Re: [RFT PATCH 1/3] usb: misc: usb3503: Fix HUB mode after bootloader initialization
On 05/03/2016 08:00 PM, Rob Herring wrote: > On Mon, May 02, 2016 at 11:55:01AM +0100, Mark Brown wrote: >> On Mon, May 02, 2016 at 11:49:12AM +0200, Krzysztof Kozlowski wrote: >> >>> This VDD regulator supply actually is not a usb3503 USB HUB regulator >>> supply... but a supply to the LAN attached to this HUB. Regulator off/on >>> is needed for LAN to show up. The hub will show up with typical reset >>> (which is also missing before my patchset btw). >> >>> The LAN, as a USB device, is auto-probed so it cannot take the regulator >>> and play with it. The simplest idea I have is to add it as "external >>> supply" to the parent: usb3503. >> >> This is common enough that that just isn't going to scale well I fear >> without some generic handling, either walking child devices at the bus >> level or at the device level with a pre-probe() callback to get the >> device to power on. The latter is more appropriate to things like >> Slimbus where the device is more likely to do active management at >> runtime, it's not clear people are building USB devices like that. > > There's a new binding and support in -next (.../usb/usb-device.txt) for > USB devices that should help here. Though, how to handle a hub on USB > and I2C buses would need to be worked out. This binding might help, especially with other idea we have - usage of pwrseq for the USB hub. The USB hub, without toggling the regulator off/on, appears as USB device only sometimes. Apparently there is some timing or other behavior. not yet known to me. When playing with regulator, the USB hub and child USB device (LAN) will appear correctly. This looks like pwrseq for MMC devices so the idea is to: 1. Move drivers/mmc/core/pwrseq* to separate directory (drivers/power/pwrseq ?) 2. Add support for pwrseq to USB core, 3. Add new pwrseq driver (or extend existing one): toggling the regulator. 4. Add pwrseq phandle to the DT node of USB hub (to the binding mentioned by Rob?). Does it look sensible? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 05/13] 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
---
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
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
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
[RFC v2 11/13] usb: port: Parse pwrseq phandle from Device Tree
Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
device. The pwrseq device will be used by USB hub to cycle the power
before activating ports.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.h | 3 +++
drivers/usb/core/port.c | 15 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e22aae..68ca89780d26 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -24,6 +24,8 @@
#include
#include "usb.h"
+struct pwrseq;
+
struct usb_hub {
struct device *intfdev; /* the "interface" device */
struct usb_device *hdev;
@@ -101,6 +103,7 @@ struct usb_port {
struct usb_dev_state *port_owner;
struct usb_port *peer;
struct dev_pm_qos_request *req;
+ struct pwrseq *pwrseq;
enum usb_port_connect_type connect_type;
usb_port_location_t location;
struct mutex status_lock;
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 14718a9ffcfb..a875bd342452 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+#include
#include "hub.h"
@@ -532,6 +534,14 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
port1)
return retval;
}
+ port_dev->dev.of_node = usb_of_get_child_node(hub->hdev->dev.of_node,
port1);
+ port_dev->pwrseq = pwrseq_alloc(&port_dev->dev);
+ if (IS_ERR(port_dev->pwrseq)) {
+ device_unregister(&port_dev->dev);
+ /* TODO: what about EPROBE_DEFER? */
+ return PTR_ERR(port_dev->pwrseq);
+ }
+
find_and_link_peer(hub, port1);
/*
@@ -573,8 +583,13 @@ void usb_hub_remove_port_device(struct usb_hub *hub, int
port1)
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_port *peer;
+ pwrseq_power_off(port_dev->pwrseq);
+
peer = port_dev->peer;
if (peer)
unlink_peers(port_dev, peer);
+
+ pwrseq_free(port_dev->pwrseq);
+ port_dev->pwrseq = NULL;
device_unregister(&port_dev->dev);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
Hi,
This is a different, second try to fix usb3503+lan on Odroid U3 board
if it was initialized by bootloader (e.g. for TFTP boot).
First version:
http://www.spinics.net/lists/linux-usb/msg140042.html
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.
Issues
==
I am not familiar with USB subsystem, so please kindly guide me
where USB related code should be placed.
In the code there are still some issues to solve (FIXME/TODO notes).
If the approach is okay, I will improve the patchset. However at this
point - IT WORKS, which is nice. :)
Best regards,
Krzysztof
Krzysztof Kozlowski (13):
usb: misc: usb3503: Clean up on driver unbind
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 toggling regulator
usb: hub: Handle deferred probe
power: pwrseq: Add support for USB hubs with external power
usb: hub: Power sequence the ports on activation
usb: port: Parse pwrseq phandle from Device Tree
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
.../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 +
MAINTAINERS| 8 +++
arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 7 ++
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.h | 52 --
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 21 --
drivers/power/pwrseq/Makefile | 3 +
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 80 +-
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 15 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 73
drivers/usb/core/hub.c | 17 -
drivers/usb/core/hub.h | 3 +
drivers/usb/core/port.c| 15
drivers/usb/misc/usb3503.c | 28
include/linux/mmc/host.h | 4 +-
include/linux/pwrseq.h | 60
22 files changed, 294 insertions(+), 113 deletions(-)
delete mode 100644 drivers/mmc/core/pwrseq.h
rename drivers/{mmc/core => power/pwrseq}/Kconfig (65%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (50%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (89%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (64%)
create mode 100644 include/linux/pwrseq.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 12/13] ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
Switch the control of buck8 to GPIO mode. It is faster than I2C/register mode and it is the easiest way to disable it (regulator state is a logical OR state of GPIO and register value). Signed-off-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts index d73aa6c58fe3..31cdc036fda4 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts @@ -74,6 +74,7 @@ regulator-name = "BUCK8_P3V3"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; + maxim,ena-gpios = <&gpa1 1 GPIO_ACTIVE_HIGH>; }; /* VDDQ for MSHC (eMMC card) */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 04/13] power: pwrseq: Enable COMPILE_TEST for drivers
Allow build testing for power sequence drivers. Signed-off-by: Krzysztof Kozlowski --- 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 b5d2d6c65f28..4731ba01a958 100644 --- a/drivers/power/pwrseq/Kconfig +++ b/drivers/power/pwrseq/Kconfig @@ -9,7 +9,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. @@ -20,7 +20,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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 10/13] 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 --- drivers/usb/core/hub.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 1c82fcc448f5..0fddaacc62bf 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -26,6 +26,7 @@ #include #include #include +#include #include #include @@ -1661,7 +1662,17 @@ 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; fail: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 13/13] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
and LAN (smsc95xx) after after successful probing were not visible in the
system ("lsusb").
In such case the devices had to be fully reset before configuring.
Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
in usb3503 HUB are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 14e653e32e0f..efa204a85c83 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -67,7 +67,7 @@
};
};
- emmc_pwrseq: pwrseq {
+ emmc_pwrseq: pwrseq1 {
pinctrl-0 = <&sd1_cd>;
pinctrl-names = "default";
compatible = "mmc-pwrseq-emmc";
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 31cdc036fda4..3da0e6b3c32a 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -41,6 +41,11 @@
cooling-levels = <0 102 170 230>;
};
+ lan_pwrseq: pwrseq2 {
+ compatible = "mmc-pwrseq-simple";
+ ext-supply = <&buck8_reg>;
+ };
+
thermal-zones {
cpu_thermal: cpu-thermal {
cooling-maps {
@@ -104,6 +109,7 @@
&ehci {
port@1 {
status = "okay";
+ usb-pwrseq = <&lan_pwrseq>;
};
port@2 {
status = "okay";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 08/13] usb: hub: Handle deferred probe
Add support for deferred probing to the usb hub. Currently EPROBE_DEFER does not exist in usb hub path but future patches will add it on the port level. Signed-off-by: Krzysztof Kozlowski --- drivers/usb/core/hub.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 38cc4bae0a82..1c82fcc448f5 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1731,6 +1731,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) struct usb_endpoint_descriptor *endpoint; struct usb_device *hdev; struct usb_hub *hub; + int ret; desc = intf->cur_altsetting; hdev = interface_to_usbdev(intf); @@ -1850,11 +1851,12 @@ descriptor_error: if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) hub->quirk_check_port_auto_suspend = 1; - if (hub_configure(hub, endpoint) >= 0) + ret = hub_configure(hub, endpoint); + if (ret >= 0) return 0; hub_disconnect(intf); - return -ENODEV; + return ret; } static int -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 06/13] power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
The power sequence hooks (mmc_pwrseq_pre_power_on(),
mmc_pwrseq_post_power_on() and mmc_pwrseq_power_off()) can be made more
generic to allow re-use in other subsystems. They do not need to take
pointer to struct mmc_host but instead the struct pwrseq should be
sufficient.
Remove the "mmc" prefix and use the pointer to struct pwrseq as
argument.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mmc/core/core.c | 6 +++---
drivers/power/pwrseq/pwrseq.c| 24 +---
drivers/power/pwrseq/pwrseq_emmc.c | 4 ++--
drivers/power/pwrseq/pwrseq_simple.c | 12 ++--
include/linux/pwrseq.h | 18 +-
5 files changed, 29 insertions(+), 35 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0f145ff6e4f1..dfc4681054a8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1719,7 +1719,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
if (host->ios.power_mode == MMC_POWER_ON)
return;
- mmc_pwrseq_pre_power_on(host);
+ pwrseq_pre_power_on(host->pwrseq);
host->ios.vdd = fls(ocr) - 1;
host->ios.power_mode = MMC_POWER_UP;
@@ -1740,7 +1740,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
*/
mmc_delay(10);
- mmc_pwrseq_post_power_on(host);
+ pwrseq_post_power_on(host->pwrseq);
host->ios.clock = host->f_init;
@@ -1759,7 +1759,7 @@ void mmc_power_off(struct mmc_host *host)
if (host->ios.power_mode == MMC_POWER_OFF)
return;
- mmc_pwrseq_power_off(host);
+ pwrseq_power_off(host->pwrseq);
host->ios.clock = 0;
host->ios.vdd = 0;
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 9c665821f890..495a19d3c30b 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -52,32 +52,26 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
-void mmc_pwrseq_pre_power_on(struct mmc_host *host)
+void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->pre_power_on)
- pwrseq->ops->pre_power_on(host);
+ pwrseq->ops->pre_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_pre_power_on);
-void mmc_pwrseq_post_power_on(struct mmc_host *host)
+void pwrseq_post_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->post_power_on)
- pwrseq->ops->post_power_on(host);
+ pwrseq->ops->post_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_post_power_on);
-void mmc_pwrseq_power_off(struct mmc_host *host)
+void pwrseq_power_off(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->power_off)
- pwrseq->ops->power_off(host);
+ pwrseq->ops->power_off(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
+EXPORT_SYMBOL_GPL(pwrseq_power_off);
void mmc_pwrseq_free(struct mmc_host *host)
{
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c
b/drivers/power/pwrseq/pwrseq_emmc.c
index a68ac9a68e04..82327d0223f2 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -37,9 +37,9 @@ static void __mmc_pwrseq_emmc_reset(struct mmc_pwrseq_emmc
*pwrseq)
udelay(200);
}
-static void mmc_pwrseq_emmc_reset(struct mmc_host *host)
+static void mmc_pwrseq_emmc_reset(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(host->pwrseq);
+ struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(_pwrseq);
__mmc_pwrseq_emmc_reset(pwrseq);
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index d5fbd653153e..ab0098412690 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -46,9 +46,9 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
}
}
-static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pre_power_on(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(host->pwrseq);
+ struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
if (!IS_ERR(pwrseq->ext_clk) && !pwrseq->clk_enabled) {
clk_prepare_enable(pwrseq->ext_clk);
@@ -58,16 +58,16 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host
*host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
-static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pos
[RFC v2 09/13] power: pwrseq: Add support for USB hubs with external power
Some USB devices on embedded boards have external power supply which has
to be reset in certain conditions. Add pwrseq interface for this.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/pwrseq/pwrseq.c | 44 +++
include/linux/pwrseq.h| 8
2 files changed, 52 insertions(+)
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 495a19d3c30b..306265f55a10 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -52,6 +52,43 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
+struct pwrseq *pwrseq_alloc(struct device *dev)
+{
+ struct device_node *np;
+ struct pwrseq *p, *ret = NULL;
+
+ np = of_parse_phandle(dev->of_node, "usb-pwrseq", 0);
+ if (!np)
+ return NULL;
+
+ mutex_lock(&pwrseq_list_mutex);
+ list_for_each_entry(p, &pwrseq_list, pwrseq_node) {
+ if (p->dev->of_node == np) {
+ if (!try_module_get(p->owner))
+ dev_err(dev,
+ "increasing module refcount failed\n");
+ else
+ ret = p;
+
+ break;
+ }
+ }
+
+ of_node_put(np);
+ mutex_unlock(&pwrseq_list_mutex);
+
+ /* FIXME: this path can be simplified... */
+ if (!ret) {
+ dev_info(dev, "usb-pwrseq defer\n");
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ dev_info(dev, "allocated usb-pwrseq\n");
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc);
+
void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
if (pwrseq && pwrseq->ops->pre_power_on)
@@ -84,6 +121,13 @@ void mmc_pwrseq_free(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
+void pwrseq_free(const struct pwrseq *pwrseq)
+{
+ if (pwrseq)
+ module_put(pwrseq->owner);
+}
+EXPORT_SYMBOL_GPL(pwrseq_free);
+
int pwrseq_register(struct pwrseq *pwrseq)
{
if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
diff --git a/include/linux/pwrseq.h b/include/linux/pwrseq.h
index fcc8fd855d4c..c3c91f50e4cb 100644
--- a/include/linux/pwrseq.h
+++ b/include/linux/pwrseq.h
@@ -31,9 +31,13 @@ void pwrseq_unregister(struct pwrseq *pwrseq);
void pwrseq_pre_power_on(struct pwrseq *pwrseq);
void pwrseq_post_power_on(struct pwrseq *pwrseq);
void pwrseq_power_off(struct pwrseq *pwrseq);
+
int mmc_pwrseq_alloc(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
+struct pwrseq *pwrseq_alloc(struct device *dev);
+void pwrseq_free(const struct pwrseq *pwrseq);
+
#else /* CONFIG_POWER_SEQ */
static inline int pwrseq_register(struct pwrseq *pwrseq)
@@ -44,9 +48,13 @@ static inline void pwrseq_unregister(struct pwrseq *pwrseq)
{}
static inline void pwrseq_pre_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_post_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_power_off(struct pwrseq *pwrseq) {}
+
static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
static inline void mmc_pwrseq_free(struct mmc_host *host) {}
+static inline struct pwrseq *pwrseq_alloc(struct device *dev) { return NULL; }
+static inline void pwrseq_free(const struct pwrseq *pwrseq) {}
+
#endif /* CONFIG_POWER_SEQ */
#endif /* _LINUX_PWRSEQ_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 07/13] power: pwrseq: simple: Add support for toggling regulator
Some devices need real hard-reset by cutting the power. During power
sequence turn off and on the regulator, if it is provided.
Signed-off-by: Krzysztof Kozlowski
---
.../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 2 +
drivers/power/pwrseq/pwrseq_simple.c | 50 ++
2 files changed, 52 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index ce0e76749671..176ff831e7f1 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -16,6 +16,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 +25,5 @@ Example:
reset-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>;
clocks = <&clk_32768_ck>;
clock-names = "ext_clock";
+ ext-supply = <&buck8>;
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index ab0098412690..4d5ea53d3ead 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -16,7 +16,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -25,6 +27,7 @@ struct mmc_pwrseq_simple {
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)
@@ -62,6 +65,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);
}
@@ -75,6 +85,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 = {
@@ -102,6 +119,32 @@ 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);
+ /* FIXME: regulator_get_exclusive? */
+ 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);
+
+ /* FIXME: handle this in a more sensible way */
+ mdelay(10);
+
+ 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) &&
@@ -124,6 +167,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;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 01/13] usb: misc: usb3503: Clean up on driver unbind
The driver should clean up after itself by unpreparing the clock when it
is unbound.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/misc/usb3503.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index b45cb77c0744..a464636675a6 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -330,6 +330,19 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
return usb3503_probe(hub);
}
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+ struct usb3503 *hub;
+
+ hub = i2c_get_clientdata(i2c);
+ if (hub) {
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+ }
+
+ return 0;
+}
+
static int usb3503_platform_probe(struct platform_device *pdev)
{
struct usb3503 *hub;
@@ -342,6 +355,19 @@ static int usb3503_platform_probe(struct platform_device
*pdev)
return usb3503_probe(hub);
}
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+ struct usb3503 *hub;
+
+ hub = platform_get_drvdata(pdev);
+ if (hub) {
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+ }
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int usb3503_i2c_suspend(struct device *dev)
{
@@ -395,6 +421,7 @@ static struct i2c_driver usb3503_i2c_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
+ .remove = usb3503_i2c_remove,
.id_table = usb3503_id,
};
@@ -404,6 +431,7 @@ static struct platform_driver usb3503_platform_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_platform_probe,
+ .remove = usb3503_platform_remove,
};
static int __init usb3503_init(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v2 02/13] power/mmc: Move pwrseq drivers to power/pwrseq
The MMC power sequence drivers are useful also outside of MMC world: for
USB devices needed a hard-reset before probing. Before extending and
re-using pwrseq drivers, move them to a new place.
The commit does not introduce significant changes in the pwrseq drivers
code so still all the functions are prefixed with "mmc_pwrseq". However
the MMC-specific pwrseq functions has to be now exported and everything
is hidden not by CONFIG_OF but by new CONFIG_POWER_SEQ option.
Signed-off-by: Krzysztof Kozlowski
---
drivers/mmc/Kconfig| 2 --
drivers/mmc/core/Makefile | 3 ---
drivers/mmc/core/core.c| 2 +-
drivers/mmc/core/host.c| 2 +-
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 17 -
drivers/power/pwrseq/Makefile | 3 +++
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 8 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 3 +--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 3 +--
{drivers/mmc/core => include/linux}/pwrseq.h | 6 +++---
12 files changed, 30 insertions(+), 21 deletions(-)
rename drivers/{mmc/core => power/pwrseq}/Kconfig (71%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (90%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (99%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (99%)
rename {drivers/mmc/core => include/linux}/pwrseq.h (94%)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2eeb38efa65..7ade379e0634 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -21,8 +21,6 @@ config MMC_DEBUG
if MMC
-source "drivers/mmc/core/Kconfig"
-
source "drivers/mmc/card/Kconfig"
source "drivers/mmc/host/Kconfig"
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index f007151dfdc6..a901d3cd09d3 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,7 +8,4 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o
-obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
-obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 99275e40bf2f..0f145ff6e4f1 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,6 @@
#include "bus.h"
#include "host.h"
#include "sdio_bus.h"
-#include "pwrseq.h"
#include "mmc_ops.h"
#include "sd_ops.h"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index e0a3ee16c0d3..98164a352dfb 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,7 +30,6 @@
#include "core.h"
#include "host.h"
#include "slot-gpio.h"
-#include "pwrseq.h"
#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 421770ddafa3..2702aca6cd2c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -511,5 +511,6 @@ config AXP20X_POWER
endif # POWER_SUPPLY
+source "drivers/power/pwrseq/Kconfig"
source "drivers/power/reset/Kconfig"
source "drivers/power/avs/Kconfig"
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index e46b75d448a5..02f9d5da2e76 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_POWER_AVS) += avs/
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o
+obj-$(CONFIG_POWER_SEQ)+= pwrseq/
obj-$(CONFIG_POWER_RESET) += reset/
obj-$(CONFIG_AXP288_FUEL_GAUGE) += axp288_fuel_gauge.o
obj-$(CONFIG_AXP288_CHARGER) += axp288_charger.o
diff --git a/drivers/mmc/core/Kconfig b/drivers/power/pwrseq/Kconfig
similarity index 71%
rename from drivers/mmc/core/Kconfig
rename to drivers/power/pwrseq/Kconfig
index 250f223aaa80..b5d2d6c65f28 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/power/pwrseq/Kconfig
@@ -1,7 +1,12 @@
-#
-# MMC core configuration
-#
-config PWRSEQ_EMMC
+menuconfig POWER_SEQ
+ default y if OF
+ bool "Hardware reset support for specific devices&quo
[RFC v2 03/13] 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 --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b016f447c6c9..2c501b795d18 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8874,6 +8874,14 @@ F: include/linux/power_supply.h F: drivers/power/ X: drivers/power/avs/ +POWER SEQ CORE and DRIVERS +M: Ulf Hansson +L: linux-...@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 + POWER STATE COORDINATION INTERFACE (PSCI) M: Mark Rutland M: Lorenzo Pieralisi -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 10/13] usb: hub: Power sequence the ports on activation
On Thu, May 05, 2016 at 10:09:47AM -0400, Alan Stern wrote: > On Thu, 5 May 2016, Krzysztof Kozlowski wrote: > > > 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 > > --- > > drivers/usb/core/hub.c | 11 +++ > > 1 file changed, 11 insertions(+) > > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > > index 1c82fcc448f5..0fddaacc62bf 100644 > > --- a/drivers/usb/core/hub.c > > +++ b/drivers/usb/core/hub.c > > @@ -26,6 +26,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -1661,7 +1662,17 @@ static int hub_configure(struct usb_hub *hub, > > > > usb_hub_adjust_deviceremovable(hdev, hub->descriptor); > > > > + /* FIXME: When do the pre-power-on? */ > > It's hard to answer this without knowing what pre-power-on involves. In my particular case, I want to achieve a full reset through regulator (off and on) because the bootloader left it in initialized state. I assume that if bootloader did not configure the device, the reset won't be harmful. In a MMC case, this pre-power-on on is setting the 'reset' GPIO (thus triggering the reset) and post-power-on is clearing the 'reset'. > Why not create a pwrseq_power_on() routine that does pre_power_on > followed by post_power_on? For my purpose it seems sensible. > > > + /* > > + 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); > > This is patch 10/13. hub->ports[i]->pwrseq doesn't get added until > 11/13. Obviously you never tried compiling each patch in the series. Ahh yes, I forgot to reorder them. Thanks for spotting this. > > > + > > hub_activate(hub, HUB_INIT); > > + > > Unnecessary blank line added. Thanks for feedback, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/06/2016 12:42 AM, Rob Herring wrote: > On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >> Hi, >> >> This is a different, second try to fix usb3503+lan on Odroid U3 board >> if it was initialized by bootloader (e.g. for TFTP boot). >> >> First version: >> http://www.spinics.net/lists/linux-usb/msg140042.html >> >> >> 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, > > You can do that, but I'm going to NAK any use of pwrseq bindings outside > of MMC. I think it is the wrong way to do things. The DT should describe > the devices. If they happen to be "simple" then the core can walk the > tree and do any setup. For example, look for "reset-gpios" and toggle > that GPIO. There is no need for a special node. Okay, I got it, no node for pwrseq but parse device properties. In case of reset-gpios it seems quite obvious but also actively used: $ git grep reset-gpios arch/arm/boot/dts | wc -l 142 Definitely pwrseq shouldn't add itself to all of these devices. My questions would be then: 1. An additional pwrseq compatible for device is acceptable? 2. How would you name the regulator? We shouldn't toggle off/on every regulator but probably only some specific ones. > >> 2. Extend the pwrseq-simple with regulator toggling, >> 3. Add support to USB hub and port core for pwrseq, > > We discussed this for USB already[1] and is why we defined how to add > USB child devices. The idea is not to add pwrseq to that. Yes, I left it for next iteration because it would require much more changes in USB core. As for now, these bindings are useless for USB devices which are not yet enumerated (because power sequence has to be done on them). Making use of these bindings would be a next step... Just let me do it one step a time. Best regards, Krzysztof > > Rob > > [1] http://www.spinics.net/lists/linux-usb/msg134082.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/06/2016 07:44 AM, Peter Chen wrote: > On Thu, May 05, 2016 at 05:42:40PM -0500, Rob Herring wrote: >> On Thu, May 05, 2016 at 02:34:13PM +0200, Krzysztof Kozlowski wrote: >>> Hi, >>> >>> This is a different, second try to fix usb3503+lan on Odroid U3 board >>> if it was initialized by bootloader (e.g. for TFTP boot). >>> >>> First version: >>> http://www.spinics.net/lists/linux-usb/msg140042.html >>> >>> >>> 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, >> >> You can do that, but I'm going to NAK any use of pwrseq bindings outside >> of MMC. I think it is the wrong way to do things. The DT should describe >> the devices. If they happen to be "simple" then the core can walk the >> tree and do any setup. For example, look for "reset-gpios" and toggle >> that GPIO. There is no need for a special node. >> > > Oh, I am doing the same thing like this patch set doing. Shame on me that I did not use Google before starting the work. I could just extend your patchset. I think we can combine our efforts. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 01/13] usb: misc: usb3503: Clean up on driver unbind
On 05/05/2016 08:32 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof
>
> Patch looks good to me, I just have a trivial comment below.
>
> On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote:
>> The driver should clean up after itself by unpreparing the clock when it
>> is unbound.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> drivers/usb/misc/usb3503.c | 28
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
>> index b45cb77c0744..a464636675a6 100644
>> --- a/drivers/usb/misc/usb3503.c
>> +++ b/drivers/usb/misc/usb3503.c
>> @@ -330,6 +330,19 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
>> return usb3503_probe(hub);
>> }
>>
>> +static int usb3503_i2c_remove(struct i2c_client *i2c)
>> +{
>> +struct usb3503 *hub;
>> +
>> +hub = i2c_get_clientdata(i2c);
>> +if (hub) {
>> +if (hub->clk)
>> +clk_disable_unprepare(hub->clk);
>> +}
>
> I think the following is simpler and easier to read:
>
> if (hub && hub->clk)
> clk_disable_unprepare(hub->clk);
>
Sure, thanks.
Best regards,
Krzysztof
>> +
>> +return 0;
>> +}
>> +
>> static int usb3503_platform_probe(struct platform_device *pdev)
>> {
>> struct usb3503 *hub;
>> @@ -342,6 +355,19 @@ static int usb3503_platform_probe(struct
>> platform_device *pdev)
>> return usb3503_probe(hub);
>> }
>>
>> +static int usb3503_platform_remove(struct platform_device *pdev)
>> +{
>> +struct usb3503 *hub;
>> +
>> +hub = platform_get_drvdata(pdev);
>> +if (hub) {
>> +if (hub->clk)
>> +clk_disable_unprepare(hub->clk);
>> +}
>> +
>
> Ditto.
>
>> +return 0;
>> +}
>> +
>> #ifdef CONFIG_PM_SLEEP
>> static int usb3503_i2c_suspend(struct device *dev)
>> {
>> @@ -395,6 +421,7 @@ static struct i2c_driver usb3503_i2c_driver = {
>> .of_match_table = of_match_ptr(usb3503_of_match),
>> },
>> .probe = usb3503_i2c_probe,
>> +.remove = usb3503_i2c_remove,
>> .id_table = usb3503_id,
>> };
>>
>> @@ -404,6 +431,7 @@ static struct platform_driver usb3503_platform_driver = {
>> .of_match_table = of_match_ptr(usb3503_of_match),
>> },
>> .probe = usb3503_platform_probe,
>> +.remove = usb3503_platform_remove,
>> };
>>
>> static int __init usb3503_init(void)
>>
>
> Reviewed-by: Javier Martinez Canillas
>
> Best regards,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 02/13] power/mmc: Move pwrseq drivers to power/pwrseq
On 05/05/2016 08:44 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> The MMC power sequence drivers are useful also outside of MMC world: for >> USB devices needed a hard-reset before probing. Before extending and >> re-using pwrseq drivers, move them to a new place. >> >> The commit does not introduce significant changes in the pwrseq drivers >> code so still all the functions are prefixed with "mmc_pwrseq". However >> the MMC-specific pwrseq functions has to be now exported and everything >> is hidden not by CONFIG_OF but by new CONFIG_POWER_SEQ option. >> >> Signed-off-by: Krzysztof Kozlowski >> --- > > [snip] > >> --- a/drivers/mmc/core/Kconfig >> +++ b/drivers/power/pwrseq/Kconfig >> @@ -1,7 +1,12 @@ >> -# >> -# MMC core configuration >> -# >> -config PWRSEQ_EMMC >> +menuconfig POWER_SEQ >> +default y if OF >> +bool "Hardware reset support for specific devices" >> +help >> + Provides drivers which reset the specific device before... >> + > > I think this text could be improved a little bit, maybe something like: > > "Provides drivers that implements specific power sequences for chips, > using the generic power sequence management interface". > > The rest looks good to me. > > Reviewed-by: Javier Martinez Canillas Yes, I wanted to code, not to focus on descriptions, so also commit messages should be extended. I'll fix this in next iteration. BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 05/13] power: pwrseq: Remove mmc prefix from mmc_pwrseq
On 05/05/2016 09:09 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote: >> The "mmc" prefix is no longer needed after moving the pwrseq core code >> from mmc/ to power/. >> >> Signed-off-by: Krzysztof Kozlowski >> --- > > [snip] > >> 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 >> > > I don't think this header inclusion is needed. At least I didn't see anything > defined there that's used in this driver. This also applies to pwrseq_simple. > > I think you could remove those in another preparatory patches before the move. > > Reviewed-by: Javier Martinez Canillas Good catch, thanks. BR, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 07/13] power: pwrseq: simple: Add support for toggling regulator
On 05/05/2016 09:31 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 05/05/2016 08:34 AM, 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.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>
> [snip]
>
>>
>> #define to_pwrseq_simple(p) container_of(p, struct mmc_pwrseq_simple,
>> pwrseq)
>> @@ -62,6 +65,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);
>> +}
>> +
>
> Shouldn't this be in mmc_pwrseq_simple_pre_power_on() instead?
>
> For example, a chip may need to be powered on before attempting to
> toggle its reset or power pins using some GPIO lines.
Indeed this should be still sorted out but here the assumption is that
regulator is disabled (by probe()) so it should be turned on with
GPIO-reset set.
This can be done at the end of pre-power-on or here (beginning of
post-power-on). On the other hand I understand these pre/post callbacks
as one starting the reset sequence (pre) and second as finishing it
(post). In case of regulators, finishing power sequence is to turn the
regulator on.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 09/13] power: pwrseq: Add support for USB hubs with external power
On 05/05/2016 09:52 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote:
>> Some USB devices on embedded boards have external power supply which has
>> to be reset in certain conditions. Add pwrseq interface for this.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> drivers/power/pwrseq/pwrseq.c | 44
>> +++
>> include/linux/pwrseq.h| 8
>> 2 files changed, 52 insertions(+)
>>
>> diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
>> index 495a19d3c30b..306265f55a10 100644
>> --- a/drivers/power/pwrseq/pwrseq.c
>> +++ b/drivers/power/pwrseq/pwrseq.c
>> @@ -52,6 +52,43 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
>> }
>> EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
>>
>> +struct pwrseq *pwrseq_alloc(struct device *dev)
>> +{
>
> This function is USB specific so better to call it usb_pwrseq_alloc() instead.
Indeed it is parsing USB specific bindings so such prefix is needed.
> Although, this function has a lot of duplicated code from mmc_pwrseq_alloc()
> so I think is better to keep the name generic and factorize the common code.
>
> I expect other devices are also needing some kind of power seq in the future
> so having a single alloc function instead of each for device type makes sense.
Yes, this can be cleaned up and unified.
>
>> +struct device_node *np;
>> +struct pwrseq *p, *ret = NULL;
>> +
>> +np = of_parse_phandle(dev->of_node, "usb-pwrseq", 0);
>
> I know this is just an RFC but you should really add DT bindings for this.
Yep, next step.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 11/13] usb: port: Parse pwrseq phandle from Device Tree
On 05/05/2016 10:10 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote:
>> Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
>> device. The pwrseq device will be used by USB hub to cycle the power
>> before activating ports.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>
> [snip]
>
>>
>> @@ -532,6 +534,14 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
>> port1)
>> return retval;
>> }
>>
>> +port_dev->dev.of_node = usb_of_get_child_node(hub->hdev->dev.of_node,
>> port1);
>> +port_dev->pwrseq = pwrseq_alloc(&port_dev->dev);
>> +if (IS_ERR(port_dev->pwrseq)) {
>> +device_unregister(&port_dev->dev);
>> +/* TODO: what about EPROBE_DEFER? */
>
> I think it's OK since the call chain is:
>
> hub_probe()
>hub_configure()
> usb_hub_create_port_device()
>
> so the hub_probe() will be deferred if the usb-pwrseq was not registered yet.
> Unless I misunderstood your question :)
>
> Anyway, patch looks good to me:
>
> Reviewed-by: Javier Martinez Canillas
Yes and deferred probing works in my case. That is an older comment
actually.
Thanks for review,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 13/13] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On 05/05/2016 10:16 PM, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 05/05/2016 08:34 AM, Krzysztof Kozlowski wrote:
>> On Odroid U3 (Exynos4412-based) board if USB was initialized by
>> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
>> and LAN (smsc95xx) after after successful probing were not visible in the
>> system ("lsusb").
>>
>> In such case the devices had to be fully reset before configuring.
>> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
>> in usb3503 HUB are not sufficient. Instead full reset has to be done by
>> disabling and enabling regulator.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>
> [snip]
>
>>
>> +lan_pwrseq: pwrseq2 {
>> +compatible = "mmc-pwrseq-simple";
>
> It feels strange to have a "mmc-pwrseq-simple" compatible for a USB power
> sequence provider. As I mentioned in the other patch, I think there should
> either be a DT binding for the USB pwrseq-simple with a "usb-pwrseq-simple"
> compatible that binds to the same pwrseq-simple driver or maybe having a
> generic DT binding for any device with a new "pwrseq-simple" compatible.
>
> Patch looks good to me though, so after having a DT binding and changing
> the compatible string:
>
> Reviewed-by: Javier Martinez Canillas
Probably this will change after Rob's feedback. :)
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dwc3-exynos: Fix deferred probing storm.
On 05/24/2016 08:13 PM, Steinar H. Gunderson wrote:
> dwc3-exynos has two problems during init if the regulators are slow
> to come up (for instance if the I2C bus driver is not on the initramfs)
> and return probe deferral. First, every time this happens, the driver
> leaks the USB phys created; they need to be deallocated on error.
>
> Second, since the phy devices are created before the regulators fail,
> this means that there's a new device to re-trigger deferred probing,
> which causes it to essentially go into a busy loop of re-probing the
> device until the regulators come up.
>
> Move the phy creation to after the regulators have succeeded, and also
> fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
> which doesn't contain the I2C driver), this reduces the number of probe
> attempts (for each of the two controllers) from more than 2000 to eight.
>
> Reported-by: Steinar H. Gunderson
> Signed-off-by: Steinar H. Gunderson
This is the same person so no need for "Reported-by". The reported-by is
used if someone else submits patch after your bug report.
Please (when resubmitting or applying) add following tags:
Fixes: d720f057fda4 ("usb: dwc3: exynos: add nop transceiver support")
Cc:
This will help downstream (like Debian) using stable kernels.
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> ---
> drivers/usb/dwc3/dwc3-exynos.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
> index dd5cb55..2f1fb7e 100644
> --- a/drivers/usb/dwc3/dwc3-exynos.c
> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> @@ -128,12 +128,6 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, exynos);
>
> - ret = dwc3_exynos_register_phys(exynos);
> - if (ret) {
> - dev_err(dev, "couldn't register PHYs\n");
> - return ret;
> - }
> -
> exynos->dev = dev;
>
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> @@ -183,20 +177,29 @@ static int dwc3_exynos_probe(struct platform_device
> *pdev)
> goto err3;
> }
>
> + ret = dwc3_exynos_register_phys(exynos);
> + if (ret) {
> + dev_err(dev, "couldn't register PHYs\n");
> + goto err4;
> + }
> +
> if (node) {
> ret = of_platform_populate(node, NULL, NULL, dev);
> if (ret) {
> dev_err(dev, "failed to add dwc3 core\n");
> - goto err4;
> + goto err5;
> }
> } else {
> dev_err(dev, "no device node, failed to add dwc3 core\n");
> ret = -ENODEV;
> - goto err4;
> + goto err5;
> }
>
> return 0;
>
> +err5:
> + platform_device_unregister(exynos->usb2_phy);
> + platform_device_unregister(exynos->usb3_phy);
> err4:
> regulator_disable(exynos->vdd10);
> err3:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dwc3-exynos: Fix deferred probing storm.
On 05/27/2016 01:46 PM, Steinar H. Gunderson wrote: > On Fri, May 27, 2016 at 03:23:35PM +0530, Vivek Gautam wrote: >> I don't have any concerns with the patch apart from the ones >> Krzysztof has already pointed out. >> LGTM. > > Should I repost the patch, or will people just make these commit message > changes for me? I guess balbi@ is the right person to review and merge, > since he maintains the driver. Although resend is not strictly needed because maintainer might do the changes by himself... but he might just miss the comments as well (and e.g. use patchwork to apply the patch). I think it would be useful if you send a v2 with fixes pointed by me and accumulated review-tags (mine and Vivek's Reviewed-by). Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On 05/31/2016 02:58 AM, Peter Chen wrote: > On Sat, May 28, 2016 at 11:36:13AM +0800, Peter Chen wrote: >> All, how we move on for this? >> >> 1. Using a generic driver to manage both mmc and USB (and further >> subsystem), USB and further subsystem do not use pwrseq node in dts. >> 2. USB creates the similar driver under drivers/usb for its own use. >> >> Which one do you prefer, thanks. >> > > Hi Krzysztof Kozlowski, > > I think option 1 may be better according to Rob and Ulf's comment. Hi, I like the option #1 as well. The generic driver should rely and parse existing bindings like 'reset-gpios'. Still additional property (e.g. "do-the-power-sequence") seems needed as we do not want to play with all reset-gpios in DTB. > Would you like going on your patch set? You can work on generic pwrseq > driver, I will do USB stuffs based on generic pwrseq driver? Great, that sounds good! I'll start the work. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] usb: misc: usb3503: Set platform data
Driver supports two paths of device instantiation: as platform and i2c device. In the platform path it lacks of storing the driver specific structure as drvdata. Signed-off-by: Krzysztof Kozlowski --- Changes since v1: 1. New patch. --- drivers/usb/misc/usb3503.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c index b45cb77c0744..0cf2987b322f 100644 --- a/drivers/usb/misc/usb3503.c +++ b/drivers/usb/misc/usb3503.c @@ -338,6 +338,7 @@ static int usb3503_platform_probe(struct platform_device *pdev) if (!hub) return -ENOMEM; hub->dev = &pdev->dev; + platform_set_drvdata(pdev, hub); return usb3503_probe(hub); } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] usb: misc: usb3503: Clean up on driver unbind
The driver should clean up after itself by unpreparing the clock when it
is unbound.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
1. Add Javier's tag.
2. Follow Javier's suggestion - the 'hub' cannot be null now.
---
drivers/usb/misc/usb3503.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 0cf2987b322f..8e7737d7ac0a 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -330,6 +330,17 @@ static int usb3503_i2c_probe(struct i2c_client *i2c,
return usb3503_probe(hub);
}
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+ struct usb3503 *hub;
+
+ hub = i2c_get_clientdata(i2c);
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
static int usb3503_platform_probe(struct platform_device *pdev)
{
struct usb3503 *hub;
@@ -343,6 +354,17 @@ static int usb3503_platform_probe(struct platform_device
*pdev)
return usb3503_probe(hub);
}
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+ struct usb3503 *hub;
+
+ hub = platform_get_drvdata(pdev);
+ if (hub->clk)
+ clk_disable_unprepare(hub->clk);
+
+ return 0;
+}
+
#ifdef CONFIG_PM_SLEEP
static int usb3503_i2c_suspend(struct device *dev)
{
@@ -396,6 +418,7 @@ static struct i2c_driver usb3503_i2c_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_i2c_probe,
+ .remove = usb3503_i2c_remove,
.id_table = usb3503_id,
};
@@ -405,6 +428,7 @@ static struct platform_driver usb3503_platform_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe = usb3503_platform_probe,
+ .remove = usb3503_platform_remove,
};
static int __init usb3503_init(void)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 09/12] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
device. The pwrseq device will be used by USB hub to cycle the power
before activating ports.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.h | 3 +++
drivers/usb/core/port.c | 15 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e22aae..68ca89780d26 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -24,6 +24,8 @@
#include
#include "usb.h"
+struct pwrseq;
+
struct usb_hub {
struct device *intfdev; /* the "interface" device */
struct usb_device *hdev;
@@ -101,6 +103,7 @@ struct usb_port {
struct usb_dev_state *port_owner;
struct usb_port *peer;
struct dev_pm_qos_request *req;
+ struct pwrseq *pwrseq;
enum usb_port_connect_type connect_type;
usb_port_location_t location;
struct mutex status_lock;
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 460c855be0d0..89b9bdfc7061 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+#include
#include "hub.h"
@@ -526,6 +528,14 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
port1)
return retval;
}
+ port_dev->dev.of_node = usb_of_get_child_node(hdev->dev.parent->of_node,
+ port1);
+ port_dev->pwrseq = pwrseq_alloc(&port_dev->dev, "usb-pwrseq");
+ if (IS_ERR(port_dev->pwrseq)) {
+ device_unregister(&port_dev->dev);
+ return PTR_ERR(port_dev->pwrseq);
+ }
+
find_and_link_peer(hub, port1);
/*
@@ -567,8 +577,13 @@ void usb_hub_remove_port_device(struct usb_hub *hub, int
port1)
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_port *peer;
+ pwrseq_power_off(port_dev->pwrseq);
+
peer = port_dev->peer;
if (peer)
unlink_peers(port_dev, peer);
+
+ pwrseq_free(port_dev->pwrseq);
+ port_dev->pwrseq = NULL;
device_unregister(&port_dev->dev);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 05/12] power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
The power sequence hooks (mmc_pwrseq_pre_power_on(),
mmc_pwrseq_post_power_on() and mmc_pwrseq_power_off()) can be made more
generic to allow re-use in other subsystems. They do not need to take
pointer to struct mmc_host but instead the struct pwrseq should be
sufficient.
Remove the "mmc" prefix and use the pointer to struct pwrseq as
argument.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/mmc/core/core.c | 6 +++---
drivers/power/pwrseq/pwrseq.c| 24 +---
drivers/power/pwrseq/pwrseq_emmc.c | 6 ++
drivers/power/pwrseq/pwrseq_simple.c | 14 ++
include/linux/pwrseq.h | 18 +-
5 files changed, 29 insertions(+), 39 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index edefc3fbebe6..09a4722f9037 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1719,7 +1719,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
if (host->ios.power_mode == MMC_POWER_ON)
return;
- mmc_pwrseq_pre_power_on(host);
+ pwrseq_pre_power_on(host->pwrseq);
host->ios.vdd = fls(ocr) - 1;
host->ios.power_mode = MMC_POWER_UP;
@@ -1740,7 +1740,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
*/
mmc_delay(10);
- mmc_pwrseq_post_power_on(host);
+ pwrseq_post_power_on(host->pwrseq);
host->ios.clock = host->f_init;
@@ -1759,7 +1759,7 @@ void mmc_power_off(struct mmc_host *host)
if (host->ios.power_mode == MMC_POWER_OFF)
return;
- mmc_pwrseq_power_off(host);
+ pwrseq_power_off(host->pwrseq);
host->ios.clock = 0;
host->ios.vdd = 0;
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 9c665821f890..495a19d3c30b 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -52,32 +52,26 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
-void mmc_pwrseq_pre_power_on(struct mmc_host *host)
+void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->pre_power_on)
- pwrseq->ops->pre_power_on(host);
+ pwrseq->ops->pre_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_pre_power_on);
-void mmc_pwrseq_post_power_on(struct mmc_host *host)
+void pwrseq_post_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->post_power_on)
- pwrseq->ops->post_power_on(host);
+ pwrseq->ops->post_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_post_power_on);
-void mmc_pwrseq_power_off(struct mmc_host *host)
+void pwrseq_power_off(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->power_off)
- pwrseq->ops->power_off(host);
+ pwrseq->ops->power_off(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
+EXPORT_SYMBOL_GPL(pwrseq_power_off);
void mmc_pwrseq_free(struct mmc_host *host)
{
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c
b/drivers/power/pwrseq/pwrseq_emmc.c
index a68ac9a68e04..dbb7e753beb2 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -19,8 +19,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_emmc {
struct pwrseq pwrseq;
struct notifier_block reset_nb;
@@ -37,9 +35,9 @@ static void __mmc_pwrseq_emmc_reset(struct mmc_pwrseq_emmc
*pwrseq)
udelay(200);
}
-static void mmc_pwrseq_emmc_reset(struct mmc_host *host)
+static void mmc_pwrseq_emmc_reset(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(host->pwrseq);
+ struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(_pwrseq);
__mmc_pwrseq_emmc_reset(pwrseq);
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index d5fbd653153e..93807a6ef162 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -18,8 +18,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_simple {
struct pwrseq pwrseq;
bool clk_enabled;
@@ -46,9 +44,9 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
}
}
-static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pre_power_on(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(host->pwrseq);
+ struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
if (!IS_ERR(pwrseq->ext_clk) && !pwrseq-
[PATCH v3 08/12] usb: hub: Handle deferred probe
Add support for deferred probing to the usb hub. Currently EPROBE_DEFER does not exist in usb hub path but future patches will add it on the port level. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- drivers/usb/core/hub.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index bee13517676f..c421745b84aa 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1733,6 +1733,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) struct usb_endpoint_descriptor *endpoint; struct usb_device *hdev; struct usb_hub *hub; + int ret; desc = intf->cur_altsetting; hdev = interface_to_usbdev(intf); @@ -1852,11 +1853,12 @@ descriptor_error: if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) hub->quirk_check_port_auto_suspend = 1; - if (hub_configure(hub, endpoint) >= 0) + ret = hub_configure(hub, endpoint); + if (ret >= 0) return 0; hub_disconnect(intf); - return -ENODEV; + return ret; } static int -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 07/12] power: pwrseq: Add support for USB hubs with external power
Some USB devices on embedded boards have external power supply which has
to be reset in certain conditions. Add pwrseq interface for this.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/pwrseq/pwrseq.c | 47 ++-
include/linux/pwrseq.h| 11 ++
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 495a19d3c30b..722aff4f740f 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -1,7 +1,9 @@
/*
- * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2016 Samsung Electronics
*
* Author: Ulf Hansson
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
@@ -52,6 +54,42 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name)
+{
+ struct device_node *np;
+ struct pwrseq *p, *ret = NULL;
+
+ np = of_parse_phandle(dev->of_node, phandle_name, 0);
+ if (!np)
+ return NULL;
+
+ mutex_lock(&pwrseq_list_mutex);
+ list_for_each_entry(p, &pwrseq_list, pwrseq_node) {
+ if (p->dev->of_node == np) {
+ if (!try_module_get(p->owner))
+ dev_err(dev,
+ "increasing module refcount failed\n");
+ else
+ ret = p;
+
+ break;
+ }
+ }
+
+ of_node_put(np);
+ mutex_unlock(&pwrseq_list_mutex);
+
+ if (!ret) {
+ dev_dbg(dev, "%s defer probe\n", phandle_name);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ dev_info(dev, "allocated usb-pwrseq\n");
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc);
+
void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
if (pwrseq && pwrseq->ops->pre_power_on)
@@ -84,6 +122,13 @@ void mmc_pwrseq_free(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
+void pwrseq_free(const struct pwrseq *pwrseq)
+{
+ if (pwrseq)
+ module_put(pwrseq->owner);
+}
+EXPORT_SYMBOL_GPL(pwrseq_free);
+
int pwrseq_register(struct pwrseq *pwrseq)
{
if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
diff --git a/include/linux/pwrseq.h b/include/linux/pwrseq.h
index fcc8fd855d4c..6215b3d6350d 100644
--- a/include/linux/pwrseq.h
+++ b/include/linux/pwrseq.h
@@ -31,9 +31,13 @@ void pwrseq_unregister(struct pwrseq *pwrseq);
void pwrseq_pre_power_on(struct pwrseq *pwrseq);
void pwrseq_post_power_on(struct pwrseq *pwrseq);
void pwrseq_power_off(struct pwrseq *pwrseq);
+
int mmc_pwrseq_alloc(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name);
+void pwrseq_free(const struct pwrseq *pwrseq);
+
#else /* CONFIG_POWER_SEQ */
static inline int pwrseq_register(struct pwrseq *pwrseq)
@@ -44,9 +48,16 @@ static inline void pwrseq_unregister(struct pwrseq *pwrseq)
{}
static inline void pwrseq_pre_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_post_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_power_off(struct pwrseq *pwrseq) {}
+
static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
static inline void mmc_pwrseq_free(struct mmc_host *host) {}
+static inline struct pwrseq *pwrseq_alloc(struct device *dev, const char
*phandle_name)
+{
+ return NULL;
+}
+static inline void pwrseq_free(const struct pwrseq *pwrseq) {}
+
#endif /* CONFIG_POWER_SEQ */
#endif /* _LINUX_PWRSEQ_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 11/12] ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
Switch the control of buck8 to GPIO mode. It is faster than I2C/register mode and it is the easiest way to disable it (regulator state is a logical OR state of GPIO and register value). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts index d73aa6c58fe3..31cdc036fda4 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts @@ -74,6 +74,7 @@ regulator-name = "BUCK8_P3V3"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; + maxim,ena-gpios = <&gpa1 1 GPIO_ACTIVE_HIGH>; }; /* VDDQ for MSHC (eMMC card) */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
and LAN (smsc95xx) after after successful probing were not visible in the
system ("lsusb").
In such case the devices had to be fully reset before configuring.
Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
in usb3503 HUB are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 31cdc036fda4..23e30e4609df 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -99,11 +99,15 @@
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
refclk-frequency = <2400>;
+
+ power-sequence;
+ ext-supply = <&buck8_reg>;
};
&ehci {
port@1 {
status = "okay";
+ usb-pwrseq = <&usb3503>;
};
port@2 {
status = "okay";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 01/12] power/mmc: Move pwrseq drivers to power/pwrseq
The MMC power sequence drivers are useful also outside of MMC world: for
USB devices needed a hard-reset before probing. Before extending and
re-using pwrseq drivers, move them to a new place.
The commit does not introduce significant changes in the pwrseq drivers
code so still all the functions are prefixed with "mmc_pwrseq". However
the MMC-specific pwrseq functions has to be now exported and everything
is hidden not by CONFIG_OF but by new CONFIG_POWER_SEQ option.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
.../pwrseq/pwrseq-emmc.txt}| 0
.../pwrseq/pwrseq-simple.txt} | 0
drivers/mmc/Kconfig| 2 --
drivers/mmc/core/Makefile | 3 ---
drivers/mmc/core/core.c| 2 +-
drivers/mmc/core/host.c| 2 +-
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 18 +-
drivers/power/pwrseq/Makefile | 3 +++
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 8 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 3 +--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 3 +--
{drivers/mmc/core => include/linux}/pwrseq.h | 6 +++---
14 files changed, 31 insertions(+), 21 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} (100%)
rename drivers/{mmc/core => power/pwrseq}/Kconfig (66%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (90%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (99%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (99%)
rename {drivers/mmc/core => include/linux}/pwrseq.h (94%)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2eeb38efa65..7ade379e0634 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -21,8 +21,6 @@ config MMC_DEBUG
if MMC
-source "drivers/mmc/core/Kconfig"
-
source "drivers/mmc/card/Kconfig"
source "drivers/mmc/host/Kconfig"
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index f007151dfdc6..a901d3cd09d3 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,7 +8,4 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o
-obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
-obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8b4dfd45433b..edefc3fbebe6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,6 @@
#include "bus.h"
#include "host.h"
#include "sdio_bus.h"
-#include "pwrseq.h"
#include "mmc_ops.h"
#include "sd_ops.h"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 1be42fab1a30..1db7d5802adc 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,7 +30,6 @@
#include "core.h"
#include "host.h"
#include "slot-gpio.h"
-#include "pwrseq.h"
#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 421770ddafa3..2702aca6cd2c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -511,5 +511,6 @@ config AXP20X_POWER
endif # POWER_SUPPLY
+source "drivers/power/pwrseq/Kconfig"
source "drivers/power/reset/Kconfig"
source "driver
[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 --- 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 #include #include +#include #include #include @@ -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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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
---
.../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
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
* Simple MMC power sequence management
*/
+#include
#include
#include
#include
@@ -16,13 +19,16 @@
#include
#include
#include
+#include
#include
+#include
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(p
[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
Reviewed-by: Javier Martinez Canillas
---
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
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
struct mmc_pwrseq_simple {
- struct mmc_pwrseq pwrseq;
+ struct pwrseq pwrseq;
bool clk_enabled;
struct clk *ext_clk;
struct gpio_descs *reset_gpios;
[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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 03/12] power: pwrseq: Enable COMPILE_TEST for drivers
Allow build testing for power sequence drivers. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 Reviewed-by: Javier Martinez Canillas --- 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 +L: linux-...@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 M: Lorenzo Pieralisi -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/12] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
On 06/01/2016 10:57 AM, Stephen Boyd wrote:
> Quoting Krzysztof Kozlowski (2016-06-01 01:02:18)
>> Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
>> device. The pwrseq device will be used by USB hub to cycle the power
>> before activating ports.
>>
>> Signed-off-by: Krzysztof Kozlowski
>
> Drive by review comment.
>
> I was hoping this would help me with a problem I'm having where I have a
> hub (smsc4604) that needs to be taken out of reset before my HSIC
> controller sends a USB reset to it, but it seems this is more about
> doing some sort of power on sequence after enumeration?
This example is not finished but from what you wrote, it might suit your
needs as well. The power sequence is done before enumeration because
without it, the device won't enumerate.
The exact power sequence for USB devices has to be still developed.
Comments are welcomed.
>> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
>> index 460c855be0d0..89b9bdfc7061 100644
>> --- a/drivers/usb/core/port.c
>> +++ b/drivers/usb/core/port.c
>> @@ -18,6 +18,8 @@
>>
>> #include
>> #include
>> +#include
>> +#include
>>
>> #include "hub.h"
>>
>> @@ -526,6 +528,14 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
>> port1)
>> return retval;
>> }
>>
>> + port_dev->dev.of_node =
>> usb_of_get_child_node(hdev->dev.parent->of_node,
>> + port1);
>> + port_dev->pwrseq = pwrseq_alloc(&port_dev->dev, "usb-pwrseq");
>> + if (IS_ERR(port_dev->pwrseq)) {
>> + device_unregister(&port_dev->dev);
>> + return PTR_ERR(port_dev->pwrseq);
>
> Are we certain that port_dev hasn't been freed at this point? We just
> called device_unregister() on it, so it seems safer to save away the
> return value before calling device_unregister() here.
Right, good point. Thanks for feedback.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 12/12] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On 06/01/2016 01:59 PM, Peter Chen wrote:
> On Wed, Jun 01, 2016 at 10:02:21AM +0200, Krzysztof Kozlowski wrote:
>> On Odroid U3 (Exynos4412-based) board if USB was initialized by
>> bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
>> and LAN (smsc95xx) after after successful probing were not visible in the
>> system ("lsusb").
>>
>> In such case the devices had to be fully reset before configuring.
>> Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
>> in usb3503 HUB are not sufficient. Instead full reset has to be done by
>> disabling and enabling regulator.
>>
>> Signed-off-by: Krzysztof Kozlowski
>> ---
>> arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> index 31cdc036fda4..23e30e4609df 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
>> @@ -99,11 +99,15 @@
>> clock-names = "refclk";
>> clocks = <&pmu_system_controller 0>;
>> refclk-frequency = <2400>;
>> +
>> +power-sequence;
>> +ext-supply = <&buck8_reg>;
>> };
>>
>> &ehci {
>> port@1 {
>> status = "okay";
>> +usb-pwrseq = <&usb3503>;
>> };
>> port@2 {
>> status = "okay";
>> --
>> 1.9.1
>>
>
> The hub is under the port1, you may need to describe it
> under the port@1, see below:
> Documentation/devicetree/bindings/usb/usb-device.txt
My configuration is a little bit different than yours.
In my case I have a USB hub (usb3503) which is also a a i2c device
because it has to be configured through I2C.
I can add the power-sequence properties to the I2C node or as you
pointed under port using the vendor-product-id compatible. In the first
option: not many USB changes are needed. It works for me, at least as a
proof of concept.
The second solution: currently it does not work because the USB device
does not get enumerated before the power sequence begins. It would be
great if you could implement this on USB side.
>
> If I get Rob's comments correctly, you may need to consider
> below MMC and USB device tree description together, it seems
> hard for USB to use pwrseq driver, sorry for confusing you.
>
> If rob can accept below USB device description, we have to
> do it under USB. In future, if there is some suitable framework,
> we can move it.
>
> 1. MMC device:
> usdhc3_pwrseq: usdhc3_pwrseq {
> compatible = "mmc-pwrseq-simple";
> reset-gpios = <&gpio4 5 GPIO_ACTIVE_LOW>, /* WL_REG_ON */
> <&gpio4 7 GPIO_ACTIVE_LOW>, /* WL_HOSTWAKE
> */
> <&gpio3 25 GPIO_ACTIVE_LOW>, /* BT_REG_ON */
> <&gpio3 27 GPIO_ACTIVE_LOW>, /* BT_HOSTWAKE
> */
> <&gpio4 4 GPIO_ACTIVE_LOW>, /* BT_WAKE */
> <&gpio4 6 GPIO_ACTIVE_LOW>; /* BT_RST_N */
> };
>
> &usdhc3 {
> pinctrl-names = "default", "state_100mhz", "state_200mhz";
> pinctrl-0 = <&pinctrl_usdhc3>;
> pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> bus-width = <4>;
> non-removable;
> keep-power-in-suspend;
> wakeup-source;
> mmc-pwrseq = <&usdhc3_pwrseq>;
> status = "okay";
> };
>
> 2. USB device
>
> &usbotg1 {
> vbus-supply = <®_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>;
> };
Yes, that looks like what Rob wanted... Do you plan to work on it? The
power sequence is needed before device is enumerated.
BTW, if you would like to play with the patchset, it is here:
repo: https://github.com/krzk/linux
branch: for-next/odroid-u3-usb3503-lan-boot-fixes-v3
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 >> --- >> .../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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/12] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 02/14] simplefb: Use new devm_of_regulator_all_get helper and bulk API
Switch from manual way of getting all regulators to usage of
devm_of_regulator_all_get(). Additionally use the regulator bulk API
which changes the logic in case of failure of regulator enable. Before
if regulator_enable() returned error for one regulator, rest of them
were still enabled. The bulk API does everything atomically.
Signed-off-by: Krzysztof Kozlowski
---
Not tested.
---
drivers/video/fbdev/simplefb.c | 71 +-
1 file changed, 14 insertions(+), 57 deletions(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index e9cf19977285..897b95efa40d 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -178,8 +179,8 @@ struct simplefb_par {
struct clk **clks;
#endif
#if defined CONFIG_OF && defined CONFIG_REGULATOR
- u32 regulator_count;
- struct regulator **regulators;
+ unsigned int regulator_count;
+ struct regulator_bulk_data *regulators;
#endif
};
@@ -278,8 +279,6 @@ static void simplefb_clocks_destroy(struct simplefb_par
*par) { }
#if defined CONFIG_OF && defined CONFIG_REGULATOR
-#define SUPPLY_SUFFIX "-supply"
-
/*
* Regulator handling code.
*
@@ -303,61 +302,23 @@ static int simplefb_regulators_init(struct simplefb_par
*par,
struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
- struct property *prop;
- struct regulator *regulator;
- const char *p;
- int count = 0, i = 0, ret;
+ int ret;
if (dev_get_platdata(&pdev->dev) || !np)
return 0;
- /* Count the number of regulator supplies */
- for_each_property_of_node(np, prop) {
- p = strstr(prop->name, SUPPLY_SUFFIX);
- if (p && p != prop->name)
- count++;
- }
-
- if (!count)
+ ret = devm_of_regulator_all_get(&pdev->dev, &par->regulator_count,
&par->regulators);
+ if (ret)
+ return ret;
+ else if (!par->regulator_count)
return 0;
- par->regulators = devm_kcalloc(&pdev->dev, count,
- sizeof(struct regulator *), GFP_KERNEL);
- if (!par->regulators)
- return -ENOMEM;
-
- /* Get all the regulators */
- for_each_property_of_node(np, prop) {
- char name[32]; /* 32 is max size of property name */
-
- p = strstr(prop->name, SUPPLY_SUFFIX);
- if (!p || p == prop->name)
- continue;
-
- strlcpy(name, prop->name,
- strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
- regulator = devm_regulator_get_optional(&pdev->dev, name);
- if (IS_ERR(regulator)) {
- if (PTR_ERR(regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- dev_err(&pdev->dev, "regulator %s not found: %ld\n",
- name, PTR_ERR(regulator));
- continue;
- }
- par->regulators[i++] = regulator;
- }
- par->regulator_count = i;
-
/* Enable all the regulators */
- for (i = 0; i < par->regulator_count; i++) {
- ret = regulator_enable(par->regulators[i]);
- if (ret) {
- dev_err(&pdev->dev,
- "failed to enable regulator %d: %d\n",
- i, ret);
- devm_regulator_put(par->regulators[i]);
- par->regulators[i] = NULL;
- }
+ ret = regulator_bulk_enable(par->regulator_count, par->regulators);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to enable regulators: %d\n", ret);
+ return ret;
}
return 0;
@@ -365,14 +326,10 @@ static int simplefb_regulators_init(struct simplefb_par
*par,
static void simplefb_regulators_destroy(struct simplefb_par *par)
{
- int i;
-
if (!par->regulators)
return;
- for (i = 0; i < par->regulator_count; i++)
- if (par->regulators[i])
- regulator_disable(par->regulators[i]);
+ regulator_bulk_disable(par->regulator_count, par->regulators);
}
#else
static int simplefb_regulators_init(struct simplefb_par *par,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 11/14] EXAMPLE CODE: usb: port: Parse pwrseq phandle from Device Tree
Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
device. The pwrseq device will be used by USB hub to cycle the power
before activating ports.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.h | 3 +++
drivers/usb/core/port.c | 16
2 files changed, 19 insertions(+)
diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
index 34c1a7e22aae..68ca89780d26 100644
--- a/drivers/usb/core/hub.h
+++ b/drivers/usb/core/hub.h
@@ -24,6 +24,8 @@
#include
#include "usb.h"
+struct pwrseq;
+
struct usb_hub {
struct device *intfdev; /* the "interface" device */
struct usb_device *hdev;
@@ -101,6 +103,7 @@ struct usb_port {
struct usb_dev_state *port_owner;
struct usb_port *peer;
struct dev_pm_qos_request *req;
+ struct pwrseq *pwrseq;
enum usb_port_connect_type connect_type;
usb_port_location_t location;
struct mutex status_lock;
diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
index 460c855be0d0..4fce0250179c 100644
--- a/drivers/usb/core/port.c
+++ b/drivers/usb/core/port.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+#include
#include "hub.h"
@@ -526,6 +528,15 @@ int usb_hub_create_port_device(struct usb_hub *hub, int
port1)
return retval;
}
+ port_dev->dev.of_node = usb_of_get_child_node(hdev->dev.parent->of_node,
+ port1);
+ port_dev->pwrseq = pwrseq_alloc(&port_dev->dev, "usb-pwrseq");
+ if (IS_ERR(port_dev->pwrseq)) {
+ retval = PTR_ERR(port_dev->pwrseq);
+ device_unregister(&port_dev->dev);
+ return retval;
+ }
+
find_and_link_peer(hub, port1);
/*
@@ -567,8 +578,13 @@ void usb_hub_remove_port_device(struct usb_hub *hub, int
port1)
struct usb_port *port_dev = hub->ports[port1 - 1];
struct usb_port *peer;
+ pwrseq_power_off(port_dev->pwrseq);
+
peer = port_dev->peer;
if (peer)
unlink_peers(port_dev, peer);
+
+ pwrseq_free(port_dev->pwrseq);
+ port_dev->pwrseq = NULL;
device_unregister(&port_dev->dev);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 14/14] ARM: dts: exynos: Fix LAN and HUB after bootloader initialization on Odroid U3
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
and LAN (smsc95xx) after after successful probing were not visible in the
system ("lsusb").
In such case the devices had to be fully reset before configuring.
Reset by GPIO (called RESET_N pin) and by RESET field in STCD register
in usb3503 HUB are not sufficient. Instead full reset has to be done by
disabling and enabling regulator.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 31cdc036fda4..8fd50061d91b 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -99,11 +99,15 @@
clock-names = "refclk";
clocks = <&pmu_system_controller 0>;
refclk-frequency = <2400>;
+
+ power-sequence;
+ vdd-supply = <&buck8_reg>;
};
&ehci {
port@1 {
status = "okay";
+ usb-pwrseq = <&usb3503>;
};
port@2 {
status = "okay";
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 10/14] usb: hub: Handle deferred probe
Add support for deferred probing to the usb hub. Currently EPROBE_DEFER does not exist in usb hub path but future patches will add it on the port level. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- drivers/usb/core/hub.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index bee13517676f..c421745b84aa 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -1733,6 +1733,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id) struct usb_endpoint_descriptor *endpoint; struct usb_device *hdev; struct usb_hub *hub; + int ret; desc = intf->cur_altsetting; hdev = interface_to_usbdev(intf); @@ -1852,11 +1853,12 @@ descriptor_error: if (id->driver_info & HUB_QUIRK_CHECK_PORT_AUTOSUSPEND) hub->quirk_check_port_auto_suspend = 1; - if (hub_configure(hub, endpoint) >= 0) + ret = hub_configure(hub, endpoint); + if (ret >= 0) return 0; hub_disconnect(intf); - return -ENODEV; + return ret; } static int -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 06/14] 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
Reviewed-by: Javier Martinez Canillas
---
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
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
struct mmc_pwrseq_simple {
- struct mmc_pwrseq pwrseq;
+ struct pwrseq pwrseq;
bool clk_enabled;
struct clk *ext_clk;
struct gpio_descs *reset_gpios;
[RFC v4 13/14] ARM: dts: exynos: Switch the buck8 to GPIO mode on Odroid U3
Switch the control of buck8 to GPIO mode. It is faster than I2C/register mode and it is the easiest way to disable it (regulator state is a logical OR state of GPIO and register value). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts index d73aa6c58fe3..31cdc036fda4 100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts @@ -74,6 +74,7 @@ regulator-name = "BUCK8_P3V3"; regulator-min-microvolt = <330>; regulator-max-microvolt = <330>; + maxim,ena-gpios = <&gpa1 1 GPIO_ACTIVE_HIGH>; }; /* VDDQ for MSHC (eMMC card) */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 00/14] usb/mmc/power: Generic power sequence (and fix USB/LAN when TFTP booting)
Hi,
Another version for solving a problem of power sequence on USB
hubs and devices. Apparently I am not the only one experiencing it.
The patchset tries to provide a framework for generic power sequence
of USB devices but the USB part is left to Peter Chen.
Patchset is also available here:
repo: https://github.com/krzk/linux
branch: for-next/odroid-u3-usb3503-lan-boot-fixes-v4
Changes since v3
1. Address Rob's comments. All regulator supplies are parsed and
toggled during power sequence. This comes with two new patches:
a. regulator,
b. simplefb.
2. Minor fixes in pwrseq-simple driver - proper module removal path.
3. Minor fixes in example USB code (pointed out by Stephen Boyd).
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 (14):
regulator: of: Add helper for getting all supplies
simplefb: Use new devm_of_regulator_all_get helper and bulk API
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 regulators 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} | 30 ++-
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/mmc/core/pwrseq_simple.c | 141
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/power/pwrseq/pwrseq_simple.c | 245 +
drivers/regulator/of_regulator.c | 86
drivers/usb/core/hub.c | 16 +-
drivers/usb/core/hub.h | 3 +
drivers/usb/core/port.c| 15 ++
drivers/video/fbdev/simplefb.c | 71 ++
include/linux/mmc/host.h | 4 +-
include/linux/pwrseq.h | 63 ++
include/linux/regulator/of_regulator.h | 13 ++
26 files changed, 680 insertions(+), 395 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} (50%)
delete mode 100644 drivers/mmc/core/pwrseq.c
delete mode 100644 drivers/mmc/core/pwrseq.h
delete mode 100644 drivers/mmc/
[RFC v4 05/14] power: pwrseq: Enable COMPILE_TEST for drivers
Allow build testing for power sequence drivers. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Javier Martinez Canillas --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 12/14] 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 --- 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 #include #include +#include #include #include @@ -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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 08/14] power: pwrseq: simple: Add support for regulators and generic property
Some devices need real hard-reset by cutting the power. During power
sequence turn off and on all of provided regulators.
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, supplies etc.
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/power/pwrseq/pwrseq-simple.txt| 30 +-
drivers/power/pwrseq/pwrseq_simple.c | 113 -
2 files changed, 136 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..7e5a414a67fc 100644
--- a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
@@ -1,11 +1,18 @@
-* 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. Property for any node
+ Required properties:
+ - power-sequence
+
+2. Separate node (not recommended for new users)
+ Required properties:
+ - compatible : contains "mmc-pwrseq-simple".
+
Optional properties:
- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are
asserted
@@ -16,6 +23,8 @@ Optional properties:
See ../clocks/clock-bindings.txt for details.
- clock-names : Must include the following entry:
"ext_clock" (External clock provided to the card).
+- *-supply : If supplies are provided, the driver will enable and disable
+ them during power sequence.
Example:
@@ -25,3 +34,16 @@ Example:
clocks = <&clk_32768_ck>;
clock-names = "ext_clock";
}
+
+ 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;
+ vdd-supply = <&buck8_reg>;
+ };
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index 93807a6ef162..f70e207f994b 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
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
* Simple MMC power sequence management
*/
+#include
#include
#include
#include
@@ -16,13 +19,25 @@
#include
#include
#include
+#include
+#include
#include
+#include
+
+static LIST_HEAD(mmc_pwrseq_devs);
+
+struct mmc_pwrseq_dev {
+ struct platform_device *pdev;
+ struct list_head entry;
+};
struct mmc_pwrseq_simple {
struct pwrseq pwrseq;
bool clk_enabled;
struct clk *ext_clk;
struct gpio_descs *reset_gpios;
+ unsigned int regulator_count;
+ struct regulator_bulk_data *regulators;
};
#define to_pwrseq_simple(p) container_of(p, struct mmc_pwrseq_simple, pwrseq)
@@ -60,6 +75,14 @@ static void mmc_pwrseq_simple_post_power_on(struct pwrseq
*_pwrseq)
{
struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
+ if (pwrseq->regulators) {
+ int err;
+
+ err = regulator_bulk_enable(pwrseq->regulator_count,
+ pwrseq->regulators);
+ WARN_ON_ONCE(err);
+ }
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
@@ -73,6 +96,14 @@ static void mmc_pwrseq_simple_power_off(struct pwrseq
*_pwrseq)
clk_disable_unprepare(pwrseq->ext_clk);
pwrseq->clk_enabled = false;
}
+
+ if (pwrseq->regulators) {
+ int err;
+
+ err = regulator_bulk_disable(pwrseq->regulator_count,
+pwrseq->regulators);
+ WARN_ON_ONCE(err);
+ }
}
static const struct pwrseq_ops mmc_pwrseq_simple_ops = {
@@ -91,6 +122,7 @@ static int mmc_pwrseq_simple_probe(struct platform_device
*pdev)
{
struct mmc_pwrseq_simple *pwrseq;
struct device *dev
[RFC v4 09/14] power: pwrseq: Add support for USB hubs with external power
Some USB devices on embedded boards have external power supply which has
to be reset in certain conditions. Add pwrseq interface for this.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/pwrseq/pwrseq.c | 47 ++-
include/linux/pwrseq.h| 11 ++
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 495a19d3c30b..722aff4f740f 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -1,7 +1,9 @@
/*
- * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2014 Linaro Ltd
+ * Copyright (C) 2016 Samsung Electronics
*
* Author: Ulf Hansson
+ * Krzysztof Kozlowski
*
* License terms: GNU General Public License (GPL) version 2
*
@@ -52,6 +54,42 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name)
+{
+ struct device_node *np;
+ struct pwrseq *p, *ret = NULL;
+
+ np = of_parse_phandle(dev->of_node, phandle_name, 0);
+ if (!np)
+ return NULL;
+
+ mutex_lock(&pwrseq_list_mutex);
+ list_for_each_entry(p, &pwrseq_list, pwrseq_node) {
+ if (p->dev->of_node == np) {
+ if (!try_module_get(p->owner))
+ dev_err(dev,
+ "increasing module refcount failed\n");
+ else
+ ret = p;
+
+ break;
+ }
+ }
+
+ of_node_put(np);
+ mutex_unlock(&pwrseq_list_mutex);
+
+ if (!ret) {
+ dev_dbg(dev, "%s defer probe\n", phandle_name);
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ dev_info(dev, "allocated usb-pwrseq\n");
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pwrseq_alloc);
+
void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
if (pwrseq && pwrseq->ops->pre_power_on)
@@ -84,6 +122,13 @@ void mmc_pwrseq_free(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_free);
+void pwrseq_free(const struct pwrseq *pwrseq)
+{
+ if (pwrseq)
+ module_put(pwrseq->owner);
+}
+EXPORT_SYMBOL_GPL(pwrseq_free);
+
int pwrseq_register(struct pwrseq *pwrseq)
{
if (!pwrseq || !pwrseq->ops || !pwrseq->dev)
diff --git a/include/linux/pwrseq.h b/include/linux/pwrseq.h
index fcc8fd855d4c..6215b3d6350d 100644
--- a/include/linux/pwrseq.h
+++ b/include/linux/pwrseq.h
@@ -31,9 +31,13 @@ void pwrseq_unregister(struct pwrseq *pwrseq);
void pwrseq_pre_power_on(struct pwrseq *pwrseq);
void pwrseq_post_power_on(struct pwrseq *pwrseq);
void pwrseq_power_off(struct pwrseq *pwrseq);
+
int mmc_pwrseq_alloc(struct mmc_host *host);
void mmc_pwrseq_free(struct mmc_host *host);
+struct pwrseq *pwrseq_alloc(struct device *dev, const char *phandle_name);
+void pwrseq_free(const struct pwrseq *pwrseq);
+
#else /* CONFIG_POWER_SEQ */
static inline int pwrseq_register(struct pwrseq *pwrseq)
@@ -44,9 +48,16 @@ static inline void pwrseq_unregister(struct pwrseq *pwrseq)
{}
static inline void pwrseq_pre_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_post_power_on(struct pwrseq *pwrseq) {}
static inline void pwrseq_power_off(struct pwrseq *pwrseq) {}
+
static inline int mmc_pwrseq_alloc(struct mmc_host *host) { return 0; }
static inline void mmc_pwrseq_free(struct mmc_host *host) {}
+static inline struct pwrseq *pwrseq_alloc(struct device *dev, const char
*phandle_name)
+{
+ return NULL;
+}
+static inline void pwrseq_free(const struct pwrseq *pwrseq) {}
+
#endif /* CONFIG_POWER_SEQ */
#endif /* _LINUX_PWRSEQ_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 04/14] 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 Reviewed-by: Javier Martinez Canillas --- 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 +L: linux-...@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 M: Lorenzo Pieralisi -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC v4 03/14] power/mmc: Move pwrseq drivers to power/pwrseq
The MMC power sequence drivers are useful also outside of MMC world: for
USB devices needed a hard-reset before probing. Before extending and
re-using pwrseq drivers, move them to a new place.
The commit does not introduce significant changes in the pwrseq drivers
code so still all the functions are prefixed with "mmc_pwrseq". However
the MMC-specific pwrseq functions has to be now exported and everything
is hidden not by CONFIG_OF but by new CONFIG_POWER_SEQ option.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
.../pwrseq/pwrseq-emmc.txt}| 0
.../pwrseq/pwrseq-simple.txt} | 0
drivers/mmc/Kconfig| 2 --
drivers/mmc/core/Makefile | 3 ---
drivers/mmc/core/core.c| 2 +-
drivers/mmc/core/host.c| 2 +-
drivers/power/Kconfig | 1 +
drivers/power/Makefile | 1 +
drivers/{mmc/core => power/pwrseq}/Kconfig | 18 +-
drivers/power/pwrseq/Makefile | 3 +++
drivers/{mmc/core => power/pwrseq}/pwrseq.c| 8 ++--
drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c | 3 +--
drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c | 3 +--
{drivers/mmc/core => include/linux}/pwrseq.h | 6 +++---
14 files changed, 31 insertions(+), 21 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} (100%)
rename drivers/{mmc/core => power/pwrseq}/Kconfig (66%)
create mode 100644 drivers/power/pwrseq/Makefile
rename drivers/{mmc/core => power/pwrseq}/pwrseq.c (90%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_emmc.c (99%)
rename drivers/{mmc/core => power/pwrseq}/pwrseq_simple.c (99%)
rename {drivers/mmc/core => include/linux}/pwrseq.h (94%)
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-emmc.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
b/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
similarity index 100%
rename from Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
rename to Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index f2eeb38efa65..7ade379e0634 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -21,8 +21,6 @@ config MMC_DEBUG
if MMC
-source "drivers/mmc/core/Kconfig"
-
source "drivers/mmc/card/Kconfig"
source "drivers/mmc/host/Kconfig"
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index f007151dfdc6..a901d3cd09d3 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -8,7 +8,4 @@ mmc_core-y := core.o bus.o host.o \
sdio.o sdio_ops.o sdio_bus.o \
sdio_cis.o sdio_io.o sdio_irq.o \
quirks.o slot-gpio.o
-mmc_core-$(CONFIG_OF) += pwrseq.o
-obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
-obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 8b4dfd45433b..edefc3fbebe6 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -43,7 +44,6 @@
#include "bus.h"
#include "host.h"
#include "sdio_bus.h"
-#include "pwrseq.h"
#include "mmc_ops.h"
#include "sd_ops.h"
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 1be42fab1a30..1db7d5802adc 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -29,7 +30,6 @@
#include "core.h"
#include "host.h"
#include "slot-gpio.h"
-#include "pwrseq.h"
#define cls_dev_to_mmc_host(d) container_of(d, struct mmc_host, class_dev)
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 421770ddafa3..2702aca6cd2c 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -511,5 +511,6 @@ config AXP20X_POWER
endif # POWER_SUPPLY
+source "drivers/power/pwrseq/Kconfig"
source "drivers/power/reset/Kconfig"
source "driver
[RFC v4 07/14] power: pwrseq: Generalize mmc_pwrseq operations by removing mmc prefix
The power sequence hooks (mmc_pwrseq_pre_power_on(),
mmc_pwrseq_post_power_on() and mmc_pwrseq_power_off()) can be made more
generic to allow re-use in other subsystems. They do not need to take
pointer to struct mmc_host but instead the struct pwrseq should be
sufficient.
Remove the "mmc" prefix and use the pointer to struct pwrseq as
argument.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/mmc/core/core.c | 6 +++---
drivers/power/pwrseq/pwrseq.c| 24 +---
drivers/power/pwrseq/pwrseq_emmc.c | 6 ++
drivers/power/pwrseq/pwrseq_simple.c | 14 ++
include/linux/pwrseq.h | 18 +-
5 files changed, 29 insertions(+), 39 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index edefc3fbebe6..09a4722f9037 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1719,7 +1719,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
if (host->ios.power_mode == MMC_POWER_ON)
return;
- mmc_pwrseq_pre_power_on(host);
+ pwrseq_pre_power_on(host->pwrseq);
host->ios.vdd = fls(ocr) - 1;
host->ios.power_mode = MMC_POWER_UP;
@@ -1740,7 +1740,7 @@ void mmc_power_up(struct mmc_host *host, u32 ocr)
*/
mmc_delay(10);
- mmc_pwrseq_post_power_on(host);
+ pwrseq_post_power_on(host->pwrseq);
host->ios.clock = host->f_init;
@@ -1759,7 +1759,7 @@ void mmc_power_off(struct mmc_host *host)
if (host->ios.power_mode == MMC_POWER_OFF)
return;
- mmc_pwrseq_power_off(host);
+ pwrseq_power_off(host->pwrseq);
host->ios.clock = 0;
host->ios.vdd = 0;
diff --git a/drivers/power/pwrseq/pwrseq.c b/drivers/power/pwrseq/pwrseq.c
index 9c665821f890..495a19d3c30b 100644
--- a/drivers/power/pwrseq/pwrseq.c
+++ b/drivers/power/pwrseq/pwrseq.c
@@ -52,32 +52,26 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
}
EXPORT_SYMBOL_GPL(mmc_pwrseq_alloc);
-void mmc_pwrseq_pre_power_on(struct mmc_host *host)
+void pwrseq_pre_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->pre_power_on)
- pwrseq->ops->pre_power_on(host);
+ pwrseq->ops->pre_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_pre_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_pre_power_on);
-void mmc_pwrseq_post_power_on(struct mmc_host *host)
+void pwrseq_post_power_on(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->post_power_on)
- pwrseq->ops->post_power_on(host);
+ pwrseq->ops->post_power_on(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_post_power_on);
+EXPORT_SYMBOL_GPL(pwrseq_post_power_on);
-void mmc_pwrseq_power_off(struct mmc_host *host)
+void pwrseq_power_off(struct pwrseq *pwrseq)
{
- struct pwrseq *pwrseq = host->pwrseq;
-
if (pwrseq && pwrseq->ops->power_off)
- pwrseq->ops->power_off(host);
+ pwrseq->ops->power_off(pwrseq);
}
-EXPORT_SYMBOL_GPL(mmc_pwrseq_power_off);
+EXPORT_SYMBOL_GPL(pwrseq_power_off);
void mmc_pwrseq_free(struct mmc_host *host)
{
diff --git a/drivers/power/pwrseq/pwrseq_emmc.c
b/drivers/power/pwrseq/pwrseq_emmc.c
index a68ac9a68e04..dbb7e753beb2 100644
--- a/drivers/power/pwrseq/pwrseq_emmc.c
+++ b/drivers/power/pwrseq/pwrseq_emmc.c
@@ -19,8 +19,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_emmc {
struct pwrseq pwrseq;
struct notifier_block reset_nb;
@@ -37,9 +35,9 @@ static void __mmc_pwrseq_emmc_reset(struct mmc_pwrseq_emmc
*pwrseq)
udelay(200);
}
-static void mmc_pwrseq_emmc_reset(struct mmc_host *host)
+static void mmc_pwrseq_emmc_reset(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(host->pwrseq);
+ struct mmc_pwrseq_emmc *pwrseq = to_pwrseq_emmc(_pwrseq);
__mmc_pwrseq_emmc_reset(pwrseq);
}
diff --git a/drivers/power/pwrseq/pwrseq_simple.c
b/drivers/power/pwrseq/pwrseq_simple.c
index d5fbd653153e..93807a6ef162 100644
--- a/drivers/power/pwrseq/pwrseq_simple.c
+++ b/drivers/power/pwrseq/pwrseq_simple.c
@@ -18,8 +18,6 @@
#include
#include
-#include
-
struct mmc_pwrseq_simple {
struct pwrseq pwrseq;
bool clk_enabled;
@@ -46,9 +44,9 @@ static void mmc_pwrseq_simple_set_gpios_value(struct
mmc_pwrseq_simple *pwrseq,
}
}
-static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pre_power_on(struct pwrseq *_pwrseq)
{
- struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(host->pwrseq);
+ struct mmc_pwrseq_simple *pwrseq = to_pwrseq_simple(_pwrseq);
if (!IS_ERR(pwrseq->ext_clk) && !pwrseq-
[RFC v4 01/14] regulator: of: Add helper for getting all supplies
Few drivers have a need of getting regulator supplies without knowing
their names:
1. The Simple Framebuffer driver works on setup provided by bootloader
(outside of scope of kernel);
2. Generic power sequence driver may be attached to any device node.
Add a Device Tree helper for parsing "-supply" properties and returning
allocated bulk regulator consumers.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/of_regulator.c | 86 ++
include/linux/regulator/of_regulator.h | 13 +
2 files changed, 99 insertions(+)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index cd828dbf9d52..0d2c8dd0ebc0 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -350,3 +350,89 @@ struct regulator_init_data
*regulator_of_get_init_data(struct device *dev,
return init_data;
}
+
+/**
+ * devm_of_regulator_all_get - get all regulator consumers
+ *
+ * @dev: Device to supply
+ * @num_consumers Number of consumers registered (only on success)
+ * @consumers: Configuration of consumers; names of supplies and clients
+ * are stored here; allocated only on success (NULL otherwise);
+ *
+ * @return 0 on success, an errno on failure.
+ *
+ * This helper function allows drivers to get all regulator consumers
+ * for given device in one operation. The names of regulator supplies
+ * do not have to be provided. If any of the regulators cannot be
+ * acquired then any regulators that were allocated will be freed
+ * before returning to the caller.
+ */
+int devm_of_regulator_all_get(struct device *dev, unsigned int *num_consumers,
+ struct regulator_bulk_data **consumers)
+{
+ struct device_node *np = dev->of_node;
+ struct regulator_bulk_data *bulk;
+ unsigned int count = 0, i = 0;
+ struct property *prop;
+ const char *p;
+ int ret;
+
+ if (!np) {
+ ret = 0;
+ goto err; /* Not really an error */
+ }
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, "-supply");
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count) {
+ ret = 0;
+ goto err; /* Not really an error */
+ }
+
+ bulk = devm_kcalloc(dev, count, sizeof(**consumers), GFP_KERNEL);
+ if (!bulk) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ /* Get all the names for supplies */
+ for_each_property_of_node(np, prop) {
+ char *name;
+ int len;
+
+ p = strstr(prop->name, "-supply");
+ if (!p || p == prop->name)
+ continue;
+
+ len = strlen(prop->name) - strlen("-supply") + 1;
+ name = devm_kzalloc(dev, len, GFP_KERNEL);
+ if (!name) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ strlcpy(name, prop->name, len);
+ bulk[i++].supply = name;
+ }
+
+ ret = devm_regulator_bulk_get(dev, i, bulk);
+ if (ret)
+ goto err;
+
+ *consumers = bulk;
+ *num_consumers = i;
+
+ return 0;
+
+err:
+ *num_consumers = 0;
+ *consumers = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(devm_of_regulator_all_get);
diff --git a/include/linux/regulator/of_regulator.h
b/include/linux/regulator/of_regulator.h
index 763953f7e3b8..93a3b7fe92e8 100644
--- a/include/linux/regulator/of_regulator.h
+++ b/include/linux/regulator/of_regulator.h
@@ -7,6 +7,7 @@
#define __LINUX_OF_REG_H
struct regulator_desc;
+struct regulator_bulk_data;
struct of_regulator_match {
const char *name;
@@ -24,6 +25,9 @@ extern struct regulator_init_data
extern int of_regulator_match(struct device *dev, struct device_node *node,
struct of_regulator_match *matches,
unsigned int num_matches);
+extern int devm_of_regulator_all_get(struct device *dev,
+unsigned int *num_consumers,
+struct regulator_bulk_data **consumers);
#else
static inline struct regulator_init_data
*of_get_regulator_init_data(struct device *dev,
@@ -40,6 +44,15 @@ static inline int of_regulator_match(struct device *dev,
{
return 0;
}
+static inline int devm_of_regulator_all_get(struct device *dev,
+ unsigned int *num_consumers,
+ struct regulator_bulk_data
**consumers)
+{
+ *num_consumers = 0;
+ *consumers = NULL;
+
+ return 0;
+}
#endif /* CONFIG_OF */
#endif /* __LINUX_OF_REG_H */
--
1.9.1
-
Re: [RFC v4 01/14] regulator: of: Add helper for getting all supplies
On 06/09/2016 12:29 PM, Mark Brown wrote:
> On Thu, Jun 09, 2016 at 11:44:18AM +0200, Krzysztof Kozlowski wrote:
>> Few drivers have a need of getting regulator supplies without knowing
>> their names:
>> 1. The Simple Framebuffer driver works on setup provided by bootloader
>>(outside of scope of kernel);
>> 2. Generic power sequence driver may be attached to any device node.
>>
>> Add a Device Tree helper for parsing "-supply" properties and returning
>> allocated bulk regulator consumers.
>
> I'm still very concerned that this is just an invitation to people to
> write half baked regulator consumers and half baked DTs to go along with
> it, making it a standard API that doesn't have big red flags on it that
> will flag up when "normal" drivers use it is not good. Right now this
> just looks like a standard API and people are going to just start using
> it. If we are going to do this perhaps we need a separate header or
> something to help flag this up.
No problem, I can move it to a special header. Actually, if you dislike
this as an API, it does not have to be in header at all. I can just
duplicate the simplefb code.
> In the case of power sequences I'd expect the sequences to perform
> operations on named supplies - the core shouldn't know what the supplies
> are but the thing specifying the sequence should.
Hm, so maybe passing names like:
usb3503@08 {
reset-gpios = <&gpx3 5 GPIO_ACTIVE_HIGH>;
initial-mode = <1>;
vdd-supply = <&buck8_reg>;
foo-supply = <&buck9_reg>;
power-sequence;
power-sequence-supplies = "vdd", "foo";
};
but this is getting against initial idea of not adding any
power-sequence properties.
>
>> drivers/regulator/of_regulator.c | 86
>> ++
>> include/linux/regulator/of_regulator.h | 13 +
>> 2 files changed, 99 insertions(+)
>
> The external interface shouldn't be DT specific, the Intel people are
> busy importing all of DT into ACPI so they'll doubtless want an ACPI
> version.
Sure, I'll add it if this approach is acceptable. At this moment this
is not necessary to show my idea so I prefer to avoid doing work which
might be discarded very fast by review.
Thanks for feedback!
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/12] power: pwrseq: rename file name for generic driver
On 06/17/2016 12:09 PM, Peter Chen wrote:
> The individual driver file name is better to contain module name.
>
> Signed-off-by: Peter Chen
> ---
> .../power/pwrseq/{pwrseq-simple.txt => mmc-pwrseq-simple.txt} | 0
> drivers/power/pwrseq/Makefile | 4
> ++--
> drivers/power/pwrseq/{pwrseq.c => core.c} | 0
> drivers/power/pwrseq/{pwrseq_simple.c => pwrseq_mmc_simple.c} | 0
> 4 files changed, 2 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/power/pwrseq/{pwrseq-simple.txt =>
> mmc-pwrseq-simple.txt} (100%)
> rename drivers/power/pwrseq/{pwrseq.c => core.c} (100%)
> rename drivers/power/pwrseq/{pwrseq_simple.c => pwrseq_mmc_simple.c} (100%)
>
> diff --git a/Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> b/Documentation/devicetree/bindings/power/pwrseq/mmc-pwrseq-simple.txt
> similarity index 100%
> rename from Documentation/devicetree/bindings/power/pwrseq/pwrseq-simple.txt
> rename to Documentation/devicetree/bindings/power/pwrseq/mmc-pwrseq-simple.txt
> diff --git a/drivers/power/pwrseq/Makefile b/drivers/power/pwrseq/Makefile
> index 9e40e4b..d475e01 100644
> --- a/drivers/power/pwrseq/Makefile
> +++ b/drivers/power/pwrseq/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_POWER_SEQ) += pwrseq.o
> -obj-$(CONFIG_POWER_SEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_POWER_SEQ) += core.o
> +obj-$(CONFIG_POWER_SEQ_SIMPLE) += pwrseq_mmc_simple.o
Although the driver was developed for MMC but it is quite generic (or
rather - mmc independent). The name of the driver is just
"pwrseq_simple" so I think MMC prefix is not needed.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Regression, usb-dwc3 not working, Odroid XU3, usb 3.0
Hi, Since three recent next releases (first on 20160630), on Odroid XU3 board the USB 3.0 host port (the only one) stopped working. This is a "samsung,exynos5250-dwusb3" (drivers/usb/dwc3/dwc3-exynos.c). Two issues here: 1. The port does not show up as USB 3.0 device. This one device is missing: Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub 2. The port does not work even for 2.0 devices (I didn't test 1.0). config: exynos_defconfig (ARM) DTS: exynos5422-odroidxu3.dts Bisect points to merge commit: # first bad commit: [215db9481814bfae69cde49d82865c74189e435f] Merge tag 'usb-for-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Bisect log: # bad: [d936b5e461b9545fa9a8a3357a40eea17aea5e28] Add linux-next specific files for 20160701 # good: [1a0a02d1efa066001fd315c1b4df583d939fa2c4] Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect start 'next/master' 'next/stable' # good: [e3f87b945da70903776e67a549ab3df78c4d6389] Merge remote-tracking branch 'drm/drm-next' git bisect good e3f87b945da70903776e67a549ab3df78c4d6389 # good: [d71ef0d1368d8d6054ef44765c0f1fe866f4b2e0] Merge remote-tracking branch 'clockevents/clockevents/next' git bisect good d71ef0d1368d8d6054ef44765c0f1fe866f4b2e0 # bad: [9aff7978ef28c3eb5415c624049c189d48b13dff] Merge remote-tracking branch 'staging/staging-next' git bisect bad 9aff7978ef28c3eb5415c624049c189d48b13dff # good: [47feda95152a47aa15091c93ea7ad82869127278] Merge remote-tracking branch 'tty/tty-next' git bisect good 47feda95152a47aa15091c93ea7ad82869127278 # good: [6f65aa8925f7a908eb4d08339c03c40a300ac461] staging/android: make sw_ioctl info internal to sw_sync.c git bisect good 6f65aa8925f7a908eb4d08339c03c40a300ac461 # bad: [215db9481814bfae69cde49d82865c74189e435f] Merge tag 'usb-for-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next git bisect bad 215db9481814bfae69cde49d82865c74189e435f # good: [f2df679b6c556fd3b0b7ffafea170f1679086455] usb: dwc3: gadget: avoid while(1) in run_stop() git bisect good f2df679b6c556fd3b0b7ffafea170f1679086455 # good: [0d7995031a8e7a34e5638d57a44a51aae39e321c] usb: renesas_usbhs: show error code when probe failed git bisect good 0d7995031a8e7a34e5638d57a44a51aae39e321c # good: [86065c2719a5685cef36945f09def3f0658c7860] xhci: don't rely on precalculated value of needed trbs in the enqueue loop git bisect good 86065c2719a5685cef36945f09def3f0658c7860 # good: [95b57df45062d7005ff01ed956b69166b6b3481e] usb: dwc3: host: use build-in property instead of platform data git bisect good 95b57df45062d7005ff01ed956b69166b6b3481e # good: [4fdef698383db07d829da567e0e405fc41ff3a89] usb: renesas_usbhs: fix NULL pointer dereference in xfer_work() git bisect good 4fdef698383db07d829da567e0e405fc41ff3a89 # good: [4e84e22195910b315b36eca149febd0a6b02f7c4] usb: early/ehci-dbgp: make it explicitly non-modular git bisect good 4e84e22195910b315b36eca149febd0a6b02f7c4 # good: [107a4b535b7d1da4203a26949775d67173e96e04] usb: renesas_usbhs: make usbhs_write32() static git bisect good 107a4b535b7d1da4203a26949775d67173e96e04 # good: [15e4292a2d21e9997fdb2b8c014cc461b3f268f0] usb: renesas_usbhs: protect the CFIFOSEL setting in usbhsg_ep_enable() git bisect good 15e4292a2d21e9997fdb2b8c014cc461b3f268f0 # first bad commit: [215db9481814bfae69cde49d82865c74189e435f] Merge tag 'usb-for-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next Attached dmesg - good and bad. Please let me know if you need more information. Best regards, Krzysztof [0.00] Booting Linux on physical CPU 0x100 [0.00] Linux version 4.7.0-rc4-00069-gf2df679b6c55 (k.kozlowski@AMDC2174) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) ) #926 SMP PREEMPT Mon Jul 4 12:51:19 CEST 2016 [0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Hardkernel Odroid XU3 [0.00] cma: Reserved 64 MiB at 0xba80 [0.00] Memory policy: Data cache writealloc [0.00] Samsung CPU ID: 0xe5422001 [0.00] On node 0 totalpages: 514560 [0.00] free_area_init_node: node 0, pgdat c0c4c4c0, node_mem_map ef02 [0.00] Normal zone: 1536 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 192512 pages, LIFO batch:31 [0.00] HighMem zone: 322048 pages, LIFO batch:31 [0.00] Running under secure firmware. [0.00] percpu: Embedded 13 pages/cpu @eef62000 s24000 r8192 d21056 u53248 [0.00] pcpu-alloc: s24000 r8192 d21056 u53248 alloc=13*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 513024 [0.00] Kernel
Re: [PATCH 1/2] dt-bindings: usb: add DT binding for s3c2410 USB OHCI controller
On Fri, Nov 25, 2016 at 12:47:28PM -0200, Sergio Prado wrote:
> Adds the device tree bindings description for Samsung S3C2410 and
> compatible USB OHCI controller.
>
> Signed-off-by: Sergio Prado
> ---
> .../devicetree/bindings/usb/s3c2410-usb.txt| 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/s3c2410-usb.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> new file mode 100644
> index ..e45b38ce2986
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/s3c2410-usb.txt
> @@ -0,0 +1,22 @@
> +Samsung S3C2410 and compatible SoC USB controller
> +
> +OHCI
> +
> +Required properties:
> + - compatible: should be "samsung,s3c2410-ohci" for USB host controller
> + - reg: address and lenght of the controller memory mapped region
s/lenght/length/
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> + - interrupts: interrupt number for the USB OHCI controller
> + - clocks: Should reference the bus and host clocks
> + - clock-names: Should contain two strings
> + "usb-bus-host" for the USB bus clock
> + "usb-host" for the USB host clock
> +
> +Example:
> +
> +usb0: ohci@4900 {
> + compatible = "samsung,s3c2410-ohci";
> + reg = <0x4900 0x100>;
> + interrupts = <0 0 26 3>;
> + clocks = <&clocks UCLK>, <&clocks HCLK_USBH>;
> + clock-names = "usb-bus-host", "usb-host";
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: ohci: s3c2410: allow probing from device tree
On Fri, Nov 25, 2016 at 12:47:29PM -0200, Sergio Prado wrote:
> Allows configuring Samsung's s3c2410 USB OHCI controller using a
> devicetree.
>
> Signed-off-by: Sergio Prado
> ---
> drivers/usb/host/ohci-s3c2410.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
> index 7a1919ca543a..d8e03a801f2e 100644
> --- a/drivers/usb/host/ohci-s3c2410.c
> +++ b/drivers/usb/host/ohci-s3c2410.c
> @@ -457,6 +457,13 @@ static int ohci_hcd_s3c2410_drv_resume(struct device
> *dev)
> .resume = ohci_hcd_s3c2410_drv_resume,
> };
>
> +static const struct of_device_id ohci_hcd_s3c2410_dt_ids[] = {
> + { .compatible = "samsung,s3c2410-ohci" },
> + { /* sentinel */ }
> +};
> +
A nit, usually MODULE_DEVICE_TABLE comes right after the table, without
a blank line.
Beside that:
Acked-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> +MODULE_DEVICE_TABLE(of, ohci_hcd_s3c2410_dt_ids);
> +
> static struct platform_driver ohci_hcd_s3c2410_driver = {
> .probe = ohci_hcd_s3c2410_drv_probe,
> .remove = ohci_hcd_s3c2410_drv_remove,
> @@ -464,6 +471,7 @@ static int ohci_hcd_s3c2410_drv_resume(struct device *dev)
> .driver = {
> .name = "s3c2410-ohci",
> .pm = &ohci_hcd_s3c2410_pm_ops,
> + .of_match_table = ohci_hcd_s3c2410_dt_ids,
> },
> };
>
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting
On Tue, Dec 13, 2016 at 2:34 PM, Hans Verkuil wrote: > Try again, this time with Krzysztof's new email address... > > > On 13/12/16 13:20, Hans Verkuil wrote: >> >> Hi Krzysztof, >> >> This still seems to be broken with the latest 4.9 kernel, right? >> >> Has there been any progress on this? Do you have an updated patch series >> for me to use? Hi, I think it is not fixed. Still. I left this work to others. AFAIK, Peter Chen is working on a new generic approach: https://lwn.net/Articles/703556/ On top of his patchset, Odroid would need some DTS code as well (and maybe something in usb3503). However I do not plan to work on this anymore as I do not have Odroid U3 anymore. Marek and Bartlomiej from Samsung Poland are in CC-list so maybe they would like to continue the work? Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 0/8] power: add power sequence library
On Mon, Nov 14, 2016 at 09:35:51AM +0800, Peter Chen wrote: > Hi all, > > This is a follow-up for my last power sequence framework patch set [1]. > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of > power sequence instances will be added at postcore_initcall, the match > criteria is compatible string first, if the compatible string is not > matched between dts and library, it will try to use generic power sequence. > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off > if only one power sequence instance is needed, for more power sequences > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub > driver). > > In future, if there are special power sequence requirements, the special > power sequence library can be created. > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > two hot-plug devices to simulate this use case, the related binding > change is updated at patch [1/6], The udoo board changes were tested > using my last power sequence patch set.[3] > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > need to power on itself before it can be found by ULPI bus. > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > > Changes for v10: > - Improve the kernel-doc for power sequence core, including exported APIs and > main structure. [Patch 2/8] > - Change Kconfig, and let the user choose power sequence. [Patch 2/8] > - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not > be intended to export currently. [Patch 2/8] > - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8] Hi Peter, It is great that you continued the work on this. I saw (in some previous mails) your repo mentioned: https://git.kernel.org/cgit/linux/kernel/git/peter.chen/usb.git/ Does it contain the recent version of this patchset? I want to build on top of it fixes for usb3503 on Odroid U3 board. Best regards, Krzysztof > > Changes for v9: > - Add Vaibhav Hiremath's reviewed-by [Patch 4/8] > - Rebase to v4.9-rc1 > > Changes for v8: > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid > preallocate instances problem which the number of instance is decided at > compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8] > - Delete pwrseq_compatible_sample.c which is the demo purpose to show > compatible > match method. [Patch 2/8] > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8] > > Changes for v7: > - Create kinds of power sequence instance at postcore_initcall, and match > the instance with node using compatible string, the beneit of this is > the host driver doesn't need to consider which pwrseq instance needs > to be used, and pwrseq core will match it, however, it eats some memories > if less power sequence instances are used. [Patch 2/8] > - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch > 2/8] > - Fix the comments Vaibhav Hiremath adds for error path for clock and do not > use device_node for parameters at pwrseq_on. [Patch 2/8] > - Simplify the caller to use power sequence, follows Alan's commnets [Patch > 4/8] > - Tested three pwrseq instances together using both specific compatible > string and > generic libraries. > > Changes for v6: > - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6]) > - Change chipidea core of_node assignment for coming user. (patch [5/6]) > - Applies Joshua Clayton's three dts changes for two boards, > the USB device's reg has only #address-cells, but without #size-cells. > > Changes for v5: > - Delete pwrseq_register/pwrseq_unregister, which is useless currently > - Fix the linker error when the pwrseq user is compiled as module > > Changes for v4: > - Create the patch on next-20160722 > - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6] > - Using more friendly wait method for reset gpio [Patch 2/6] > - Support multiple input clocks [Patch 2/6] > - Add Rob Herring's ack for DT changes > - Add Joshua Clayton's Tested-by > > Changes for v3: > - Delete "power-sequence" property at binding-doc, and change related code > at both library and user code. > - Change binding-doc example node name with Rob's comments > - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags, > add additional code request gpio with proper gpio flags > - Add Philipp Zabel's Ack and MAINTAINER's entry > > Changes for v2: > - Delete "pwrseq" prefix and clock-names for properties at dt binding > - Should use structure not but its pointer for kzalloc > - Since chipidea core has no of_node, let core's of_node equals glue > layer's at core's probe > > Joshua Clayton (2): > ARM: dts: imx6qdl: Enable usb node children with > ARM: dts: imx6q-evi: Fix onboard hub reset line > > Peter Chen (6): > bindin
Re: [PATCH v11 0/8] power: add power sequence library
On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote: > Hi all, > > This is a follow-up for my last power sequence framework patch set [1]. > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of > power sequence instances will be added at postcore_initcall, the match > criteria is compatible string first, if the compatible string is not > matched between dts and library, it will try to use generic power sequence. > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off > if only one power sequence instance is needed, for more power sequences > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub > driver). > > In future, if there are special power sequence requirements, the special > power sequence library can be created. > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > two hot-plug devices to simulate this use case, the related binding > change is updated at patch [1/6], The udoo board changes were tested > using my last power sequence patch set.[3] > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > need to power on itself before it can be found by ULPI bus. > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > Unfortunately I was unable to utilize this library to solve Odroid U3 usb3503/lan9730 power sequence (as a continuation of my old series [0][1]). The main problem is that power sequence instance (pwrseq_generic.c) is not a device. I don't get why it is not a device. It would be rather intuitive to me to make it a device. Also it would make life easier because you could use all device-like consumer APIs (of getting clocks, GPIOs etc). Since it is not a device, it is not possible to use regulator consumer API. I need a regulator because I need to toggle the power. Other encountered issue is that power sequence happens early, before the unused regulators are turned off by the system. However maybe this is the necessity from other point of view. My case is annoyingly over-complicated so I am slowly getting sertain that it is not generic. Anyway it looks like this: EHCI controller | |--HSIC0--lan9730 (reset is done only through regulator) |--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by usb3504 driver) Overall, I want to reset the lan9730. This can be done only through power - buck8. buck8 state is an logical OR of register set by I2C and GPIO. Thus to turn it off, it is not sufficient just to set register to 0x0 because the GPIO is keeping it on. The best way is to switch the buck8 to gpio-enable-control thus only GPIO will be toggling it... still through the regulator consumer API (because it is an GPIO for the regulator, not for the reset!). However these two seems coupled. On invalid reset sequence, both chips die. The usb3504 has its own existing reset sequence and my findings show that it should happen after lan9730 reset sequence. Otherwise all devices might be lost... [0] http://www.spinics.net/lists/linux-mmc/msg37386.html [1] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4 Best regards, Krzysztof > Changes for v11: > - Fix warning: (USB) selects POWER_SEQUENCE which has unmet direct > dependencies (OF) > - Delete redundant copyright statement. > - Change pr_warn to pr_debug at wrseq_find_available_instance > - Refine kerneldoc > - %s/ENONET/ENOENT > - Allocate pwrseq list node before than carry out power sequence on > - Add mutex_lock/mutex_lock for pwrseq node browse at > pwrseq_find_available_instance > - Add pwrseq_suspend/resume for API both single instance and list > - Add .pwrseq_suspend/resume for pwrseq_generic.c > - Add pwrseq_suspend_list and pwrseq_resume_list for USB hub suspend > and resume routine > > Changes for v10: > - Improve the kernel-doc for power sequence core, including exported APIs and > main structure. [Patch 2/8] > - Change Kconfig, and let the user choose power sequence. [Patch 2/8] > - Delete EXPORT_SYMBOL and change related APIs as local, these APIs do not > be intended to export currently. [Patch 2/8] > - Selete POWER_SEQUENCE at USB core's Kconfig. [Patch 4/8] > > Changes for v9: > - Add Vaibhav Hiremath's reviewed-by [Patch 4/8] > - Rebase to v4.9-rc1 > > Changes for v8: > - Allocate one extra pwrseq instance if pwrseq_get has succeed, it can avoid > preallocate instances problem which the number of instance is decided at > compile time, thanks for Heiko Stuebner's suggestion [Patch 2/8] > - Delete pwrseq_compatible_sample.c which is the demo purpose to show > compatible > match method. [Patch 2/8] > - Add Maciej S. Szmigiero's tested-by. [Patch 7/8] > > Changes for v7: > - Create kinds of power sequence instance at postcore_initcall, and match > the instance with node using compatible strin
Re: [PATCH v11 0/8] power: add power sequence library
On Fri, Jan 06, 2017 at 05:18:41PM +0200, Krzysztof Kozlowski wrote: > On Thu, Jan 05, 2017 at 02:01:51PM +0800, Peter Chen wrote: > > Hi all, > > > > This is a follow-up for my last power sequence framework patch set [1]. > > According to Rob Herring and Ulf Hansson's comments[2]. The kinds of > > power sequence instances will be added at postcore_initcall, the match > > criteria is compatible string first, if the compatible string is not > > matched between dts and library, it will try to use generic power sequence. > > > > The host driver just needs to call of_pwrseq_on/of_pwrseq_off > > if only one power sequence instance is needed, for more power sequences > > are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub > > driver). > > > > In future, if there are special power sequence requirements, the special > > power sequence library can be created. > > > > This patch set is tested on i.mx6 sabresx evk using a dts change, I use > > two hot-plug devices to simulate this use case, the related binding > > change is updated at patch [1/6], The udoo board changes were tested > > using my last power sequence patch set.[3] > > > > Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also > > need to power on itself before it can be found by ULPI bus. > > > > [1] http://www.spinics.net/lists/linux-usb/msg142755.html > > [2] http://www.spinics.net/lists/linux-usb/msg143106.html > > [3] http://www.spinics.net/lists/linux-usb/msg142815.html > > > > Unfortunately I was unable to utilize this library to solve Odroid U3 > usb3503/lan9730 power sequence (as a continuation of my old series [0][1]). > > The main problem is that power sequence instance (pwrseq_generic.c) is > not a device. I don't get why it is not a device. It would be rather > intuitive to me to make it a device. Also it would make life easier > because you could use all device-like consumer APIs (of getting clocks, > GPIOs etc). Since it is not a device, it is not possible to use > regulator consumer API. > > I need a regulator because I need to toggle the power. > > Other encountered issue is that power sequence happens early, before the > unused regulators are turned off by the system. However maybe this is > the necessity from other point of view. > > My case is annoyingly over-complicated so I am slowly getting sertain > that it is not generic. Anyway it looks like this: > > EHCI controller > | > |--HSIC0--lan9730 (reset is done only through regulator) > |--HSIC1--usb3504 (it has a reset GPIO... but it is toggled by > usb3504 driver) > > Overall, I want to reset the lan9730. This can be done only through > power - buck8. buck8 state is an logical OR of register set by I2C and > GPIO. Thus to turn it off, it is not sufficient just to set register to > 0x0 because the GPIO is keeping it on. The best way is to switch the > buck8 to gpio-enable-control thus only GPIO will be toggling it... still > through the regulator consumer API (because it is an GPIO for the > regulator, not for the reset!). > > However these two seems coupled. On invalid reset sequence, both chips > die. The usb3504 has its own existing reset sequence and my findings > show that it should happen after lan9730 reset sequence. Otherwise all > devices might be lost... Update - it's working! I skipped entirely the regulator API and I am playing with its GPIO. This sounds like a hack but finally after few days of different tries I was able to find a working, reproducible solution. It turned out that the yours pwrseq is working quite good. I'll send a follow-up for my board soon. Best regards, Krzysztof > > [0] http://www.spinics.net/lists/linux-mmc/msg37386.html > [1] > https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-lan-boot-fixes-v4 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: host: ehci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
Returning from for_each_available_child_of_node() loop requires cleaning
up node refcount. Error paths lacked it so for example in case of
deferred probe, the refcount of phy node was left increased.
Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when
getting PHYs")
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/host/ehci-exynos.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 42e5b66353ef..7a603f66a9bc 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -77,10 +77,12 @@ static int exynos_ehci_get_phy(struct device *dev,
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
+ of_node_put(child);
return ret;
} else if (ret != -ENOSYS && ret != -ENODEV) {
dev_err(dev,
"Error retrieving usb2 phy: %d\n", ret);
+ of_node_put(child);
return ret;
}
}
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: host: ohci-exynos: Decrese node refcount on exynos_ehci_get_phy() error paths
Returning from for_each_available_child_of_node() loop requires cleaning
up node refcount. Error paths lacked it so for example in case of
deferred probe, the refcount of phy node was left increased.
Fixes: 6d40500ac9b6 ("usb: ehci/ohci-exynos: Fix of_node_put() for child when
getting PHYs")
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/host/ohci-exynos.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
index 2cd105be7319..6865b919403f 100644
--- a/drivers/usb/host/ohci-exynos.c
+++ b/drivers/usb/host/ohci-exynos.c
@@ -66,10 +66,12 @@ static int exynos_ohci_get_phy(struct device *dev,
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
+ of_node_put(child);
return ret;
} else if (ret != -ENOSYS && ret != -ENODEV) {
dev_err(dev,
"Error retrieving usb2 phy: %d\n", ret);
+ of_node_put(child);
return ret;
}
}
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index b01a43851294..1750d99862b9 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y CONFIG_POWER_RESET_ST=y CONFIG_POWER_AVS=y CONFIG_ROCKCHIP_IODOMAIN=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
Replace spaces with tabs in EHCI and OHCI ports indentation.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4.dtsi | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737baa45e..3209c60389e2 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -370,19 +370,19 @@
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- reg = <0>;
- phys = <&exynos_usbphy 1>;
- status = "disabled";
+ reg = <0>;
+ phys = <&exynos_usbphy 1>;
+ status = "disabled";
};
port@1 {
- reg = <1>;
- phys = <&exynos_usbphy 2>;
- status = "disabled";
+ reg = <1>;
+ phys = <&exynos_usbphy 2>;
+ status = "disabled";
};
port@2 {
- reg = <2>;
- phys = <&exynos_usbphy 3>;
- status = "disabled";
+ reg = <2>;
+ phys = <&exynos_usbphy 3>;
+ status = "disabled";
};
};
@@ -396,9 +396,9 @@
#address-cells = <1>;
#size-cells = <0>;
port@0 {
- reg = <0>;
- phys = <&exynos_usbphy 1>;
- status = "disabled";
+ reg = <0>;
+ phys = <&exynos_usbphy 1>;
+ status = "disabled";
};
};
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
The ethernet adapter LAN9730, after enabling in bootloader (e.g. for
tftpboot) requires reset during boot. Otherwise it won't come up.
The schematics of Odroid U3 are detailed enough but after grabbing
knowledge also from other sources (like U-Boot) the overall design looks
like:
1. LAN9730 is connected to HSIC0 and USB3503 to HSIC1 of EHCI controller.
2. USB3503 comes with its own reset pin: gpx3-5.
3. Reset pin of LAN9730 is pulled up to 3.3 V so it cannot be used.
4. The supply of 3.3 V for LAN9730 is delivered from buck8.
5. Buck8 state is a logical OR of registry value (through I2C command)
and ENB8 pin. The ENB8, not described in schematics, is in fact
gpa1-1.
6. Missing or wrongly timed reset of LAN9730 might result in missing of
two devices: LAN9730 and USB3503. Without reset, LAN9730 will not
come up, if it was enabled by bootloader.
To fix the issue use the generic power sequence driver and toggle the
ENB8 (buck8) pin. Reset duration of 500 us was chosen by experiments
(shortest working time was 400 us). This is an easiest way to fix the
long standing LAN9730 reset issue.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c54dca9..aef49007cba0 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -84,10 +84,23 @@
regulator-max-microvolt = <280>;
};
+&max77686 {
+ pinctrl-0 = <&max77686_irq &max77686_enb8>;
+};
+
&mshc_0 {
vqmmc-supply = <&ldo22_reg>;
};
+&pinctrl_0 {
+ max77686_enb8: max77686-enb8 {
+ samsung,pins = "gpa1-1";
+ samsung,pin-function = ;
+ samsung,pin-pud = ;
+ samsung,pin-drv = ;
+ };
+};
+
&pwm {
pinctrl-0 = <&pwm0_out>;
pinctrl-names = "default";
@@ -103,7 +116,15 @@
&ehci {
port@1 {
+ /* HSIC for LAN9730 */
status = "okay";
+ /* buck8 enable pin, use it for power sequence */
+ reset-gpios = <&gpa1 1 GPIO_ACTIVE_LOW>;
+ /*
+* Reset duration of 500 us was chosen experimentally.
+* Minimal working value was 400 us. Add some safe margin.
+*/
+ reset-duration-us = <500>;
};
port@2 {
status = "okay";
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
Hi,
Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
Chen, we got a power sequence generic library which solves my long
standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
My previous attempts for this can be found here [0].
This patchset is based on Peter's v11 of power sequence [1].
Patchset is available also on my Github [2].
More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
LAN9730 on Odroid U3 after tftpboot").
Best regards,
Krzysztof
[0] http://www.spinics.net/lists/linux-mmc/msg37386.html
[1] https://lwn.net/Articles/710736/
[2] https://github.com/krzk/linux/commits/for-next/odroid-u3-usb3503-pwrseq
Krzysztof Kozlowski (4):
ARM: dts: exynos: Fix indentation of EHCI and OHCI ports
ARM: dts: exynos: Fix LAN9730 on Odroid U3 after tftpboot
ARM: exynos_defconfig: Enable power sequence for Odroid U3
ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
arch/arm/boot/dts/exynos4.dtsi| 24
arch/arm/boot/dts/exynos4412-odroidu3.dts | 21 +
arch/arm/configs/exynos_defconfig | 2 ++
arch/arm/configs/multi_v7_defconfig | 1 +
4 files changed, 36 insertions(+), 12 deletions(-)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 1/8] binding-doc: power: pwrseq-generic: add binding doc for generic power sequence library
On Thu, Jan 05, 2017 at 02:01:52PM +0800, Peter Chen wrote: > Add binding doc for generic power sequence library. > > Signed-off-by: Peter Chen > Acked-by: Philipp Zabel > Acked-by: Rob Herring > --- > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 > ++ > 1 file changed, 48 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: exynos_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Enable also GPIO_SYSFS which is useful for playing with GPIO during debug process. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/exynos_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index 79c415c33f69..ad1a509c296a 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -99,6 +99,7 @@ CONFIG_SPI=y CONFIG_SPI_GPIO=y CONFIG_SPI_S3C64XX=y CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y CONFIG_GPIO_WM8994=y CONFIG_POWER_SUPPLY=y CONFIG_BATTERY_SBS=y @@ -108,6 +109,7 @@ CONFIG_CHARGER_MAX14577=y CONFIG_CHARGER_MAX77693=y CONFIG_CHARGER_MAX8997=y CONFIG_CHARGER_TPS65090=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_NTC_THERMISTOR=y CONFIG_SENSORS_PWM_FAN=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 2/8] power: add power sequence library
On Thu, Jan 05, 2017 at 02:01:53PM +0800, Peter Chen wrote: > We have an well-known problem that the device needs to do some power > sequence before it can be recognized by related host, the typical > example like hard-wired mmc devices and usb devices. > > This power sequence is hard to be described at device tree and handled by > related host driver, so we have created a common power sequence > library to cover this requirement. The core code has supplied > some common helpers for host driver, and individual power sequence > libraries handle kinds of power sequence for devices. The pwrseq > librares always need to allocate extra instance for compatible > string match. > > pwrseq_generic is intended for general purpose of power sequence, which > handles gpios and clocks currently, and can cover other controls in > future. The host driver just needs to call of_pwrseq_on/of_pwrseq_off > if only one power sequence is needed, else call of_pwrseq_on_list > /of_pwrseq_off_list instead (eg, USB hub driver). > > For new power sequence library, it can add its compatible string > to pwrseq_of_match_table, then the pwrseq core will match it with > DT's, and choose this library at runtime. > > Signed-off-by: Peter Chen > Tested-by: Maciej S. Szmigiero > Tested-by Joshua Clayton > Reviewed-by: Matthias Kaehlcke > Tested-by: Matthias Kaehlcke > --- > MAINTAINERS | 9 + > drivers/power/Kconfig | 1 + > drivers/power/Makefile| 1 + > drivers/power/pwrseq/Kconfig | 20 ++ > drivers/power/pwrseq/Makefile | 2 + > drivers/power/pwrseq/core.c | 335 > ++ > drivers/power/pwrseq/pwrseq_generic.c | 224 +++ > include/linux/power/pwrseq.h | 81 > 8 files changed, 673 insertions(+) > create mode 100644 drivers/power/pwrseq/Kconfig > create mode 100644 drivers/power/pwrseq/Makefile > create mode 100644 drivers/power/pwrseq/core.c > create mode 100644 drivers/power/pwrseq/pwrseq_generic.c > create mode 100644 include/linux/power/pwrseq.h > Acked-by: Krzysztof Kozlowski Tested on Odroid U3 (reset sequence for LAN9730): Tested-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 3/8] binding-doc: usb: usb-device: add optional properties for power sequence
On Thu, Jan 05, 2017 at 02:01:54PM +0800, Peter Chen wrote: > Add optional properties for power sequence. > > Signed-off-by: Peter Chen > Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/usb/usb-device.txt | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > Acked-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 4/8] usb: core: add power sequence handling for USB devices
On Thu, Jan 05, 2017 at 02:01:55PM +0800, Peter Chen wrote: > Some hard-wired USB devices need to do power sequence to let the > device work normally, the typical power sequence like: enable USB > PHY clock, toggle reset pin, etc. But current Linux USB driver > lacks of such code to do it, it may cause some hard-wired USB devices > works abnormal or can't be recognized by controller at all. > > In this patch, it calls power sequence library APIs to finish > the power sequence events. It will do power on sequence at hub's > probe for all devices under this hub (includes root hub). > At hub_disconnect, it will do power off sequence which is at powered > on list. > > Signed-off-by: Peter Chen > Tested-by Joshua Clayton > Tested-by: Maciej S. Szmigiero > Reviewed-by: Vaibhav Hiremath > --- > drivers/usb/Kconfig| 1 + > drivers/usb/core/hub.c | 48 > drivers/usb/core/hub.h | 1 + > 3 files changed, 46 insertions(+), 4 deletions(-) > Acked-by: Krzysztof Kozlowski Tested on Odroid U3 (reset sequence for LAN9730): Tested-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
Odroid U3 needs a power sequence for lan9730, if it was enabled by bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device is present on Odroid U3). Signed-off-by: Krzysztof Kozlowski --- Changes since v1 (v1 -> v1.1): 1. Enable also usb3503 driver. --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index b01a43851294..8cc73e084b25 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -443,6 +443,7 @@ CONFIG_POWER_RESET_RMOBILE=y CONFIG_POWER_RESET_ST=y CONFIG_POWER_AVS=y CONFIG_ROCKCHIP_IODOMAIN=y +CONFIG_PWRSEQ_GENERIC=y CONFIG_SENSORS_IIO_HWMON=y CONFIG_SENSORS_LM90=y CONFIG_SENSORS_LM95245=y @@ -686,6 +687,7 @@ CONFIG_USB_DWC2=y CONFIG_USB_CHIPIDEA=y CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_CHIPIDEA_HOST=y +CONFIG_USB_HSIC_USB3503=m CONFIG_AB8500_USB=y CONFIG_KEYSTONE_USB_PHY=y CONFIG_OMAP_USB3=y -- 2.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1.1] ARM: multi_v7_defconfig: Enable power sequence for Odroid U3
On Mon, Jan 9, 2017 at 6:24 PM, Javier Martinez Canillas wrote: > Hello Krzysztof, > > I think it would had been clearer if the subject prefix was "[PATCH v1.1 > 4/4]" :) Ah, yes. > > On 01/07/2017 06:16 AM, Krzysztof Kozlowski wrote: >> Odroid U3 needs a power sequence for lan9730, if it was enabled by >> bootloader. Also enable the USB3503 HSCI to USB2.0 driver (device >> is present on Odroid U3). >> >> Signed-off-by: Krzysztof Kozlowski >> >> --- >> > > Do you think that makes sense to also enable GPIO_SYS for debugging > purposes as you do in patch 3/4? I like the GPIO_SYSFS interface because it is easy to use. However now, after your question, I found this: http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/470154.html ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms ... so instead I will drop it from exynos_defconfig. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 7 January 2017 at 14:21, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> > Chen, we got a power sequence generic library which solves my long
> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >
> > My previous attempts for this can be found here [0].
> >
> > This patchset is based on Peter's v11 of power sequence [1].
> > Patchset is available also on my Github [2].
> >
> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> > LAN9730 on Odroid U3 after tftpboot").
> >
> >
>
> [snip]
>
> On which u-boot should this be tested.
>
> On HK u-boot tftp boot is not supported.
... so you gave an answer: you cannot test it on HK. How many other
U-Boot flavors you know? :)
Best regards,
Krzysztof
> --
> U-Boot 2010.12-0-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
>
>
> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
> APLL = 1000MHz, MPLL = 800MHz
> DRAM: 2 GiB
>
> PMIC VERSION : 0x00, CHIP REV : 2
> TrustZone Enabled BSP
> BL1 version: 20121128
>
>
> Checking Boot Mode ... SDMMC
> MMC Device 0: 14804 MB
> MMC Device 1 not found
> *** Warning - using default environment
>
> USB3503 NINT = OUTPUT LOW!
> ModeKey Check... run normal_boot
> No ethernet found.
> Hit any key to stop autoboot: 0
> Exynos4412 #
> Exynos4412 #
> Exynos4412 #
> Exynos4412 # usb start
> (Re)start USB...
> USB0: Exynos4412-ehci: init hccr 1258 and hcor 12580010 hc_length 16
> usb: usb_refclk_enable is active low: NO
> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
> USB EHCI 1.00
> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
> EHCI fail timeout STS_ASS set
>
> USB device not accepting new address (error=8000)
> EHCI fail timeout STS_ASS set
> 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
>scanning usb for ethernet devices... 0 Ethernet Device(s) found
> Exynos4412 #
>
> Best Regards
> -Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
On Mon, Jan 09, 2017 at 11:56:41PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 9 January 2017 at 23:47, Krzysztof Kozlowski wrote:
> > On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 7 January 2017 at 14:21, Krzysztof Kozlowski wrote:
> >> > Hi,
> >> >
> >> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> >> > Chen, we got a power sequence generic library which solves my long
> >> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >> >
> >> > My previous attempts for this can be found here [0].
> >> >
> >> > This patchset is based on Peter's v11 of power sequence [1].
> >> > Patchset is available also on my Github [2].
> >> >
> >> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> >> > LAN9730 on Odroid U3 after tftpboot").
> >> >
> >> >
> >>
> >> [snip]
> >>
> >> On which u-boot should this be tested.
> >>
> >> On HK u-boot tftp boot is not supported.
> >
> > ... so you gave an answer: you cannot test it on HK. How many other
> > U-Boot flavors you know? :)
> >
>
> u-boot mainline have tftp support enable, so I will try to test on this
> u-boot.
Yes, please try it. Some time ago I was using v2016.03-rc3 and now
recent (~40 commits after v2017.01-rc2). Both are working fine however
the configuration (partitions, default env settings etc) differs from HK
so migration was not straightforward.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
On Tue, Jan 10, 2017 at 06:09:40PM +0100, Bartlomiej Zolnierkiewicz wrote: > BTW What is interesting is that the Exynos7 dts patch [2] has never > made it into upstream for some reason. In the meantime however > Exynos5433 (similar to Exynos7 to some degree) became the user of > susp_clk. > > [1] https://lkml.org/lkml/2014/11/21/247 > [2] https://patchwork.kernel.org/patch/5355161/ > +Cc Alim and Pankaj, Anyone would like to resend [2] after rebasing and testing? Interrupt flags would have to be fixed and status=disabled added. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3-exynos fix unspecified suspend clk error handling
On Tue, Jan 10, 2017 at 11:37:24AM -0700, Shuah Khan wrote: > On 01/10/2017 11:23 AM, Bartlomiej Zolnierkiewicz wrote: > > I also think that regardless of what is decided on making susp_clk > > non-optional for some Exynos SoCs we should probably remove the debug > > message as it doesn't bring useful information and may be confusing. > > > > Shuah, can you take care of this? > > Yes. This message as it reads now is not only confusing, but also can > lead users to think something is wrong. > > I can get rid of it or I could change it from info to debug and change > it to read: > > "Optional Suspend clock isn't found. Diver operation isn't impacted" It is even more confusing. If the clock is required (by binding, by hardware) - make it an error. If it is completely not important - do not print anything. If it is optional but helpful (enabling clock gives someything) then print something... but it is not that case. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
On Tue, Jan 24, 2017 at 02:48:09PM +0100, Richard Genoud wrote:
> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
> the USB ports on odroid-XU4 don't work anymore.
Hi,
Thanks for the patch. Please:
1. Use recent kernel to test it, which could be one of: mainline
(Linus'), recent linux-next or my for-next branch. Why am I thinking
that you did not test it on thse? Because you sent the patch to
k.kozlow...@samsung.com. The guy disappeared four months ago and
recent kernel has all addresses updated (including mailmap).
2. Fix the title to match subsystem (git log --oneline
arch/arm/boot/dts/exynos*).
>
> Inserting an usb key (USB2.0) on the USB3.0 port result in:
> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
> msec, port status = 0xc400fe3
> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
> endpoint command.
> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
> [ 74.606276] usb 3-1: USB disconnect, device number 2
> [ 74.613565] usb 4-1: USB disconnect, device number 2
> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
> device (SATA to USB3 for instance).
> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
> RTL8153 chip.
Odroid-XU3
s/realtek/Realtek/
However I do not think that Realtek matters here. The USB3 ports are
directly accessible on XU3. On XU4 on the other hand, the port USB3-0 is
connected to USB hub. I think the sentence about Realtek is then
misleading, so just mention the XU3.
>
> If the lines:
> if (dwc->revision > DWC3_REVISION_194A)
> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
> are commented out, the USB3.0 start working.
s/start/starts/
>
> For a full analyse: https://lkml.org/lkml/2017/1/18/678
Documentation/process/submitting-patches.rst
Instead of this above (lkml.org is highly discouraged) use proper
https://lkml.kernel.org/ in "Link:" put next to other tags (look at
recent commits), however I do not find this link as necessary. Just
describe here what is wrong and how you are going to fix it.
>
> Felipe suggested that suspend should be disabled temporarily while
> what's wrong with DCW3 is figured out.
>
> Tested on Odroid XU4
>
> Suggested-by: Felipe Balbi
> Tested-by: Richard Genoud
Being an author implies testing. Please remove the tag.
> Signed-off-by: Richard Genoud
> Cc: sta...@vger.kernel.org # 4.4+
Malformed tag - missing <>.
> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
No need for such long hash (2164a476205c).
I wonder about pointing the commit which introduced the issue. Usually
the fixes directly indicates how far we want the patch to be backported.
In this case this should be backported to kernel bringing XU4 DTS. The
commit which was not valid, was the commit adding DTS without this
property. 2164a476205c was innocent for XU4 because XU4 did not exist
that time.
Definitely something is wrong if Fixes tag does not match indicated
backport version.
> ---
> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> index 2faf88627a48..f62dbd9b5ad3 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
> @@ -43,6 +43,15 @@
> status = "okay";
> };
>
> +&usbdrd_dwc3_0 {
> + /*
> + * without that, usb devices are not recognized when
> + * they are plugged.
s/without/Without/
s/usb/USB.
> + * cf: https://lkml.org/lkml/2017/1/18/678
No external resources. You can extend a little bit the sentence above to
two sentences. Combined with "git log" this would be sufficient.
Best regards,
Krzysztof
> + */
> + snps,dis_u3_susphy_quirk;
> +};
> +
> &usbdrd_dwc3_1 {
> dr_mode = "host";
> };
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote:
> Hi Richard,
>
> On 24 January 2017 at 19:18, Richard Genoud wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
>> msec, port status = 0xc400fe3
>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
>> endpoint command.
>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>> host.
>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
>> RTL8153 chip.
>>
>> If the lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi
>> Tested-by: Richard Genoud
>> Signed-off-by: Richard Genoud
>> Cc: sta...@vger.kernel.org # 4.4+
>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>> status = "okay";
>> };
>>
>> +&usbdrd_dwc3_0 {
>> + /*
>> +* without that, usb devices are not recognized when
>> +* they are plugged.
>> +* cf: https://lkml.org/lkml/2017/1/18/678
>> +*/
>> + snps,dis_u3_susphy_quirk;
>> +};
>> +
>> &usbdrd_dwc3_1 {
>> dr_mode = "host";
>> };
>> --
>
> Thanks for this patch.
> But could you consider moving this changes as below.
>
> https://lkml.org/lkml/2015/3/18/400
The patch above (and other DTS patches from the set) was not even sent
to linux-samsung-soc nor to me... It is sad how easily one's work can
disappear. Also, it is really worthless to solve the same problem
twice.
Cc Marek and Bartlomiej,
Guys, do you want to continue with Robert's patch (linked above by
Anand)? If yes, please take the ownership (Robert's address is not
valid anymore). If not, I will take Richard's patch after
resubmission.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
wrote:
> Hi Krzysztof,
>
> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>
>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote:
>>>
>>> On 24 January 2017 at 19:18, Richard Genoud
>>> wrote:
>>>>
>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>
>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>> 2 msec, port status = 0xc400fe3
>>>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>> stop endpoint command.
>>>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>> host.
>>>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>>>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>>>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>> USB3.0 device (SATA to USB3 for instance).
>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>> realtek RTL8153 chip.
>>>>
>>>> If the lines:
>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>> are commented out, the USB3.0 start working.
>>>>
>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>
>>>> Felipe suggested that suspend should be disabled temporarily while
>>>> what's wrong with DCW3 is figured out.
>>>>
>>>> Tested on Odroid XU4
>>>>
>>>> Suggested-by: Felipe Balbi
>>>> Tested-by: Richard Genoud
>>>> Signed-off-by: Richard Genoud
>>>> Cc: sta...@vger.kernel.org # 4.4+
>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>> ---
>>>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>>>> 1 file changed, 9 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>> @@ -43,6 +43,15 @@
>>>> status = "okay";
>>>> };
>>>>
>>>> +&usbdrd_dwc3_0 {
>>>> + /*
>>>> +* without that, usb devices are not recognized when
>>>> +* they are plugged.
>>>> +* cf: https://lkml.org/lkml/2017/1/18/678
>>>> +*/
>>>> + snps,dis_u3_susphy_quirk;
>>>> +};
>>>> +
>>>> &usbdrd_dwc3_1 {
>>>> dr_mode = "host";
>>>> };
>>>> --
>>>
>>> Thanks for this patch.
>>> But could you consider moving this changes as below.
>>>
>>> https://lkml.org/lkml/2015/3/18/400
>>
>> The patch above (and other DTS patches from the set) was not even sent
>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>> disappear. Also, it is really worthless to solve the same problem
>> twice.
>
>
> Well, they were sent about 2 years ago... and you were also working on this
> topic. ;)
Nope, I have never worked on this. That time I was in Korea so my
tasks were completely different. Later when I got back, I took for a
second U3 OTG which was not involving this thing.
>> Cc Marek and Bartlomiej,
>> Guys, do you want to continue with Robert's patch (linked above by
>> Anand)? If yes, please take the ownership (Robert's address is not
>> valid anymore). If not, I will take Richard's patch after
>> resubmission.
>
>
> Take Richard's patch because it has a bit more details describing why such
> quirk
> is needed.
>
> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>
> Maybe it would make sense to set those quirks for both DWC3 controllers, as
> this
> issue with PHY suspend seems to be a Exynos specific thing.
Okay,
Richard, please continue with your patch.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
On Sun, Oct 09, 2016 at 02:34:14PM +, Anand Moon wrote:
> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> as to avoid them being build when not used. This also allows us to use the
> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>
> Signed-off-by: Anand Moon
> ---
> drivers/usb/host/ehci-exynos.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 42e5b66..1899900 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
Does not look like an equivalent change. How will it behave in a config
with !SUSPEND && !HIBERNATE && PM?
Best regards,
Krzysztof
> static int exynos_ehci_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> @@ -292,15 +292,13 @@ static int exynos_ehci_resume(struct device *dev)
> ehci_resume(hcd, false);
> return 0;
> }
> -#else
> -#define exynos_ehci_suspend NULL
> -#define exynos_ehci_resume NULL
> -#endif
>
> static const struct dev_pm_ops exynos_ehci_pm_ops = {
> - .suspend= exynos_ehci_suspend,
> - .resume = exynos_ehci_resume,
> + SET_SYSTEM_SLEEP_PM_OPS(exynos_ehci_suspend, exynos_ehci_resume)
> };
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#define DEV_PM_OPS IS_ENABLED(CONFIG_PM_SLEEP) ? &exynos_ehci_pm_ops : NULL
>
> #ifdef CONFIG_OF
> static const struct of_device_id exynos_ehci_match[] = {
> @@ -317,7 +315,7 @@ static struct platform_driver exynos_ehci_driver = {
> .shutdown = usb_hcd_platform_shutdown,
> .driver = {
> .name = "exynos-ehci",
> - .pm = &exynos_ehci_pm_ops,
> + .pm = DEV_PM_OPS,
> .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote: > Hi Krzysztof, > > On 9 October 2016 at 22:04, Krzysztof Kozlowski wrote: > > On Sun, Oct 09, 2016 at 02:34:14PM +, Anand Moon wrote: > >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP > >> as to avoid them being build when not used. This also allows us to use the > >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code. > >> > >> Signed-off-by: Anand Moon > >> --- > >> drivers/usb/host/ehci-exynos.c | 14 ++ > >> 1 file changed, 6 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/usb/host/ehci-exynos.c > >> b/drivers/usb/host/ehci-exynos.c > >> index 42e5b66..1899900 100644 > >> --- a/drivers/usb/host/ehci-exynos.c > >> +++ b/drivers/usb/host/ehci-exynos.c > >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device > >> *pdev) > >> return 0; > >> } > >> > >> -#ifdef CONFIG_PM > >> +#ifdef CONFIG_PM_SLEEP > > > > Does not look like an equivalent change. How will it behave in a config > > with !SUSPEND && !HIBERNATE && PM? > > > > [snip] > > I just wanted to update suspend and resume callback to use > SET_SYSTEM_SLEEP_PM_OPS > as they are define under CONFIG_PM_SLEEP so I update above to avoid > compilation warning/error. First of all you did not answer to my question, so let me rephrase into two: 1. Is the code equivalent? 2. What will be the output with !SUSPEND && !HIBERNATE && PM? You didn't mention compilation warning/error in message commit so I do not know what you are thinking about... Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote: > hi Krzysztof, > > On 9 October 2016 at 22:57, Krzysztof Kozlowski wrote: > > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote: > >> Hi Krzysztof, > >> > >> On 9 October 2016 at 22:04, Krzysztof Kozlowski wrote: > >> > On Sun, Oct 09, 2016 at 02:34:14PM +, Anand Moon wrote: > >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP > >> >> as to avoid them being build when not used. This also allows us to use > >> >> the > >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code. > >> >> > >> >> Signed-off-by: Anand Moon > >> >> --- > >> >> drivers/usb/host/ehci-exynos.c | 14 ++ > >> >> 1 file changed, 6 insertions(+), 8 deletions(-) > >> >> > >> >> diff --git a/drivers/usb/host/ehci-exynos.c > >> >> b/drivers/usb/host/ehci-exynos.c > >> >> index 42e5b66..1899900 100644 > >> >> --- a/drivers/usb/host/ehci-exynos.c > >> >> +++ b/drivers/usb/host/ehci-exynos.c > >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct > >> >> platform_device *pdev) > >> >> return 0; > >> >> } > >> >> > >> >> -#ifdef CONFIG_PM > >> >> +#ifdef CONFIG_PM_SLEEP > >> > > >> > Does not look like an equivalent change. How will it behave in a config > >> > with !SUSPEND && !HIBERNATE && PM? > >> > > >> > >> [snip] > >> > >> I just wanted to update suspend and resume callback to use > >> SET_SYSTEM_SLEEP_PM_OPS > >> as they are define under CONFIG_PM_SLEEP so I update above to avoid > >> compilation warning/error. > > > Apologize: for not understanding your question. > > > First of all you did not answer to my question, so let me rephrase into > > two: > > 1. Is the code equivalent? > > No CONFIG_PM and CONFIG_PM_SLEEP are different options. > But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig So the code is not equivalent... > > CONFIG_PM_SLEEP=n or > # CONFIG_PM_SLEEP is not set > > > 2. What will be the output with !SUSPEND && !HIBERNATE && PM? > > # > # Power management options > # > # CONFIG_SUSPEND is not set > # CONFIG_HIBERNATION is not set > # CONFIG_PM is not set > > When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set > CONFIG_PM is disabled and so is CONFIG_PM_SLEEP. In my config, the CONFIG_PM was enabled thus the code changes the functionality... Maybe this was intented but I really don't get it from the commit message or from your explanations here. Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
2015-12-17 3:07 GMT+09:00 Sergei Shtylyov :
> Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
> enable a system with an integrated USB OTG dual-role transceiver to
> function as an USB OTG dual-role device. In addition to sensing/controlling
> Vbus, the chip also passes thru the ID signal from the USB OTG connector.
> On some Renesas boards, this signal is just fed into the SoC thru a GPIO
> pin -- there's no real OTG controller, only host and gadget USB controllers
> sharing the same USB bus; however, we'd like to allow host or gadget
> drivers to be loaded depending on the cable type, hence the need for the
> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
> (however, we aren't currently interested in them), the OFFVBUS# signal is
> controlled by the host controllers, there's also the SHDN# signal wired to
> a GPIO, it should be driven high for the normal operation.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 3:
> - reformatted the change log.
>
> Changes in version 2:
> - added the USB gadget cable support;
> - added the remove() driver method which drives SHDN# GPIO low to save power;
> - dropped vendor prefix from the ID GPIO property name;
> - changed the GPIO property name suffix to "-gpios";
> - switched to usign extcon_set_cable_state_() API;
> - switched to using the gpiod/sleeping 'gpiolib' APIs;
> - addded error messages to max3355_probe();
> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
> - renamed 'ret' variable to 'err' in max3355_probe();
> - expanded the Kconfig entry help text;
> - added vendor name to the patch summary, the bindings document, the Kconfig
> entry, the driver heading comment, the module description, and the change
> log;
> - fixed up and reformatted the change log.
>
> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
> drivers/extcon/Kconfig |8
> drivers/extcon/Makefile |1
> drivers/extcon/extcon-max3355.c | 153
>
> 4 files changed, 183 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> ===
> --- /dev/null
> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
> @@ -0,0 +1,21 @@
> +Maxim Integrated MAX3355 USB OTG chip
> +-
> +
> +MAX3355 integrates a charge pump and comparators to enable a system with an
> +integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
> +device.
> +
> +Required properties:
> +- compatible: should be "maxim,max3355";
> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
> pin
> + connected to the MAX3355's SHDN# pin;
Could you add some indentation to the wrapped line for this property?
For readability.
> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
> + connected to the MAX3355's ID_OUT pin.
Ditto.
Why this property lacks the vendor prefix i(n comparison to shdn-gpios
which has the prefix)?
> +
> +Example (Koelsch board):
> +
> + usb-otg {
> + compatible = "maxim,max3355";
> + maxim,shdn-gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> + id-gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>;
> + };
> Index: renesas/drivers/extcon/Kconfig
> ===
> --- renesas.orig/drivers/extcon/Kconfig
> +++ renesas/drivers/extcon/Kconfig
> @@ -52,6 +52,14 @@ config EXTCON_MAX14577
> Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port
> accessory
> detector and switch.
>
> +config EXTCON_MAX3355
> + tristate "Maxim MAX3355 USB OTG EXTCON Support"
> + help
> + If you say yes here you get support for the USB OTG role detection
> by
> + MAX3355. The MAX3355 chip integrates a charge pump and comparators
> to
> + enable a system with an integrated USB OTG dual-role transceiver to
> + function as an USB OTG dual-role device.
> +
> config EXTCON_MAX77693
> tristate "Maxim MAX77693 EXTCON Support"
> depends on MFD_MAX77693 && INPUT
> Index: renesas/drivers/extcon/Makefile
> ===
> --- renesas.orig/drivers/extcon/Makefile
> +++ renesas/drivers/extcon/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
> obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
> obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
> obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
> +obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
> obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
> obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
> obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
> Index: renesas/drivers/extcon/extcon-max3355.c
> =
Re: [PATCH v3] extcon: add Maxim MAX3355 driver
On 17.12.2015 23:36, Sergei Shtylyov wrote: > Hello. > > On 12/17/2015 3:53 AM, Krzysztof Kozlowski wrote: > >>> Maxim Integrated MAX3355E chip integrates a charge pump and >>> comparators to >>> enable a system with an integrated USB OTG dual-role transceiver to >>> function as an USB OTG dual-role device. In addition to >>> sensing/controlling >>> Vbus, the chip also passes thru the ID signal from the USB OTG >>> connector. >>> On some Renesas boards, this signal is just fed into the SoC thru a GPIO >>> pin -- there's no real OTG controller, only host and gadget USB >>> controllers >>> sharing the same USB bus; however, we'd like to allow host or gadget >>> drivers to be loaded depending on the cable type, hence the need for the >>> MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs >>> (however, we aren't currently interested in them), the OFFVBUS# >>> signal is >>> controlled by the host controllers, there's also the SHDN# signal >>> wired to >>> a GPIO, it should be driven high for the normal operation. >>> >>> Signed-off-by: Sergei Shtylyov >>> >>> --- >>> Changes in version 3: >>> - reformatted the change log. >>> >>> Changes in version 2: >>> - added the USB gadget cable support; >>> - added the remove() driver method which drives SHDN# GPIO low to >>> save power; >>> - dropped vendor prefix from the ID GPIO property name; >>> - changed the GPIO property name suffix to "-gpios"; >>> - switched to usign extcon_set_cable_state_() API; >>> - switched to using the gpiod/sleeping 'gpiolib' APIs; >>> - addded error messages to max3355_probe(); >>> - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call; >>> - renamed 'ret' variable to 'err' in max3355_probe(); >>> - expanded the Kconfig entry help text; >>> - added vendor name to the patch summary, the bindings document, the >>> Kconfig >>>entry, the driver heading comment, the module description, and the >>> change log; >>> - fixed up and reformatted the change log. >>> >>> Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 + >>> drivers/extcon/Kconfig |8 >>> drivers/extcon/Makefile |1 >>> drivers/extcon/extcon-max3355.c | 153 >>> >>> 4 files changed, 183 insertions(+) >>> >>> Index: >>> renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt >>> === >>> --- /dev/null >>> +++ renesas/Documentation/devicetree/bindings/extcon/extcon-max3355.txt >>> @@ -0,0 +1,21 @@ >>> +Maxim Integrated MAX3355 USB OTG chip >>> +- >>> + >>> +MAX3355 integrates a charge pump and comparators to enable a system >>> with an >>> +integrated USB OTG dual-role transceiver to function as a USB OTG >>> dual-role >>> +device. >>> + >>> +Required properties: >>> +- compatible: should be "maxim,max3355"; >>> +- maxim,shdn-gpios: should contain a phandle and GPIO specifier for >>> the GPIO pin >>> + connected to the MAX3355's SHDN# pin; >> >> Could you add some indentation to the wrapped line for this property? >> For readability. > >If it's not indented enough, I can add more spaces/tabs. Ahh, now I see it is sufficient. I need fix my email client. > >>> +- id-gpios: should contain a phandle and GPIO specifier for the GPIO >>> pin >>> + connected to the MAX3355's ID_OUT pin. >> >> Ditto. >> >> Why this property lacks the vendor prefix i(n comparison to shdn-gpios >> which has the prefix)? > >Since the extcon-usb-gpio driver uses "id-gpio" prop already. I can > add back the vendor prefix if you insist. It is for USB ID and palmas has it already as well so I do not insist. Seems generic. > > [...] >>> Index: renesas/drivers/extcon/extcon-max3355.c >>> === >>> --- /dev/null >>> +++ renesas/drivers/extcon/extcon-max3355.c >>> @@ -0,0 +1,153 @@ > [...] >>> +static int max3355_probe(struct platform_device *pdev) >>&g
Re: [BUG] Regression, usb-dwc3 not working, Odroid XU3, usb 3.0
On 07/04/2016 01:33 PM, Felipe Balbi wrote: > > Hi, > > Krzysztof Kozlowski writes: > >> Hi, >> >> >> Since three recent next releases (first on 20160630), on Odroid XU3 board >> the USB 3.0 host port (the only one) stopped working. >> >> This is a "samsung,exynos5250-dwusb3" (drivers/usb/dwc3/dwc3-exynos.c). >> >> Two issues here: >> 1. The port does not show up as USB 3.0 device. >> This one device is missing: >> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >> >> 2. The port does not work even for 2.0 devices (I didn't test 1.0). >> >> >> config: exynos_defconfig (ARM) >> DTS: exynos5422-odroidxu3.dts > > apply [1] and try again. That commit is already in greg/usb-testing [2] > and it should trickle down to usb-next shortly. > > [1] https://marc.info/?l=linux-usb&m=146728795330915&w=2 > [2] > https://git.kernel.org/cgit/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing&id=322832f2f19e04c866a0ce4bdac8cff8e695f2b3 > Ahhh, indeed, fixed. FWIW: Tested-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 06/15] pinctrl: rockchip: Add missing MFD_SYSCON dependency on HAS_IOMEM
The MFD_SYSCON depends on HAS_IOMEM so when selecting it avoid unmet direct dependencies. Signed-off-by: Krzysztof Kozlowski --- drivers/pinctrl/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig index fb8200b8e8ec..dc7ab58d4d74 100644 --- a/drivers/pinctrl/Kconfig +++ b/drivers/pinctrl/Kconfig @@ -131,6 +131,7 @@ config PINCTRL_MESON config PINCTRL_ROCKCHIP bool + depends on HAS_IOMEM# For MFD_SYSCON select PINMUX select GENERIC_PINCONF select GENERIC_IRQ_CHIP -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
