2021–11–16: A bunch of mostly Pinephone Pro news

fusb302 bug from the previous post

My fix for fusb302 disconnect bug from the last post was reviewed by upstream maintainers and will be accepted for mainline kernel and likely also merged into stable kernels.

Phone LCD getting all garbled after disconnecting the external monitor

I've successfully chased down one bug that caused internal display to be clocked wrong after plugging in and removing the USB dock. It turns out RK3399 can generate rather precise pixel clock for the displays, if and only if the clock tree is configured to use a fractional divider (numerator/denominator can both be any 16-bit value, which is perfect!). It was not configured to use it in Pinephone Pro DT, and thus just a very rough clock rate was set each time the display pipeline was re-configured, and it turned out the display is very senstitive to the pixel clock rate. To makes things worse the clock rate was not even set consistently, but changed based on situation. 2.4Mhz difference here or there is not something that LCD controller tolerates well. With the fix, it's possible to generate the required pixel clocks precisely almost to a single Hertz and the problems go away.

Panfrost/Lima panicking the 5.16-rc1 kernels

I've also hit an issue in a brand new 5.16-rc1 kernel, that led to kernel panics whenever panfrost was being used. I reported it and it will be fixed upstream in -rc2.

HW issues and needless de-railements

I've had problems with USB 2.0 in device mode on Pinepehone Pro. Connecting the phone to USB 2.0 port would cause USB enumeration failures, but BC1.2 detection was working. I assumed it must be some software issue, because if BC1.2 worked (it's using the same wires in the cable that are used for USB 2.0 data link).

It turned out the red Pine64 USB-A → Type-C cable was somehow half-broken. Using a different red Pine64 cable allowed the phone to enumerate correctly. Go figure.

I also have issues with the Type-C port being a bit wobbly on my Pinephone Pro unit, so I padded it a bit with some spare thermal padding that I have at home, to fix it in place. Sometimes I can still see USB re-enumeration in kernel log when I shift things around on my table and touch the cable going to the phone. It makes it hard to distinguish software and hardware issues, slowing down development with needless debugging that leads nowhere and confuses me, until I figure out it's just a bad cable or a bad connector connection, or whatever. :(

Development now moved on to 5.16-rc1

I've rebased my kernel branches on top of 5.16-rc1 and with all these issues out of the way, it now works quite nicely for development and testing of the PPP support in the kernel. I've thus moved all my PPP work to 5.16-rc1.

New charger driver for RK818

I've implemented and tested the charger driver for RK818 PMIC. It can now correctly set input power limits, based on what limit is reported by Type-C controller based on standard PD and BC1.2 negotiation protocols. I've verified this with the Power-Z USB Type-C power meter.

I've also discovered a more standard way to pass input current limits based on a link between two power supplies in the device tree. This helped me clean up the code a bit, and make it eventually a bit more upstreamable.

Cleaner implemnetation of USB OTG, Type-C and USB Power Delivery on Pinephone Pro

I've found yet easier and more proper ways to tie everything together in both drivers and the device tree for all Type-C support to work.

For example previously I used graph lookup in DT to connect fusb302/tcpm to my new typec-extcon bridge driver, which requires very wordy port/endpoint setup on both nodes in the DT. See my cameras support patch for Pinephone Pro for an example of this port/endpoint based device node relationships. Looking at the kernel code, I figured that instead of complicated port/endpoint dance, typec interfaces also allow to just use a simple references like usb-role-switch = <&typec_extcon>;, mode-switch = <&typec_extcon>;, orientation-switch = <&typec_extcon>; to refer to the providers of various typec interfaces. Much simpler! It would be nice if this was documented somewhere. :)

Because typec-extcon device driver is just a software artifact to adapt two incompatible in-kernel software interfaces together (typec mux/switch/role switch ↔ extcon), and it's not driving a real hardware, it's certainly not going to be accepted upstream. Device tree should describe hardware and not software components. typec-extcon bridge is still a useful stepping stone on the way to a propper upstream support. It makes everything work with little to no changes to existing drivers, and it's easy to support until various drivers are extended with proper typec interfaces.

USB host/peripheral mode works very well now. Display port support is also much better, but still has some issues that need fixing.

Pinebook Pro port

I've also modified the DT of Pinebook Pro to use the same approach to Type-C support as Pinephone Pro. One major issue with Pinebook Pro is that it can't limit input current based on what software wants. It consumes 12.5 W from Type-C port if it can (as long as voltage doesn't drop bellow 4.5V). This makes proper implentation of power delivery impossible. It's risky to connect PBP to regular USB-A ports on the computer due to this. The limit is 5× of what it should be for USB 2.0 port, and 2.8× more for USB 3.0 port. It will also not work well with Type-C docks, that need to reserve some power for other devices connected to the dock and thus tell PBP over power delivery protocol to limit input current to < 2.5 A.

Megi's media section :)

If you're a visual person, here's a bunch of random images/videos that I posted recently to #pinedev, that you might have missed if you don't follow the developer's chat. :)

Suspend/resume of Pinehone Pro with Power-Z attached – measuring current taken from Type-C connector with battery charger disabled, this is quite a good approximation of power needed in suspend to RAM
Some attempts to try to make Pinephone Pro consume as much power as possible – From my input current limiter tests.
Die photos from the factory investigation of a chip I fried while working on the Pinephone keyboard's firmware – It shows the path the desctructive current took through the chip during a latch-up.

Next steps

LCD is not running at 60Hz. It's only running at ~53Hz and it's not very easy to improve this. Just changing the pixel clock frequency breaks the display output. Timing configuration for the mode seems to not match what's configured to the display. Kernel previously set the clock rate to 66.3Mhz instead of 69Mhz requested by the mode. With precise clock being set, the display doesn't work at all. So this needs to be cleaned up a bit. Application note for configuring the display for a particular timing is not available, so this will be hard. Few hours of trying various changes so far led nowhere.

Rockchip Type-C phy probably needs some improvements with connector plug orientation handling for display port signals. Both orientations work for USB3, but not for displayport alt mode. There's some patch available from Rockchip, so maybe it improves things.