Hugh Cole-Baker

Hello, nanopc t4 folks,
 
Some, not so long time ago, I worked on fusb302.ko driver and device tree improvements in order to make USB Type-C port working properly in the mainline 5.* kernel. I managed to get DisplayPort over type-C + some general type-c handling improved before my board simply died. Unfortunately, I was not able to finish all the planned work and cannot continue further  However, I guess, working DP is already fairly good achievement that might be interesting for many of us. Hereby, I want to publish some patches to the mainline!!! driver and device tree that add missing functionality, so one can get DP+type-C working on NanoPC T4 (and all RK3399 based boards with Fairchild FUSB302 chip for PD with relatively small DT adjustments). I would be very happy if results of my work can be helpful to others and extremely happy if there any volunteers, who are willing to continue work on this subject. My primary goal was to contribute to Armbian, first of all, with a potential mainline repo contribution. What was added:
Extcon notifications support (type-c related cables) in the stock fusb302 driver (developed by Google folks, but also used by Intel  if I understand correctly) DisplayPort altmode is registered automatically, if device tree has proper modelling for that DisplayPort altmode is entered as soon as DP cable connection is detected (both DP+USB3.0 and DP only pin assignments are supported)  DisplayPort altmode is handled by the unified DP altmode driver rather than custom out-of-tree PD chip driver "connector" node modelling in the device tree according to the mainline kernel docs and modern requirements fusb node phandle is still specified as extcon source for Rockchip's proprietary drivers, however, last can be easily adjusted to resolve extcon directly from connector node link (as soon as extcon property is declared as deprecated for all new development). fusb302 driver is now correctly linked to dwc3 driver which provides role_switch functionality (+1 step to correct "Dual Role" mode handling based on the cable detection). This also eliminates annoying error message in the boot log: "OF: graph: no port node found in /i2c@ff3d0000/typec-portc@22"  
Please, also notice that type-c mode is forced to Host as in the most of rk3399 based SBC dtbs presently. This is rather a workaround for such boards, than a permanent solution, until all necessary bits are developed for correct role switching in the drivers. I kindly ask some NanoPC T4 owners to build mainline kernel with my patches and test whether expected functionality also works for you. Those patches apply to linux kernel since 5.6 when I started to work, but should also apply to way earlier versions according to my brief analysis of kernel commits history.
 
fusb302-add-extcon.patch rk3399-nanopc-t4-type-c-modeling.patch

A couple of other reasons I can think of why it wouldn't work: Does the user you're running ffmpeg as have write permission on /dev/video*,  /dev/media* and /dev/dri/card* devices? And did the compile time checks for v4l2_request support in FFmpeg pass? (you need to see v4l2_request under "External libraries providing hardware acceleration:", and h264_v4l2request under "Enabled hwaccels:", in the output of FFmpeg's configure script when you're compiling it). For the FFmpeg configure checks to pass, AFAIK you need the kernel headers from a recent kernel with v4l2-request support installed, e.g. kernel v5.6.

Sure, I was thinking about it.
Feeling motivated by your message  I will do that tonight

@piter75 Are you planning to send the ATF "switch power domains on before reset" patch upstream to https://review.trustedfirmware.org/ ? It fixes the issue with mainline ATF + Linux where Linux will hang after rebooting; I have tested the patch with my own custom build of Debian and it now reboots 100% successfully. It would be really useful for all mainline distros if it was applied to mainline ATF.