Auto-wake behavior when external power is connected

[diodelass]

I've noticed that my Pinebook Pro immediately wakes up from a suspend-to-RAM state whenever external power is connected or disconnected. I find this concerning, because this is approximately the last time I would ever want it to wake from sleep mode automatically - particularly since it does this even if the lid is closed at the time, and it's very hard to tell from the outside if the device is asleep or awake with the lid down.

What will it take to change this? I'm bracing myself for the worst, because I can't imagine the OS is involved at all in wake conditions - hence my posting in the hardware section. Is this something that could be fixed in the firmware with a straightforward method, or is it going to require attaching debugging clips to an IC in there somewhere, or what?

It's puzzling to me how this behavior was established in the first place. Is it affecting other units as well, or is ours somehow a fluke?

[sundog]

Just confirmed that our pinebook pro exhibits the same behavior running ayufan's bionic lxde image 0.9.16 using the barrel connector for power.

Also agree that this is sub-optimal.

[diodelass]

After having dealt with it for a couple days, this behavior is driving me mad. I can't close the lid and then put it on its charger, because connecting the charger immediately wakes it up. I can't unplug it and stuff it into a backpack, either, because that wakes it up too. If the power flickers in the night, it wakes up. If I jostle the cord by accident and it momentarily loses contact, it wakes up. It's kind of absurd.

Can anyone familiar with the hardware tell us more about why this happens, and perhaps how it might be fixed? Keeping my computers asleep until I purposefully wake them is a rather important part of my use of them.

[xalius]

If I had to guess, I would say it's the PMIC interrupt from the RK808 that notifies the OS of a power management event:

15.2.5.4 INT_STS_MSK_REG2 : Interrupt Status Register #2
Bit 1 PLUG_OUT_INT_IM: Charger plug out event interrupt mask.
1: Mask the interrupt
0: Do not mask the interrupt
Bit 0 PLUG_IN_INT_IM: Charger plug in event interrupt mask
1: Mask the interrupt
0: Do not mask the interruptk

In normal operation you want to handle those to know that a charger is present, in suspend probably those and other PMIC IRQs should be masked.
The question is, where in the software stack is this handled exactly, ATF or Linux?

[PineyMike]

If I had to guess, I would say it's the PMIC interrupt from the RK808 that notifies the OS of a power management event:

15.2.5.4 INT_STS_MSK_REG2 : Interrupt Status Register #2
Bit 1 PLUG_OUT_INT_IM: Charger plug out event interrupt mask.
1: Mask the interrupt
0: Do not mask the interrupt
Bit 0 PLUG_IN_INT_IM: Charger plug in event interrupt mask
1: Mask the interrupt
0: Do not mask the interruptk

In normal operation you want to handle those to know that a charger is present, in suspend probably those and other PMIC IRQs should be masked.
The question is, where in the software stack is this handled exactly, ATF or Linux?

Did you ever find a solution here? I'm having the same issue with a really vanilla Manjaro Sway install.  I was hoping it was something in systemd or something?

[dsimic]

If I had to guess, I would say it's the PMIC interrupt from the RK808 that notifies the OS of a power management event:

15.2.5.4 INT_STS_MSK_REG2 : Interrupt Status Register #2
Bit 1 PLUG_OUT_INT_IM: Charger plug out event interrupt mask.
1: Mask the interrupt
0: Do not mask the interrupt
Bit 0 PLUG_IN_INT_IM: Charger plug in event interrupt mask
1: Mask the interrupt
0: Do not mask the interruptk

In normal operation you want to handle those to know that a charger is present, in suspend probably those and other PMIC IRQs should be masked.
The question is, where in the software stack is this handled exactly, ATF or Linux?

As far as I can see, it should be done in the RK808 Linux kernel driver.  Haven't had the time to check in detail, but it should be performed in the rk8xx_suspend() and rk8xx_resume() functions.

[dsimic]

Good news!  I'll implement the required changes to the RK808 driver, so the respective wakeup events (i.e., interrupts) are ignored, and provide a patched kernel package for testing.  After the issue is confirmed to be resolved, I'll submit the patch for upstreaming into the Linux kernel mainline.

[dsimic]

Even better news!

No changes to the RK808 kernel driver are required, simply do the following as root and (un)plugging the charger will no longer wake up a suspended PineBook Pro:

Code:

echo disabled > /sys/devices/platform/dc-charger/power/wakeup

You may also create a sysctl rule and place it in /etc/sysctl.d, to have this configured automatically upon every boot.

Here are more details about the whole ordeal with charger (un)plugging detection.  As already described earlier in this thread, the RK808 PMIC has a very nice built-in feature that senses the charger voltage and generates interrupts upon the charger plug in and plug out events.  However, as visible on page 12 in the PineBook Pro schematicc, there's pretty much no way that anything reaches the RK808's pin #34 (VDC input).  Why would anyone connect capacitors in series with a stabilized DC input?

The ugly fix we're dealing with is that one of the RK3399's GPIO inputs is used for sensing the presence of charger, which makes no sense whatsoever.  That's the "dc-charger" device/node from above, which is just a charger present/absent flag.  This is clearly a bug in the PineBook Pro schematic, and I suppose that it could (and should) be fixed by using a pair of isolation diodes instead of the capacitors.

The proper way, however, is to use the RK808's functionality, instead of abusing a RK3399's GPIO line.  Furthermore, should we start a list of bugs to be fixed in the next PineBook Pro PCB revision?