Earlier this year, we announced our partnership with Flipper to support their next device, the Flipper One. Today we're zooming in on one problem we've been tackling: making USB-C DisplayPort Alternate Mode work properly, so that a single USB-C port can drive a display.

See it live in Prague!

Heading to OSS + ELC EU 2026? Stop by the ELC Tech Showcase in a couple of days to see a live demo on the Flipper One. Then come back here for the details of how we got there!

USB Power Delivery

The secret sauce to get USB Alternate Modes working is the USB power delivery protocol (USB-PD). As the name implies it is used to negotiate the voltage and current as well as the direction of the power. But apart from that, the protocol is also used to identify and set up the so-called USB-C Alternate Modes. Using these modes means that some pins on the connector are used for non-USB functionality.

How do USB Alternate Modes work?

To explain USB-C Alternate modes it is necessary to have a good understanding of the USB-C connector.

As you can see it has a total of 24 pins. Some functionality is intentionally assigned to multiple pins; for example, VBUS (voltage supply, red background) and GND (ground, black background) are on 4 pins in a mirrored setup. This way they always end up on the same position independent of the plug orientation. Having them multiple times is necessary anyway to allow the connector to carry enough current. Similarly, D+ and D- (green background) are available twice in the middle of the connector in a mirrored layout to always end up in the same position. Here only two pins are used and the other two are effectively ignored. These pins carry the USB2 signals and don't need special tricks to work (as long as the connector gets a proper physical connection).

For the RX and TX pins (yellow background), which carry USB3 and the Alternate Modes (AltMode), things work differently. They are not mirrored (which would result in half of the pins being unused). Instead the USB-C device is supposed to have the functionality of swapping them back to normal orientation with a switch circuit if the connector is plugged in the reverse direction. Obviously that means the device must be aware of the connector orientation in the first place. This is also figured out via the USB-PD protocol.

The USB-PD communication happens on one of the CC pins (blue background) with the other providing 5V even when VBUS carries a higher one. Last but not least the SBU pins are just for sideband and unused for simple USB. More on them later.

Now that the basic pinout of the USB-C connector is clear, the USB-PD protocol takes care of the following:

• figure out the connector orientation
• negotiate the data flow direction (which side is the host/gadget)
• negotiate the power flow direction and configuration
• negotiate the alternate and accessory modes

Once the AltMode negotiation is done by USB-PD, the hardware needs to multiplex the involved pins from the USB controller to the alternative function, e.g., DisplayPort (DP).

The Rockchip RK3588/RK3576 hardware setup

The Rockchip SoCs allow implementing this quite complex setup relatively easy from a hardware perspective. They come with a Synopsys DesignWare SuperSpeed USB 3.0 Controller, which is handled by the DWC3 driver and also used by many other SoCs. They also have a Synopsys DesignWare DisplayPort controller. Like any modern controllers involving fast IO, they need a physical layer (PHY) to generate the correct electrical signals. Here both of these controllers share a combined PHY (from now on called USBDP), which provides options for relatively free multiplexing of 4 differential pairs to either of these controllers. This allows doing the orientation swap and the multiplexing discussed in the previous section without any external components.

The only external component needed is a USB-PD controller (probably not integrated by Rockchip due to voltage isolation requirements). Thus a complete USB-C setup on Rockchip typically looks like this:

• USB-C's RX1, RX2, TX1, TX2 as well as SBU1 and SBU2 routed to USBDP
• D- and D+ routed to USB2 PHY
• CC1 and CC2 routed to an external USB-PD chip, e.g., fusb302
• power routing is out of scope for this blog post

There are different types of USB-PD controllers. Basically they can be divided into self-contained ones, which are typically found in laptops. These have a firmware, which contains a big state machine and automatically handles the USB-PD communication.

The alternative, which is usually found on Rockchip boards, is chips that do not communicate on their own. These chips need to be explicitly told what to do. The kernel contains a huge state machine called TCPM (Type-C Port Manager) that takes care of negotiating power, data, and AltModes. This article focuses on this hardware setup.

USB-PD Software Support

