spi/tegra114: Correct support for cs_change

The tegra114 driver wasn't currently handling the cs_change
functionality. cs_change is meant to invert the decisions of whether
or not to deactivate CS after each transfer. Without cs_change, after
every transfer (other than the last in the message) the normal behavior
is to leave CS active. For the last transfer, normally CS is
deactivated when the transfer is complete.

With cs_change set on a transfer (other than last one) CS would be
deactivated and the next transfer would need to activate it again. If
cs_change was set on the last tranfer in a message, then CS would be
left active when the message compeleted.

Also, this builds in logic so that if a different device tries to start
a transfer while CS is active from a different device, it will abort the
previous transfer and start a new one for the new device.

This splits tegra_spi_start_transfer_one into 2 functions, the new one
being tegra_spi_setup_transfer_one. The setup function is safe to call
on all transfers, sets up for the transfer, and handles the special case
of the first transfer in a message. In this special case, it needs to
know whether or not it needs to activate CS.

This work was based on the spi-atmel driver.

Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

0 files changed, 0 insertions, 0 deletions