[PATCH v1 1/2] mtd: fsl-quadspi: add support to create dynamic LUT entry
frieder.schrempf at exceet.de
Tue Jan 9 08:25:57 PST 2018
> Add support to create dynamic LUT entry.
> Current approach of creating LUT entries for various cmds like read, write,
> erase, readid, readsr, we, wd etc is that when QSPI controller gets
> initialized at that time static LUT entries for these cmds get created.
> Patch add support to create the LUT at run time based on the operation
> being performed.
> Added API fsl_qspi_prepare_lut(), this API would going to be called from
> fsl_qspi_read_reg, fsl_qspi_write_reg, fsl_qspi_write, fsl_qspi_read and
> fsl_qspi_erase APIs.
> This API would fetch required info like opcode, protocol info, dummy info
> for creating LUT from instance of 'struct spi_nor' and then prepare LUT
> entry for the required command.
I'm just about to get started working on a similar topic, so I have some
general (maybe stupid) questions concerning the dynamic LUT implementation:
Why do you actually need to be able to switch between different kind of
commands for READ/WRITE/ERASE at time of execution?
Wouldn't it be better to init the LUT statically, after the chip was
detected and at that time decide which READ/WRITE/ERASE command is best
for the connected chip?
Have you tested what kind of impact the dynamic loading of a command
sequence to the LUT registers before each operation has on the performance?
In the context of the upcoming SPI NAND framework, I am working on NAND
support for the FSL QSPI controller.
I have a working driver at  derived from the NOR driver.
As discussed with Boris () the plan is to add NAND support to the NOR
driver until a common spi-flash layer is available to hold code, that is
used by both types of SPI flash, NOR and NAND.
To achieve this, some kind of dynamic LUT allocation is needed, too.
But at first glance it seems me, that it would be better to actually use
the LUT entries as much as possible and create the entries at time of
init depending on flash type (NOR/NAND) and flash capabilities
In the exotic case of needing to switch between different command sets
(for hybrid NOR/NAND devices, see ) one could reinit the LUT for the
current target upon selecting it.
Or maybe it is even better to create a mechanism that fills the LUT with
entries when they are first needed and be able to reuse them until the
space in the LUT runs out and entries need to be overriden.
What do you think?
As I'm quite new to this, maybe someone can point to other
implementations with similar approaches for reference, if there are any.
Thanks and regards,
More information about the linux-mtd