Squashed backup commit (no shallow-clone history issues) of xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2 branch, upstream commit 9eece662e) plus all fixes applied to get everpal_defconfig building clean against a modern (GCC 15.2.0) toolchain -- see the previous commit message on the lineage-23.2 branch (also in this repo history is not available here since this is a squashed snapshot; full incremental history lives in the local DL380 checkout and the upstream GitHub remote). Upstream: https://github.com/xiaomi-mt6833-dev/kernel_xiaomi_mt6833 (lineage-23.2)
17 lines
884 B
Plaintext
17 lines
884 B
Plaintext
SPI Chip Select behavior:
|
|
|
|
With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA
|
|
bit whether the Slave Select Line is controlled by hardware (CPHA=0) or
|
|
controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that
|
|
the Slave Select is always under software control and being asserted during
|
|
the entire SPI transfer. - And not just bits_per_word duration.
|
|
|
|
In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this
|
|
behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2
|
|
timing, you can utilize the GPIO controlled SPI Slave Select option instead.
|
|
In this case, you should use GPIO based CS for all of your slaves and not just
|
|
the ones using mode 0 or 2 in order to guarantee correct CS toggling behavior.
|
|
|
|
You can even use the same pin whose peripheral role is a SSEL,
|
|
but use it as a GPIO instead.
|