Pinephone Pro – support merged into my kernel tree
I've integrated initial support for Pinephone Pro, that was previously done
by Martijn Braam and Kamil Trzciński (ayufan) into my kernel
tree, and spent yesterday looking at various issues that I've found with that
kernel tree and fixing them.
I've fixed some of the most annoying issues, some of them with the help of
carlos from #pinedev IRC chat:
- First issue that I looked at was display shutting down and never recovering
after the first blanking event (DPMS). I noticed PCLK in the
dw-mipi-dsi driver getting disabled more times than being enabled,
which is a indicator of driver being buggy. After a few hours of reading through
DRM subsystem, I've figured that dw-mipi-dsi was just using the bridge code
wrong, and DPMS could have never worked with that driver. I fixed the DSI
controller driver and adapted the Pinephone Pro display panel driver to match
the new expectations around
prepare/enable callbacks, and DPMS now
works without crashes or kernel warnings.
- I noticed that
/proc/interrupts was showing hundreds of
thousands of interrupts for various devices: touchscreen, rk818 PMIC, and fusb
type-c controller. The cause was incorrect voltage regulator assigned to one of
the I/O domains. The SoC was expecting 3V input levels, but was getting 1.8V on
the GPIOs the interrupt lines are connected to, and this led to those interrupt
lines being considered asserted all the time. Three interrupt storms at once
- Goodix touchscreen was still producing a lot of interrupts even after the
above fix. This ended up being caused by Goodix driver trying to detect the type
of interrupt to be used from the touchscreen's internal configuration, and the
guess being wrong. After consulting the datasheet, I decided to use rising edge
interrupt and that stopped touchscreen interrupts from happening every 1ms. Now
they only appear, whe the touchscreen is touched.
- With interrupts being calmed down from milions per a few minutes to barely
any, I was able to use mainline TF-A from the master to achieve suspend to RAM
on Pinephone Pro with no closed source binary blobs. It seems to just work,
though the power savings are not as high as with the Android factory image
I tested previously. Android factory 160mW in suspend. Mainline
- And that was another issue. Power consumption should not vary when I touch
the screen in suspended mode, but I've already debugged this issue in the past
on the original Pinephone, and I was able to just enable the solution I've
implemented to this problem previously. This solution is to power down the
touchscreen in system suspend completely. With that the suspend power
consumptions stays at 400mW no matter what I do.
- Carlos shared a patch with me that he uses on his Pinebook Pro that
implements runtime suspend for eMMC. This patch saves about 200mW of power when
eMMC is idling on both Pinephone Pro and Pinebook Pro.
After all these fixes I've made more suspend/resume tests, and it seems that
it all works much better now. Pinephone Pro now idles at ~1.7 W, which is very
close to what kernel can achieve by suspending all devices it has under control
currently (s2idle). With suspend to RAM, it can get as low as 400 mW.
Next time it will be useful to figure out how to reliably power down and
reset the phone, because that's not working great at the moment either.
It will be also interesting to figure out how to achieve 160 mW in suspend
to RAM that the Android factory image seems to be capable of, from my previous
Pinephone Pro code is now integrated into my kernel in two branches: ppp-dt and ppp-drivers.
I squashed all the original DT
code and split the driver code from device tree changes and started building on
top. I've excluded Type-C related
changes, for now, because they are not documented well and I don't trust
that they don't break non pinephone kernel builds.
I've also switched to 5 Ghz wifi (40MHz channel) and Pinephone Pro's seems
to be able to achieve 15 MiB/s with that, which is a nice upgrade over
More to come…