Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

From: Vignesh R
Date: Fri Aug 07 2015 - 04:36:26 EST




On 08/07/2015 01:08 PM, Michal Suchanek wrote:

> Now since the description is clearer it's obvious that ti-qspi cannot
> work fully mmapped as fsl-qspi does because the setup has to be done
> over normal spi access and using non-m25p80 devices on the same bus is
> a requirement.
>
> The place where it is known if a transfer can use the mmap access is m25p80.c
>
> So my suggestion is
>
> - add a new method for spi master that gets the read opcode, dummy
> length, address, address length, buffer, buffer length and performs
> read from the flash memory in a hardware-specific way
>
> - add a check in m25p80.c that the master supports this feature and if
> so use it (eg check that the method is non-null)
>
> Presumably if some new SPI controllers with similar feature are
> supported in the future they can use the same inteface because you
> pass on everything the m25p80 read knows.
>

Ok... Do you mean something like this?

I will take m25p80 as example but can be expanded for any flash.

In include/linux/mtd.h:
struct spi_mtd_config_info {
struct spi_device *spi;
u32 page_size;
u8 addr_width;
u8 erase_opcode;
u8 read_opcode;
u8 read_dummy;
u8 program_opcode;
enum read_mode flash_read;

} /* subset of struct spi_nor */


In m25p80.c:

static int m25p80_read(struct spi_nor *nor, loff_t from,
size_t len, size_t *retlen,
u_char *buf)
{
struct spi_mtd_config_info info;
struct spi_device *spi;

if (spi->master->spi_mtd_mmap_read) {
/* Populate spi_mtd_config_info */
spi->master->spi_mtd_mmap_read(&info, from, len,
retlen, buf);
}
else {
/* no mtd specific acceleration supported try normal
* SPI way of communicating with flash
* continue with current code
* set up spi_message and call spi_sync()
*/
}

}

In spi-ti-qspi.c:
Implement spi_mtd_mmap_read while holding master->bus_lock mutex.


--
Regards
Vignesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/