| Message ID | 20180923150719.8211-1-andreas@kemnade.info (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: dts: gta04: add serial console wakeup irq | expand |
* Andreas Kemnade <andreas@kemnade.info> [180923 08:12]: > This enables the possibility to have more aggressive runtime pm > by providing proper wakeup irq for the serial console. Thanks applying to omap-for-v4.20/dt. FYI, you can now grep wake /proc/interrupts and see the wakeirq counts increase when they trigger. Might be handy for debugging PM stuff. Regards, Tony
Hi Tony, On Mon, 24 Sep 2018 15:03:45 -0700 Tony Lindgren <tony@atomide.com> wrote: > * Andreas Kemnade <andreas@kemnade.info> [180923 08:12]: > > This enables the possibility to have more aggressive runtime pm > > by providing proper wakeup irq for the serial console. > > Thanks applying to omap-for-v4.20/dt. > > FYI, you can now grep wake /proc/interrupts and see the > wakeirq counts increase when they trigger. Might be handy > for debugging PM stuff. > thanks for that information, you also had a patch for checking pm which was explicitely marked as not-to-merge. Is there any up-to-date version of it? Well, for debugging I check first average currents via bq27000 attached to omap_hdq. omap_hdq gets stuck after first transaction after idling uarts which does not happen when CM_AUTOIDLE1_CORE.AUTO_HDQ is cleared. Reloading the omap_hdq module to try to fix things makes w1 really freak out (patch already sent for that). Well, will do some rtfm and hopefully come back with a patch. afaicr there was something special... The result are power management problem in /dev/brain ;-) Regards, Andreas
* Andreas Kemnade <andreas@kemnade.info> [180925 05:32]: > Hi Tony, > > On Mon, 24 Sep 2018 15:03:45 -0700 > Tony Lindgren <tony@atomide.com> wrote: > > > * Andreas Kemnade <andreas@kemnade.info> [180923 08:12]: > > > This enables the possibility to have more aggressive runtime pm > > > by providing proper wakeup irq for the serial console. > > > > Thanks applying to omap-for-v4.20/dt. > > > > FYI, you can now grep wake /proc/interrupts and see the > > wakeirq counts increase when they trigger. Might be handy > > for debugging PM stuff. > > > thanks for that information, you also had a patch for checking > pm which was explicitely marked as not-to-merge. Is there > any up-to-date version of it? It's still the same so no updates to it. > Well, for debugging I check first average currents via bq27000 > attached to omap_hdq. omap_hdq gets stuck after first transaction > after idling uarts which does not happen when CM_AUTOIDLE1_CORE.AUTO_HDQ > is cleared. Reloading the omap_hdq module to try to fix things > makes w1 really freak out (patch already sent for that). > Well, will do some rtfm and hopefully come back with a patch. > afaicr there was something special... Hmm sounds like drivers/w1/masters/omap_hdq.c needs to implement PM runtime calls, it's probably just enabled because of only needing the interconnect fck that the uart happens to keep enabled. > The result are power management problem in /dev/brain ;-) :) Tony
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi index ac830b917776..edb7cdd33632 100644 --- a/arch/arm/boot/dts/omap3-gta04.dtsi +++ b/arch/arm/boot/dts/omap3-gta04.dtsi @@ -493,6 +493,7 @@ &uart3 { pinctrl-names = "default"; pinctrl-0 = <&uart3_pins>; + interrupts-extended = <&intc 74 &omap3_pmx_core OMAP3_UART3_RX>; }; &charger {
This enables the possibility to have more aggressive runtime pm by providing proper wakeup irq for the serial console. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> --- arch/arm/boot/dts/omap3-gta04.dtsi | 1 + 1 file changed, 1 insertion(+)