Re: spi-gpio too fast for some devices

[Christian Mauderer <oss@xxxxxxxxxxxxx>]

On 01/07/2019 18:59, Mark Brown wrote:
> On Mon, Jul 01, 2019 at 05:05:49PM +0200, Geert Uytterhoeven wrote:
>> On Sat, Jun 29, 2019 at 11:44 AM Christian Mauderer <oss@xxxxxxxxxxxxx> wrote:
> 
>>> == Approach 1:
> 
>>> With some preprocessor magic I could create two sets of bitbang
>>> functions (bitbang_txrx_be_cpha0/1 and bitbang_txrx_be_cpha0/1_slow). I
>>> can then decide which of the functions to use in
>>> spi_gpio_txrx_word_mode0 (and similar functions) based on the nsecs
>>> value. For example if (nsecs > 1000) use bitbang_txrx_be_cpha0_slow()
>>> function otherwise use bitbang_txrx_be_cpha0().
> 
>>> This approach would add a minimal delay between the bytes but not in the
>>> bits. It would allow to have fast and slow devices on the same bus. But
>>> it's a little intransparent from a user perspective because there is
>>> some special (hard coded) speed where the behaviour changes.
> 
>>> What do you think: Would one of these be acceptable as a solution?
> 
>> A third approach would be to set up the spi_bitbang.txrx_word[]
>> function pointers at runtime, to point to "fast" or "slow" versions,
>> depending on the runtime-detected speed of the system you're
>> running on.
> 
> Either of the above two would be OK (I guess Geert's suggestion is one
> way of using the functions generated by your suggestion).  A compile
> time option isn't great as it's not usable by distro kernels or anything
> which will doubtless become an issue, though of course it gets over the
> immediate problem.  I can see that we might end up wanting to add a
> property to configure the cutover between delay and no delay variants,
> that'd make things a bit more transparent to users.
> 

Accepted. I'll try to implement one of the two variants. Basically both
need the same approach (adding two sets of functions). Only the decision
is done at a different location. Geert's suggestion avoids the delays
between bytes but increases the preparation time. Most likely therefore
it's the better one for SPI slaves which need the performance so I'll
try to prefer that one.

Sorry that I'm not that common with the terms: With property you most
likely mean one changeable at run time via the /sys filesystem right?

Best regards

Christian