Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1451988 > unrolled thread
| Started by | Joshua Clayton <stillcompiling@gmail.com> |
|---|---|
| First post | 2016-07-28 18:00 +0200 |
| Last post | 2016-07-29 04:00 +0200 |
| Articles | 6 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v3 0/6] power: add power sequence library Joshua Clayton <stillcompiling@gmail.com> - 2016-07-28 18:00 +0200
Re: [PATCH v3 0/6] power: add power sequence library Fabio Estevam <festevam@gmail.com> - 2016-07-28 18:50 +0200
Re: [PATCH v3 0/6] power: add power sequence library Joshua Clayton <stillcompiling@gmail.com> - 2016-08-01 17:00 +0200
Re: [PATCH v3 0/6] power: add power sequence library Fabio Estevam <festevam@gmail.com> - 2016-08-01 18:40 +0200
Re: [PATCH v3 0/6] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-08-02 03:40 +0200
Re: [PATCH v3 0/6] power: add power sequence library Peter Chen <hzpeterchen@gmail.com> - 2016-07-29 04:00 +0200
| From | Joshua Clayton <stillcompiling@gmail.com> |
|---|---|
| Date | 2016-07-28 18:00 +0200 |
| Subject | Re: [PATCH v3 0/6] power: add power sequence library |
| Message-ID | <rZVT3-8jp-3@gated-at.bofh.it> |
Hi, Peter On 07/20/2016 02:40 AM, 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], I use a generic > power sequence library for parsing the power sequence elements on DT, > and implement generic power sequence on library. The host driver > can allocate power sequence instance, and calls pwrseq APIs accordingly. > > 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 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 > > Peter Chen (6): > binding-doc: power: pwrseq-generic: add binding doc for generic power > sequence library > power: add power sequence library > binding-doc: usb: usb-device: add optional properties for power > sequencediff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile > index 9780877..da36b78 100644 > --- a/drivers/usb/core/Makefile > +++ b/drivers/usb/core/Makefile > @@ -5,8 +5,9 @@ > usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o > usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o > usbcore-y += devio.o notify.o generic.o quirks.o devices.o > -usbcore-y += port.o of.o > +usbcore-y += port.o > > +usbcore-$(CONFIG_OF) += of.o > usbcore-$(CONFIG_PCI) += hcd-pci.o > usbcore-$(CONFIG_ACPI) += usb-acpi.o > > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c > index 2289700..3de4f88 100644 > --- a/drivers/usb/core/of.c > +++ b/drivers/usb/core/of.c > @@ -18,6 +18,7 @@ > */ > > #include <linux/of.h> > +#include <linux/usb/of.h> > usb: core: add power sequence handling for USB devices > usb: chipidea: let chipidea core device of_node equal's glue layer > device of_node > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++++++ > .../devicetree/bindings/usb/usb-device.txt | 10 +- > MAINTAINERS | 9 ++ > arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-- > drivers/power/Kconfig | 1 + > drivers/power/Makefile | 1 + > drivers/power/pwrseq/Kconfig | 20 +++ > drivers/power/pwrseq/Makefile | 2 + > drivers/power/pwrseq/core.c | 71 ++++++++++ > drivers/power/pwrseq/pwrseq_generic.c | 151 +++++++++++++++++++++ > drivers/usb/chipidea/core.c | 10 ++ > drivers/usb/core/Makefile | 1 + > drivers/usb/core/hub.c | 12 +- > drivers/usb/core/hub.h | 12 ++ > drivers/usb/core/pwrseq.c | 100 ++++++++++++++ > include/linux/power/pwrseq.h | 50 +++++++ > 16 files changed, 507 insertions(+), 17 deletions(-) > create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt > 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 drivers/usb/core/pwrseq.c > create mode 100644 include/linux/power/pwrseq.h > With these patches our on-board USB hub, a Microchip USB2513BI-AEZG, works exactly as it does with the fake regulator kludge, so... Tested-by Joshua Clayton <stillcompiling@gmail.com> I assume there is a v4 coming due to rmk's comments on patch 5. I couldn't figure out where to null the of_node in error paths, but in testing we did put a line of code to null the of_node on release. but... As an aside, I was hoping this series would magically fix a problem with the imx6q-evi which has forced us to disable runtime power management. But it did not. :( If runtime power management is enabled, when nothing is connected to the hub it disconnects and immediately reconnects about every 2 seconds, and after some seemingly random number of these events the whole system hangs (possibly udev related?). Our board has the vbus detect on the hub connected directly to 3.3v, rather than to the imx6's usbh1_vbus line. This is listed as a supported configuration, but might be the source of the problem. Thanks, Joshua
[toc] | [next] | [standalone]
| From | Fabio Estevam <festevam@gmail.com> |
|---|---|
| Date | 2016-07-28 18:50 +0200 |
| Message-ID | <rZWFr-oF-3@gated-at.bofh.it> |
| In reply to | #1451988 |
Hi Joshua, On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton <stillcompiling@gmail.com> wrote: > I assume there is a v4 coming due to rmk's comments on patch 5. > I couldn't figure out where to null the of_node in error paths, but in testing > we did put a line of code to null the of_node on release. > > but... > As an aside, > I was hoping this series would magically fix a problem > with the imx6q-evi which has forced us to disable > runtime power management. But it did not. :( I also see a similar problem on a mx28 board with a hub. Does it help in your case if you pass 'usbcore.autosuspend=-1' in the kernel command line? Regards, Fabio Estevam
[toc] | [prev] | [next] | [standalone]
| From | Joshua Clayton <stillcompiling@gmail.com> |
|---|---|
| Date | 2016-08-01 17:00 +0200 |
| Message-ID | <s1mRc-7Ds-17@gated-at.bofh.it> |
| In reply to | #1452010 |
On 07/28/2016 09:41 AM, Fabio Estevam wrote: > Hi Joshua, > > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton > <stillcompiling@gmail.com> wrote: > >> I assume there is a v4 coming due to rmk's comments on patch 5. >> I couldn't figure out where to null the of_node in error paths, but in testing >> we did put a line of code to null the of_node on release. >> >> but... >> As an aside, >> I was hoping this series would magically fix a problem >> with the imx6q-evi which has forced us to disable >> runtime power management. But it did not. :( > I also see a similar problem on a mx28 board with a hub. > > Does it help in your case if you pass 'usbcore.autosuspend=-1' in the > kernel command line? > > Regards, > > Fabio Estevam Thanks a million, Fabio! 'usbcore.autosuspend=-1' quiets the errors. ~joshua P.S. I guess this technically is a bug in chipidea usb. I'll give it a quick once over, though I am not very familiar with USB core or the CI driver.
[toc] | [prev] | [next] | [standalone]
| From | Fabio Estevam <festevam@gmail.com> |
|---|---|
| Date | 2016-08-01 18:40 +0200 |
| Message-ID | <s1opX-ih-5@gated-at.bofh.it> |
| In reply to | #1453261 |
On Mon, Aug 1, 2016 at 11:55 AM, Joshua Clayton <stillcompiling@gmail.com> wrote: > Thanks a million, Fabio! > > 'usbcore.autosuspend=-1' quiets the errors. > > ~joshua > > P.S. I guess this technically is a bug in chipidea usb. > I'll give it a quick once over, though I am not very familiar > with USB core or the CI driver. Yes, it would be really nice if we can get a proper fix for this bug.
[toc] | [prev] | [next] | [standalone]
| From | Peter Chen <hzpeterchen@gmail.com> |
|---|---|
| Date | 2016-08-02 03:40 +0200 |
| Message-ID | <s1wQx-5YM-13@gated-at.bofh.it> |
| In reply to | #1453261 |
On Mon, Aug 01, 2016 at 07:55:10AM -0700, Joshua Clayton wrote: > > > On 07/28/2016 09:41 AM, Fabio Estevam wrote: > > Hi Joshua, > > > > On Thu, Jul 28, 2016 at 12:56 PM, Joshua Clayton > > <stillcompiling@gmail.com> wrote: > > > >> I assume there is a v4 coming due to rmk's comments on patch 5. > >> I couldn't figure out where to null the of_node in error paths, but in testing > >> we did put a line of code to null the of_node on release. > >> > >> but... > >> As an aside, > >> I was hoping this series would magically fix a problem > >> with the imx6q-evi which has forced us to disable > >> runtime power management. But it did not. :( > > I also see a similar problem on a mx28 board with a hub. > > > > Does it help in your case if you pass 'usbcore.autosuspend=-1' in the > > kernel command line? > > > > Regards, > > > > Fabio Estevam > Thanks a million, Fabio! > > 'usbcore.autosuspend=-1' quiets the errors. > > ~joshua > If you are using imx6q, there are some patches which is not upstreamed to workaround one SoC problem. http://www.spinics.net/lists/linux-usb/msg98682.html Try to implement the design for notify_suspend/resume at drivers/usb/phy/phy-mxs-usb.c and drivers/usb/chipidea/host.c You can refer to the code at: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/?h=imx_4.1.15_1.0.0_ga -- Best Regards, Peter Chen
[toc] | [prev] | [next] | [standalone]
| From | Peter Chen <hzpeterchen@gmail.com> |
|---|---|
| Date | 2016-07-29 04:00 +0200 |
| Message-ID | <s05fH-6fS-9@gated-at.bofh.it> |
| In reply to | #1451988 |
On Thu, Jul 28, 2016 at 08:56:40AM -0700, Joshua Clayton wrote: > Hi, Peter > > On 07/20/2016 02:40 AM, 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], I use a generic > > power sequence library for parsing the power sequence elements on DT, > > and implement generic power sequence on library. The host driver > > can allocate power sequence instance, and calls pwrseq APIs accordingly. > > > > 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 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 > > > > Peter Chen (6): > > binding-doc: power: pwrseq-generic: add binding doc for generic power > > sequence library > > power: add power sequence library > > binding-doc: usb: usb-device: add optional properties for power > > sequencediff --git a/drivers/usb/core/Makefile b/drivers/usb/core/Makefile > > index 9780877..da36b78 100644 > > --- a/drivers/usb/core/Makefile > > +++ b/drivers/usb/core/Makefile > > @@ -5,8 +5,9 @@ > > usbcore-y := usb.o hub.o hcd.o urb.o message.o driver.o > > usbcore-y += config.o file.o buffer.o sysfs.o endpoint.o > > usbcore-y += devio.o notify.o generic.o quirks.o devices.o > > -usbcore-y += port.o of.o > > +usbcore-y += port.o > > > > +usbcore-$(CONFIG_OF) += of.o > > usbcore-$(CONFIG_PCI) += hcd-pci.o > > usbcore-$(CONFIG_ACPI) += usb-acpi.o > > > > diff --git a/drivers/usb/core/of.c b/drivers/usb/core/of.c > > index 2289700..3de4f88 100644 > > --- a/drivers/usb/core/of.c > > +++ b/drivers/usb/core/of.c > > @@ -18,6 +18,7 @@ > > */ > > > > #include <linux/of.h> > > +#include <linux/usb/of.h> > > usb: core: add power sequence handling for USB devices > > usb: chipidea: let chipidea core device of_node equal's glue layer > > device of_node > > ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property > > > > .../bindings/power/pwrseq/pwrseq-generic.txt | 48 +++++++ > > .../devicetree/bindings/usb/usb-device.txt | 10 +- > > MAINTAINERS | 9 ++ > > arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-- > > drivers/power/Kconfig | 1 + > > drivers/power/Makefile | 1 + > > drivers/power/pwrseq/Kconfig | 20 +++ > > drivers/power/pwrseq/Makefile | 2 + > > drivers/power/pwrseq/core.c | 71 ++++++++++ > > drivers/power/pwrseq/pwrseq_generic.c | 151 +++++++++++++++++++++ > > drivers/usb/chipidea/core.c | 10 ++ > > drivers/usb/core/Makefile | 1 + > > drivers/usb/core/hub.c | 12 +- > > drivers/usb/core/hub.h | 12 ++ > > drivers/usb/core/pwrseq.c | 100 ++++++++++++++ > > include/linux/power/pwrseq.h | 50 +++++++ > > 16 files changed, 507 insertions(+), 17 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt > > 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 drivers/usb/core/pwrseq.c > > create mode 100644 include/linux/power/pwrseq.h > > > > With these patches our on-board USB hub, > a Microchip USB2513BI-AEZG, works exactly as it does > with the fake regulator kludge, so... > Tested-by Joshua Clayton <stillcompiling@gmail.com> > Thanks. > I assume there is a v4 coming due to rmk's comments on patch 5. > I couldn't figure out where to null the of_node in error paths, but in testing > we did put a line of code to null the of_node on release. I will add it at v4. > > but... > As an aside, > I was hoping this series would magically fix a problem > with the imx6q-evi which has forced us to disable > runtime power management. But it did not. :( > > If runtime power management is enabled, when nothing is > connected to the hub it disconnects and immediately reconnects > about every 2 seconds, and after some seemingly random number > of these events the whole system hangs (possibly udev related?). > > Our board has the vbus detect on the hub connected directly to 3.3v, > rather than to the imx6's usbh1_vbus line. This is listed as a supported > configuration, but might be the source of the problem. > You could have a thread to discuss this problem. But if Fabio's suggestion can work for you, it may not be hardware problem. Make sure you use the correct low power mode flow, you can refer to the latest mainline code for it. -- Best Regards, Peter Chen
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web