spi-gpio too fast for some devices

[Christian Mauderer <oss@xxxxxxxxxxxxx>]

Hello,

I have a problem with the spi-gpio driver: It's too fast for one of my
devices. Now I'm searching for a good solution that could be
acceptable as a patch for the Linux kernel.

Currently there is the following comment and implementation for the
spidelay(...) function in spi-gpio.c:

> /*
>  * NOTE:  this clocks "as fast as we can".  It "should" be a function of the
>  * requested device clock.  Software overhead means we usually have trouble
>  * reaching even one Mbit/sec (except when we can inline bitops), so for now
>  * we'll just assume we never need additional per-bit slowdowns.
>  */
> #define spidelay(nsecs)	do {} while (0)

With that I have a speed of about 2.2MHz on a QCA9533 chip with 650MHz
using a 4.14 Kernel. The spidelay hasn't been changed in a newer
kernel so I assume it's still similar.

I tried to just define spidelay like follows:

> #define spidelay(nsecs)	ndelay(nsecs)

which basically works. But with that the maximum rate drops to 1.6MHz.
I assume that such a drastic performance decrease isn't acceptable for
the kernel?

Beneath that the bitrate isn't too well approximated. For a target
rate of 1MHz I get about 630kHz and for 100kHz I get 88kHz. But I'm
not sure how I could create something that has a good enough
estimation independent of the target architecture.

Any directions for how an acceptable implementation could look like?

Best regards

Christian Mauderer