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.
Attachment:
signature.asc
Description: PGP signature
