This enables the possibility to have more aggressive runtime pm
by providing proper wakeup irq for the serial console.
Signed-off-by: Andreas Kemnade <[email protected]>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 1 +
1 file changed, 1 insertion(+)
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 {
--
2.11.0
* Andreas Kemnade <[email protected]> [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 <[email protected]> wrote:
> * Andreas Kemnade <[email protected]> [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 <[email protected]> [180925 05:32]:
> Hi Tony,
>
> On Mon, 24 Sep 2018 15:03:45 -0700
> Tony Lindgren <[email protected]> wrote:
>
> > * Andreas Kemnade <[email protected]> [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