On Sat, Jun 22, 2019 at 07:45:50AM +0200, Christian Mauderer wrote:
> On 10/06/2019 18:56, Christian Mauderer wrote:
> > 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)
> >> #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?
Yes, I can't imagine that other users are going to be happy with a
performance reduction like that.
> > Any directions for how an acceptable implementation could look like?
Off the top of my head you probably need to build a second copy of the
code with the delays included and then select that copy depending on the
speed that's been requested for the device and the speed of the system
somehow. The actual bitbanging is in a header so that makes it a bit
easier to build two copies than it might otherwise be.
Attachment:
signature.asc
Description: PGP signature
