Re: spi-gpio too fast for some devices

[Christian Mauderer <oss@xxxxxxxxxxxxx>]

It seems that no one has read the mail that I've only sent to the list.
Mark Brown: You are the maintainer that would have to accept a patch in
that subsystem. Might I guide your attention to the mail?

Thanks

Christian Mauderer

On 10/06/2019 18:56, Christian Mauderer wrote:
> 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
>