@@ -370,7 +370,7 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
struct driver_data *drv_data =
spi_controller_get_devdata(spi->controller);
const struct lpss_config *config;
- u32 value;
+ u32 value, sscr0;
config = lpss_get_config(drv_data);
@@ -382,7 +382,18 @@ static void lpss_ssp_cs_control(struct spi_device *spi, bool enable)
value &= ~LPSS_CS_CONTROL_CS_HIGH;
else
value |= LPSS_CS_CONTROL_CS_HIGH;
+
+ /* To propagate CS value to output, the controller should
+ * be enabled. This is needed for devices that just do
+ * CS assert, wait and CS deassert without sending any data.
+ */
+ sscr0 = pxa2xx_spi_read(drv_data, SSCR0);
+ pxa2xx_spi_write(drv_data, SSCR0, sscr0 | SSCR0_SSE);
+
__lpss_ssp_write_priv(drv_data, config->reg_cs_ctrl, value);
+
+ /* Restore the original SSCR0 config*/
+ pxa2xx_spi_write(drv_data, SSCR0, sscr0);
}
static void cs_assert(struct spi_device *spi)
In some circumstances on Intel LPSS controllers, toggling the LPSS CS control register doesn't actually cause the CS line to toggle. This ruins SPI transactions that either rely on delay_usecs, or toggle the CS line without sending any data. This seems to be because the SSP controller is in disabled state. As per the spec, the controller needs to be enabled for CS change to take effect. This issue is not seen in cases where there is data to be transferred because then the SSCR0 gets enabled via pxa2xx_configure_sscr0(). Signed-off-by: Shobhit Srivastava <shobhit.srivastava@intel.com> --- drivers/spi/spi-pxa2xx.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)