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>
Showing
Please register or sign in to comment