On Sat, Jan 16, 2021 at 5:06 AM Bin Meng <bmeng...@gmail.com> wrote: > > Hi Brandon, > > On Sat, Jan 16, 2021 at 5:30 AM Brandon Maier > <brandon.ma...@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.ma...@rockwellcollins.com> > > CC: ja...@amarulasolutions.com > > CC: michal.si...@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.m...@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
