jernej

@XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.

You can try with (but no guarantee) in cpu0 node:
assigned-clocks = <&ccu CLK_CPUX>; assigned-clock-rates = <1080000000>; Safe default is set in SPL (one of the first things that's is done).
Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.

Check ohci, ehci and usbphy nodes in my DT: https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts#L134 and https://github.com/jernejsk/linux-1/blob/h616-hdmi/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi. You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too.
Note that these are developer level instructions - I don't plan to write more detailed steps.

that gets sorted out usually very late, when a lot of other features are already working.
 
Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later.
In short - several of these messages will probably stay in later, more complete kernel.

It's possible to make it work if you enable all USB nodes in DT. It seems like some HW quirk.

This happens on all SoCs with DE2 or newer (A83t or newer SoC). Most SoCs have only one capable plane which can display YUV formats and it's always below current framebuffer, so that "workaround" (which imo is not workaround, but just part of configuration) is always needed in your use case. Note that having video plane below UI plane is actually desired for video players - UI plane has alpha channel which makes window with video transparent.

Good summary, let me clear some things.
Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API.
Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline.
Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test.
H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work.
 
Maybe you can update your text, so we have current state overview in single post.
 

Good summary, let me clear some things.
Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API.
Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline.
Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test.
H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work.
 
Maybe you can update your text, so we have current state overview in single post.
 

If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): https://github.com/jernejsk/linux-1/tree/h616-hdmi (take branch as-is, USB works too)

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

Good thing is that things are coming together slowly. There is a hack to make USB work and first part of display stack started to work (not usable yet).

I regularly delete my branches because all work is eventually merged to  https://github.com/LibreELEC/LibreELEC.tv (you quoted quiet old post).
 
But as @Werner said, H616 is not exactly the same as H6 regarding display stuff so it needs quiet a lot of work. Cedrus will be probably easy, but that comes after display stack.

I haven't build Armbian for some time now, I'm just the guy who works on upstream U-Boot and Linux support for H616. I build all components separately and then manually put them together.

Here is fixed v2 version: https://github.com/jernejsk/u-boot/commits/h616-v2
 
Note - it's not finished yet, so it will still change (force pushes).

Here is fixed v2 version: https://github.com/jernejsk/u-boot/commits/h616-v2
 
Note - it's not finished yet, so it will still change (force pushes).

@valantissue is more complicated than just some config option. Currently U-Boot doesn't support voltage regulators and rely on ATF to enable them (A64 has HDMI voltage supply pin). Logic in ATF will turn on all referenced voltage regulators, which is mostly fine. Issue is in word "mostly" - this logic will prevent ethernet PHY to power on correctly on OrangePi 3. Distros must decide what is lesser evil for time being, having no HDMI and ethernet in U-Boot or having no ethernet in Linux on OrangePi 3 (I didn't check what Armbian does exactly). Situation was discussed with maintainers and consensus is to implement voltage regulator driver in U-Boot, but that will take time. In the mean time, ATF could be updated with a improvement, which would temporary solve both situations, but I didn't find any patch for that yet.

T95 needs different configuration of DRAM driver. Quick and dirty T95 U-Boot port with appropriate defconfig can be found here: https://github.com/jernejsk/u-boot/commits/t95

I just updated that branch, now it can boot normally from SD card.
 
You'll also need TF-A and Linux to make it usable:
https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP
https://github.com/apritzel/linux/commits/h616-WIP
 
UART, ethernet and SD card already work, so it already works good enough for headless server...

I just updated that branch, now it can boot normally from SD card.
 
You'll also need TF-A and Linux to make it usable:
https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP
https://github.com/apritzel/linux/commits/h616-WIP
 
UART, ethernet and SD card already work, so it already works good enough for headless server...

Me too. I just tested it last week and it felt much smoother than OPi3. For example, ~125 MiB file is consistently transferred in ~2 seconds on pineh64, while on OPi3 can also sometimes takes 2 seconds, but most of the time 8-14 seconds (all via scp).
Why do you think so? AFAICT almost everything is mainlined, with wifi patch merged yesterday and bluetooth not yet, but patches exist. On the other hand, OPi3 still requires several out-of-tree patches for ethernet due to unusual ethernet phy power design.

Note that @Kwiboo's ffmpeg is assuming that kernel is patched with some out-of-tree patches (you can find them in LibreELEC build system). For example, if you remove this commit, output should be much better, but that would mean that interlaced videos will be decoded incorrectly. Good news is that with Linux 5.10 H264 API will be aligned and no out-of-tree patches will be necessary anymore.

Basically yes. Note that kernel patches are only for improvements - fixing decoding issues. At least H264 API should be promoted to stable with kernel 5.10, maybe others too.
 
Any player which uses ffmpeg directly should be able to benefit from those patches. AFAIK mpv needs only one simple patch in order to use this chain. I have no idea about VLC internals so I can't say much about it. About VAAPI - request API (Cedrus implements it for decoding) is similar in terms of requirements and features to VAAPI so Bootlin created simple library to expose it. That way they could use any VAAPI capable player. However, some codec interfaces changed considerably from those times and Bootlin didn't invest any time to update this library, so it's not very useful ATM unless you know how to fix it. I know that some people has still interest in that library so I imagine it will be forked/updated once api stabilizes further.
 
Note that there is one hidden issue. As long as you play video in native size, all is well. If you want to scale it then you might get a lot of dropped frames. Issue here is how you do scaling. It's pretty intense process for CPU so you should avoid that at any cost. Unfortunately, VLC with VAAPI translation library did just that. Second option is to go with GPU. IIUC it was impossible to do with binary drivers due to missing import buffer functions, but with mesa it should work now (didn't try it myself). Note that mali400 may still be limiting factor for some cases. Another approach is to use dedicated HW cores. For example, deinterlace core on H3 can be used for scaling only (with few driver tweaks). Downside of this is that scaling process depends on SoC. This would be different even for Allwinner SoCs (not all SoCs have deinterlacer). Most efficient approach (used in LibreELEC) is to use DRM planes - you instruct display engine how to scale and crop it and where on screen to render it. However, I'm not sure if this can work on X11 at all. Wayland should be able to pull this off IIUC.
 
Disclaimer: I don't care about desktop on ARM boards so I didn't do many experiments in this regard and I don't plan to work on improving desktop experience. LE runs without any desktop on ARM boards. Note that I also don't plan to work on any player except ffmpeg/Kodi combo.

Note that ffmpeg patches for request API are important - without patched ffmpeg, all kernel patches have no meaning. Second important thing is that LibreELEC runs Kodi without X11 for ARM boards - this allows to use display more efficiently. On X11 it would be needed to render video through GPU which is less efficient. Note that I never actually tried that.