After updating the phone to the uboot-pinephone version 2022.10-1 which should support CPUIDLE it still does not seem to be working.
$ sudo cpupower idle-info
[sudo] password for alarm:
CPUidle driver: none
CPUidle governor: menu
analyzing CPU 0:CPU 0: No idle states
Is there some configuration to do that i am missing?
please test 2022.10-2 firmware: Pipeline · manjaro-arm / packages / core / uboot-pinephone · GitLab
password for alarm indicates that you use an Arch-build not a Manjaro one.
Megi mentioned in the blog you linked in the previous thread, that only that TF-A option was missing.
We added that and it’s still not working the way you want. So now you need to tell us, what else we are missing.
That quote is just copied from megi’s page linked in the other topic. Pinephone has identical output (except the username) and i did not want to type it out manually on the pc i’m using to post this.
I’m trying to get something working, not suggesting how to fix it as i don’t know. The only thing i came up with was thinking if the order of the build flags mattered like they do in some commands, probably not, but philm already made some other changes that also rearranged that identical to the example working build command.
I will give the new version a go.
The linked uboot version makes the touch screen stop working after reboot. The phone boots normally to login screen but swiping up to unlock does not work. Tested both on an updated unstable install, and on fresh beta28 install.
edit: here is something maybe related from journal:
tammi 17 14:24:33 manjaro-arm kernel: lima 1c40000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found
tammi 17 14:24:33 manjaro-arm kernel: sun50i-a64-r-pinctrl 1f02c00.pinctrl: supply vcc-pl not found, using dummy regulator
tammi 17 14:24:33 manjaro-arm kernel: axp20x-rsb sunxi-rsb-3a3: mask_invert=true is deprecated; please switch to unmask_base
tammi 17 14:24:33 manjaro-arm kernel: axp20x-adc axp813-adc: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: axp20x-battery-power-supply axp20x-battery-power-supply: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: axp20x-usb-power-supply axp20x-usb-power-supply: DMA mask not set
tammi 17 14:24:33 manjaro-arm kernel: i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -110
tammi 17 14:24:33 manjaro-arm kernel: i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -110
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS 0-005d: I2C communication failure: -110
tammi 17 14:24:33 manjaro-arm kernel: Goodix-TS: probe of 0-005d failed with error -110
Do you have access to your phone’s serial console, meaning that you can capture the messages produced on the serial console when the phone is turned on and booted?
No, the cable would become insanely expensive to buy due to shipping costs, as it is not possible to purchase it in same package as the phone (i tried).
Should these logs not be available after boot from disk?
I see, the PinePhone needs to be purchased and shipped separately because it has built-in battery. That is simply one of the DHL and FedEx rules.
Those are the serial console messages produced by the boot loader, and as such aren’t available anywhere else after the boot loader completes its job.
I’ll see to run the tests tomorrow myself, with different boot loader builds, and I’ll report my findings here.
I’m having some issues with my eyes, unfortunately, so this will have to wait until tomorrow or so.
How’s your eyes holding up? Hope you get well soon.
Thanks for checking! 
I’m rather fine now, thankfully, and I’ll start testing various boot loader builds tomorrow. I already went through the relevant TF-A source code, so I know what’s the expected behavior with the CPU idle states and Crust, and what may actually go wrong. What’s left is detailed testing.
Gah, I’ve started coughing quite badly, having a runny nose, and feeling rather bad in general, which all basically have put me out of commission. I was already sick for about a couple of weeks back in December, hoping to be done with the common cold, seasonal flu or whatever it was, but what do you know, it’s probably just that time of the year.
I’m hoping I’ll be better tomorrow or the day after, so I can perform the testing. I’m looking forward to getting to the bottom of the CPU idle issue.
I’m feeling better today, thankfully, and I’ll start testing various U-Boot/TF-A builds a bit later today.
I’ve build one based on uboot 2023.01 release. Can be found here: Pipelines · [pkg-upd] 2023.01-1 (d8acd8b9) · Commits · manjaro-arm / packages / core / uboot-pinephone · GitLab
@Strit Great, thank you very much! I’m looking at the provided log files, and I’ll post my findings here.
@Strit Could you, please, run the following command and post the resulting pinephone.dts file in the GitLab issue? Just to make sure that the device tree is amended correctly in the TF-A.
dtc -I fs -O dts /sys/firmware/devicetree/base -o pinephone.dts
The correct additions to the device tree are pretty much already confirmed by the TF-A output from the serial console that’s visible below, as an excerpt from the logs you provided, but let’s double check that to be sure, please.
INFO: PSCI: Suspend is available via SCPI
By the way, what are you getting in the following sysfs file?
/sys/devices/system/cpu/cpuidle/current_driver
@philm As a note, I’ve just checked the kernel configuration in the linux-pinephone package, and it looks right because it contains the following lines:
CONFIG_ARM_PSCI_CPUIDLE=y
CONFIG_ARM_PSCI_CPUIDLE_DOMAIN=y