What aspects of hardware is supported under AMLogic mainline at the moment.

It's a "War and Peace" explanation, but here goes:

GXBB (S905) GXL (S905X/D/W) GXM (S912) G12A (S905X2) G12B (S922X/A311D) and SM1 (S905X3) devices are "supported" in the 5.5 kernel but the numer of device-trees that have been submitted is still relatively small. I've been upstreaming remote control drivers and have some more device-trees to submit for 5.6 (based on whoever sent me samples). Upstreaming device-trees is a little slow as the maintainers are fastidious about getting the details correct (as they should be, it's what makes the upstream kernel maintainable). So "guess the working dtb" still exists on box devices, but SBC devices have an improved "out of box" experience. The mainline kernel is much better structured and more copy/paste to work with than the BSP kernel .. the proof is non-coding people like me can create working device-trees (VIM3 took me about 15 mins, VIM3L about 5 mins).

G12/SM1 have working HDMI and S/PDIF PCM audio in Linux 5.5, GXBB, GXL and GXM have working HDMI and S/PDIF PCM audio (not merged but should go upstream soon, hopefully for Linux 5.6). Some work is needed for official multi-channel and pass-through support but this will take time as the changes touch 3-4 different vendor SoC platforms that are using the dw-hdmi drivers and the ASoC tree moves slowly. Until then work-in-progress multi-channel patches exist and PCM works well.

The VDEC is the primary problem component right now. Since the summer ended the upstream APIs for V4L2 evolved and compliance work to adapt the existing code (which worked reasonably well) has taken place; H264, MPEG2, VP9 are revised and submitted upstream. HEVC is still missing and is "complicated" due to differences in the implementation for GXBB, GXL/GXM and G12 and bugs in Amlogic's firmware blobs. Kodi (19) now defaults to software-decode for anything without hardware support in the stateful V4L2 code path where it just crashed before. This makes the current gaps in VDEC support less noticeable and since G12A and up can software decode 1080p media users with those devices can simply disable hardware decode until more things are done (older weaker devices aren't so lucky). 4K media remains out of reach for now as it's all HEVC based and no ARM devices can decode that in software. The recent VDEC changes require adaptations in FFMpeg and Kodi which I hoped would have started already, but people have real jobs and lives and those developers simply haven't had time to start. It's not major rework, so I'm hoping it can be done soon-ish. The same GBM/V4L2 stateful code path is also used by Raspberry Pi who are now starting to work on the overdue MMAL removal in Kodi so they'll join the party. In the long-term sharing of stateless code-paths with Pi devices means the "Amlogic" implementation in Kodi will be massively proven and very well maintained. Samsung (Exynos) devices can also use the same path.

10-bit support is now mostly done but the patches are dependent on other series in the linux-media tree and it's not really possible (beyond my git fu) to come up with a single kernel that supports all the audio bits and 10-bit video .. but this should resolve naturally once the 5.6 merge window completes and branches have been combined. 10-bit support is the main precursor to HDR. Kodi now has bare-bones support for HDR (not all patches merged) and Allwinner and Rockchip which have a more complete V4L2 (stateless) code-path in FFMpeg than Amlogic/RPi (stateful) are using it, although 8-bit only until the common 10-bit patches merge. We worked with Intel in September/October to help get other bits of HDR plumbing merged to the kernel and there are now some Intel staff working part-time on HDR support in Kodi, though most of their work is done behind the scenes (their choice). Most of the support for AFBC and the older Amlogic proprietary compression scheme is done (Panfrost supports, not Lima) but some further work is needed on the VDEC side before CMA memory reservations can be reduced. At the moment a loony 896MB allocation is needed for 4K on all Amlogc devices which prevents 1GB devices from doing 4K. Once more pieces of the AFBC puzzle are complete that will be resolved.

GXM devices are now using Panfrost and GXBB/GXL are using lima. Both drivers continue to mature but both are merged upstream and well beyond the point where we can use them reliably with confidence. Kwiboo has just switched Rockchip images to them in the just-merged mainline bump (no more BSP kernel there either). Sadly Allwinner (also mainline now) has some quirks to resolve before those images can make the same move. We did finally discover a source for the T820 mali Linux blobs (not Amlogic) but while I have private versions in 32-bit arm format the redistributable ones are aarch64 only which isn't useful for LE which runs 32-bit userspace. As Panfrost is the way forwards anyway I stopped nagging the source for the arm versions and for severals reasons (one of which is legal) I have no plans to leak them. It's not clear when Panfrost developers will turn their attentions to the newer Bifrost GPUs but we have the blobs for those so there's no rush.

Hardware deinterlace is missing for all V4L2 hardware but jernej is working on support for Allwinner which will prototype how to integrate hardware deinterlacers into the kernel V4L2 chain; and then RK/Amlogic can adopt/reuse the same approach. Amlogic will need a rewritten deinterlace driver as the BSP one is ~20k lines of code due to lots of repeating boilerplate and support for deinterlace options that no media actually uses. Our current estimation is a rewrite can achieve the essential capabilties with an ~80% reduction in code (a similar percentage to the VDEC). Some recent tweaks in Kodi software deinterlace support have also been beneficial and while hardware deinterlace is best, the software support is no longer bad, and quite useable, so this isn't the grave ommission it used to be.

