summaryrefslogtreecommitdiffstats
path: root/COPYING
diff options
context:
space:
mode:
authorKamal Dasu <kdasu.kdev@gmail.com>2020-04-20 15:08:48 -0400
committerMark Brown <broonie@kernel.org>2020-04-21 16:05:54 +0100
commit742d5958062488d03082a9ff01a6afb3cf7bd634 (patch)
treead475ddf2be5718d61582cc2d4fb5c74874a378f /COPYING
parent0dadde344d965566589cd82797893d5aa06557a3 (diff)
downloadlinux-stable-742d5958062488d03082a9ff01a6afb3cf7bd634.tar.gz
linux-stable-742d5958062488d03082a9ff01a6afb3cf7bd634.tar.bz2
linux-stable-742d5958062488d03082a9ff01a6afb3cf7bd634.zip
spi: bcm-qspi: Drive MSPI peripheral SSb pin on cs_change
As per the spi core implementation for MSPI devices when the transfer is the last one in the message, the chip may stay selected until the next transfer. On multi-device SPI busses with nothing blocking messages going to other devices, this is just a performance hint; starting a message to another device deselects this one. But in other cases, this can be used to ensure correctness. Some devices need protocol transactions to be built from a series of spi_message submissions, where the content of one message is determined by the results of previous messages and where the whole transaction ends when the chipselect goes intactive. On CS change after completing the last serial transfer, the MSPI driver drives SSb pin CDRAM register correctly according comments in core spi.h as shown below: case 1) EOM =1, cs_change =0: SSb inactive case 2) EOM =1, cs_change =1: SSb active case 3) EOM =0, cs_change =0: SSb active case 4) EOM =0, cs_change =1: SSb inactive Signed-off-by: Kamal Dasu <kdasu.kdev@gmail.com> Link: https://lore.kernel.org/r/20200420190853.45614-5-kdasu.kdev@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions