Re: [RFC PATCH 4/6] spi: ti-qspi: Implement the spi_mem interface

Miquel Raynal
2018-02-12T07:55:19Z

Hi Boris,

> > > @@ -566,6 +567,62 @@ static int ti_qspi_spi_flash_read(struct spi_device *spi,
> > > return ret;
> > > }
> > >
> > > +static int ti_qspi_exec_mem_op(struct spi_mem *mem,
> > > + const struct spi_mem_op *op)
> > > +{
> > > + struct ti_qspi *qspi = spi_master_get_devdata(mem->spi->master);
> > > + int i, ret = 0;
> > > + u32 from = 0;
> > > +
> > > + /* Only optimize read path. */
> > > + if (!op->data.nbytes || op->data.dir != SPI_MEM_DATA_IN ||
> > > + !op->addr.nbytes || op->addr.nbytes > 4)
> > > + return -ENOTSUPP;
> > > +
> > > + for (i = 0; i < op->addr.nbytes; i++) {
> > > + from <<= 8;
> > > + from |= op->addr.buf[i];
> > > + }
> > > +
> > > + /* Address exceeds MMIO window size, fall back to regular mode. */
> >
> > I don't understand how do you fall back to regular mode?
>
> If you look at spi_mem_exec_op() you'll see that if the controller
> ->exec_op() returns -ENOTSUPP, the function will try to execute the
> operation using the regular spi_sync() API. I'll try to make it clearer
> in my next iteration.

Ok, I mixed the functions in my head and this answers the below
question as well.

>
> > Moreover if the
> > purpose of adding this function is to remove spi_flash_read().
>
> Sorry, I don't get that one. Yes, the spi_mem_ops interface is here to
> replace the ->spi_flash_xx() one, and that's exactly what I'm doing
> here: porting the existing implementation to the new interface, keeping
> the exact same limitations (only read path is optimized, and the request
> has to fall in the iomem range mapped by the driver).
>

Thanks,
Miquèl

--
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering