My 5.10 kernel is posted now on Github. Tested (very very briefly) on Android 11 AOSP as well as (very extensively) on Debian Bullseye and it seems to work still. Also going to 5.10 also appears to have fixed the crash at reboot bug. Compared to the 5.9 kernel I also added the battery driver, the joystick driver, and attached the upstream crypto hardware driver. To my knowledge the only hardware that isn't really working still is the hardware encoder; fortunately as best I can tell it's identical to the rk3399 which is upstream with a "quirk". Assuming I can figure out how to add the quirk it should be able to get the hardware decoder/encoder working. Aside from the video codec I think this is more or less what I'm going to roll with, and since 5.10 is LTS I'm going to stick with it for a while. On to now figure out the wifi, audio and sleep problems with Android.
https://github.com/macromorgan/odroid_g ... ux_android
Panfrost (upstream driver)
Joystick (hardkernel driver, could theoretically switch to upstream driver)
Crypto (upstream driver)
Wifi (out of tree driver)
Audio (rockchip driver)
RGA (upstream driver)
battery/charger (rockchip driver, could [with much effort] switch to a simple upstream driver)
hw video codec (will attempt to use upstream)
Also note that I'm going to delete my gits for the non Android kernel. No point in maintaining multiple ones since it's more or less the same. Lastly, Bifrost chips aren't yet supported on X11 (a Mesa shortcoming); if you want to test Bifrost use Wayland or Android.
edit: just added support for Hantro. Looks like the iommu fixes are only needed to support H265 on the PX30, since the upstream codec doesn't support that anyway I just added it to the devicetree. No dmesg errors and it creates a /dev/video1 and /dev/video2 device (video0 is the upstreamed RGA). So assuming that actually works it means 5.10 should support EVERYTHING hardware wise now. Suspend is mostly working now too with 2 exceptions... the dwc2 driver doesn't like it (won't re-init the USB devices after wake from suspend) and the esp8089 crashes on resume. I assume in the case of the esp8089 it's because it doesn't like being compiled into the kernel and needs to be unloaded before suspend/reloaded after suspend. I'll see if I can figure out the USB problem after suspend, then it's basically just bugfix and maintenance mode at this point.