Pinephone Pro – Type C port support
Since November last year, I've been working on and off on understanding and
implementing support for Type-C port on Pinephone Pro. It's a complex physical
interface, so it was hard to understand how everything fits together on the
Rockchip platform without going through a lot of drivers and without
understanding the USB Type-C specification. I already had some grasp of the
Type-C spec from implementing support for the similar functionality on original
So my approach with Pinephone Pro was to find all existing drivers that are
related to supporting all the features of the Type-C port on RK3399 and read
them top to bottom.
This gave me a nice overview of how everything can fit together eventually,
and also what's missing in mainline Linux compared to Rockchip BSP Linux.
I was also interested in making Type-C support (which includes power
negotiation, charging and supplying power, USB data role switching, Display Port
alternate mode, power delivery and BC1.2 spec support, and similar things) work
as best as possible as soon as possible, so that when Pinephone Pro got to a
wider audience, all this worked as well as was possible to achieve with my
limited resources in a few weaks before I was going to winter holidays.
Once I understood the drivers and their supposed interactions, I needed to
make them talk together with as little code changes as possible. This meant
using their existing interfaces.
Mainline Linux is moving in the direction of using in-kernel Type-C
interfaces for controlling the drivers that need to listen to the Type-C port
manager driver. Most drivers on the Rockchip platform don't support these
interfaces, and even if they did, these interfaces currently don't support
controlling multiple devices at once, which is necessary on this particular
platform. Instead, Rockchip drivers mostly use
(bus, really) to communicate among each other.
So as a quick stop-gap solution I decided to write the
typec-extcon driver, which adapts Type-C mux/switch/role interfaces
into extcon ones the existing drivers understand. This made it possible to
quickly wire things things together, and be able to start testing the hardware,
and finding bugs.
It works semi-reasonably now. Interdriver communication is now solid, with my
latest kernel releases for Pinephone Pro.
That doesn't mean there are no issues. The drivers themselves, that are
already mainline, have several issues:
- fusb302 driver is not very reliable, it sometimes stops detecting all
activity on CC pins until reboot, etc. It also misdetects some host devices.
I already upstreamed one fix to a bug that was preventing the driver from
notifying change from host->peripheral mode.
- USB driver powers up phy on boot, and never shuts it down. This makes it
impossible to re-configure the type-c phy to switch superspeed signals for the
reverse orientation of the type-c plug. So things like USB-SS and DP Alt mode
work only in normal plug orientation.
- Displayport driver doesn't support higher bitrate modes. It barely supports
1080p@60 so you can't use higher resolutions on external monitor connected to
USB driver will probably be reasonably easy to fix. BSP driver does things
correctly, so it can serve as an inspiration.
fusb302 will be tough to fix. The chip is not horribly complicated, but TCPM
driver fusb302 serves as a backend to is, and fusb302's problem is more in the
fact that it's quite low level, so you're setting comparators, dealing with
D/A converters, voltages, pull-up resistor values, etc. But the higher level
deals with abstract states on the CC pins. So far, issues with the driver
revolve around misdetection of states of CC pins, and infinite loops, or
unhandled states due to that.
Once the individual drivers are made to behave properly, it will be time to
think about mainlining this work. I have some plan that involves waiting for multi
consumer support for in-kernel Type-C interfaces, that is being proposed on
the USB mailing list to be reviewed and accepted. This patchset will help solve
the driver communication issue, in an upstreamable way, by allowing TCPM to talk
to multiple drivers at once. The drivers will also need to be adapted to use the
proper interfaces. This will be fairly easy at that point.
Once all that is done, it will be possible to upstream the whole work.
In the meantime there are drivers to fix.
Fixing up fusb302 is the highest priority. Identifying and solving issues in
the wild, from people using the interim solution will be another one.
When working on anx7688 driver I was able to stuff it with a lot of useful
debug output, that was then all printed to the kernel log. This allowed me to
just ask people to send me their dmesg output, when I noticed someone had
issues with things related to Type-C port, and I would not need much else from
them. I gradually improved the debug output as I tracked the known issues to
be able to understand them better as more people reported issues and sent the
logs. This was nice, and helped stabilize the Type-C support on original
Compared to that, Pinephone Pro seems quite hopeless. There's almost
0 useful output in kernel log itself, useful logs are hidden deep in debugfs
and sysfs in several places, etc. It's very time consuming to do debugging with
users, because of that. Reading the logs is hader too, becuase they are very
verbose and low-level, and are split, so there's no single timeline to skim
through. They need to be cross-references manually.
I decided to not add to this difficulty, and only help users who will be
able to install and run my exact kernel build for debugging. It's just too much
effort to also track what subset of my patches some unknown version of the
downstream Linux distribution's kernel, with no existing git tree to diff
against, decided to include.
It will take maybe 4 kernel releases to clean up for the upstreaming
I'll step away from this work for a while to prepare basic device tree for
Pinephone Pro and submit it mainline. Otherwise things will start getting messy
pretty soon with multiple kernel trees being actively used by distributions and
no shared base device tree upstream.