CPUIDLE not working on pinephone

I’ve been writing a software tool, which I call rk2aw, to fix all these issues for good on several Rockchip SoCs, including RK3399, RK3566 and RK3588. It allows you to have multiple bootloaders in SPI NOR flash, it reverses boot order so that microSD card is tried first if present, it adds a single button/LED UI which is realizable on almost every Rockchip SBC in uniform way, and it adds some device specific improvements like preventing boot when powerup happens due to USB power insertion, and not a power button press.


It’s obviously not for pinephone so not very relevant to this specific thread.

Yes, I already saw that description of the rk2aw features. Presumably, rk2aw detects the power-ups caused by plugging in a USB charger and simply turns the device off. I don’t see what else rk2aw could do, because it acts as a pre-boot loader, so to speak, by adjusting the boot-related Rockchip BROM functions.

However, I don’t think that’s the best way to handle charger-initiated power-ups, simply because virtually all smartphones and tablets, old or modern, turn on automatically when a charger is plugged into them and then go into their charge-only modes. That’s why the PinePhone’s AXP803 PMIC, for example, actually behaves that way – it was designed to be used in mobile devices.

1 Like

Just a brief update… Although I unfortunately haven’t recovered fully yet, I’ve managed to get very close to having almost a dozen of Linux kernel and U-Boot patches submitted upstream. I’m pretty sure that the patches will be accepted, and despite them not being PinePhone-related, they should help a lot when the time comes for submitting more complex PinePhone patches upstream.

Get better my friend …

1 Like

Thank you! :slight_smile:

I’m happy to report that six of my Linux kernel patches have been accepted upstream:

The links above were dead for some time, but they’re fixed now.



Nice to meet you, a new arm dev for the team :slight_smile:

1 Like

Hello! :slight_smile:

I’ve been active as a contributor to Manjaro ARM for a while, by contributing to various packages, then the things took a slightly different turn on my side, after which I unfortunately had some impactful health issues, and now I’m back by contributing various patches to upstream projects. :slight_smile:

Update, January 26, 2024: Unfortunately, I’ve been sick again, this time for about a month. :frowning: I’ve contracted some really nasty kind of flu that has found its way into my lungs, causing a real mess. I’m still recovering.

On the bright side, another Linux kernel patch has been accepted upstream: arm64: dts: rockchip: Add cache information to the SoC dtsi for RK3399. I’ll also prepare and submit upstream more similar patches for other Rockchip SoCs.


I’m happy to report that a few of my Linux kernel patches have been accepted upstream, with quite detailed and informative patch descriptions, especially when it comes to the descriptions of the RK356x and Pinebook Pro patches:

There’s also one small U-Boot patch that has been accepted upstream:

Last, but not least, a handful of my Git patches have been accepted upstream (by the way, getting patches accepted by Git is very, very, VERY hard):

More U-Boot patches are on their way to the U-Boot mailing list, and there are already more Git patches awaiting merging on the mailing list. I’ll keep updating this post as more patches become accepted upstream.

I’ve been also quite active with reviewing other people’s patches on the mailing lists, which is another great way to contribute and learn at the same time.

There’s one particularly interesting patch series on the linux-rockchip mailing list that I’ve been participating to, which improves the upstream support for the Rockchip RK3588(s) SoC. That patch series should sprout into another patch series with some really interesting new upstream kernel features, leading to measurable performance and power consumption improvements on multiple Rockchip SoCs (emphasis added only to prevent tl;dr mode from kicking in, :slight_smile: this is a rather long paragraph). Though, making all that happen, which includes getting the patches accepted upstream, will inevitably be a rather massive undertaking, both for the implementation of the patches, and for their evaluation and testing; for example, just measuring the achieved power savings accurately will be challenging.

The above-mentioned future patches will also require help from the community, in form of comprehensive stress testing, which is probably going to be a requirement for getting the whole thing upstreamed. I’ll describe it all here later, after I send some more details to the linux-rockchip mailing list.