From: <gregkh@linuxfoundation.org>
To: tony@atomide.com, alexander.levin@verizon.com, d-gerlach@ti.com,
gregkh@linuxfoundation.org, marc.zyngier@arm.com, nm@ti.com,
rogerq@ti.com, sebastian.reichel@collabora.co.uk
Cc: <stable@vger.kernel.org>, <stable-commits@vger.kernel.org>
Subject: Patch "ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen" has been added to the 4.14-stable tree
Date: Fri, 23 Feb 2018 12:09:56 +0100 [thread overview]
Message-ID: <151938419660152@kroah.com> (raw)
This is a note to let you know that I've just added the patch titled
ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Tony Lindgren <tony@atomide.com>
Date: Fri, 17 Nov 2017 08:56:58 -0800
Subject: ARM: dts: Fix omap4 hang with GPS connected to USB by using wakeupgen
From: Tony Lindgren <tony@atomide.com>
[ Upstream commit cf87634c8b24e24bf379b8c6807c8b0fb5f23567 ]
There's been a reproducable USB OHCI/EHCI cpuidle related hang on omap4
for a while that happens after about 20 - 40 minutes on an idle system
with some data feeding device being connected, like a USB GPS device or
a cellular modem.
This issue happens in cpuidle states C2 and C3 and does not happen if
cpuidle is limited to C1 state only. The symptoms are that the whole
system hangs and never wakes up from idle, and if a watchdog is
configured the system reboots after a while.
Turns out that OHCI/EHCI devices on omap4 are trying to use the GIC
interrupt controller directly as a parent instead of the WUGEN. We
need to pass the interrupts through WUGEN to GIC to provide the wakeup
events for the processor.
Let's fix the issue by removing the gic interrupt-parent and use the
default interrupt-parent wakeupgen instead. Note that omap5.dtsi had
this already fixes earlier by commit 7136d457f365 ("ARM: omap: convert
wakeupgen to stacked domains") but we somehow missed omap4 at that
point.
Fixes: 7136d457f365 ("ARM: omap: convert wakeupgen to stacked domains")
Cc: Dave Gerlach <d-gerlach@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/omap4.dtsi | 2 --
1 file changed, 2 deletions(-)
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -861,14 +861,12 @@
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
};
usbhsehci: ehci@4a064c00 {
compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
- interrupt-parent = <&gic>;
interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
};
};
Patches currently in stable-queue which might be from tony@atomide.com are
queue-4.14/arm-dts-fix-elm-interrupt-compiler-warning.patch
queue-4.14/arm-omap2-fix-sram-virt-to-phys-translation-for-save_secure_ram_context.patch
queue-4.14/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
queue-4.14/arm-dts-logicpd-som-lv-fix-gpmc-addresses-for-nand-and-enet.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
queue-4.14/arm-dts-logicpd-somlv-fix-wl127x-pinmux.patch
queue-4.14/arm-dts-am4372-correct-the-interrupts_properties-of-mcasp.patch
queue-4.14/arm-dts-am437x-cm-t43-correct-the-dmas-property-of-spi0.patch
reply other threads:[~2018-02-23 11:10 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=151938419660152@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=alexander.levin@verizon.com \
--cc=d-gerlach@ti.com \
--cc=marc.zyngier@arm.com \
--cc=nm@ti.com \
--cc=rogerq@ti.com \
--cc=sebastian.reichel@collabora.co.uk \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox