spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA
authorVladimir Oltean <vladimir.oltean@nxp.com>
Wed, 18 Mar 2020 00:15:53 +0000 (02:15 +0200)
committerMark Brown <broonie@kernel.org>
Wed, 18 Mar 2020 22:44:54 +0000 (22:44 +0000)
commit671ffde1752f594c60ccdfd75378defacfaf7c83
tree5e34af3778a26c73146855a0737e32a71a80c0af
parent4fcc7c2292def2fcb21a9644969583771c52724e
spi: spi-fsl-dspi: Fix little endian access to PUSHR CMD and TXDATA

In XSPI mode, the 32-bit PUSHR register can be written to separately:
the higher 16 bits are for commands and the lower 16 bits are for data.

This has nicely been hacked around, by defining a second regmap with a
width of 16 bits, and effectively splitting a 32-bit register into 2
16-bit ones, from the perspective of this regmap_pushr.

The problem is the assumption about the controller's endianness. If the
controller is little endian (such as anything post-LS1046A), then the
first 2 bytes, in the order imposed by memory layout, will actually hold
the TXDATA, and the last 2 bytes will hold the CMD.

So take the controller's endianness into account when performing split
writes to PUSHR. The obvious and simple solution would have been to call
regmap_get_val_endian(), but that is an internal regmap function and we
don't want to change regmap just for this. Therefore, we just re-read
the "big-endian" device tree property.

Fixes: 58ba07ec79e6 ("spi: spi-fsl-dspi: Add support for XSPI mode registers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20200318001603.9650-3-olteanv@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
drivers/spi/spi-fsl-dspi.c