Hardware GPIO improvements / SPI performance

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!

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:


which includes mention of these lines of code within Hardkernel’s version of spi-meson-spicc.c:


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.

Please see this post for initial details:


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.

Just FYI, awesometic / joshua.yang looks to have root cause the slow C4 SPI performance!

Please see this post:


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.


Here is the link that awesometic provided regarding the SPI performance improvement. It’s a fairly small change to drivers/spi/spi-meson-spicc.c.


Any CoreELEC developers reading and interested? I think the change, unfortunately, is on top of other patches that are not yet in 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.

A fair question to ask Hardkernel, certainly.

Awesometic’s reply:

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.

How this would increase the SPI speed?
When the SPI clock speed is not changed the bits/s remain same.

So I do not understand how it should help to send 64bit words in the same time as 32bit words.
The needed sending time will just double.

Or is there so much overhead on the 32/64bit words what is reduced by using 64bit words?

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.

Returning to this thread, I’m not sure much attention was paid to the second part, regarding hardware PWM.

In this Hardkernel forum thread:


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?

Thanks for any insights,

From awesometic:

Here’s the corresponding part of Odroid N2/C4 kernel.

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.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.