Suspend Investigation with a Reboot Bonus


johnicboom

Fresh as a buzzard
Joined
May 3, 2016
Messages
85
Age
42
Location
Chicago, IL, USA
Some time back, Discord user jurop#88 posted this to the pyra-dev channel:
It does not work due to issues with TXS02612 driver. Since muxing of internal uSD and uMMC is not working anyway, it is enough to disable the component in the DT to have a functional (albeit not optimized) suspend. The AS5013 driver (nubs) has no configuration for power management. The simplest workaround is just to restart the pyrainput service when exiting suspend.

I finally have a chance to check it out. I don't really know what I'm doing, but Askarus showed me how to edit the Device Tree on this thread:
...so let's jump in!

Basically, it seems that jurop#88 was right! I disabled muxing using the device tree, and Suspend seems to work now, and Restart seems to have come along for the ride. I haven't been able to automatically get the nubs to work again, so hopefully someone can lend a hand there. Or maybe I'll get it eventually. (Edit - I got it!)

I'm running Debian 12 bookworm on my SD card, but as luck would have it, I mistakenly copied my modified dtb file to the emmc's boot partition while bumbling my way through this process, so I can confirm that I can still boot from emmc, too, though I haven't tested anything else on that install.

The only reliable way I found to tell if I really disabled the TXS02612 device was by checking:
Code:
sudo dmesg | grep mmc

Before making the changes in this post, at about 1.5 seconds, there is an error referencing that device. After replacing the dtb file and rebooting, that error is gone. There may be a better way to check.

Here's what I did.

Install the necessary software (I'm not sure this is all really essential):
Code:
sudo apt install git build-essential flex bison libyaml-dev

Clone the pyra-kernel repo:
Code:
git clone --depth 1 https://dev.pyra-handheld.com/packages/pyra-kernel

Edit the dts file in your favorite editor. It's this one:
Code:
~/pyra-kernel/arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dts

Add this at the bottom, then save and close:
Code:
&mmcmux {
    status = "disabled";
};

&{/txs02612} {
    status = "disabled";
};

Compile the dtbs:
Code:
cd ~/pyra-kernel/
make pyra_defconfig dtbs

Find your dtb files in your /boot/ directory. Mine are at (on my SD card, running Debian bookworm):
Code:
/boot/dtb/linux-image-5.6.19-pyradef

The compiled dtb files get dumped in the same location as the dts files (~/pyra-kernel/arch/arm/boot/dts). The compile step created lots of dtb files, but we only need to replace the one we updated.

It's a good idea to back up your current dtb file to simplify undoing any changes you've made:
Code:
sudo cp /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb.bak

Copy the updated dtb to the dtb directory found in the step above. For me, that command was:
Code:
sudo cp ~/pyra-kernel/arch/arm/boot/dts/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb /boot/dtb/linux-image-5.6.19-pyradef/omap5-letux-cortex15-v5.3+pyra-v5.3.dtb

Reboot.

Now if you check dmesg again, you should find no mention of TXS02612:
Code:
sudo dmesg | grep mmc

At this point, you should be able use Restart from the Pyra's power button menu and have it function normally. Suspend will work, but as jurop#88 mentioned, the nubs won't work when you resume.

What works for me, is to manually restart the pyrainput service using the terminal:
Code:
sudo systemctl restart pyrainput

I thought a simple solution would be to create a systemd service that restarts the pyrainput service automatically, and it seems to work:
Code:
[Unit]
Description=Restart pyrainput service after suspend
After=suspend.target

[Service]
Type=oneshot
Environment="DISPLAY=:0"
Environment="HOME=/home/john"
Environment="USER=john"
ExecStart=/bin/systemctl restart pyrainput


[Install]
WantedBy=suspend.target

Can some Pyra owners please see if this also works for you?

I haven't done much testing so far, but suspend power usage seems to depend on what was open when I suspend. When I only had the terminal open, I saw between 2-3% battery drain in an hour. With Vivaldi also open, I saw 5% in an hour. These were NOT good tests, I still need to do some better testing in the next few days.

Also, if you suspend and then close the lid, the lid closing event wakes the device. I also haven't tested suspend automatically when the lid closes enough to say anything about it.



Update: It looks like I caused my service to only work once per boot with my RemainAfterExit=yes line...

I edited the content above with the correct service contents, removing that line and removing a commented out sleep line, since it wasn't necessary. I initially had this as my service:

Code:
[Unit]
Description=Restart pyrainput service after suspend
After=suspend.target

[Service]
Type=oneshot
Environment="DISPLAY=:0"
Environment="HOME=/home/john"
Environment="USER=john"
#ExecStartPre=/bin/sleep 1
ExecStart=/bin/systemctl restart pyrainput
RemainAfterExit=yes

[Install]
WantedBy=suspend.target

So it was only restarting the pyrainput service automatically once per boot, and I had to manually type
Code:
sudo systemctl restart pyrainputservice
every time I woke the Pyra from suspend.
 
Last edited:
I'll try this when I find more time, I'm really interested.

Did you noticed also the device to be less hot ?
Yes, when it's suspended, I'm pretty sure it cools down. My USB ports are usually warm/hot to the touch, and while testing yesterday, I noticed they were cool after it was suspended for a while.

My tests so far this afternoon, using auto-suspend when I close the lid (set in Mate's GUI Power Manager), showed a consistent 3% battery drain per hour (3 tests) with only the terminal open. I should have closed everything, but I was still also making sure the nubs come back every time. So far so good on that front - it looks like the systemd service works great.

Right now, I'm spending an hour testing charging while suspended, since I was curious (and wanted to have ample battery for my train ride home, which will be a good test of actively using suspend while the Pyra is doing things). Tomorrow, I'll have it charged up in the morning and see what a full work-day of suspend does for the battery level.
 
I only tested suspend charging a little bit, but it does work. That was with the normal micro-USB port (debug), not the micro-USB 3.0 (wide cable) port. That does slower charging. I'll test charging with the wide port tomorrow.

For the these tests, I had Syncthing running in the background, but it was only syncing my text file with the below info, and Pluma, where I was recording the measurements. Wifi is on (it disconnects on suspend, reconnects on wake), BlueTooth is off, Conservative CPU governor.

A full 8 am to 5 pm workday of suspend, and I have 55% left. That's a HUGE improvement over no suspend. My Pyra would have normally died by now, for sure.

Code:
Battery Percent | 24-hour time | charging state from that measurement to the next
53% 1625
50% 1643 sleep charging
77% 2050 sleep charging
87% 0800
83% 0900
79% 1000
76% 1100
72% 1200
69% 1300
65% 1400
62% 1500
58% 1600
55% 1700
 
Back
Top