On Sat, Jan 16, 2021 at 5:06 AM Bin Meng bmeng.cn@gmail.com wrote:
Hi Brandon,
On Sat, Jan 16, 2021 at 5:30 AM Brandon Maier brandon.maier@rockwellcollins.com wrote:
The dm_spi_ops.xfer() API does not support dual and quad SPI modes. It also doesn't allow the zynqmp_gqspi driver to calculate the correct number of dummy cycles for some NOR ops (as doing so also requires the buswidth).
Port the zynqmp_gqspi driver to spi_controller_mem_ops, which gives us the buswidth values to correctly support all SNOR_PROTO_X_X_X commands and to properly calculate dummy cycles.
Signed-off-by: Brandon Maier brandon.maier@rockwellcollins.com CC: jagan@amarulasolutions.com CC: michal.simek@xilinx.com
drivers/spi/zynqmp_gqspi.c | 164 ++++++++++++++++--------------------- 1 file changed, 70 insertions(+), 94 deletions(-)
<snip>
Looks good to me! Thanks for improving this driver. Reviewed-by: Bin Meng bin.meng@windriver.com
But I believe we should keep zynqmp_qspi_xfer() for non-flash type SPI devices.
I had dropped it as the Linux driver only implements mem_ops, and also this driver doesn't look like it would work with non-flash SPI anyway. For example the existing driver will throw an error if we try to receive data with SPI_XFER_BEGIN set, as it is assuming SPI_XFER_BEGIN means we are transmitting a NOR op code.
Regards, Bin
Thanks, Brandon