warloxx

In the end the fix seemed to be fairly simple. The function fusb302_extcon_register that was added by this patch was just called to early and was checking for usb_ss_present and dp_present to advertise the capabilities, but at that point those values where not initialized yet. So the extcon device did not have any capabilities resulting in -EPERM / "get superspeed property failed". The following patch moves the initialization until after the values are initialized. This now successfully works with a usb-c to DisplayPort cable. Although it seems to work only with some monitors. My Dell U2414H did not work, while it worked with LG 27GL850. The Dell would cause this: However that sounds like its now a displayport problem, no longer a usb alt mode problem. Getting my type-c monitor with touch interface to work took some more work. This monitor prefers to connect in a usb+DP mode. And the code in drivers/usb/typec/altmodes/displayport.c could not get a matching pin configuration between port and device. The display returned a vdo of 0xC0045 for the displayport alt mode. According to this 3rd party description https://www.st.com/resource/en/technical_article/ta0356-usb-typec-and-power-delivery-displayport-alternate-mode-stmicroelectronics.pdf this essentially means: Type-C receptacle with pin modes C and D supported as a UFP_D device. The port was registered with a vdo of 0x1C1C46 Type-C receptacle with pin modes C, D and E supported as a DFP_D device. The current code of displayport.c was not able to make a match between these even though they are compatible. It seemed to not correctly interpret the DFP_D and UFP_D bitmasks and ignoring the bit indicating receptacle or plug, which flips the meaning of those masks. With the following patch the MB16AMT monitor does now correctly get a pinmode of D (2 lanes USB + 2 lanes DP) since it also has the DP_STATUS_PREFER_MULTI_FUNC set. The USB3 interface shows up as a hub and seems to provide a DisplayLink usb device, as backup to DP I guess... The touch HID device is connected through the USB2 connection. With the fix from above, patches (like this one) that check the reverse mapping and or like this fuse302-add-extcon.patch does, registering a port with identical pinmaps for UFP_D and DFP_D even though only one mode is actually supported (~line 292 fuse302-add-extcon.patch), are no longer necessary? Anyway, so far everything seems to work now regarding the alt mode switching . Just some weirdness with DP and specific monitors.

I tried your patches to get displayport over usb-c working on nanopct4. Compiled an armbian image with mainline kernel (5.17.14) ./compile.sh docker BOARD=nanopct4 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=yes DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base COMPRESS_OUTPUTIMAGE=sha,gpg,img rk3399-nanopc-t4-type-c-modeling.patch did apply just fine, but fusb302-add-extcon.patch I had to slightly modify your patches because of changes in mainline since 5.6.x The last hunk I just updated so it would apply since there where some changes in the same lines. And the function fwnode_graph_get_remote_node was removed in this commit (https://github.com/torvalds/linux/commit/c49eea6ffec626c059ace085fce1bf501b05dbc7) so I applied the same workaround as in the commit to now use fwnode_graph_get_endpoint_by_id Once everything is booted up I get: dmesg | grep typec [ 9.123527] typec_fusb302 4-0022: DisplayPort altmode registered [ 9.191412] rockchip-typec-phy ff7c0000.phy: get polarity property failed DisplayPort altmode registered looks to me that it at least did something. Once I plugin the type-c cable however I just get this: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn The screen I test with is: MB16AMT This is a touchscreen as well, so it will try to use combined displayport+usb mode to get it all working on a single cable (confirmed working on win10 laptop). Is this mode not covered by you patches? Tried also a "normal" just displayport display with an typec to displayport cable. Then I got this: [ 73.642298] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn [ 73.933028] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn [ 73.940772] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Connected, not enabled. Enabling cdn [ 74.114884] rockchip-typec-phy ff7c0000.phy: get superspeed property failed [ 74.114898] phy phy-ff7c0000.phy.8: phy poweron failed --> -1 [ 74.114913] cdn-dp fec00000.dp: [drm:cdn_dp_enable [rockchipdrm]] *ERROR* phy power on failed: -1 [ 74.114982] cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] *ERROR* Enable dp failed -1 Flipping the type-c connector around also did not change anything (on either display). I guess something is still wrong here. I also did one test where I build the image without the add-fusb30x-driver.patch, so the armbian fuse302 driver could not have interfered here. And in both tests the behavior was the same. Any tips where I could start to dig?