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!
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:

https://forum.odroid.com/viewtopic.php?p=309553#p309553

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

https://github.com/hardkernel/linux/blob/odroidg12-4.9.y/drivers/spi/spi-meson-spicc.c#L491-L494

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:

https://forum.odroid.com/viewtopic.php?p=309582#p309582

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:

https://forum.odroid.com/viewtopic.php?p=309888#p309888

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.

Cheers,
Matt

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.

https://github.com/hardkernel/linux/commit/98774b14800f028b86288b18262227af623559b7

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.

Cheers,
Matt

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.

https://github.com/hardkernel/linux/commit/98774b14800f028b86288b18262227af623559b7#diff-feaa520439b458b6c5ff6bf593c0ee324859210f365798a85d376c026313f003R591

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.

About | FAQ | Terms of Service | Privacy Policy | Legal Notice