Re: spi-gpio too fast for some devices

[Christian Mauderer <oss@xxxxxxxxxxxxx>]

On 24/06/2019 15:23, Mark Brown wrote:
> 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.
> 

Hello Mark,

thanks for the answer and the direction. I'll have a look at the driver
and try to create a rough plan which function I can replace without
creating too much of copy and paste code and without loosing too much
performance. I'm not sure yet where a good location would be to decide
which function should be used depending on the speed but I'll try to
find one.

I'll report back as soon as I have a plan and (maybe) at least a sketch
for a patch. Most likely that will need some time because I only do that
in my free time.

Best regards

Christian