Both of the topics below come from playing around with a SPI-attached LCD display on an Odroid C4. I’m hoping they may be of general enough interest, or be helpful to more than just the C4, that the CoreELEC developers might entertain them.
For one of them, I can point to some device driver code specifically (though it may be part of a larger patch set). I know less about the second topic.
Thanks in advance!
Matt
SPI Performance
At the moment, I have some evidence that the C4 is underperforming an RPi3 on its SPI interface. User odroid on the Odroid user forum responded with this post:
That change indeed does not appear to be part of CoreELEC/linux-amlog’s meson_spicc_setup_pio_burst() function. As I mentioned above, the change is no doubt more widespread than just those lines, and I don’t know how extensive it is.
Hardware-based PWM
At the moment, RPi.GPIO-Odroid uses a pthreads approach for software control of PWM. Awesometic (joshua.yang) is willing to update that code to make use of the C4’s hardware PWM, but he pointed out some mismatches in CoreELEC versus Hardkernel’s Ubuntu in that regard.
That change indeed does not appear to be part of CoreELEC/linux-amlog’s meson_spicc_setup_pio_burst() function. As I mentioned above, the change is no doubt more widespread than just those lines, and I don’t know how extensive it is.
Looks like the change in question originated in a patch for Odroid-N2:
That change indeed does not appear to be part of CoreELEC/linux-amlog’s meson_spicc_setup_pio_burst() function.
I tried Hardkernel’s build of Ubuntu 20.04 on the C4 this evening.
I’m not entirely sure that the force64b option is getting to the spi_meson_spicc module. I edited /etc/modules to include it and rebooted, but the module was getting loaded prior to that change. (I also cannot successfully unload it via modprobe -r, but perhaps that is normal for some modules.)
Anyway, no real change to report in luma.example’s bounce.by demonstration – it’s still achieving ~8 FPS.
We have found the root cause and have made a patch for fixing that.
Finally, we can see 31~32 fps for the bounce.py example with 72MHz SPI bus speed. Please see the below video.
The kernel including this patch will be released in the middle of next week. This might depend on our kernel update conditions.
Hardkernel’s Ubuntu kernel is clearly separate from the kernel that CE is using. I’ve asked for the details of the change, though. Perhaps it can also be incorporated into CE’s kernel.
We discussed this internally, and I think this is still work in progress.
And if it’s not, I don’t see how this is a good way of doing this. What if the SPI device doesn’t support 64 bit words? There’s no way to turn this off.
I have tested simply with an SPI LED strip (WS2801) on Ubuntu, and it seems working normally.
We believe that the 64 bit work doesn’t affect the other conditions. That will be enabled only when the SPI buffer size is large enough. If it isn’t, that 64 bit options won’t do anything and the data streams as it is.
You can see the conditions for that.
So for now, I think it will be fine to be released. But if any issues occurred later, then I will revert that and we should find out the other way to increase the SPI performance for FBTFT LCDs.
If spi-meson-spicc is limited to a PIO model for moving data, then there likely is a fair amount of overhead. If you read through the thread on the Odroid forum, right now the C4 is underperforming an RPi3.
As things stand, the C4’s ability to drive the bounce demo I was using as a benchmark appeared to plateau; increasing the SPI frequency alone did not yield any performance improvement. With the change, awesometic was able to show much improved performance, although he ended up using a higher SPI frequency than my RPi3 example.
Seems like the change is either going to have to involve moving more data at once (to amortize overhead better) or figure out how to get spi-meson-spicc using DMA.
some differences were pointed out between the /sys/class/pwm contents available in CE compared to Hardkernel’s Linux.
What governs the creation of that /sys/class/pwm portion of sysfs? Might it be possible, via suitable device tree updates, to get hardware PWM working even in the current CE release?
That device tree defines pwm_ab, pwm_cd, and pwm_ef within cbus, all using the same compatible specification of amlogic,g12a-ee-pwm. The ab, cd, and ef designation does seem to better match the S950X3 datasheet.
Two more pwm_* “devices” appear in an aobus section.
Both of those sections reside within soc.
I have absolutely no clue whether DT updates alone stand any chance of being helpful!
FWIW, awesometic has also been working on updates to RPi.GPIO to make use of hardware PWM for N2 and C4. Those updates are still under test.