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.
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. :)
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.