Basically all of the software lives in the kernel, which needs to know the hardware topology. On Rockchip platforms this is sourced from the device tree. For a working setup, quite a few things are needed. First of all, the kernel needs to know about the USB-C controller, which has the USB-C connector as a subnode with links to the different controllers involved:

&i2c2
	typec-portc@22 {
		compatible = "fcs,fusb302";
		reg = <22>;
		/* ... */

		connector {
			compatible = "usb-c-connector";
			data-role = "dual"; /* USB data can go both directions */
			power-role = "dual"; /* can receive or provide power */
			try-power-role = "source"; /* prefer providing power */
			/* ... */

			/* AltModes support on this connector */
			altmodes {
				displayport {
					/*
					 * Standard or Vendor ID
					 * 0xff01 = DisplayPort
					 */
					svid = /bits/ 16 <0xff01>;
					/*
					 * Vendor Defined Message Data Object
					 * This provides extra information about the DP implementation,
					 * such as the direction (output only in this case) or the supported
					 * pin configurations
					 */
					vdo = <0x00001c46>;
				};
			};

			ports {
				/* ... */
				port@0 {
					/* this links to the destination of the USB2 pins (USB2 PHY/controller) */
				};
				port@1 {
					/* this links to the destination of the RX1/RX2/TX1/TX2 pins (USBDP) */
				};
				port@2 {
					/* this links to the destination of the SBU pins (USBDP) */
				};
			};
		};
	};
};

The USBDP PHY, on the other hand, is also described in DT and looks like this:

usbdp_phy {
	mode-switch;
	orientation-switch;
	/* ... */

	ports {
		/* ... */

		port@0 {
			/* outgoing differential lanes */
		};

		port@1 {
			/* incoming connection from USB3 controller */
		};

		port@2 {
			/* incoming connection from DP controller */
		};

		port@3 {
			/* outgoing connection for DP aux (SBU) */
		};
	};
};

TCPM - Step 1

When a cable is connected to the board, the TCPM state machine gets going and tries to figure out how to handle it. The exact steps depend on the remote device, but will look similar to the diagram, which is from a Dell U2725QE. If anything goes wrong during this phase, USB-C AltModes will not be available. USB3 may or may not work depending on the exact problem. USB2 is independent and usually works. Issues can be debugged via a special log file available in debugfs. The exact path depends on the PD controller; in this example it can be found at /sys/kernel/debug/usb/tcpm-2-0022/log. Be aware that reading the file automatically clears it. At the end of this step, power and data roles have been negotiated. In other words, the following questions have been answered:

• Which sides provide power?
• Which voltage is being used?
• What's the maximum current?
• Which side is the USB host?

As you can see, it has nothing to do with AltModes, but this is a mandatory first step in the protocol.

TCPM - Step 2

After the initial setup took place, it is still possible to change things. For example the mentioned Dell display initially accepts any data role (DR) or power role (PR) and then asks for it to be swapped once the initial negotiation happened. This is also something that can be controlled from the Rockchip side, of course. For the first USB-C connector the control knob is /sys/class/typec/port0/data_role. The directory also contains other files possibly interesting for debugging problems.

TCPM - Step 3

Once everything has settled, TCPM will try to figure out extra capabilities, which work by requesting SVIDs (Standard or Vendor IDs) via vendor-defined messages (VDM). For this a second state machine runs on top of the basic one. Each alternate mode supported by the remote side is registered and can be found in /sys/class/typec/port0/port0-partner/port0-partner.*. Commonly found SVIDs are 0x8087 (Thunderbolt) and 0xff01 (DisplayPort).

Entering the AltModes results in a matching kernel driver being probed, which handles some things. For DisplayPort it is typec_displayport and results in an extra subdirectory displayport, which contains a few files with extra information:

• configuration - sink or source (Rockchip platform does not support DP input and thus source)
• pin_assignment - DP AltMode supports different pin modes, e.g. "D" (2x USB3, 2x DP)
• irq_hpd - hotplug detect interrupt (mostly relevant for DP multi-stream transport)
• hpd - hotplug detect state (should be "1" for a connected display, could be "0" when e.g., a display is not connected to a USB-C -> DP adapter)