3D isn't on anyone's agenda so will have to be done through community contribution. The challenge is (will be) that the only Linux hardware that ever supported 3D well is the Raspberry Pi, so anyone who cares about 3D support bought one to avoid coding it themselves, and now that 3D is mostly a dead format it's unlikely someone will be inspired enough to spend time on it .. but never say never.

Ethernet support is generally good and some recent changes should help to resolve some lurking gremlins with clone chipsets and older devices with bad hardware implementations .. subject to the right device-tree with the right options configured. Tuning can now be done via device-tree, instead of needing hacks in actual code.

WiFi support is generally very good and anything with a Broadcom/Ampak SDIO module should just work (including the latest BCM4359 chips which have just been submitted upstream). Realtek chips are still a bit random and we have no plans to add out-of-tree vendor binaries to Amlogic releases (or Rockchip, or Allwinner) as our experience with them on RPi/Generic is they break with each kernel bump and are a pain in the arse. There is work in the linux-wireless tree to upstream proper Realtek drivers, but focussed on current chipsets not the older stuff. I'd guess it's another scenario where support for older chipsets will be back-filled around the time there aren't many devices in active use that need them. The main driver gaps for Amlogic are the SSV6051P which has sources that are so bad nobody wants to port them (we tried, the code is hideous, we gave up) and the manufacturer went bust in 2016 so there's no documentation, and the other chip (908XS?) which is a Realtek clone but with some hardware register differences so you can't just add the different IDs to the (out of tree, thus bad) Realtek driver. There are no sources for that chip (only a pre-compiled driver blob for 3.14 kernel) so it can die in fire.

DVB drivers are .. meh. I've made repeated attempts to encourage afl1 to upstream his DVB code but his initial attempt to submit pin-control changes didn't use scripts/checkpatch.pl or scripts/get-maintainers.pl and as a result it hasn't been seen or reviewed or merged. I've pointed out the error and offered to resubmit on his behalf .. but with no response. The original BSP driver source he started working from has no GPL license and isn't well structured by mainline standards so there will be a ton of critique from maintainers and he's clearly not interested. I'm still working on some other possible sources for DVB rewrites, but I expect this to take time. I would advocate that DVB users purchase a USB tuner or get a Raspberry Pi 3B+ with DVB HAT to stick somewhere in the network as they're cheap and well supported with usptream drivers.

For SBC devices that want to boot mainline u-boot, all the Odroid and Khadas boards are supported now along with various older GXBB boards, and between them you have prior-art to add new boards from. U-boot 2020.01 has VIM3 support and I sent VIM3L changes which will be included in u-boot 2020.04, but the patches backport. I've also done some work for WeTek Hub/Play2 support but GXBB cannot boot mainline u-boot from emmc (GXBB checks for boot firmware in the first sector which conflicts with MBR tables, which is why the BSP u-boot has some crazy not-upstreamable custom partition scheme to workaround the SoC design mistake). WeTek users who previously installed LE to emmc (the only Amlogic box devices we have ever supported emmc install on) will either need to run the "box" image from SD card, or can boot it to zero the emmc out (which then allows mainline u-boot to run from SD card) and can then format the emmc to use as /storage (it all sounds more complicated than the 10 mins work it actually is). There is sub-zero interest for supporting mainline u-boot or "internal" emmc installs on generic boxes because too many Amlogic devices use cheap RAM chips that require twaeked timing data in boot firmware, and this makes it near-impossible to support a wide range of boxes with a common u-boot and FIP source. The mainline AMLGX and AMLG12 "box" images boot from SD card easily and the performance difference is negligible with most hardware and a decent SD card. Internal installs are a proven support minefield and we have better things to expend effort upon.

In summary.. the main barrier for a useable daily-driver 1080p device is the HEVC codec and rework in FFMpeg/Kodi. The core SBC devices we prefer over box devices now have very stable core platform support. More exotic 4K, 10-bit and then HDR things are still some months away - largely as the driver code is common to several SoC platforms. Kodi 19 has been pulled forwards to kick-start the Python3 migration so GBM/V4L2 changes will push back to Kodi 20 which will be a shorter sprint and probably still close to the original Kodi 19 dates (not that we ever named dates) but we'll do some kind of official rolling LE alpha in the backround until then. I'm not going to guess at "finished" dates (there's always something to do) but I see the glass is well over half-full now. Others will choose to see it half-empty, but you can't please everyone. If you want to comment, please remember the total number of people working on the mainline future of the Amlogic platform remains small and positive comments are always more inspiring to receive than pithy ones. I'm optimistic that 2020 will be a good year for Amlogic, but we're still in the first week of January. Have a Happy New Year

The commit message is misleadingly worded. VP9 and HEVC share some common pluming which is provided by that commiit. In the same series you also have the full VP9 decoder. HEVC is still missing from the line-up. We are now in the odd situation of having the firmware that was missing a few months ago, but now the driver is absent. Previous patches that added HEVC support are not aligned to the updated firmware and recent compliance changes in APIs .. so rework is needed. Google (who is funding most of the current development) cares most about H264 and VP9 so those are being done first (annoyingly).