Dear all,
finally I wrote experimental support for 10-bit HDMI output on Allwinner H6, so HDR videos should render without any processing, directly to TV. Note, due to missing HW decoding driver features, only VP9 is rendered in 10-bit, while HEVC is still rendered in 8-bit. However, due to proper settings in HDMI output, it should be better colourwise anyway.
Please test.
Source: https://github.com/jernejsk/LibreELEC.tv/commits/h6-10bit
Update file: http://jernej.libreelec.tv/test/h6-10bit/
My understanding with DVFS is you have to switch the voltage first, then bump the clock.
For raising frequency yes. For lowering it, it's the other way around.
I guess I am wondering if you don't wait for the voltage ramp-up and you have adjusted the clock before the voltage is stablized would that cause SoC to crash (i.e. not enough voltage/current to support the higher clock rate).
You can easily adjust ramp up time in DT with regulator-ramp-delay. For testing purposes, you can set it to some ridiculous high number, like 100 ms.
If you check other interrupts, you'll notice that they are offset by 32 in regards to numbers in manual. First 32 interrupts are special.
Can you test some other frequency? IIRC it's possible to select opp through sysfs. If it doesn't matter which frequency is selected, as long as it's not switched, then the bug is in frequency switching code.
I have to give you big thank you for your patience in debugging this issue.
This also solves the Ethernet issue.
Great, I'll revert that.
Is there a reference document that indicates the voltages @ frequencies that should be used?
No, just values used in vendor (BSP) kernel. Another possibility would be code, which actually switches frequency.
Ethernet issue is related to commit f8e03eae5, reverted and it is working.
Can you try reverting https://github.com/LibreELEC/L…05b2a87387d72b21619a96da0 instead?
It seems to me this clock-latency-ns DT node is largely informational?
TBH I don't know. But waiting a bit more doesn't hurt much.
frakkin64 if you don't mind messing with DT, there are some differences between mainline and bsp worth testing. BSP DT has clock latency set to 2000000 and it's missing opp points for 1608 MHz and 1704 MHz. Would you mind testing this? It's all in sun50i-h6-cpu-opp.dtsi.
So it's either a combination of scheduler + iommu disabling, or it didn't run long enough, or it is frequency switching.
Frequency switching can be a bit tricky, true.
Can you trigger the config target via scripts/build, or do you usually do that outside of the LE build system?
Easiest way is to execute make ARCH=arm64 menuconfig in LE linux build folder and change whatever you want. Then you diff changes between .config in build folder and linux.aarch64.conf and pick changes that are of interest. Don't take all changes, there are some magic values, which are replaced by build script.
Note that this is just test, IOMMU benefits are big. It protects unallocated memory being used by HW (in other words, it prevents HW corrupting memory) and it allows any amount of free memory to be allocated to video decoding (otherwise only CMA memory can be used, which is limited in size).
I tested HEVC on H6 multiple times this week and it worked fine. Please test with some HEVC sample first. If that works, then it's most likely addon issue.
Thanks for testing. Can you also try with CONFIG_SUN50I_IOMMU disabled? Just to make sure IOMMU is not at fault.
I have one possible explanation - IOMMU. H6 driver doesn't have locking implemented in some functions, but other do. Without that, race conditions are possible when allocating and freeing memory during video decoding and rendering.
Updated patches are here: https://github.com/jernejsk/Li…e0e8645187224ebdee7aa57b1 They should apply to both, LE11 and LE12, branches.
Let me know if you need builded image.
Ok, thanks for testing. So official image (from OrangePi site) has same issue? If that's so, it's most likely design issue. I can borrow oscilloscope at some point and measure timings and voltage levels, just to see if software is properly configured. But that won't happen anytime soon.
Yeah, Kodi was updated 
ds
for the patch though, i see a bunch of numbered files in subdirectories in "projects\Allwinner\patches". Do I just create a new text file somewhere in there with the contents of your patch? Does it matter what I name it?
You can name it whatever you want, as long as it ends in .patch.
You can always do that, but there is no guarantee that it was noticed and fixed.