Switching into DP AltMode also results in TCPM informing the mode-switch about the change. In case of Rockchip this is the USBDP (see DT snippet above). So that will take the pin assignment information and route the pins correctly to the DP and USB3 controller.

Apart from that HPD is interesting: On a normal DisplayPort connector, HPD is a physical pin. But with the USB-C DP AltMode there are not enough pins. Thus the HPD information is provided via the PD protocol using VDMs.

The DisplayPort controller

The Rockchip DP controller has a multiplexer on its HPD line, which allows to select between the hardware pin (as mentioned this is not available on USB-C) or getting the HPD status from a register that can be set in software. Thus for USB-C the multiplexer must be configured to get HPD from this register and then the USB-PD messages with DP hotplug info must be stored into the register.

In the vendor kernel, the muxes are configured by USBDP. This works, but brings an interesting problem: If nothing is connected, the whole DP controller can turn itself off. But writing into the mux requires that the DP controller is powered as the registers are in the same power domain as the DP controller itself. This is solved by following the design Qualcomm and MediaTek already use: The USB-C controller sets itself as a DRM bridge, which forwards hotplug signals to the next bridge in the chain (USBDP), which does the same. This way the software events lands in the driver for the DP controller, which can power on the controller before configuring the mux.

Once the hotplug signal is there, the DP controller will try to establish a link. In this phase it will use the DP auxiliary channel (routed via USB-C's SBU pins) to do bi-directional communication with the display. At this point things are no longer USB-C specific and it is no different from a normal DP connection. If the DP AUX link test succeeded, /sys/class/drm/card1-DP-1/status will show "connected".

At this point the EDID data will also be queried from the display and the available modes should be available in /sys/class/drm/card1-DP-1/modes

Interesting side issues

While working on the patches to get all of this implemented, a few interesting problems turned up:

1. Changing the mux configuration and/or powering parts of the PHY requires re-initializing the USBDP PHY, which breaks running connections. This is not a big deal when the mode changes, which usually means a device is (un)plugged and there is no running connection.
   
   But it means that the DP side of the USBDP PHY must be powered on if the current USB-C hardware negotiated it via USB-PD even when the software is currently not using it. Otherwise enabling the DP side later on would kill an active USB connection.
   
   For example the following scenario would be really bad without enabling the DP side ahead of time:
   
   Step 1: you connect a USB-C dock with USB and HDMI ports
   
   Step 2: you connect a disk to USB
   
   Step 3: you mount the disk and copy some files
   
   Step 4: you connect a display to the dock's HDMI port
   
   Resetting the USBDP PHY at this point to enable DP functionality would reset the USB connection and abort the ongoing data transfer. To avoid this it is necessary to enable DP when the dock is connected and before USB is actively being used.
   
   
2. Apart from that, restarting the USBDP PHY while the DWC3 USB controller is already running may result in a bringup failure. This is specific to the Rockchip integration, but unfortunately there is no proper errata or TRM description for this behavior. After some trial-and-error cycles, it turned out that the PHY can be reliably restarted when the USB3 controller's interface is kept in reset state during the PHY reset.
   
   
3. Some modes (i.e., resolutions at specific refresh rates) do not work properly. This is independent of this work and a problem with the video controller not being able to come up with a matching pixel clock. The further it diverts, the higher the chance of the display not accepting the incoming video stream. This problem is independent of USB-C and would also appear on boards using the DP controller with a native DP connector. It needs to be worked on separately.

When will this arrive in the mainline kernel?

You can check out the rockchip-devel branch in our git repository. It contains all the necessary bits for ArmSom's Sige 5.

All changes on the USB controller side have reached the mainline kernel. Changes for the USBDP PHY and the DRM side have been sent and are currently in the review phase. How long it takes depends a lot on the upstream maintainers' review capacity. If you want to speed things up, it helps tremendously to assist the community with testing and reviews. At the point of this blog post the patches for the PHY got split into 4 separate series in addition to the DP controller series:

• PATCHv15 for part 1 of USBDP PHY changes
• PATCHv15 for part 2 of USBDP PHY changes
• PATCHv16 for new Rockchip specific DWC3 glue driver
• PATCHv16 for part 3 of USBDP PHY changes
• PATCHv11 series for preparing DP controller