* [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller
@ 2018-08-31 10:29 ` Yogesh Gaur
0 siblings, 0 replies; 64+ messages in thread
From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw)
To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree
Cc: robh, mark.rutland, shawnguo, linux-arm-kernel,
computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur
- Add a driver for NXP FlexSPI host controller
FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475,
which supports two SPI channels and up to 4 external devices.
Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines)
i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8
bidirectional data lines.
FlexSPI controller is similar to the existing Freescale/NXP QuadSPI
controller with advanced features.
- Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2
filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets.
LX2160ARDB is having two NOR slave device connected on single bus A
i.e. A0 and A1 (CS0 and CS1).
LX2160AQDS is having two NOR slave device connected on separate buses
one flash on A0 and second on B1 i.e. (CS0 and CS3).
Verified this driver on following SPI NOR flashes:
Micron, mt35xu512aba[3], [Read - 1 bit mode]
Cypress, s25fl512s, [Read - 1/2/4 bit mode]
Patch 1 adds variable size in spi_device struct, to save the
size of connected slave device.
Patch 2 adds flags for octal I/O data transfer.
Support for octal flash commands and other framework changes would going to be done in different
patch set.
Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on
new spi-mem framework.
Patch 4 add binding file for this driver.
Patch 5 add device node property for FlexSPI driver for lx2160 SoC.
Patch 6 enables the config option.
Patch 7 add MAINTAINERS file.
[1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf
[2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721
[3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445
This series adds below patches:
Yogesh Gaur (7):
spi: add slave device size in spi_device struct
spi: add flags for octal I/O data transfer
spi: spi-mem: Add a driver for NXP FlexSPI controller
dt-bindings: spi: add binding file for NXP FlexSPI driver
arm64: dts: lx2160a: add fspi node property
arm64: defconfig: enable NXP FlexSPI driver
MAINTAINERS: add maintainers for the NXP FlexSPI driver
.../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 +
MAINTAINERS | 6 +
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +
arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 +
arch/arm64/configs/defconfig | 1 +
drivers/mtd/devices/m25p80.c | 6 +
drivers/mtd/spi-nor/spi-nor.c | 2 +
drivers/spi/Kconfig | 10 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++
include/linux/spi/spi.h | 4 +
11 files changed, 1347 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt
create mode 100644 drivers/spi/spi-nxp-fspi.c
--
2.7.4
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-08-31 10:29 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw) To: linux-arm-kernel - Add a driver for NXP FlexSPI host controller FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, which supports two SPI channels and up to 4 external devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8 bidirectional data lines. FlexSPI controller is similar to the existing Freescale/NXP QuadSPI controller with advanced features. - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets. LX2160ARDB is having two NOR slave device connected on single bus A i.e. A0 and A1 (CS0 and CS1). LX2160AQDS is having two NOR slave device connected on separate buses one flash on A0 and second on B1 i.e. (CS0 and CS3). Verified this driver on following SPI NOR flashes: Micron, mt35xu512aba[3], [Read - 1 bit mode] Cypress, s25fl512s, [Read - 1/2/4 bit mode] Patch 1 adds variable size in spi_device struct, to save the size of connected slave device. Patch 2 adds flags for octal I/O data transfer. Support for octal flash commands and other framework changes would going to be done in different patch set. Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on new spi-mem framework. Patch 4 add binding file for this driver. Patch 5 add device node property for FlexSPI driver for lx2160 SoC. Patch 6 enables the config option. Patch 7 add MAINTAINERS file. [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721 [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445 This series adds below patches: Yogesh Gaur (7): spi: add slave device size in spi_device struct spi: add flags for octal I/O data transfer spi: spi-mem: Add a driver for NXP FlexSPI controller dt-bindings: spi: add binding file for NXP FlexSPI driver arm64: dts: lx2160a: add fspi node property arm64: defconfig: enable NXP FlexSPI driver MAINTAINERS: add maintainers for the NXP FlexSPI driver .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 + MAINTAINERS | 6 + arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 + arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + arch/arm64/configs/defconfig | 1 + drivers/mtd/devices/m25p80.c | 6 + drivers/mtd/spi-nor/spi-nor.c | 2 + drivers/spi/Kconfig | 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++ include/linux/spi/spi.h | 4 + 11 files changed, 1347 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt create mode 100644 drivers/spi/spi-nxp-fspi.c -- 2.7.4 ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:29 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Add 'size' data variable in spi_device struct. This is to save the size of the connected slave device. After slave device scan, spi_nor_scan, size being assigned to this from MTD layer. SFDP read is being requested before completion of spi_nor_scan() routine, thus populate device size before making read request to the SPI controller. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- drivers/mtd/devices/m25p80.c | 6 ++++++ drivers/mtd/spi-nor/spi-nor.c | 2 ++ include/linux/spi/spi.h | 2 ++ 3 files changed, 10 insertions(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t from, size_t len, /* convert the dummy cycles to the number of bytes */ op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; + /* for case of SFDP header read commands, populate spi device size */ + if (flash->spimem->spi->size == 0) + flash->spimem->spi->size = nor->mtd.size; + while (remaining) { op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX; ret = spi_mem_adjust_op_size(flash->spimem, &op); @@ -215,6 +219,8 @@ static int m25p_probe(struct spi_mem *spimem) if (ret) return ret; + spi->size = nor->mtd.size; + return mtd_device_register(&nor->mtd, data ? data->parts : NULL, data ? data->nr_parts : 0); } diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 6042df8..b066bed 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2864,6 +2864,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, if (info->flags & SPI_S3AN) nor->flags |= SNOR_F_READY_XSR_RDY; + mtd->size = info->sector_size * info->n_sectors; + /* Parse the Serial Flash Discoverable Parameters table. */ ret = spi_nor_init_params(nor, info, ¶ms); if (ret) diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index a64235e..558aeed 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats, * for driver coldplugging, and in uevents used for hotplugging * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when * not using a GPIO line) + * @size: size of the connected slave device * * @statistics: statistics for the spi_device * @@ -168,6 +169,7 @@ struct spi_device { void *controller_data; char modalias[SPI_NAME_SIZE]; int cs_gpio; /* chip select gpio */ + u32 size; /* size of slave device */ /* the statistics */ struct spi_statistics statistics; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-08-31 10:29 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw) To: linux-arm-kernel Add 'size' data variable in spi_device struct. This is to save the size of the connected slave device. After slave device scan, spi_nor_scan, size being assigned to this from MTD layer. SFDP read is being requested before completion of spi_nor_scan() routine, thus populate device size before making read request to the SPI controller. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- drivers/mtd/devices/m25p80.c | 6 ++++++ drivers/mtd/spi-nor/spi-nor.c | 2 ++ include/linux/spi/spi.h | 2 ++ 3 files changed, 10 insertions(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t from, size_t len, /* convert the dummy cycles to the number of bytes */ op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; + /* for case of SFDP header read commands, populate spi device size */ + if (flash->spimem->spi->size == 0) + flash->spimem->spi->size = nor->mtd.size; + while (remaining) { op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX; ret = spi_mem_adjust_op_size(flash->spimem, &op); @@ -215,6 +219,8 @@ static int m25p_probe(struct spi_mem *spimem) if (ret) return ret; + spi->size = nor->mtd.size; + return mtd_device_register(&nor->mtd, data ? data->parts : NULL, data ? data->nr_parts : 0); } diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 6042df8..b066bed 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2864,6 +2864,8 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, if (info->flags & SPI_S3AN) nor->flags |= SNOR_F_READY_XSR_RDY; + mtd->size = info->sector_size * info->n_sectors; + /* Parse the Serial Flash Discoverable Parameters table. */ ret = spi_nor_init_params(nor, info, ¶ms); if (ret) diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index a64235e..558aeed 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats, * for driver coldplugging, and in uevents used for hotplugging * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when * not using a GPIO line) + * @size: size of the connected slave device * * @statistics: statistics for the spi_device * @@ -168,6 +169,7 @@ struct spi_device { void *controller_data; char modalias[SPI_NAME_SIZE]; int cs_gpio; /* chip select gpio */ + u32 size; /* size of slave device */ /* the statistics */ struct spi_statistics statistics; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH 1/7] spi: add slave device size in spi_device struct 2018-08-31 10:29 ` Yogesh Gaur (?) @ 2018-08-31 11:41 ` Geert Uytterhoeven -1 siblings, 0 replies; 64+ messages in thread From: Geert Uytterhoeven @ 2018-08-31 11:41 UTC (permalink / raw) To: Yogesh Gaur Cc: MTD Maling List, Boris Brezillon, Marek Vasut, linux-spi, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Mark Rutland, Rob Herring, Linux Kernel Mailing List, Frieder Schrempf, Brian Norris, Shawn Guo, Linux ARM Hi Yogesh, Thanks for your patch! On Fri, Aug 31, 2018 at 12:33 PM Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Add 'size' data variable in spi_device struct. > This is to save the size of the connected slave device. What is the "size" of an SPI slave device? > After slave device scan, spi_nor_scan, size being assigned to this > from MTD layer. Ah, this is MTD specific? > SFDP read is being requested before completion of spi_nor_scan() > routine, thus populate device size before making read request > to the SPI controller. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats, > * for driver coldplugging, and in uevents used for hotplugging > * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when > * not using a GPIO line) > + * @size: size of the connected slave device Please document what is the meaning of "size". > * > * @statistics: statistics for the spi_device > * > @@ -168,6 +169,7 @@ struct spi_device { > void *controller_data; > char modalias[SPI_NAME_SIZE]; > int cs_gpio; /* chip select gpio */ > + u32 size; /* size of slave device */ > > /* the statistics */ > struct spi_statistics statistics; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-08-31 11:41 ` Geert Uytterhoeven 0 siblings, 0 replies; 64+ messages in thread From: Geert Uytterhoeven @ 2018-08-31 11:41 UTC (permalink / raw) To: linux-arm-kernel Hi Yogesh, Thanks for your patch! On Fri, Aug 31, 2018 at 12:33 PM Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Add 'size' data variable in spi_device struct. > This is to save the size of the connected slave device. What is the "size" of an SPI slave device? > After slave device scan, spi_nor_scan, size being assigned to this > from MTD layer. Ah, this is MTD specific? > SFDP read is being requested before completion of spi_nor_scan() > routine, thus populate device size before making read request > to the SPI controller. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats, > * for driver coldplugging, and in uevents used for hotplugging > * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when > * not using a GPIO line) > + * @size: size of the connected slave device Please document what is the meaning of "size". > * > * @statistics: statistics for the spi_device > * > @@ -168,6 +169,7 @@ struct spi_device { > void *controller_data; > char modalias[SPI_NAME_SIZE]; > int cs_gpio; /* chip select gpio */ > + u32 size; /* size of slave device */ > > /* the statistics */ > struct spi_statistics statistics; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-08-31 11:41 ` Geert Uytterhoeven 0 siblings, 0 replies; 64+ messages in thread From: Geert Uytterhoeven @ 2018-08-31 11:41 UTC (permalink / raw) To: Yogesh Gaur Cc: MTD Maling List, Boris Brezillon, Marek Vasut, linux-spi, open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, Mark Rutland, Rob Herring, Linux Kernel Mailing List, Frieder Schrempf, Brian Norris, Shawn Guo, Linux ARM Hi Yogesh, Thanks for your patch! On Fri, Aug 31, 2018 at 12:33 PM Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Add 'size' data variable in spi_device struct. > This is to save the size of the connected slave device. What is the "size" of an SPI slave device? > After slave device scan, spi_nor_scan, size being assigned to this > from MTD layer. Ah, this is MTD specific? > SFDP read is being requested before completion of spi_nor_scan() > routine, thus populate device size before making read request > to the SPI controller. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -127,6 +127,7 @@ void spi_statistics_add_transfer_stats(struct spi_statistics *stats, > * for driver coldplugging, and in uevents used for hotplugging > * @cs_gpio: gpio number of the chipselect line (optional, -ENOENT when > * not using a GPIO line) > + * @size: size of the connected slave device Please document what is the meaning of "size". > * > * @statistics: statistics for the spi_device > * > @@ -168,6 +169,7 @@ struct spi_device { > void *controller_data; > char modalias[SPI_NAME_SIZE]; > int cs_gpio; /* chip select gpio */ > + u32 size; /* size of slave device */ > > /* the statistics */ > struct spi_statistics statistics; Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 1/7] spi: add slave device size in spi_device struct 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 11:58 ` Lothar Waßmann -1 siblings, 0 replies; 64+ messages in thread From: Lothar Waßmann @ 2018-08-31 11:58 UTC (permalink / raw) To: Yogesh Gaur Cc: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree, mark.rutland, robh, linux-kernel, frieder.schrempf, computersforpeace, shawnguo, linux-arm-kernel Hi, On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > Add 'size' data variable in spi_device struct. > This is to save the size of the connected slave device. > > After slave device scan, spi_nor_scan, size being assigned to this > from MTD layer. > > SFDP read is being requested before completion of spi_nor_scan() > routine, thus populate device size before making read request > to the SPI controller. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > drivers/mtd/devices/m25p80.c | 6 ++++++ > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > include/linux/spi/spi.h | 2 ++ > 3 files changed, 10 insertions(+) > > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index fe260cc..6c7ad86 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t from, size_t len, > /* convert the dummy cycles to the number of bytes */ > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > + /* for case of SFDP header read commands, populate spi device size */ > + if (flash->spimem->spi->size == 0) > + flash->spimem->spi->size = nor->mtd.size; > + If the 'size' is an spimem specific variable it should be added to the spi_mem struct rather than the spi_device struct. Lothar Waßmann ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-08-31 11:58 ` Lothar Waßmann 0 siblings, 0 replies; 64+ messages in thread From: Lothar Waßmann @ 2018-08-31 11:58 UTC (permalink / raw) To: linux-arm-kernel Hi, On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > Add 'size' data variable in spi_device struct. > This is to save the size of the connected slave device. > > After slave device scan, spi_nor_scan, size being assigned to this > from MTD layer. > > SFDP read is being requested before completion of spi_nor_scan() > routine, thus populate device size before making read request > to the SPI controller. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > drivers/mtd/devices/m25p80.c | 6 ++++++ > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > include/linux/spi/spi.h | 2 ++ > 3 files changed, 10 insertions(+) > > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c > index fe260cc..6c7ad86 100644 > --- a/drivers/mtd/devices/m25p80.c > +++ b/drivers/mtd/devices/m25p80.c > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, loff_t from, size_t len, > /* convert the dummy cycles to the number of bytes */ > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > + /* for case of SFDP header read commands, populate spi device size */ > + if (flash->spimem->spi->size == 0) > + flash->spimem->spi->size = nor->mtd.size; > + If the 'size' is an spimem specific variable it should be added to the spi_mem struct rather than the spi_device struct. Lothar Wa?mann ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 1/7] spi: add slave device size in spi_device struct 2018-08-31 11:58 ` Lothar Waßmann (?) @ 2018-09-03 4:47 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-03 4:47 UTC (permalink / raw) To: Lothar Waßmann Cc: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree, mark.rutland, robh, linux-kernel, frieder.schrempf, computersforpeace, shawnguo, linux-arm-kernel Hi Lothar, > -----Original Message----- > From: Lothar Waßmann [mailto:LW@KARO-electronics.de] > Sent: Friday, August 31, 2018 5:28 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org; mark.rutland@arm.com; robh@kernel.org; linux- > kernel@vger.kernel.org; frieder.schrempf@exceet.de; > computersforpeace@gmail.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > Hi, > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > Add 'size' data variable in spi_device struct. > > This is to save the size of the connected slave device. > > > > After slave device scan, spi_nor_scan, size being assigned to this > > from MTD layer. > > > > SFDP read is being requested before completion of spi_nor_scan() > > routine, thus populate device size before making read request to the > > SPI controller. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > drivers/mtd/devices/m25p80.c | 6 ++++++ > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > include/linux/spi/spi.h | 2 ++ > > 3 files changed, 10 insertions(+) > > > > diff --git a/drivers/mtd/devices/m25p80.c > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > --- a/drivers/mtd/devices/m25p80.c > > +++ b/drivers/mtd/devices/m25p80.c > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > loff_t from, size_t len, > > /* convert the dummy cycles to the number of bytes */ > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > + /* for case of SFDP header read commands, populate spi device size */ > > + if (flash->spimem->spi->size == 0) > > + flash->spimem->spi->size = nor->mtd.size; > > + > If the 'size' is an spimem specific variable it should be added to the spi_mem > struct rather than the spi_device struct. Sure, would move 'size' from struct spi_device to the struct spi_mem. -- Regards Yogesh Gaur. > > Lothar Waßmann ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-09-03 4:47 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-03 4:47 UTC (permalink / raw) To: linux-arm-kernel Hi Lothar, > -----Original Message----- > From: Lothar Wa?mann [mailto:LW at KARO-electronics.de] > Sent: Friday, August 31, 2018 5:28 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > devicetree at vger.kernel.org; mark.rutland at arm.com; robh at kernel.org; linux- > kernel at vger.kernel.org; frieder.schrempf at exceet.de; > computersforpeace at gmail.com; shawnguo at kernel.org; linux-arm- > kernel at lists.infradead.org > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > Hi, > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > Add 'size' data variable in spi_device struct. > > This is to save the size of the connected slave device. > > > > After slave device scan, spi_nor_scan, size being assigned to this > > from MTD layer. > > > > SFDP read is being requested before completion of spi_nor_scan() > > routine, thus populate device size before making read request to the > > SPI controller. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > drivers/mtd/devices/m25p80.c | 6 ++++++ > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > include/linux/spi/spi.h | 2 ++ > > 3 files changed, 10 insertions(+) > > > > diff --git a/drivers/mtd/devices/m25p80.c > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > --- a/drivers/mtd/devices/m25p80.c > > +++ b/drivers/mtd/devices/m25p80.c > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > loff_t from, size_t len, > > /* convert the dummy cycles to the number of bytes */ > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > + /* for case of SFDP header read commands, populate spi device size */ > > + if (flash->spimem->spi->size == 0) > > + flash->spimem->spi->size = nor->mtd.size; > > + > If the 'size' is an spimem specific variable it should be added to the spi_mem > struct rather than the spi_device struct. Sure, would move 'size' from struct spi_device to the struct spi_mem. -- Regards Yogesh Gaur. > > Lothar Wa?mann ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-09-03 4:47 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-03 4:47 UTC (permalink / raw) To: Lothar Waßmann Cc: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree, mark.rutland, robh, linux-kernel, frieder.schrempf, computersforpeace, shawnguo, linux-arm-kernel Hi Lothar, > -----Original Message----- > From: Lothar Waßmann [mailto:LW@KARO-electronics.de] > Sent: Friday, August 31, 2018 5:28 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org; mark.rutland@arm.com; robh@kernel.org; linux- > kernel@vger.kernel.org; frieder.schrempf@exceet.de; > computersforpeace@gmail.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > Hi, > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > Add 'size' data variable in spi_device struct. > > This is to save the size of the connected slave device. > > > > After slave device scan, spi_nor_scan, size being assigned to this > > from MTD layer. > > > > SFDP read is being requested before completion of spi_nor_scan() > > routine, thus populate device size before making read request to the > > SPI controller. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > drivers/mtd/devices/m25p80.c | 6 ++++++ > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > include/linux/spi/spi.h | 2 ++ > > 3 files changed, 10 insertions(+) > > > > diff --git a/drivers/mtd/devices/m25p80.c > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > --- a/drivers/mtd/devices/m25p80.c > > +++ b/drivers/mtd/devices/m25p80.c > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > loff_t from, size_t len, > > /* convert the dummy cycles to the number of bytes */ > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > + /* for case of SFDP header read commands, populate spi device size */ > > + if (flash->spimem->spi->size == 0) > > + flash->spimem->spi->size = nor->mtd.size; > > + > If the 'size' is an spimem specific variable it should be added to the spi_mem > struct rather than the spi_device struct. Sure, would move 'size' from struct spi_device to the struct spi_mem. -- Regards Yogesh Gaur. > > Lothar Waßmann ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 1/7] spi: add slave device size in spi_device struct 2018-09-03 4:47 ` Yogesh Narayan Gaur @ 2018-09-03 8:36 ` Boris Brezillon -1 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-03 8:36 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Lothar Waßmann, linux-mtd, marek.vasut, linux-spi, devicetree, mark.rutland, robh, linux-kernel, frieder.schrempf, computersforpeace, shawnguo, linux-arm-kernel Hi Yogesh, On Mon, 3 Sep 2018 04:47:25 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Lothar, > > > -----Original Message----- > > From: Lothar Waßmann [mailto:LW@KARO-electronics.de] > > Sent: Friday, August 31, 2018 5:28 PM > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > devicetree@vger.kernel.org; mark.rutland@arm.com; robh@kernel.org; linux- > > kernel@vger.kernel.org; frieder.schrempf@exceet.de; > > computersforpeace@gmail.com; shawnguo@kernel.org; linux-arm- > > kernel@lists.infradead.org > > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > > > Hi, > > > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > > Add 'size' data variable in spi_device struct. > > > This is to save the size of the connected slave device. > > > > > > After slave device scan, spi_nor_scan, size being assigned to this > > > from MTD layer. > > > > > > SFDP read is being requested before completion of spi_nor_scan() > > > routine, thus populate device size before making read request to the > > > SPI controller. > > > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > > --- > > > drivers/mtd/devices/m25p80.c | 6 ++++++ > > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > > include/linux/spi/spi.h | 2 ++ > > > 3 files changed, 10 insertions(+) > > > > > > diff --git a/drivers/mtd/devices/m25p80.c > > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > > --- a/drivers/mtd/devices/m25p80.c > > > +++ b/drivers/mtd/devices/m25p80.c > > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > > loff_t from, size_t len, > > > /* convert the dummy cycles to the number of bytes */ > > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > > > + /* for case of SFDP header read commands, populate spi device size */ > > > + if (flash->spimem->spi->size == 0) > > > + flash->spimem->spi->size = nor->mtd.size; > > > + > > If the 'size' is an spimem specific variable it should be added to the spi_mem > > struct rather than the spi_device struct. > > Sure, would move 'size' from struct spi_device to the struct spi_mem. Before you send a new version doing that, I'd like to understand why you need this information. Can you wait a bit so I have some time to review the driver? Thanks, Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] spi: add slave device size in spi_device struct @ 2018-09-03 8:36 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-03 8:36 UTC (permalink / raw) To: linux-arm-kernel Hi Yogesh, On Mon, 3 Sep 2018 04:47:25 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Lothar, > > > -----Original Message----- > > From: Lothar Wa?mann [mailto:LW at KARO-electronics.de] > > Sent: Friday, August 31, 2018 5:28 PM > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Cc: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > > devicetree at vger.kernel.org; mark.rutland at arm.com; robh at kernel.org; linux- > > kernel at vger.kernel.org; frieder.schrempf at exceet.de; > > computersforpeace at gmail.com; shawnguo at kernel.org; linux-arm- > > kernel at lists.infradead.org > > Subject: Re: [PATCH 1/7] spi: add slave device size in spi_device struct > > > > Hi, > > > > On Fri, 31 Aug 2018 15:59:58 +0530 Yogesh Gaur wrote: > > > Add 'size' data variable in spi_device struct. > > > This is to save the size of the connected slave device. > > > > > > After slave device scan, spi_nor_scan, size being assigned to this > > > from MTD layer. > > > > > > SFDP read is being requested before completion of spi_nor_scan() > > > routine, thus populate device size before making read request to the > > > SPI controller. > > > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > > --- > > > drivers/mtd/devices/m25p80.c | 6 ++++++ > > > drivers/mtd/spi-nor/spi-nor.c | 2 ++ > > > include/linux/spi/spi.h | 2 ++ > > > 3 files changed, 10 insertions(+) > > > > > > diff --git a/drivers/mtd/devices/m25p80.c > > > b/drivers/mtd/devices/m25p80.c index fe260cc..6c7ad86 100644 > > > --- a/drivers/mtd/devices/m25p80.c > > > +++ b/drivers/mtd/devices/m25p80.c > > > @@ -124,6 +124,10 @@ static ssize_t m25p80_read(struct spi_nor *nor, > > loff_t from, size_t len, > > > /* convert the dummy cycles to the number of bytes */ > > > op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8; > > > > > > + /* for case of SFDP header read commands, populate spi device size */ > > > + if (flash->spimem->spi->size == 0) > > > + flash->spimem->spi->size = nor->mtd.size; > > > + > > If the 'size' is an spimem specific variable it should be added to the spi_mem > > struct rather than the spi_device struct. > > Sure, would move 'size' from struct spi_device to the struct spi_mem. Before you send a new version doing that, I'd like to understand why you need this information. Can you wait a bit so I have some time to review the driver? Thanks, Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 2/7] spi: add flags for octal I/O data transfer 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:29 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Add flags for Octal I/O data transfer Required for the SPI controller which can do data transfer (TX/RX) on 8 data lines e.g. NXP FlexSPI controller. SPI_TX_OCTAL: transmit with 8 wires SPI_RX_OCTAL: receive with 8 wires Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- include/linux/spi/spi.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 558aeed..180f277 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -164,6 +164,8 @@ struct spi_device { #define SPI_TX_QUAD 0x200 /* transmit with 4 wires */ #define SPI_RX_DUAL 0x400 /* receive with 2 wires */ #define SPI_RX_QUAD 0x800 /* receive with 4 wires */ +#define SPI_TX_OCTAL 0x1000 /* transmit with 8 wires */ +#define SPI_RX_OCTAL 0x2000 /* receive with 8 wires */ int irq; void *controller_state; void *controller_data; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] spi: add flags for octal I/O data transfer @ 2018-08-31 10:29 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:29 UTC (permalink / raw) To: linux-arm-kernel Add flags for Octal I/O data transfer Required for the SPI controller which can do data transfer (TX/RX) on 8 data lines e.g. NXP FlexSPI controller. SPI_TX_OCTAL: transmit with 8 wires SPI_RX_OCTAL: receive with 8 wires Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- include/linux/spi/spi.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index 558aeed..180f277 100644 --- a/include/linux/spi/spi.h +++ b/include/linux/spi/spi.h @@ -164,6 +164,8 @@ struct spi_device { #define SPI_TX_QUAD 0x200 /* transmit with 4 wires */ #define SPI_RX_DUAL 0x400 /* receive with 2 wires */ #define SPI_RX_QUAD 0x800 /* receive with 4 wires */ +#define SPI_TX_OCTAL 0x1000 /* transmit with 8 wires */ +#define SPI_RX_OCTAL 0x2000 /* receive with 8 wires */ int irq; void *controller_state; void *controller_data; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:30 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur - Add a driver for NXP FlexSPI host controller (0) What is the FlexSPI controller? FlexSPI is a flexsible SPI host controller which supports two SPI channels and up to 4 external devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8 bidirectional data lines. It uses new SPI memory interface of the SPI framework to issue flash memory operations to up to four connected flash chips (2 buses with 2 CS each). Chipselect for each flash can be selected as per address assigned in controller specific registers. FlexSPI controller is similar to the existing Freescale/NXP QuadSPI controller with advanced features. (1) The FlexSPI controller is driven by the LUT(Look-up Table) registers. The LUT registers are a look-up-table for sequences of instructions. A valid sequence consists of four LUT registers. Maximum 32 LUT sequences can be programmed simultaneously. (2) The definition of the LUT register shows below: --------------------------------------------------- | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | --------------------------------------------------- There are several types of INSTRx, such as: CMD : the SPI NOR command. ADDR : the address for the SPI NOR command. DUMMY : the dummy cycles needed by the SPI NOR command. .... There are several types of PADx, such as: PAD1 : use a singe I/O line. PAD2 : use two I/O lines. PAD4 : use quad I/O lines. PAD8 : use octal I/O lines. .... (3) LUTs are being created at run-time based on the commands passed from the spi-mem framework. Thus, using single LUT index. (4) Software triggered Flash read/write access by IP Bus. (5) Memory mapped read access by AHB Bus. (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility on NXP LX2160ARDB and LX2160AQDS targets. LX2160ARDB is having two NOR slave device connected on single bus A i.e. A0 and A1 (CS0 and CS1). LX2160AQDS is having two NOR slave device connected on separate buses one flash on A0 and second on B1 i.e. (CS0 and CS3). Verified this driver on following SPI NOR flashes: Micron, mt35xu512ab, [Read - 1 bit mode] Cypress, s25fl512s, [Read - 1/2/4 bit mode] - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. - Add entry in the 'spi-nor/Makefile'. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- drivers/spi/Kconfig | 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1253 insertions(+) create mode 100644 drivers/spi/spi-nxp-fspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index ad5d68e..68da874 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI help This enables Freescale i.MX LPSPI controllers in master mode. +config SPI_NXP_FLEXSPI + tristate "NXP Flex SPI controller" + depends on ARCH_LAYERSCAPE || HAS_IOMEM + help + This enables support for the Flex SPI controller in master mode. + Up to four slave devices can be connected on two buses with two + chipselects each. + This controller does not support generic SPI messages and only + supports the high-level SPI memory interface. + config SPI_GPIO tristate "GPIO-based bitbanging SPI Master" depends on GPIOLIB || COMPILE_TEST diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index cb1f437..52c9f18 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o obj-$(CONFIG_SPI_MT65XX) += spi-mt65xx.o obj-$(CONFIG_SPI_MXS) += spi-mxs.o obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o spi-octeon-objs := spi-cavium.o spi-cavium-octeon.o obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c new file mode 100644 index 0000000..677401b --- /dev/null +++ b/drivers/spi/spi-nxp-fspi.c @@ -0,0 +1,1242 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/* + * NXP FlexSPI(FSPI) controller driver. + * + * Copyright 2018 NXP + * + * Based on SPI MEM interface: + * Author: + * Yogesh Gaur <yogeshnarayan.gaur@nxp.com> + */ + +#include <linux/bitops.h> +#include <linux/clk.h> +#include <linux/completion.h> +#include <linux/delay.h> +#include <linux/err.h> +#include <linux/errno.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/jiffies.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/platform_device.h> +#include <linux/pm_qos.h> +#include <linux/sizes.h> + +#include <linux/spi/spi.h> +#include <linux/spi/spi-mem.h> + +/* + * The driver only uses one single LUT entry, that is updated on + * each call of exec_op(). Index 0 is preset at boot with a basic + * read operation, so let's use the last entry (31). + */ +#define SEQID_LUT 31 + +/* Registers used by the driver */ +#define FSPI_MCR0 0x00 +#define FSPI_MCR0_AHB_TIMEOUT_SHIFT 24 +#define FSPI_MCR0_AHB_TIMEOUT_MASK (0xFF << FSPI_MCR0_AHB_TIMEOUT_SHIFT) +#define FSPI_MCR0_IP_TIMEOUT_SHIFT 16 +#define FSPI_MCR0_IP_TIMEOUT_MASK (0xFF << FSPI_MCR0_IP_TIMEOUT_SHIFT) +#define FSPI_MCR0_LEARN_EN_SHIFT 15 +#define FSPI_MCR0_LEARN_EN_MASK (1 << FSPI_MCR0_LEARN_EN_SHIFT) +#define FSPI_MCR0_SCRFRUN_EN_SHIFT 14 +#define FSPI_MCR0_SCRFRUN_EN_MASK (1 << FSPI_MCR0_SCRFRUN_EN_SHIFT) +#define FSPI_MCR0_OCTCOMB_EN_SHIFT 13 +#define FSPI_MCR0_OCTCOMB_EN_MASK (1 << FSPI_MCR0_OCTCOMB_EN_SHIFT) +#define FSPI_MCR0_DOZE_EN_SHIFT 12 +#define FSPI_MCR0_DOZE_EN_MASK (1 << FSPI_MCR0_DOZE_EN_SHIFT) +#define FSPI_MCR0_HSEN_SHIFT 11 +#define FSPI_MCR0_HSEN_MASK (1 << FSPI_MCR0_HSEN_SHIFT) +#define FSPI_MCR0_SERCLKDIV_SHIFT 8 +#define FSPI_MCR0_SERCLKDIV_MASK (7 << FSPI_MCR0_SERCLKDIV_SHIFT) +#define FSPI_MCR0_ATDF_EN_SHIFT 7 +#define FSPI_MCR0_ATDF_EN_MASK (1 << FSPI_MCR0_ATDF_EN_SHIFT) +#define FSPI_MCR0_ARDF_EN_SHIFT 6 +#define FSPI_MCR0_ARDF_EN_MASK (1 << FSPI_MCR0_ARDF_EN_SHIFT) +#define FSPI_MCR0_RXCLKSRC_SHIFT 4 +#define FSPI_MCR0_RXCLKSRC_MASK (3 << FSPI_MCR0_RXCLKSRC_SHIFT) +#define FSPI_MCR0_END_CFG_SHIFT 2 +#define FSPI_MCR0_END_CFG_MASK (3 << FSPI_MCR0_END_CFG_SHIFT) +#define FSPI_MCR0_MDIS_SHIFT 1 +#define FSPI_MCR0_MDIS_MASK (1 << FSPI_MCR0_MDIS_SHIFT) +#define FSPI_MCR0_SWRST_SHIFT 0 +#define FSPI_MCR0_SWRST_MASK (1 << FSPI_MCR0_SWRST_SHIFT) + +#define FSPI_MCR1 0x04 +#define FSPI_MCR1_SEQ_TIMEOUT_SHIFT 16 +#define FSPI_MCR1_SEQ_TIMEOUT_MASK (0xFFFF << FSPI_MCR1_SEQ_TIMEOUT_SHIFT) +#define FSPI_MCR1_AHB_TIMEOUT_SHIFT 0 +#define FSPI_MCR1_AHB_TIMEOUT_MASK (0xFFFF << FSPI_MCR1_AHB_TIMEOUT_SHIFT) + +#define FSPI_MCR2 0x08 +#define FSPI_MCR2_IDLE_WAIT_SHIFT 24 +#define FSPI_MCR2_IDLE_WAIT_MASK (0xFF << FSPI_MCR2_IDLE_WAIT_SHIFT) +#define FSPI_MCR2_SAMEDEVICEEN_SHIFT 15 +#define FSPI_MCR2_SAMEDEVICEEN_MASK (1 << FSPI_MCR2_SAMEDEVICEEN_SHIFT) +#define FSPI_MCR2_CLRLRPHS_SHIFT 14 +#define FSPI_MCR2_CLRLRPHS_MASK (1 << FSPI_MCR2_CLRLRPHS_SHIFT) +#define FSPI_MCR2_ABRDATSZ_SHIFT 8 +#define FSPI_MCR2_ABRDATSZ_MASK (1 << FSPI_MCR2_ABRDATSZ_SHIFT) +#define FSPI_MCR2_ABRLEARN_SHIFT 7 +#define FSPI_MCR2_ABRLEARN_MASK (1 << FSPI_MCR2_ABRLEARN_SHIFT) +#define FSPI_MCR2_ABR_READ_SHIFT 6 +#define FSPI_MCR2_ABR_READ_MASK (1 << FSPI_MCR2_ABR_READ_SHIFT) +#define FSPI_MCR2_ABRWRITE_SHIFT 5 +#define FSPI_MCR2_ABRWRITE_MASK (1 << FSPI_MCR2_ABRWRITE_SHIFT) +#define FSPI_MCR2_ABRDUMMY_SHIFT 4 +#define FSPI_MCR2_ABRDUMMY_MASK (1 << FSPI_MCR2_ABRDUMMY_SHIFT) +#define FSPI_MCR2_ABR_MODE_SHIFT 3 +#define FSPI_MCR2_ABR_MODE_MASK (1 << FSPI_MCR2_ABR_MODE_SHIFT) +#define FSPI_MCR2_ABRCADDR_SHIFT 2 +#define FSPI_MCR2_ABRCADDR_MASK (1 << FSPI_MCR2_ABRCADDR_SHIFT) +#define FSPI_MCR2_ABRRADDR_SHIFT 1 +#define FSPI_MCR2_ABRRADDR_MASK (1 << FSPI_MCR2_ABRRADDR_SHIFT) +#define FSPI_MCR2_ABR_CMD_SHIFT 0 +#define FSPI_MCR2_ABR_CMD_MASK (1 << FSPI_MCR2_ABR_CMD_SHIFT) + +#define FSPI_AHBCR 0x0c +#define FSPI_AHBCR_RDADDROPT_SHIFT 6 +#define FSPI_AHBCR_RDADDROPT_MASK (1 << FSPI_AHBCR_RDADDROPT_SHIFT) +#define FSPI_AHBCR_PREF_EN_SHIFT 5 +#define FSPI_AHBCR_PREF_EN_MASK (1 << FSPI_AHBCR_PREF_EN_SHIFT) +#define FSPI_AHBCR_BUFF_EN_SHIFT 4 +#define FSPI_AHBCR_BUFF_EN_MASK (1 << FSPI_AHBCR_BUFF_EN_SHIFT) +#define FSPI_AHBCR_CACH_EN_SHIFT 3 +#define FSPI_AHBCR_CACH_EN_MASK (1 << FSPI_AHBCR_CACH_EN_SHIFT) +#define FSPI_AHBCR_CLRTXBUF_SHIFT 2 +#define FSPI_AHBCR_CLRTXBUF_MASK (1 << FSPI_AHBCR_CLRTXBUF_SHIFT) +#define FSPI_AHBCR_CLRRXBUF_SHIFT 1 +#define FSPI_AHBCR_CLRRXBUF_MASK (1 << FSPI_AHBCR_CLRRXBUF_SHIFT) +#define FSPI_AHBCR_PAR_EN_SHIFT 0 +#define FSPI_AHBCR_PAR_EN_MASK (1 << FSPI_AHBCR_PAR_EN_SHIFT) + +#define FSPI_INTEN 0x10 +#define FSPI_INTEN_SCLKSBWR_SHIFT 9 +#define FSPI_INTEN_SCLKSBWR_MASK (1 << FSPI_INTEN_SCLKSBWR_SHIFT) +#define FSPI_INTEN_SCLKSBRD_SHIFT 8 +#define FSPI_INTEN_SCLKSBRD_MASK (1 << FSPI_INTEN_SCLKSBRD_SHIFT) +#define FSPI_INTEN_DATALRNFL_SHIFT 7 +#define FSPI_INTEN_DATALRNFL_MASK (1 << FSPI_INTEN_DATALRNFL_SHIFT) +#define FSPI_INTEN_IPTXWE_SHIFT 6 +#define FSPI_INTEN_IPTXWE_MASK (1 << FSPI_INTEN_IPTXWE_SHIFT) +#define FSPI_INTEN_IPRXWA_SHIFT 5 +#define FSPI_INTEN_IPRXWA_MASK (1 << FSPI_INTEN_IPRXWA_SHIFT) +#define FSPI_INTEN_AHBCMDERR_SHIFT 4 +#define FSPI_INTEN_AHBCMDERR_MASK (1 << FSPI_INTEN_AHBCMDERR_SHIFT) +#define FSPI_INTEN_IPCMDERR_SHIFT 3 +#define FSPI_INTEN_IPCMDERR_MASK (1 << FSPI_INTEN_IPCMDERR_SHIFT) +#define FSPI_INTEN_AHBCMDGE_SHIFT 2 +#define FSPI_INTEN_AHBCMDGE_MASK (1 << FSPI_INTEN_AHBCMDGE_SHIFT) +#define FSPI_INTEN_IPCMDGE_SHIFT 1 +#define FSPI_INTEN_IPCMDGE_MASK (1 << FSPI_INTEN_IPCMDGE_SHIFT) +#define FSPI_INTEN_IPCMDDONE_SHIFT 0 +#define FSPI_INTEN_IPCMDDONE_MASK (1 << FSPI_INTEN_IPCMDDONE_SHIFT) + +#define FSPI_INTR 0x14 +#define FSPI_INTR_SCLKSBWR_SHIFT 9 +#define FSPI_INTR_SCLKSBWR_MASK (1 << FSPI_INTR_SCLKSBWR_SHIFT) +#define FSPI_INTR_SCLKSBRD_SHIFT 8 +#define FSPI_INTR_SCLKSBRD_MASK (1 << FSPI_INTR_SCLKSBRD_SHIFT) +#define FSPI_INTR_DATALRNFL_SHIFT 7 +#define FSPI_INTR_DATALRNFL_MASK (1 << FSPI_INTR_DATALRNFL_SHIFT) +#define FSPI_INTR_IPTXWE_SHIFT 6 +#define FSPI_INTR_IPTXWE_MASK (1 << FSPI_INTR_IPTXWE_SHIFT) +#define FSPI_INTR_IPRXWA_SHIFT 5 +#define FSPI_INTR_IPRXWA_MASK (1 << FSPI_INTR_IPRXWA_SHIFT) +#define FSPI_INTR_AHBCMDERR_SHIFT 4 +#define FSPI_INTR_AHBCMDERR_MASK (1 << FSPI_INTR_AHBCMDERR_SHIFT) +#define FSPI_INTR_IPCMDERR_SHIFT 3 +#define FSPI_INTR_IPCMDERR_MASK (1 << FSPI_INTR_IPCMDERR_SHIFT) +#define FSPI_INTR_AHBCMDGE_SHIFT 2 +#define FSPI_INTR_AHBCMDGE_MASK (1 << FSPI_INTR_AHBCMDGE_SHIFT) +#define FSPI_INTR_IPCMDGE_SHIFT 1 +#define FSPI_INTR_IPCMDGE_MASK (1 << FSPI_INTR_IPCMDGE_SHIFT) +#define FSPI_INTR_IPCMDDONE_SHIFT 0 +#define FSPI_INTR_IPCMDDONE_MASK (1 << FSPI_INTR_IPCMDDONE_SHIFT) + +#define FSPI_LUTKEY 0x18 +#define FSPI_LUTKEY_VALUE 0x5AF05AF0 + +#define FSPI_LCKCR 0x1C + +#define FSPI_LCKER_LOCK 0x1 +#define FSPI_LCKER_UNLOCK 0x2 + +#define FSPI_BUFXCR_INVALID_MSTRID 0xE +#define FSPI_AHBRX_BUF0CR0 0x20 +#define FSPI_AHBRX_BUF1CR0 0x24 +#define FSPI_AHBRX_BUF2CR0 0x28 +#define FSPI_AHBRX_BUF3CR0 0x2C +#define FSPI_AHBRX_BUF4CR0 0x30 +#define FSPI_AHBRX_BUF5CR0 0x34 +#define FSPI_AHBRX_BUF6CR0 0x38 +#define FSPI_AHBRX_BUF7CR0 0x3C +#define FSPI_AHBRXBUF0CR7_PREF_SHIFT 31 +#define FSPI_AHBRXBUF0CR7_PREF_MASK (1 << FSPI_AHBRXBUF0CR7_PREF_SHIFT) + +#define FSPI_AHBRX_BUF0CR1 0x40 +#define FSPI_AHBRX_BUF1CR1 0x44 +#define FSPI_AHBRX_BUF2CR1 0x48 +#define FSPI_AHBRX_BUF3CR1 0x4C +#define FSPI_AHBRX_BUF4CR1 0x50 +#define FSPI_AHBRX_BUF5CR1 0x54 +#define FSPI_AHBRX_BUF6CR1 0x58 +#define FSPI_AHBRX_BUF7CR1 0x5C +#define FSPI_BUFXCR1_MSID_SHIFT 0x0 +#define FSPI_BUFXCR1_MSID_MASK (0xF << FSPI_BUFXCR1_MSID_SHIFT) +#define FSPI_BUFXCR1_PRIO_SHIFT 0x8 +#define FSPI_BUFXCR1_PRIO_MASK (0x7 << FSPI_BUFXCR1_PRIO_SHIFT) + +#define FSPI_FLSHA1CR0 0x60 +#define FSPI_FLSHA2CR0 0x64 +#define FSPI_FLSHB1CR0 0x68 +#define FSPI_FLSHB2CR0 0x6C +#define FSPI_FLSHXCR0_SZ_SHIFT 10 +#define FSPI_FLSHXCR0_SZ_MASK (0x3FFFFF << FSPI_FLSHXCR0_SZ_SHIFT) + +#define FSPI_FLSHA1CR1 0x70 +#define FSPI_FLSHA2CR1 0x74 +#define FSPI_FLSHB1CR1 0x78 +#define FSPI_FLSHB2CR1 0x7C +#define FSPI_FLSHXCR1_CSINTR_SHIFT 16 +#define FSPI_FLSHXCR1_CSINTR_MASK \ + (0xFFFF << FSPI_FLSHXCR1_CSINTR_SHIFT) +#define FSPI_FLSHXCR1_CAS_SHIFT 11 +#define FSPI_FLSHXCR1_CAS_MASK (0xF << FSPI_FLSHXCR1_CAS_SHIFT) +#define FSPI_FLSHXCR1_WA_SHIFT 10 +#define FSPI_FLSHXCR1_WA_MASK (1 << FSPI_FLSHXCR1_WA_SHIFT) +#define FSPI_FLSHXCR1_TCSH_SHIFT 5 +#define FSPI_FLSHXCR1_TCSH_MASK (0x1F << FSPI_FLSHXCR1_TCSH_SHIFT) +#define FSPI_FLSHXCR1_TCSS_SHIFT 0 +#define FSPI_FLSHXCR1_TCSS_MASK (0x1F << FSPI_FLSHXCR1_TCSS_SHIFT) + +#define FSPI_FLSHA1CR2 0x80 +#define FSPI_FLSHA2CR2 0x84 +#define FSPI_FLSHB1CR2 0x88 +#define FSPI_FLSHB2CR2 0x8C +#define FSPI_FLSHXCR2_CLRINSP_SHIFT 24 +#define FSPI_FLSHXCR2_CLRINSP_MASK (1 << FSPI_FLSHXCR2_CLRINSP_SHIFT) +#define FSPI_FLSHXCR2_AWRWAIT_SHIFT 16 +#define FSPI_FLSHXCR2_AWRWAIT_MASK (0xFF << FSPI_FLSHXCR2_AWRWAIT_SHIFT) +#define FSPI_FLSHXCR2_AWRSEQN_SHIFT 13 +#define FSPI_FLSHXCR2_AWRSEQN_MASK (0x7 << FSPI_FLSHXCR2_AWRSEQN_SHIFT) +#define FSPI_FLSHXCR2_AWRSEQI_SHIFT 8 +#define FSPI_FLSHXCR2_AWRSEQI_MASK (0xF << FSPI_FLSHXCR2_AWRSEQI_SHIFT) +#define FSPI_FLSHXCR2_ARDSEQN_SHIFT 5 +#define FSPI_FLSHXCR2_ARDSEQN_MASK (0x7 << FSPI_FLSHXCR2_ARDSEQN_SHIFT) +#define FSPI_FLSHXCR2_ARDSEQI_SHIFT 0 +#define FSPI_FLSHXCR2_ARDSEQI_MASK (0xF << FSPI_FLSHXCR2_ARDSEQI_SHIFT) + +#define FSPI_IPCR0 0xA0 + +#define FSPI_IPCR1 0xA4 +#define FSPI_IPCR1_IPAREN_SHIFT 31 +#define FSPI_IPCR1_IPAREN_MASK (1 << FSPI_IPCR1_IPAREN_SHIFT) +#define FSPI_IPCR1_SEQNUM_SHIFT 24 +#define FSPI_IPCR1_SEQNUM_MASK (0xF << FSPI_IPCR1_SEQNUM_SHIFT) +#define FSPI_IPCR1_SEQID_SHIFT 16 +#define FSPI_IPCR1_SEQID_MASK (0xF << FSPI_IPCR1_SEQID_SHIFT) +#define FSPI_IPCR1_IDATSZ_SHIFT 0 +#define FSPI_IPCR1_IDATSZ_MASK (0xFFFF << FSPI_IPCR1_IDATSZ_SHIFT) + +#define FSPI_IPCMD 0xB0 +#define FSPI_IPCMD_TRG_SHIFT 0 +#define FSPI_IPCMD_TRG_MASK (1 << FSPI_IPCMD_TRG_SHIFT) + +#define FSPI_DLPR 0xB4 + +#define FSPI_IPRXFCR 0xB8 +#define FSPI_IPRXFCR_CLR_SHIFT 0 +#define FSPI_IPRXFCR_CLR_MASK (1 << FSPI_IPRXFCR_CLR_SHIFT) +#define FSPI_IPRXFCR_DMA_EN_SHIFT 1 +#define FSPI_IPRXFCR_DMA_EN_MASK (1 << FSPI_IPRXFCR_DMA_EN_SHIFT) +#define FSPI_IPRXFCR_WMRK_SHIFT 2 +#define FSPI_IPRXFCR_WMRK_MASK (0x1F << FSPI_IPRXFCR_WMRK_SHIFT) + +#define FSPI_IPTXFCR 0xBC +#define FSPI_IPTXFCR_CLR_SHIFT 0 +#define FSPI_IPTXFCR_CLR_MASK (1 << FSPI_IPTXFCR_CLR_SHIFT) +#define FSPI_IPTXFCR_DMA_EN_SHIFT 1 +#define FSPI_IPTXFCR_DMA_EN_MASK (1 << FSPI_IPTXFCR_DMA_EN_SHIFT) +#define FSPI_IPTXFCR_WMRK_SHIFT 2 +#define FSPI_IPTXFCR_WMRK_MASK (0x1F << FSPI_IPTXFCR_WMRK_SHIFT) + +#define FSPI_DLLACR 0xC0 +#define FSPI_DLLACR_OVRDEN_SHIFT 8 +#define FSPI_DLLACR_OVRDEN_MASK (1 << FSPI_DLLACR_OVRDEN_SHIFT) + +#define FSPI_DLLBCR 0xC4 +#define FSPI_DLLBCR_OVRDEN_SHIFT 8 +#define FSPI_DLLBCR_OVRDEN_MASK (1 << FSPI_DLLBCR_OVRDEN_SHIFT) + +#define FSPI_STS0 0xE0 +#define FSPI_STS0_DLPHA_SHIFT 9 +#define FSPI_STS0_DLPHA_MASK (0x1F << FSPI_STS0_DLPHA_SHIFT) +#define FSPI_STS0_DLPHB_SHIFT 4 +#define FSPI_STS0_DLPHB_MASK (0x1F << FSPI_STS0_DLPHB_SHIFT) +#define FSPI_STS0_CMD_SRC_SHIFT 2 +#define FSPI_STS0_CMD_SRC_MASK (3 << FSPI_STS0_CMD_SRC_SHIFT) +#define FSPI_STS0_ARB_IDLE_SHIFT 1 +#define FSPI_STS0_ARB_IDLE_MASK (1 << FSPI_STS0_ARB_IDLE_SHIFT) +#define FSPI_STS0_SEQ_IDLE_SHIFT 0 +#define FSPI_STS0_SEQ_IDLE_MASK (1 << FSPI_STS0_SEQ_IDLE_SHIFT) + +#define FSPI_STS1 0xE4 +#define FSPI_STS1_IP_ERRCD_SHIFT 24 +#define FSPI_STS1_IP_ERRCD_MASK (0xF << FSPI_STS1_IP_ERRCD_SHIFT) +#define FSPI_STS1_IP_ERRID_SHIFT 16 +#define FSPI_STS1_IP_ERRID_MASK (0xF << FSPI_STS1_IP_ERRID_SHIFT) +#define FSPI_STS1_AHB_ERRCD_SHIFT 8 +#define FSPI_STS1_AHB_ERRCD_MASK (0xF << FSPI_STS1_AHB_ERRCD_SHIFT) +#define FSPI_STS1_AHB_ERRID_SHIFT 0 +#define FSPI_STS1_AHB_ERRID_MASK (0xF << FSPI_STS1_AHB_ERRID_SHIFT) + +#define FSPI_AHBSPNST 0xEC +#define FSPI_AHBSPNST_DATLFT_SHIFT 16 +#define FSPI_AHBSPNST_DATLFT_MASK \ + (0xFFFF << FSPI_AHBSPNST_DATLFT_SHIFT) +#define FSPI_AHBSPNST_BUFID_SHIFT 1 +#define FSPI_AHBSPNST_BUFID_MASK (7 << FSPI_AHBSPNST_BUFID_SHIFT) +#define FSPI_AHBSPNST_ACTIVE_SHIFT 0 +#define FSPI_AHBSPNST_ACTIVE_MASK (1 << FSPI_AHBSPNST_ACTIVE_SHIFT) + +#define FSPI_IPRXFSTS 0xF0 +#define FSPI_IPRXFSTS_RDCNTR_SHIFT 16 +#define FSPI_IPRXFSTS_RDCNTR_MASK \ + (0xFFFF << FSPI_IPRXFSTS_RDCNTR_SHIFT) +#define FSPI_IPRXFSTS_FILL_SHIFT 0 +#define FSPI_IPRXFSTS_FILL_MASK (0xFF << FSPI_IPRXFSTS_FILL_SHIFT) + +#define FSPI_IPTXFSTS 0xF4 +#define FSPI_IPTXFSTS_WRCNTR_SHIFT 16 +#define FSPI_IPTXFSTS_WRCNTR_MASK \ + (0xFFFF << FSPI_IPTXFSTS_WRCNTR_SHIFT) +#define FSPI_IPTXFSTS_FILL_SHIFT 0 +#define FSPI_IPTXFSTS_FILL_MASK (0xFF << FSPI_IPTXFSTS_FILL_SHIFT) + +#define FSPI_RFDR 0x100 +#define FSPI_TFDR 0x180 + +#define FSPI_LUT_BASE 0x200 +#define FSPI_LUT_OFFSET (SEQID_LUT * 4 * 4) +#define FSPI_LUT_REG(idx) \ + (FSPI_LUT_BASE + FSPI_LUT_OFFSET + (idx) * 4) + +/* register map end */ + +/* Instruction set for the LUT register. */ +#define LUT_STOP 0x00 +#define LUT_CMD 0x01 +#define LUT_ADDR 0x02 +#define LUT_CADDR_SDR 0x03 +#define LUT_MODE 0x04 +#define LUT_MODE2 0x05 +#define LUT_MODE4 0x06 +#define LUT_MODE8 0x07 +#define LUT_NXP_WRITE 0x08 +#define LUT_NXP_READ 0x09 +#define LUT_LEARN_SDR 0x0A +#define LUT_DATSZ_SDR 0x0B +#define LUT_DUMMY 0x0C +#define LUT_DUMMY_RWDS_SDR 0x0D +#define LUT_JMP_ON_CS 0x1F +#define LUT_CMD_DDR 0x21 +#define LUT_ADDR_DDR 0x22 +#define LUT_CADDR_DDR 0x23 +#define LUT_MODE_DDR 0x24 +#define LUT_MODE2_DDR 0x25 +#define LUT_MODE4_DDR 0x26 +#define LUT_MODE8_DDR 0x27 +#define LUT_WRITE_DDR 0x28 +#define LUT_READ_DDR 0x29 +#define LUT_LEARN_DDR 0x2A +#define LUT_DATSZ_DDR 0x2B +#define LUT_DUMMY_DDR 0x2C +#define LUT_DUMMY_RWDS_DDR 0x2D + +/* + * Calculate number of required PAD bits for LUT register. + * + * The pad stands for the number of IO lines [0:7]. + * For example, the octal read needs eight IO lines, + * so you should use LUT_PAD(8). This macro + * returns 3 i.e. use eight (2^3) IP lines for read. + */ +#define LUT_PAD(x) (fls(x) - 1) + +/* + * Macro for constructing the LUT entries with the following + * register layout: + * + * --------------------------------------------------- + * | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | + * --------------------------------------------------- + */ +#define PAD_SHIFT 8 +#define INSTR_SHIFT 10 +#define OPRND_SHIFT 16 + +/* Macros for constructing the LUT register. */ +#define LUT_DEF(idx, ins, pad, opr) \ + ((((ins) << INSTR_SHIFT) | ((pad) << PAD_SHIFT) | \ + (opr)) << (((idx) % 2) * OPRND_SHIFT)) + +/* Oprands for the LUT register. */ +#define ADDR24BIT 0x18 +#define ADDR32BIT 0x20 + +enum nxp_fspi_devtype { + NXP_FSPI_LX2160A, +}; + +struct nxp_fspi_devtype_data { + enum nxp_fspi_devtype devtype; + unsigned int rxfifo; + unsigned int txfifo; + unsigned int ahb_buf_size; + unsigned int quirks; +}; + +static const struct nxp_fspi_devtype_data lx2160a_data = { + .devtype = NXP_FSPI_LX2160A, + .rxfifo = SZ_512, /* (64 * 64 bits) */ + .txfifo = SZ_1K, /* (128 * 64 bits) */ + .ahb_buf_size = SZ_2K, /* (256 * 64 bits) */ + .quirks = 0, +}; + +#define NXP_FSPI_MAX_CHIPSELECT 4 + +struct nxp_fspi_slave { + u32 slave_size; + u32 slave_base_addr; +}; + +struct nxp_fspi { + void __iomem *iobase; + void __iomem *ahb_addr; + u32 memmap_phy; + struct clk *clk, *clk_en; + struct device *dev; + struct completion c; + const struct nxp_fspi_devtype_data *devtype_data; + struct mutex lock; + struct pm_qos_request pm_qos_req; + struct nxp_fspi_slave slave[NXP_FSPI_MAX_CHIPSELECT]; + int selected; + u8 seq; + u32 start_addr; + u32 memmap_offs; + u32 memmap_len; + void (*write)(u32 val, void __iomem *addr); + u32 (*read)(void __iomem *addr); +}; + +static void fspi_writel_be(u32 val, void __iomem *addr) +{ + iowrite32be(val, addr); +} + +static void fspi_writel(u32 val, void __iomem *addr) +{ + iowrite32(val, addr); +} + +static u32 fspi_readl_be(void __iomem *addr) +{ + return ioread32be(addr); +} + +static u32 fspi_readl(void __iomem *addr) +{ + return ioread32(addr); +} + +static irqreturn_t nxp_fspi_irq_handler(int irq, void *dev_id) +{ + struct nxp_fspi *f = dev_id; + u32 reg; + + /* clear interrupt */ + reg = f->read(f->iobase + FSPI_INTR); + f->write(FSPI_INTR_IPCMDDONE_MASK, f->iobase + FSPI_INTR); + + if (reg & FSPI_INTR_IPCMDDONE_MASK) + complete(&f->c); + + return IRQ_HANDLED; +} + +static int nxp_fspi_check_buswidth(struct nxp_fspi *f, u8 width) +{ + switch (width) { + case 1: + case 2: + case 4: + case 8: + return 0; + } + + return -ENOTSUPP; +} + +static bool nxp_fspi_supports_op(struct spi_mem *mem, + const struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + int ret; + + ret = nxp_fspi_check_buswidth(f, op->cmd.buswidth); + + if (op->addr.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->addr.buswidth); + + if (op->dummy.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->dummy.buswidth); + + if (op->data.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->data.buswidth); + + if (ret) + return false; + + /* + * The number of instructions needed for the op, needs + * to fit into a single LUT entry. + */ + if (op->addr.nbytes + + (op->dummy.nbytes ? 1:0) + + (op->data.nbytes ? 1:0) > 6) + return false; + + /* Max 64 dummy clock cycles supported */ + if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64) + return false; + + /* Max data length, check controller limits and alignment */ + if (op->data.dir == SPI_MEM_DATA_IN && + (op->data.nbytes > f->devtype_data->ahb_buf_size || + (op->data.nbytes > f->devtype_data->rxfifo - 4 && + !IS_ALIGNED(op->data.nbytes, 8)))) + return false; + + if (op->data.dir == SPI_MEM_DATA_OUT && + op->data.nbytes > f->devtype_data->txfifo) + return false; + + return true; +} + +/* + * If the slave device content being changed by Write/Erase, need to + * invalidate the AHB buffer. This can be achieved by doing reset of the + * controller using setting SWRESET bit for MCR0 register. + */ +static inline void nxp_fspi_invalid(struct nxp_fspi *f) +{ + u32 reg; + + reg = f->read(f->iobase + FSPI_MCR0); + f->write(reg | FSPI_MCR0_SWRST_MASK, f->iobase + FSPI_MCR0); + + while (f->read(f->iobase + FSPI_MCR0) & FSPI_MCR0_SWRST_MASK) + ; +} + +static void nxp_fspi_prepare_lut(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + u32 lutval[4] = {}; + int lutidx = 1, i; + + /* cmd */ + lutval[0] |= LUT_DEF(0, LUT_CMD, LUT_PAD(op->cmd.buswidth), + op->cmd.opcode); + + /* addr bus width */ + if (op->addr.nbytes) { + u32 addrlen = (op->addr.nbytes == 3) ? ADDR24BIT : ADDR32BIT; + + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_ADDR, + LUT_PAD(op->addr.buswidth), + addrlen); + lutidx++; + } + + /* dummy bytes, if needed */ + if (op->dummy.nbytes) { + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_DUMMY, + LUT_PAD(op->dummy.buswidth), + op->dummy.nbytes * 8 / + op->dummy.buswidth); + lutidx++; + } + + /* read/write data bytes */ + if (op->data.nbytes) { + lutval[lutidx / 2] |= LUT_DEF(lutidx, + op->data.dir == SPI_MEM_DATA_IN ? + LUT_NXP_READ : LUT_NXP_WRITE, + LUT_PAD(op->data.buswidth), + 0); + lutidx++; + } + + /* stop condition. */ + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_STOP, 0, 0); + + /* unlock LUT */ + f->write(FSPI_LUTKEY_VALUE, f->iobase + FSPI_LUTKEY); + f->write(FSPI_LCKER_UNLOCK, f->iobase + FSPI_LCKCR); + + /* fill LUT */ + for (i = 0; i < ARRAY_SIZE(lutval); i++) + f->write(lutval[i], base + FSPI_LUT_REG(i)); + + dev_dbg(f->dev, "CMD[%x] lutval[0:%x \t 1:%x \t 2:%x \t 3:%x]\n", + op->cmd.opcode, lutval[0], lutval[1], lutval[2], lutval[3]); + + /* lock LUT */ + f->write(FSPI_LUTKEY_VALUE, f->iobase + FSPI_LUTKEY); + f->write(FSPI_LCKER_LOCK, f->iobase + FSPI_LCKCR); +} + +static int nxp_fspi_clk_prep_enable(struct nxp_fspi *f) +{ + int ret; + + ret = clk_prepare_enable(f->clk_en); + if (ret) + return ret; + + ret = clk_prepare_enable(f->clk); + if (ret) { + clk_disable_unprepare(f->clk_en); + return ret; + } + + return 0; +} + +static void nxp_fspi_clk_disable_unprep(struct nxp_fspi *f) +{ + clk_disable_unprepare(f->clk); + clk_disable_unprepare(f->clk_en); +} + +#define FSPI_SLAVE_MIN_SIZE SZ_2K /* ahb_buf_size */ + +/* + * In FlexSPI controller, flash access is based on value of FSPI_FLSHXXCR0 + * register and start base address of the slave device. + * + * (Higher address) + * -------- <-- FLSHB2CR0 + * | B2 | + * | | + * B2 start address --> -------- <-- FLSHB1CR0 + * | B1 | + * | | + * B1 start address --> -------- <-- FLSHA2CR0 + * | A2 | + * | | + * A2 start address --> -------- <-- FLSHA1CR0 + * | A1 | + * | | + * A1 start address --> -------- (Lower address) + * + * + * Start base address defines the starting address range for given CS and + * FSPI_FLSHXXCR0 defines the size of the slave device connected at given CS. + * For e.g. to access CS3 (B2), start base address is sum of size of the slave + * devices connected at A1, A2 and B1. + * FLSHB2CR0 register would have the value of the slave device size connected + * at CS3. + * + * Before slave device probe, slave size is programmed as 0. + * ReadId cmd (NOR slave devices) is being requested for slave device before + * device probe. For such cases, when slave size is 0, program default slave + * device size, only for the connected slave device, as + * FlexSPI controller's ahb_buf_size. + */ +static void nxp_fspi_select_mem(struct nxp_fspi *f, struct spi_device *spi) +{ + unsigned long rate = spi->max_speed_hz; + int ret; + uint64_t size_kb; + + /* + * Return, + * if previously selected slave device is same as current requested + * slave device. + * and if, slave device size has been configured correctly and is + * greater than default set size, FSPI_SLAVE_MIN_SIZE. + */ + if ((f->selected == spi->chip_select) && + (f->slave[spi->chip_select].slave_size > FSPI_SLAVE_MIN_SIZE)) + return; + + if (spi->size == 0) /* e.g. in NOR slave device for 9F (ReadId) cmd */ + size_kb = FSPI_SLAVE_MIN_SIZE >> FSPI_FLSHXCR0_SZ_SHIFT; + else + size_kb = spi->size >> FSPI_FLSHXCR0_SZ_SHIFT; + + switch (spi->chip_select) { + case 0: + f->write(size_kb, f->iobase + FSPI_FLSHA1CR0); + f->slave[0].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[0].slave_base_addr = 0; + break; + case 1: + f->write(size_kb, f->iobase + FSPI_FLSHA2CR0); + f->slave[1].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[1].slave_base_addr = f->slave[0].slave_size; + break; + case 2: + f->write(size_kb, f->iobase + FSPI_FLSHB1CR0); + f->slave[2].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[2].slave_base_addr = f->slave[0].slave_size + + f->slave[1].slave_size; + break; + case 3: + f->write(size_kb, f->iobase + FSPI_FLSHB2CR0); + f->slave[3].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[3].slave_base_addr = f->slave[0].slave_size + + f->slave[1].slave_size + + f->slave[2].slave_size; + break; + default: + return; + } + + f->start_addr = f->slave[spi->chip_select].slave_base_addr; + + dev_dbg(f->dev, "Slave device [CS:%x size:%x start_addr:0x%08x]\n", + spi->chip_select, spi->size, f->start_addr); + + nxp_fspi_clk_disable_unprep(f); + + ret = clk_set_rate(f->clk, rate); + if (ret) + return; + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) + return; + f->selected = spi->chip_select; +} + +#define FSPI_MIN_IOMAP SZ_4M + +static void nxp_fspi_read_ahb(struct nxp_fspi *f, const struct spi_mem_op *op) +{ + u32 len = op->data.nbytes; + + /* if necessary, ioremap buffer before AHB read . */ + if (!f->ahb_addr) { + f->memmap_offs = f->start_addr + op->addr.val; + f->memmap_len = len > FSPI_MIN_IOMAP ? len : FSPI_MIN_IOMAP; + f->ahb_addr = ioremap_nocache(f->memmap_phy + f->memmap_offs, + f->memmap_len); + if (!f->ahb_addr) { + dev_err(f->dev, "ioremap failed\n"); + return; + } + } else if (f->start_addr + op->addr.val < f->memmap_offs + || f->start_addr + op->addr.val + len > + f->memmap_offs + f->memmap_len) { + + iounmap(f->ahb_addr); + + f->memmap_offs = f->start_addr + op->addr.val; + f->memmap_len = len > FSPI_MIN_IOMAP ? len : FSPI_MIN_IOMAP; + f->ahb_addr = ioremap_nocache(f->memmap_phy + f->memmap_offs, + f->memmap_len); + if (!f->ahb_addr) { + dev_err(f->dev, "ioremap failed\n"); + return; + } + } + memcpy_fromio(op->data.buf.in, (f->ahb_addr + f->start_addr + + op->addr.val - f->memmap_offs), len); +} + +static void nxp_fspi_fill_txfifo(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int i, j; + int size, tmp_size; + u32 data = 0; + u32 *txbuf = (u32 *) op->data.buf.out; + + /* clear the TX FIFO. */ + f->write(FSPI_IPTXFCR_CLR_MASK, base + FSPI_IPTXFCR); + + size = op->data.nbytes / 8; + for (i = 0; i < size; i++) { + /* Wait for TXFIFO empty */ + while (!(f->read(base + FSPI_INTR) & FSPI_INTR_IPTXWE_MASK)) + ; + + j = 0; + tmp_size = 8; + while (tmp_size > 0) { + data = 0; + memcpy(&data, txbuf, 4); + f->write(data, base + FSPI_TFDR + j * 4); + tmp_size -= 4; + j++; + txbuf += 1; + } + f->write(FSPI_INTR_IPTXWE_MASK, base + FSPI_INTR); + } + + size = op->data.nbytes % 8; + if (size) { + /* Wait for TXFIFO empty */ + while (!(f->read(base + FSPI_INTR) & FSPI_INTR_IPTXWE_MASK)) + ; + j = 0; + tmp_size = 0; + while (size > 0) { + data = 0; + tmp_size = (size < 4) ? size : 4; + memcpy(&data, txbuf, tmp_size); + f->write(data, base + FSPI_TFDR + j * 4); + size -= tmp_size; + j++; + txbuf += 1; + } + f->write(FSPI_INTR_IPTXWE_MASK, base + FSPI_INTR); + } +} + +static void nxp_fspi_read_rxfifo(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int i, j; + int size, tmp_size; + u32 tmp = 0; + u8 *buf = op->data.buf.in; + u32 len = op->data.nbytes; + + while (len > 0) { + size = len / 8; + + for (i = 0; i < size; i++) { + /* Wait for RXFIFO available */ + while (!(f->read(base + FSPI_INTR) + & FSPI_INTR_IPRXWA_MASK)) + ; + + j = 0; + tmp_size = 8; + while (tmp_size > 0) { + tmp = 0; + tmp = f->read(base + FSPI_RFDR + j * 4); + memcpy(buf, &tmp, 4); + tmp_size -= 4; + j++; + buf += 4; + } + /* move the FIFO pointer */ + f->write(FSPI_INTR_IPRXWA_MASK, base + FSPI_INTR); + len -= 8; + } + + size = len % 8; + + j = 0; + if (size) { + /* Wait for RXFIFO available */ + while (!(f->read(base + FSPI_INTR) + & FSPI_INTR_IPRXWA_MASK)) + ; + + while (len > 0) { + tmp = 0; + size = (len < 4) ? len : 4; + tmp = f->read(base + FSPI_RFDR + j * 4); + memcpy(buf, &tmp, size); + len -= size; + j++; + buf += size; + } + } + + /* invalid the RXFIFO */ + f->write(FSPI_IPRXFCR_CLR_MASK, base + FSPI_IPRXFCR); + /* move the FIFO pointer */ + f->write(FSPI_INTR_IPRXWA_MASK, base + FSPI_INTR); + } +} + +static int nxp_fspi_do_op(struct nxp_fspi *f, const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int seqnum = 0; + int err = 0; + u32 reg; + + reg = f->read(base + FSPI_IPRXFCR); + /* invalid RXFIFO first */ + reg &= ~FSPI_IPRXFCR_DMA_EN_MASK; + reg = reg | FSPI_IPRXFCR_CLR_MASK; + f->write(reg, base + FSPI_IPRXFCR); + + init_completion(&f->c); + + f->write(f->start_addr + op->addr.val, base + FSPI_IPCR0); + /* + * Always start the sequence at the same index since we update + * the LUT at each exec_op() call. And also specify the DATA + * length, since it's has not been specified in the LUT. + */ + f->write(op->data.nbytes | + (SEQID_LUT << FSPI_IPCR1_SEQID_SHIFT) | + (seqnum << FSPI_IPCR1_SEQNUM_SHIFT), + base + FSPI_IPCR1); + + /* trigger the LUT now */ + f->write(FSPI_IPCMD_TRG_MASK, base + FSPI_IPCMD); + + /* Wait for the interrupt. */ + if (!wait_for_completion_timeout(&f->c, msecs_to_jiffies(1000))) + err = -ETIMEDOUT; + + if (!err && op->data.nbytes && op->data.dir == SPI_MEM_DATA_IN) + nxp_fspi_read_rxfifo(f, op); + + return err; +} + +static int nxp_fspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + void __iomem *base = f->iobase; + int err = 0; + unsigned int timeout = 1000; + + mutex_lock(&f->lock); + + /* wait for the controller being ready */ + do { + u32 status; + + status = f->read(base + FSPI_STS0); + if ((status & FSPI_STS0_ARB_IDLE_MASK) && + (status & FSPI_STS0_SEQ_IDLE_MASK)) + break; + udelay(1); + dev_dbg(f->dev, "The controller is busy, 0x%x\n", status); + } while (--timeout); + + nxp_fspi_select_mem(f, mem->spi); + + nxp_fspi_prepare_lut(f, op); + /* + * If we have large chunks of data, we read them through the AHB bus + * by accessing the mapped memory. In all other cases we use + * IP commands to access the flash. + */ + if (op->data.nbytes > (f->devtype_data->rxfifo - 4) && + op->data.dir == SPI_MEM_DATA_IN) { + nxp_fspi_read_ahb(f, op); + } else { + if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT) + nxp_fspi_fill_txfifo(f, op); + + err = nxp_fspi_do_op(f, op); + + /* Invalidate the data in the AHB buffer. */ + if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT) + nxp_fspi_invalid(f); + } + + mutex_unlock(&f->lock); + + return err; +} + +static int nxp_fspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + + if (op->data.dir == SPI_MEM_DATA_OUT) { + if (op->data.nbytes > f->devtype_data->txfifo) + op->data.nbytes = f->devtype_data->txfifo; + } else { + if (op->data.nbytes > f->devtype_data->ahb_buf_size) + op->data.nbytes = f->devtype_data->ahb_buf_size; + else if (op->data.nbytes > (f->devtype_data->rxfifo - 4)) + op->data.nbytes = ALIGN_DOWN(op->data.nbytes, 8); + } + + return 0; +} + +static int nxp_fspi_default_setup(struct nxp_fspi *f) +{ + void __iomem *base = f->iobase; + int ret, i; + u32 reg; + + /* disable and unprepare clock to avoid glitch pass to controller */ + nxp_fspi_clk_disable_unprep(f); + + /* the default frequency, we will change it later if necessary. */ + ret = clk_set_rate(f->clk, 20000000); + if (ret) + return ret; + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) + return ret; + + /* Reset the module */ + f->write(FSPI_MCR0_SWRST_MASK, base + FSPI_MCR0); + do { + udelay(1); + } while (f->read(f->iobase + FSPI_MCR0) & FSPI_MCR0_SWRST_MASK); + + /* Disable the module */ + f->write(FSPI_MCR0_MDIS_MASK, base + FSPI_MCR0); + + /* Reset the DLL register to default value */ + f->write(FSPI_DLLACR_OVRDEN_MASK, base + FSPI_DLLACR); + f->write(FSPI_DLLBCR_OVRDEN_MASK, base + FSPI_DLLBCR); + + /* enable module */ + f->write(FSPI_MCR0_AHB_TIMEOUT_MASK | FSPI_MCR0_IP_TIMEOUT_MASK, + base + FSPI_MCR0); + + /* + * Disable same device enable bit and configure all slave devices + * independently. + */ + reg = f->read(f->iobase + FSPI_MCR2); + reg = reg & ~(1 << (FSPI_MCR2_SAMEDEVICEEN_SHIFT)); + f->write(reg, base + FSPI_MCR2); + + /* AHB configuration for access buffer 0~7. */ + for (i = 0; i < 7; i++) + f->write(0, base + FSPI_AHBRX_BUF0CR0 + 4 * i); + + /* + * Set ADATSZ with the maximum AHB buffer size to improve the read + * performance. + */ + f->write((f->devtype_data->ahb_buf_size / 8 | + FSPI_AHBRXBUF0CR7_PREF_MASK), base + FSPI_AHBRX_BUF7CR0); + + /* prefetch and no start address alignment limitation */ + f->write(FSPI_AHBCR_PREF_EN_MASK | FSPI_AHBCR_RDADDROPT_MASK, + base + FSPI_AHBCR); + + /* Set lut sequence ID for AHB Read. */ + f->write(SEQID_LUT, base + FSPI_FLSHA1CR2); + + f->selected = -1; + f->seq = 0; + + /* enable the interrupt */ + f->write(FSPI_INTEN_IPCMDDONE_MASK, base + FSPI_INTEN); + + return 0; +} + +static const struct spi_controller_mem_ops nxp_fspi_mem_ops = { + .adjust_op_size = nxp_fspi_adjust_op_size, + .supports_op = nxp_fspi_supports_op, + .exec_op = nxp_fspi_exec_op, +}; + +static int nxp_fspi_probe(struct platform_device *pdev) +{ + struct spi_controller *ctlr; + struct device *dev = &pdev->dev; + struct device_node *np = dev->of_node; + struct resource *res; + struct nxp_fspi *f; + int ret; + + ctlr = spi_alloc_master(&pdev->dev, sizeof(*f)); + if (!ctlr) + return -ENOMEM; + + ctlr->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL | + SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL; + + f = spi_controller_get_devdata(ctlr); + f->dev = dev; + f->devtype_data = of_device_get_match_data(dev); + if (!f->devtype_data) { + ret = -ENODEV; + goto err_put_ctrl; + } + + platform_set_drvdata(pdev, f); + + /* find the resources - configuration register address space */ + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_base"); + f->iobase = devm_ioremap_resource(dev, res); + if (IS_ERR(f->iobase)) { + ret = PTR_ERR(f->iobase); + goto err_put_ctrl; + } + + /* + * R/W functions for big- or little-endian registers: + * The FSPI controller's endianness is independent of + * the CPU core's endianness. So far, although the CPU + * core is little-endian the FSPI controller can use + * big-endian or little-endian. + */ + if (of_property_read_bool(np, "big-endian")) { + f->write = fspi_writel_be; + f->read = fspi_readl_be; + } else { + f->write = fspi_writel; + f->read = fspi_readl; + } + + /* find the resources - controller memory mapped space */ + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_mmap"); + + if (!devm_request_mem_region(dev, res->start, resource_size(res), + res->name)) { + dev_err(dev, "can't request region for resource %pR\n", res); + ret = -EBUSY; + goto err_put_ctrl; + } + + f->memmap_phy = res->start; + + /* find the clocks */ + f->clk_en = devm_clk_get(dev, "fspi_en"); + if (IS_ERR(f->clk_en)) { + ret = PTR_ERR(f->clk_en); + goto err_put_ctrl; + } + + f->clk = devm_clk_get(dev, "fspi"); + if (IS_ERR(f->clk)) { + ret = PTR_ERR(f->clk); + goto err_put_ctrl; + } + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) { + dev_err(dev, "can not enable the clock\n"); + goto err_put_ctrl; + } + + /* find the irq */ + ret = platform_get_irq(pdev, 0); + if (ret < 0) { + dev_err(dev, "failed to get the irq: %d\n", ret); + goto err_disable_clk; + } + + ret = devm_request_irq(dev, ret, + nxp_fspi_irq_handler, 0, pdev->name, f); + if (ret) { + dev_err(dev, "failed to request irq: %d\n", ret); + goto err_disable_clk; + } + + mutex_init(&f->lock); + + ctlr->bus_num = -1; + ctlr->num_chipselect = NXP_FSPI_MAX_CHIPSELECT; + ctlr->mem_ops = &nxp_fspi_mem_ops; + + nxp_fspi_default_setup(f); + + ctlr->dev.of_node = np; + + ret = spi_register_controller(ctlr); + if (ret) + goto err_destroy_mutex; + + return 0; + +err_destroy_mutex: + mutex_destroy(&f->lock); + +err_disable_clk: + nxp_fspi_clk_disable_unprep(f); + +err_put_ctrl: + spi_controller_put(ctlr); + + dev_err(dev, "NXP FSPI probe failed\n"); + return ret; +} + +static int nxp_fspi_remove(struct platform_device *pdev) +{ + struct nxp_fspi *f = platform_get_drvdata(pdev); + + /* disable the hardware */ + f->write(FSPI_MCR0_MDIS_MASK, f->iobase + FSPI_MCR0); + + nxp_fspi_clk_disable_unprep(f); + + mutex_destroy(&f->lock); + + if (f->ahb_addr) + iounmap(f->ahb_addr); + + return 0; +} + +static int nxp_fspi_suspend(struct device *dev) +{ + return 0; +} + +static int nxp_fspi_resume(struct device *dev) +{ + struct nxp_fspi *f = dev_get_drvdata(dev); + + nxp_fspi_default_setup(f); + + return 0; +} + +static const struct of_device_id nxp_fspi_dt_ids[] = { + { .compatible = "nxp,lx2160a-fspi", .data = (void *)&lx2160a_data, }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, nxp_fspi_dt_ids); + +static const struct dev_pm_ops nxp_fspi_pm_ops = { + .suspend = nxp_fspi_suspend, + .resume = nxp_fspi_resume, +}; + +static struct platform_driver nxp_fspi_driver = { + .driver = { + .name = "nxp-fspi", + .of_match_table = nxp_fspi_dt_ids, + .pm = &nxp_fspi_pm_ops, + }, + .probe = nxp_fspi_probe, + .remove = nxp_fspi_remove, +}; +module_platform_driver(nxp_fspi_driver); + +MODULE_DESCRIPTION("NXP FSPI Controller Driver"); +MODULE_AUTHOR("NXP Semiconductors"); +MODULE_LICENSE("GPL v2"); -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-08-31 10:30 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-arm-kernel - Add a driver for NXP FlexSPI host controller (0) What is the FlexSPI controller? FlexSPI is a flexsible SPI host controller which supports two SPI channels and up to 4 external devices. Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8 bidirectional data lines. It uses new SPI memory interface of the SPI framework to issue flash memory operations to up to four connected flash chips (2 buses with 2 CS each). Chipselect for each flash can be selected as per address assigned in controller specific registers. FlexSPI controller is similar to the existing Freescale/NXP QuadSPI controller with advanced features. (1) The FlexSPI controller is driven by the LUT(Look-up Table) registers. The LUT registers are a look-up-table for sequences of instructions. A valid sequence consists of four LUT registers. Maximum 32 LUT sequences can be programmed simultaneously. (2) The definition of the LUT register shows below: --------------------------------------------------- | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | --------------------------------------------------- There are several types of INSTRx, such as: CMD : the SPI NOR command. ADDR : the address for the SPI NOR command. DUMMY : the dummy cycles needed by the SPI NOR command. .... There are several types of PADx, such as: PAD1 : use a singe I/O line. PAD2 : use two I/O lines. PAD4 : use quad I/O lines. PAD8 : use octal I/O lines. .... (3) LUTs are being created at run-time based on the commands passed from the spi-mem framework. Thus, using single LUT index. (4) Software triggered Flash read/write access by IP Bus. (5) Memory mapped read access by AHB Bus. (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility on NXP LX2160ARDB and LX2160AQDS targets. LX2160ARDB is having two NOR slave device connected on single bus A i.e. A0 and A1 (CS0 and CS1). LX2160AQDS is having two NOR slave device connected on separate buses one flash on A0 and second on B1 i.e. (CS0 and CS3). Verified this driver on following SPI NOR flashes: Micron, mt35xu512ab, [Read - 1 bit mode] Cypress, s25fl512s, [Read - 1/2/4 bit mode] - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. - Add entry in the 'spi-nor/Makefile'. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- drivers/spi/Kconfig | 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1253 insertions(+) create mode 100644 drivers/spi/spi-nxp-fspi.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index ad5d68e..68da874 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -251,6 +251,16 @@ config SPI_FSL_LPSPI help This enables Freescale i.MX LPSPI controllers in master mode. +config SPI_NXP_FLEXSPI + tristate "NXP Flex SPI controller" + depends on ARCH_LAYERSCAPE || HAS_IOMEM + help + This enables support for the Flex SPI controller in master mode. + Up to four slave devices can be connected on two buses with two + chipselects each. + This controller does not support generic SPI messages and only + supports the high-level SPI memory interface. + config SPI_GPIO tristate "GPIO-based bitbanging SPI Master" depends on GPIOLIB || COMPILE_TEST diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index cb1f437..52c9f18 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -59,6 +59,7 @@ obj-$(CONFIG_SPI_MPC52xx) += spi-mpc52xx.o obj-$(CONFIG_SPI_MT65XX) += spi-mt65xx.o obj-$(CONFIG_SPI_MXS) += spi-mxs.o obj-$(CONFIG_SPI_NUC900) += spi-nuc900.o +obj-$(CONFIG_SPI_NXP_FLEXSPI) += spi-nxp-fspi.o obj-$(CONFIG_SPI_OC_TINY) += spi-oc-tiny.o spi-octeon-objs := spi-cavium.o spi-cavium-octeon.o obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c new file mode 100644 index 0000000..677401b --- /dev/null +++ b/drivers/spi/spi-nxp-fspi.c @@ -0,0 +1,1242 @@ +// SPDX-License-Identifier: GPL-2.0+ + +/* + * NXP FlexSPI(FSPI) controller driver. + * + * Copyright 2018 NXP + * + * Based on SPI MEM interface: + * Author: + * Yogesh Gaur <yogeshnarayan.gaur@nxp.com> + */ + +#include <linux/bitops.h> +#include <linux/clk.h> +#include <linux/completion.h> +#include <linux/delay.h> +#include <linux/err.h> +#include <linux/errno.h> +#include <linux/interrupt.h> +#include <linux/io.h> +#include <linux/jiffies.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/platform_device.h> +#include <linux/pm_qos.h> +#include <linux/sizes.h> + +#include <linux/spi/spi.h> +#include <linux/spi/spi-mem.h> + +/* + * The driver only uses one single LUT entry, that is updated on + * each call of exec_op(). Index 0 is preset at boot with a basic + * read operation, so let's use the last entry (31). + */ +#define SEQID_LUT 31 + +/* Registers used by the driver */ +#define FSPI_MCR0 0x00 +#define FSPI_MCR0_AHB_TIMEOUT_SHIFT 24 +#define FSPI_MCR0_AHB_TIMEOUT_MASK (0xFF << FSPI_MCR0_AHB_TIMEOUT_SHIFT) +#define FSPI_MCR0_IP_TIMEOUT_SHIFT 16 +#define FSPI_MCR0_IP_TIMEOUT_MASK (0xFF << FSPI_MCR0_IP_TIMEOUT_SHIFT) +#define FSPI_MCR0_LEARN_EN_SHIFT 15 +#define FSPI_MCR0_LEARN_EN_MASK (1 << FSPI_MCR0_LEARN_EN_SHIFT) +#define FSPI_MCR0_SCRFRUN_EN_SHIFT 14 +#define FSPI_MCR0_SCRFRUN_EN_MASK (1 << FSPI_MCR0_SCRFRUN_EN_SHIFT) +#define FSPI_MCR0_OCTCOMB_EN_SHIFT 13 +#define FSPI_MCR0_OCTCOMB_EN_MASK (1 << FSPI_MCR0_OCTCOMB_EN_SHIFT) +#define FSPI_MCR0_DOZE_EN_SHIFT 12 +#define FSPI_MCR0_DOZE_EN_MASK (1 << FSPI_MCR0_DOZE_EN_SHIFT) +#define FSPI_MCR0_HSEN_SHIFT 11 +#define FSPI_MCR0_HSEN_MASK (1 << FSPI_MCR0_HSEN_SHIFT) +#define FSPI_MCR0_SERCLKDIV_SHIFT 8 +#define FSPI_MCR0_SERCLKDIV_MASK (7 << FSPI_MCR0_SERCLKDIV_SHIFT) +#define FSPI_MCR0_ATDF_EN_SHIFT 7 +#define FSPI_MCR0_ATDF_EN_MASK (1 << FSPI_MCR0_ATDF_EN_SHIFT) +#define FSPI_MCR0_ARDF_EN_SHIFT 6 +#define FSPI_MCR0_ARDF_EN_MASK (1 << FSPI_MCR0_ARDF_EN_SHIFT) +#define FSPI_MCR0_RXCLKSRC_SHIFT 4 +#define FSPI_MCR0_RXCLKSRC_MASK (3 << FSPI_MCR0_RXCLKSRC_SHIFT) +#define FSPI_MCR0_END_CFG_SHIFT 2 +#define FSPI_MCR0_END_CFG_MASK (3 << FSPI_MCR0_END_CFG_SHIFT) +#define FSPI_MCR0_MDIS_SHIFT 1 +#define FSPI_MCR0_MDIS_MASK (1 << FSPI_MCR0_MDIS_SHIFT) +#define FSPI_MCR0_SWRST_SHIFT 0 +#define FSPI_MCR0_SWRST_MASK (1 << FSPI_MCR0_SWRST_SHIFT) + +#define FSPI_MCR1 0x04 +#define FSPI_MCR1_SEQ_TIMEOUT_SHIFT 16 +#define FSPI_MCR1_SEQ_TIMEOUT_MASK (0xFFFF << FSPI_MCR1_SEQ_TIMEOUT_SHIFT) +#define FSPI_MCR1_AHB_TIMEOUT_SHIFT 0 +#define FSPI_MCR1_AHB_TIMEOUT_MASK (0xFFFF << FSPI_MCR1_AHB_TIMEOUT_SHIFT) + +#define FSPI_MCR2 0x08 +#define FSPI_MCR2_IDLE_WAIT_SHIFT 24 +#define FSPI_MCR2_IDLE_WAIT_MASK (0xFF << FSPI_MCR2_IDLE_WAIT_SHIFT) +#define FSPI_MCR2_SAMEDEVICEEN_SHIFT 15 +#define FSPI_MCR2_SAMEDEVICEEN_MASK (1 << FSPI_MCR2_SAMEDEVICEEN_SHIFT) +#define FSPI_MCR2_CLRLRPHS_SHIFT 14 +#define FSPI_MCR2_CLRLRPHS_MASK (1 << FSPI_MCR2_CLRLRPHS_SHIFT) +#define FSPI_MCR2_ABRDATSZ_SHIFT 8 +#define FSPI_MCR2_ABRDATSZ_MASK (1 << FSPI_MCR2_ABRDATSZ_SHIFT) +#define FSPI_MCR2_ABRLEARN_SHIFT 7 +#define FSPI_MCR2_ABRLEARN_MASK (1 << FSPI_MCR2_ABRLEARN_SHIFT) +#define FSPI_MCR2_ABR_READ_SHIFT 6 +#define FSPI_MCR2_ABR_READ_MASK (1 << FSPI_MCR2_ABR_READ_SHIFT) +#define FSPI_MCR2_ABRWRITE_SHIFT 5 +#define FSPI_MCR2_ABRWRITE_MASK (1 << FSPI_MCR2_ABRWRITE_SHIFT) +#define FSPI_MCR2_ABRDUMMY_SHIFT 4 +#define FSPI_MCR2_ABRDUMMY_MASK (1 << FSPI_MCR2_ABRDUMMY_SHIFT) +#define FSPI_MCR2_ABR_MODE_SHIFT 3 +#define FSPI_MCR2_ABR_MODE_MASK (1 << FSPI_MCR2_ABR_MODE_SHIFT) +#define FSPI_MCR2_ABRCADDR_SHIFT 2 +#define FSPI_MCR2_ABRCADDR_MASK (1 << FSPI_MCR2_ABRCADDR_SHIFT) +#define FSPI_MCR2_ABRRADDR_SHIFT 1 +#define FSPI_MCR2_ABRRADDR_MASK (1 << FSPI_MCR2_ABRRADDR_SHIFT) +#define FSPI_MCR2_ABR_CMD_SHIFT 0 +#define FSPI_MCR2_ABR_CMD_MASK (1 << FSPI_MCR2_ABR_CMD_SHIFT) + +#define FSPI_AHBCR 0x0c +#define FSPI_AHBCR_RDADDROPT_SHIFT 6 +#define FSPI_AHBCR_RDADDROPT_MASK (1 << FSPI_AHBCR_RDADDROPT_SHIFT) +#define FSPI_AHBCR_PREF_EN_SHIFT 5 +#define FSPI_AHBCR_PREF_EN_MASK (1 << FSPI_AHBCR_PREF_EN_SHIFT) +#define FSPI_AHBCR_BUFF_EN_SHIFT 4 +#define FSPI_AHBCR_BUFF_EN_MASK (1 << FSPI_AHBCR_BUFF_EN_SHIFT) +#define FSPI_AHBCR_CACH_EN_SHIFT 3 +#define FSPI_AHBCR_CACH_EN_MASK (1 << FSPI_AHBCR_CACH_EN_SHIFT) +#define FSPI_AHBCR_CLRTXBUF_SHIFT 2 +#define FSPI_AHBCR_CLRTXBUF_MASK (1 << FSPI_AHBCR_CLRTXBUF_SHIFT) +#define FSPI_AHBCR_CLRRXBUF_SHIFT 1 +#define FSPI_AHBCR_CLRRXBUF_MASK (1 << FSPI_AHBCR_CLRRXBUF_SHIFT) +#define FSPI_AHBCR_PAR_EN_SHIFT 0 +#define FSPI_AHBCR_PAR_EN_MASK (1 << FSPI_AHBCR_PAR_EN_SHIFT) + +#define FSPI_INTEN 0x10 +#define FSPI_INTEN_SCLKSBWR_SHIFT 9 +#define FSPI_INTEN_SCLKSBWR_MASK (1 << FSPI_INTEN_SCLKSBWR_SHIFT) +#define FSPI_INTEN_SCLKSBRD_SHIFT 8 +#define FSPI_INTEN_SCLKSBRD_MASK (1 << FSPI_INTEN_SCLKSBRD_SHIFT) +#define FSPI_INTEN_DATALRNFL_SHIFT 7 +#define FSPI_INTEN_DATALRNFL_MASK (1 << FSPI_INTEN_DATALRNFL_SHIFT) +#define FSPI_INTEN_IPTXWE_SHIFT 6 +#define FSPI_INTEN_IPTXWE_MASK (1 << FSPI_INTEN_IPTXWE_SHIFT) +#define FSPI_INTEN_IPRXWA_SHIFT 5 +#define FSPI_INTEN_IPRXWA_MASK (1 << FSPI_INTEN_IPRXWA_SHIFT) +#define FSPI_INTEN_AHBCMDERR_SHIFT 4 +#define FSPI_INTEN_AHBCMDERR_MASK (1 << FSPI_INTEN_AHBCMDERR_SHIFT) +#define FSPI_INTEN_IPCMDERR_SHIFT 3 +#define FSPI_INTEN_IPCMDERR_MASK (1 << FSPI_INTEN_IPCMDERR_SHIFT) +#define FSPI_INTEN_AHBCMDGE_SHIFT 2 +#define FSPI_INTEN_AHBCMDGE_MASK (1 << FSPI_INTEN_AHBCMDGE_SHIFT) +#define FSPI_INTEN_IPCMDGE_SHIFT 1 +#define FSPI_INTEN_IPCMDGE_MASK (1 << FSPI_INTEN_IPCMDGE_SHIFT) +#define FSPI_INTEN_IPCMDDONE_SHIFT 0 +#define FSPI_INTEN_IPCMDDONE_MASK (1 << FSPI_INTEN_IPCMDDONE_SHIFT) + +#define FSPI_INTR 0x14 +#define FSPI_INTR_SCLKSBWR_SHIFT 9 +#define FSPI_INTR_SCLKSBWR_MASK (1 << FSPI_INTR_SCLKSBWR_SHIFT) +#define FSPI_INTR_SCLKSBRD_SHIFT 8 +#define FSPI_INTR_SCLKSBRD_MASK (1 << FSPI_INTR_SCLKSBRD_SHIFT) +#define FSPI_INTR_DATALRNFL_SHIFT 7 +#define FSPI_INTR_DATALRNFL_MASK (1 << FSPI_INTR_DATALRNFL_SHIFT) +#define FSPI_INTR_IPTXWE_SHIFT 6 +#define FSPI_INTR_IPTXWE_MASK (1 << FSPI_INTR_IPTXWE_SHIFT) +#define FSPI_INTR_IPRXWA_SHIFT 5 +#define FSPI_INTR_IPRXWA_MASK (1 << FSPI_INTR_IPRXWA_SHIFT) +#define FSPI_INTR_AHBCMDERR_SHIFT 4 +#define FSPI_INTR_AHBCMDERR_MASK (1 << FSPI_INTR_AHBCMDERR_SHIFT) +#define FSPI_INTR_IPCMDERR_SHIFT 3 +#define FSPI_INTR_IPCMDERR_MASK (1 << FSPI_INTR_IPCMDERR_SHIFT) +#define FSPI_INTR_AHBCMDGE_SHIFT 2 +#define FSPI_INTR_AHBCMDGE_MASK (1 << FSPI_INTR_AHBCMDGE_SHIFT) +#define FSPI_INTR_IPCMDGE_SHIFT 1 +#define FSPI_INTR_IPCMDGE_MASK (1 << FSPI_INTR_IPCMDGE_SHIFT) +#define FSPI_INTR_IPCMDDONE_SHIFT 0 +#define FSPI_INTR_IPCMDDONE_MASK (1 << FSPI_INTR_IPCMDDONE_SHIFT) + +#define FSPI_LUTKEY 0x18 +#define FSPI_LUTKEY_VALUE 0x5AF05AF0 + +#define FSPI_LCKCR 0x1C + +#define FSPI_LCKER_LOCK 0x1 +#define FSPI_LCKER_UNLOCK 0x2 + +#define FSPI_BUFXCR_INVALID_MSTRID 0xE +#define FSPI_AHBRX_BUF0CR0 0x20 +#define FSPI_AHBRX_BUF1CR0 0x24 +#define FSPI_AHBRX_BUF2CR0 0x28 +#define FSPI_AHBRX_BUF3CR0 0x2C +#define FSPI_AHBRX_BUF4CR0 0x30 +#define FSPI_AHBRX_BUF5CR0 0x34 +#define FSPI_AHBRX_BUF6CR0 0x38 +#define FSPI_AHBRX_BUF7CR0 0x3C +#define FSPI_AHBRXBUF0CR7_PREF_SHIFT 31 +#define FSPI_AHBRXBUF0CR7_PREF_MASK (1 << FSPI_AHBRXBUF0CR7_PREF_SHIFT) + +#define FSPI_AHBRX_BUF0CR1 0x40 +#define FSPI_AHBRX_BUF1CR1 0x44 +#define FSPI_AHBRX_BUF2CR1 0x48 +#define FSPI_AHBRX_BUF3CR1 0x4C +#define FSPI_AHBRX_BUF4CR1 0x50 +#define FSPI_AHBRX_BUF5CR1 0x54 +#define FSPI_AHBRX_BUF6CR1 0x58 +#define FSPI_AHBRX_BUF7CR1 0x5C +#define FSPI_BUFXCR1_MSID_SHIFT 0x0 +#define FSPI_BUFXCR1_MSID_MASK (0xF << FSPI_BUFXCR1_MSID_SHIFT) +#define FSPI_BUFXCR1_PRIO_SHIFT 0x8 +#define FSPI_BUFXCR1_PRIO_MASK (0x7 << FSPI_BUFXCR1_PRIO_SHIFT) + +#define FSPI_FLSHA1CR0 0x60 +#define FSPI_FLSHA2CR0 0x64 +#define FSPI_FLSHB1CR0 0x68 +#define FSPI_FLSHB2CR0 0x6C +#define FSPI_FLSHXCR0_SZ_SHIFT 10 +#define FSPI_FLSHXCR0_SZ_MASK (0x3FFFFF << FSPI_FLSHXCR0_SZ_SHIFT) + +#define FSPI_FLSHA1CR1 0x70 +#define FSPI_FLSHA2CR1 0x74 +#define FSPI_FLSHB1CR1 0x78 +#define FSPI_FLSHB2CR1 0x7C +#define FSPI_FLSHXCR1_CSINTR_SHIFT 16 +#define FSPI_FLSHXCR1_CSINTR_MASK \ + (0xFFFF << FSPI_FLSHXCR1_CSINTR_SHIFT) +#define FSPI_FLSHXCR1_CAS_SHIFT 11 +#define FSPI_FLSHXCR1_CAS_MASK (0xF << FSPI_FLSHXCR1_CAS_SHIFT) +#define FSPI_FLSHXCR1_WA_SHIFT 10 +#define FSPI_FLSHXCR1_WA_MASK (1 << FSPI_FLSHXCR1_WA_SHIFT) +#define FSPI_FLSHXCR1_TCSH_SHIFT 5 +#define FSPI_FLSHXCR1_TCSH_MASK (0x1F << FSPI_FLSHXCR1_TCSH_SHIFT) +#define FSPI_FLSHXCR1_TCSS_SHIFT 0 +#define FSPI_FLSHXCR1_TCSS_MASK (0x1F << FSPI_FLSHXCR1_TCSS_SHIFT) + +#define FSPI_FLSHA1CR2 0x80 +#define FSPI_FLSHA2CR2 0x84 +#define FSPI_FLSHB1CR2 0x88 +#define FSPI_FLSHB2CR2 0x8C +#define FSPI_FLSHXCR2_CLRINSP_SHIFT 24 +#define FSPI_FLSHXCR2_CLRINSP_MASK (1 << FSPI_FLSHXCR2_CLRINSP_SHIFT) +#define FSPI_FLSHXCR2_AWRWAIT_SHIFT 16 +#define FSPI_FLSHXCR2_AWRWAIT_MASK (0xFF << FSPI_FLSHXCR2_AWRWAIT_SHIFT) +#define FSPI_FLSHXCR2_AWRSEQN_SHIFT 13 +#define FSPI_FLSHXCR2_AWRSEQN_MASK (0x7 << FSPI_FLSHXCR2_AWRSEQN_SHIFT) +#define FSPI_FLSHXCR2_AWRSEQI_SHIFT 8 +#define FSPI_FLSHXCR2_AWRSEQI_MASK (0xF << FSPI_FLSHXCR2_AWRSEQI_SHIFT) +#define FSPI_FLSHXCR2_ARDSEQN_SHIFT 5 +#define FSPI_FLSHXCR2_ARDSEQN_MASK (0x7 << FSPI_FLSHXCR2_ARDSEQN_SHIFT) +#define FSPI_FLSHXCR2_ARDSEQI_SHIFT 0 +#define FSPI_FLSHXCR2_ARDSEQI_MASK (0xF << FSPI_FLSHXCR2_ARDSEQI_SHIFT) + +#define FSPI_IPCR0 0xA0 + +#define FSPI_IPCR1 0xA4 +#define FSPI_IPCR1_IPAREN_SHIFT 31 +#define FSPI_IPCR1_IPAREN_MASK (1 << FSPI_IPCR1_IPAREN_SHIFT) +#define FSPI_IPCR1_SEQNUM_SHIFT 24 +#define FSPI_IPCR1_SEQNUM_MASK (0xF << FSPI_IPCR1_SEQNUM_SHIFT) +#define FSPI_IPCR1_SEQID_SHIFT 16 +#define FSPI_IPCR1_SEQID_MASK (0xF << FSPI_IPCR1_SEQID_SHIFT) +#define FSPI_IPCR1_IDATSZ_SHIFT 0 +#define FSPI_IPCR1_IDATSZ_MASK (0xFFFF << FSPI_IPCR1_IDATSZ_SHIFT) + +#define FSPI_IPCMD 0xB0 +#define FSPI_IPCMD_TRG_SHIFT 0 +#define FSPI_IPCMD_TRG_MASK (1 << FSPI_IPCMD_TRG_SHIFT) + +#define FSPI_DLPR 0xB4 + +#define FSPI_IPRXFCR 0xB8 +#define FSPI_IPRXFCR_CLR_SHIFT 0 +#define FSPI_IPRXFCR_CLR_MASK (1 << FSPI_IPRXFCR_CLR_SHIFT) +#define FSPI_IPRXFCR_DMA_EN_SHIFT 1 +#define FSPI_IPRXFCR_DMA_EN_MASK (1 << FSPI_IPRXFCR_DMA_EN_SHIFT) +#define FSPI_IPRXFCR_WMRK_SHIFT 2 +#define FSPI_IPRXFCR_WMRK_MASK (0x1F << FSPI_IPRXFCR_WMRK_SHIFT) + +#define FSPI_IPTXFCR 0xBC +#define FSPI_IPTXFCR_CLR_SHIFT 0 +#define FSPI_IPTXFCR_CLR_MASK (1 << FSPI_IPTXFCR_CLR_SHIFT) +#define FSPI_IPTXFCR_DMA_EN_SHIFT 1 +#define FSPI_IPTXFCR_DMA_EN_MASK (1 << FSPI_IPTXFCR_DMA_EN_SHIFT) +#define FSPI_IPTXFCR_WMRK_SHIFT 2 +#define FSPI_IPTXFCR_WMRK_MASK (0x1F << FSPI_IPTXFCR_WMRK_SHIFT) + +#define FSPI_DLLACR 0xC0 +#define FSPI_DLLACR_OVRDEN_SHIFT 8 +#define FSPI_DLLACR_OVRDEN_MASK (1 << FSPI_DLLACR_OVRDEN_SHIFT) + +#define FSPI_DLLBCR 0xC4 +#define FSPI_DLLBCR_OVRDEN_SHIFT 8 +#define FSPI_DLLBCR_OVRDEN_MASK (1 << FSPI_DLLBCR_OVRDEN_SHIFT) + +#define FSPI_STS0 0xE0 +#define FSPI_STS0_DLPHA_SHIFT 9 +#define FSPI_STS0_DLPHA_MASK (0x1F << FSPI_STS0_DLPHA_SHIFT) +#define FSPI_STS0_DLPHB_SHIFT 4 +#define FSPI_STS0_DLPHB_MASK (0x1F << FSPI_STS0_DLPHB_SHIFT) +#define FSPI_STS0_CMD_SRC_SHIFT 2 +#define FSPI_STS0_CMD_SRC_MASK (3 << FSPI_STS0_CMD_SRC_SHIFT) +#define FSPI_STS0_ARB_IDLE_SHIFT 1 +#define FSPI_STS0_ARB_IDLE_MASK (1 << FSPI_STS0_ARB_IDLE_SHIFT) +#define FSPI_STS0_SEQ_IDLE_SHIFT 0 +#define FSPI_STS0_SEQ_IDLE_MASK (1 << FSPI_STS0_SEQ_IDLE_SHIFT) + +#define FSPI_STS1 0xE4 +#define FSPI_STS1_IP_ERRCD_SHIFT 24 +#define FSPI_STS1_IP_ERRCD_MASK (0xF << FSPI_STS1_IP_ERRCD_SHIFT) +#define FSPI_STS1_IP_ERRID_SHIFT 16 +#define FSPI_STS1_IP_ERRID_MASK (0xF << FSPI_STS1_IP_ERRID_SHIFT) +#define FSPI_STS1_AHB_ERRCD_SHIFT 8 +#define FSPI_STS1_AHB_ERRCD_MASK (0xF << FSPI_STS1_AHB_ERRCD_SHIFT) +#define FSPI_STS1_AHB_ERRID_SHIFT 0 +#define FSPI_STS1_AHB_ERRID_MASK (0xF << FSPI_STS1_AHB_ERRID_SHIFT) + +#define FSPI_AHBSPNST 0xEC +#define FSPI_AHBSPNST_DATLFT_SHIFT 16 +#define FSPI_AHBSPNST_DATLFT_MASK \ + (0xFFFF << FSPI_AHBSPNST_DATLFT_SHIFT) +#define FSPI_AHBSPNST_BUFID_SHIFT 1 +#define FSPI_AHBSPNST_BUFID_MASK (7 << FSPI_AHBSPNST_BUFID_SHIFT) +#define FSPI_AHBSPNST_ACTIVE_SHIFT 0 +#define FSPI_AHBSPNST_ACTIVE_MASK (1 << FSPI_AHBSPNST_ACTIVE_SHIFT) + +#define FSPI_IPRXFSTS 0xF0 +#define FSPI_IPRXFSTS_RDCNTR_SHIFT 16 +#define FSPI_IPRXFSTS_RDCNTR_MASK \ + (0xFFFF << FSPI_IPRXFSTS_RDCNTR_SHIFT) +#define FSPI_IPRXFSTS_FILL_SHIFT 0 +#define FSPI_IPRXFSTS_FILL_MASK (0xFF << FSPI_IPRXFSTS_FILL_SHIFT) + +#define FSPI_IPTXFSTS 0xF4 +#define FSPI_IPTXFSTS_WRCNTR_SHIFT 16 +#define FSPI_IPTXFSTS_WRCNTR_MASK \ + (0xFFFF << FSPI_IPTXFSTS_WRCNTR_SHIFT) +#define FSPI_IPTXFSTS_FILL_SHIFT 0 +#define FSPI_IPTXFSTS_FILL_MASK (0xFF << FSPI_IPTXFSTS_FILL_SHIFT) + +#define FSPI_RFDR 0x100 +#define FSPI_TFDR 0x180 + +#define FSPI_LUT_BASE 0x200 +#define FSPI_LUT_OFFSET (SEQID_LUT * 4 * 4) +#define FSPI_LUT_REG(idx) \ + (FSPI_LUT_BASE + FSPI_LUT_OFFSET + (idx) * 4) + +/* register map end */ + +/* Instruction set for the LUT register. */ +#define LUT_STOP 0x00 +#define LUT_CMD 0x01 +#define LUT_ADDR 0x02 +#define LUT_CADDR_SDR 0x03 +#define LUT_MODE 0x04 +#define LUT_MODE2 0x05 +#define LUT_MODE4 0x06 +#define LUT_MODE8 0x07 +#define LUT_NXP_WRITE 0x08 +#define LUT_NXP_READ 0x09 +#define LUT_LEARN_SDR 0x0A +#define LUT_DATSZ_SDR 0x0B +#define LUT_DUMMY 0x0C +#define LUT_DUMMY_RWDS_SDR 0x0D +#define LUT_JMP_ON_CS 0x1F +#define LUT_CMD_DDR 0x21 +#define LUT_ADDR_DDR 0x22 +#define LUT_CADDR_DDR 0x23 +#define LUT_MODE_DDR 0x24 +#define LUT_MODE2_DDR 0x25 +#define LUT_MODE4_DDR 0x26 +#define LUT_MODE8_DDR 0x27 +#define LUT_WRITE_DDR 0x28 +#define LUT_READ_DDR 0x29 +#define LUT_LEARN_DDR 0x2A +#define LUT_DATSZ_DDR 0x2B +#define LUT_DUMMY_DDR 0x2C +#define LUT_DUMMY_RWDS_DDR 0x2D + +/* + * Calculate number of required PAD bits for LUT register. + * + * The pad stands for the number of IO lines [0:7]. + * For example, the octal read needs eight IO lines, + * so you should use LUT_PAD(8). This macro + * returns 3 i.e. use eight (2^3) IP lines for read. + */ +#define LUT_PAD(x) (fls(x) - 1) + +/* + * Macro for constructing the LUT entries with the following + * register layout: + * + * --------------------------------------------------- + * | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | + * --------------------------------------------------- + */ +#define PAD_SHIFT 8 +#define INSTR_SHIFT 10 +#define OPRND_SHIFT 16 + +/* Macros for constructing the LUT register. */ +#define LUT_DEF(idx, ins, pad, opr) \ + ((((ins) << INSTR_SHIFT) | ((pad) << PAD_SHIFT) | \ + (opr)) << (((idx) % 2) * OPRND_SHIFT)) + +/* Oprands for the LUT register. */ +#define ADDR24BIT 0x18 +#define ADDR32BIT 0x20 + +enum nxp_fspi_devtype { + NXP_FSPI_LX2160A, +}; + +struct nxp_fspi_devtype_data { + enum nxp_fspi_devtype devtype; + unsigned int rxfifo; + unsigned int txfifo; + unsigned int ahb_buf_size; + unsigned int quirks; +}; + +static const struct nxp_fspi_devtype_data lx2160a_data = { + .devtype = NXP_FSPI_LX2160A, + .rxfifo = SZ_512, /* (64 * 64 bits) */ + .txfifo = SZ_1K, /* (128 * 64 bits) */ + .ahb_buf_size = SZ_2K, /* (256 * 64 bits) */ + .quirks = 0, +}; + +#define NXP_FSPI_MAX_CHIPSELECT 4 + +struct nxp_fspi_slave { + u32 slave_size; + u32 slave_base_addr; +}; + +struct nxp_fspi { + void __iomem *iobase; + void __iomem *ahb_addr; + u32 memmap_phy; + struct clk *clk, *clk_en; + struct device *dev; + struct completion c; + const struct nxp_fspi_devtype_data *devtype_data; + struct mutex lock; + struct pm_qos_request pm_qos_req; + struct nxp_fspi_slave slave[NXP_FSPI_MAX_CHIPSELECT]; + int selected; + u8 seq; + u32 start_addr; + u32 memmap_offs; + u32 memmap_len; + void (*write)(u32 val, void __iomem *addr); + u32 (*read)(void __iomem *addr); +}; + +static void fspi_writel_be(u32 val, void __iomem *addr) +{ + iowrite32be(val, addr); +} + +static void fspi_writel(u32 val, void __iomem *addr) +{ + iowrite32(val, addr); +} + +static u32 fspi_readl_be(void __iomem *addr) +{ + return ioread32be(addr); +} + +static u32 fspi_readl(void __iomem *addr) +{ + return ioread32(addr); +} + +static irqreturn_t nxp_fspi_irq_handler(int irq, void *dev_id) +{ + struct nxp_fspi *f = dev_id; + u32 reg; + + /* clear interrupt */ + reg = f->read(f->iobase + FSPI_INTR); + f->write(FSPI_INTR_IPCMDDONE_MASK, f->iobase + FSPI_INTR); + + if (reg & FSPI_INTR_IPCMDDONE_MASK) + complete(&f->c); + + return IRQ_HANDLED; +} + +static int nxp_fspi_check_buswidth(struct nxp_fspi *f, u8 width) +{ + switch (width) { + case 1: + case 2: + case 4: + case 8: + return 0; + } + + return -ENOTSUPP; +} + +static bool nxp_fspi_supports_op(struct spi_mem *mem, + const struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + int ret; + + ret = nxp_fspi_check_buswidth(f, op->cmd.buswidth); + + if (op->addr.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->addr.buswidth); + + if (op->dummy.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->dummy.buswidth); + + if (op->data.nbytes) + ret |= nxp_fspi_check_buswidth(f, op->data.buswidth); + + if (ret) + return false; + + /* + * The number of instructions needed for the op, needs + * to fit into a single LUT entry. + */ + if (op->addr.nbytes + + (op->dummy.nbytes ? 1:0) + + (op->data.nbytes ? 1:0) > 6) + return false; + + /* Max 64 dummy clock cycles supported */ + if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64) + return false; + + /* Max data length, check controller limits and alignment */ + if (op->data.dir == SPI_MEM_DATA_IN && + (op->data.nbytes > f->devtype_data->ahb_buf_size || + (op->data.nbytes > f->devtype_data->rxfifo - 4 && + !IS_ALIGNED(op->data.nbytes, 8)))) + return false; + + if (op->data.dir == SPI_MEM_DATA_OUT && + op->data.nbytes > f->devtype_data->txfifo) + return false; + + return true; +} + +/* + * If the slave device content being changed by Write/Erase, need to + * invalidate the AHB buffer. This can be achieved by doing reset of the + * controller using setting SWRESET bit for MCR0 register. + */ +static inline void nxp_fspi_invalid(struct nxp_fspi *f) +{ + u32 reg; + + reg = f->read(f->iobase + FSPI_MCR0); + f->write(reg | FSPI_MCR0_SWRST_MASK, f->iobase + FSPI_MCR0); + + while (f->read(f->iobase + FSPI_MCR0) & FSPI_MCR0_SWRST_MASK) + ; +} + +static void nxp_fspi_prepare_lut(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + u32 lutval[4] = {}; + int lutidx = 1, i; + + /* cmd */ + lutval[0] |= LUT_DEF(0, LUT_CMD, LUT_PAD(op->cmd.buswidth), + op->cmd.opcode); + + /* addr bus width */ + if (op->addr.nbytes) { + u32 addrlen = (op->addr.nbytes == 3) ? ADDR24BIT : ADDR32BIT; + + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_ADDR, + LUT_PAD(op->addr.buswidth), + addrlen); + lutidx++; + } + + /* dummy bytes, if needed */ + if (op->dummy.nbytes) { + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_DUMMY, + LUT_PAD(op->dummy.buswidth), + op->dummy.nbytes * 8 / + op->dummy.buswidth); + lutidx++; + } + + /* read/write data bytes */ + if (op->data.nbytes) { + lutval[lutidx / 2] |= LUT_DEF(lutidx, + op->data.dir == SPI_MEM_DATA_IN ? + LUT_NXP_READ : LUT_NXP_WRITE, + LUT_PAD(op->data.buswidth), + 0); + lutidx++; + } + + /* stop condition. */ + lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_STOP, 0, 0); + + /* unlock LUT */ + f->write(FSPI_LUTKEY_VALUE, f->iobase + FSPI_LUTKEY); + f->write(FSPI_LCKER_UNLOCK, f->iobase + FSPI_LCKCR); + + /* fill LUT */ + for (i = 0; i < ARRAY_SIZE(lutval); i++) + f->write(lutval[i], base + FSPI_LUT_REG(i)); + + dev_dbg(f->dev, "CMD[%x] lutval[0:%x \t 1:%x \t 2:%x \t 3:%x]\n", + op->cmd.opcode, lutval[0], lutval[1], lutval[2], lutval[3]); + + /* lock LUT */ + f->write(FSPI_LUTKEY_VALUE, f->iobase + FSPI_LUTKEY); + f->write(FSPI_LCKER_LOCK, f->iobase + FSPI_LCKCR); +} + +static int nxp_fspi_clk_prep_enable(struct nxp_fspi *f) +{ + int ret; + + ret = clk_prepare_enable(f->clk_en); + if (ret) + return ret; + + ret = clk_prepare_enable(f->clk); + if (ret) { + clk_disable_unprepare(f->clk_en); + return ret; + } + + return 0; +} + +static void nxp_fspi_clk_disable_unprep(struct nxp_fspi *f) +{ + clk_disable_unprepare(f->clk); + clk_disable_unprepare(f->clk_en); +} + +#define FSPI_SLAVE_MIN_SIZE SZ_2K /* ahb_buf_size */ + +/* + * In FlexSPI controller, flash access is based on value of FSPI_FLSHXXCR0 + * register and start base address of the slave device. + * + * (Higher address) + * -------- <-- FLSHB2CR0 + * | B2 | + * | | + * B2 start address --> -------- <-- FLSHB1CR0 + * | B1 | + * | | + * B1 start address --> -------- <-- FLSHA2CR0 + * | A2 | + * | | + * A2 start address --> -------- <-- FLSHA1CR0 + * | A1 | + * | | + * A1 start address --> -------- (Lower address) + * + * + * Start base address defines the starting address range for given CS and + * FSPI_FLSHXXCR0 defines the size of the slave device connected at given CS. + * For e.g. to access CS3 (B2), start base address is sum of size of the slave + * devices connected at A1, A2 and B1. + * FLSHB2CR0 register would have the value of the slave device size connected + * at CS3. + * + * Before slave device probe, slave size is programmed as 0. + * ReadId cmd (NOR slave devices) is being requested for slave device before + * device probe. For such cases, when slave size is 0, program default slave + * device size, only for the connected slave device, as + * FlexSPI controller's ahb_buf_size. + */ +static void nxp_fspi_select_mem(struct nxp_fspi *f, struct spi_device *spi) +{ + unsigned long rate = spi->max_speed_hz; + int ret; + uint64_t size_kb; + + /* + * Return, + * if previously selected slave device is same as current requested + * slave device. + * and if, slave device size has been configured correctly and is + * greater than default set size, FSPI_SLAVE_MIN_SIZE. + */ + if ((f->selected == spi->chip_select) && + (f->slave[spi->chip_select].slave_size > FSPI_SLAVE_MIN_SIZE)) + return; + + if (spi->size == 0) /* e.g. in NOR slave device for 9F (ReadId) cmd */ + size_kb = FSPI_SLAVE_MIN_SIZE >> FSPI_FLSHXCR0_SZ_SHIFT; + else + size_kb = spi->size >> FSPI_FLSHXCR0_SZ_SHIFT; + + switch (spi->chip_select) { + case 0: + f->write(size_kb, f->iobase + FSPI_FLSHA1CR0); + f->slave[0].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[0].slave_base_addr = 0; + break; + case 1: + f->write(size_kb, f->iobase + FSPI_FLSHA2CR0); + f->slave[1].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[1].slave_base_addr = f->slave[0].slave_size; + break; + case 2: + f->write(size_kb, f->iobase + FSPI_FLSHB1CR0); + f->slave[2].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[2].slave_base_addr = f->slave[0].slave_size + + f->slave[1].slave_size; + break; + case 3: + f->write(size_kb, f->iobase + FSPI_FLSHB2CR0); + f->slave[3].slave_size = size_kb << FSPI_FLSHXCR0_SZ_SHIFT; + f->slave[3].slave_base_addr = f->slave[0].slave_size + + f->slave[1].slave_size + + f->slave[2].slave_size; + break; + default: + return; + } + + f->start_addr = f->slave[spi->chip_select].slave_base_addr; + + dev_dbg(f->dev, "Slave device [CS:%x size:%x start_addr:0x%08x]\n", + spi->chip_select, spi->size, f->start_addr); + + nxp_fspi_clk_disable_unprep(f); + + ret = clk_set_rate(f->clk, rate); + if (ret) + return; + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) + return; + f->selected = spi->chip_select; +} + +#define FSPI_MIN_IOMAP SZ_4M + +static void nxp_fspi_read_ahb(struct nxp_fspi *f, const struct spi_mem_op *op) +{ + u32 len = op->data.nbytes; + + /* if necessary, ioremap buffer before AHB read . */ + if (!f->ahb_addr) { + f->memmap_offs = f->start_addr + op->addr.val; + f->memmap_len = len > FSPI_MIN_IOMAP ? len : FSPI_MIN_IOMAP; + f->ahb_addr = ioremap_nocache(f->memmap_phy + f->memmap_offs, + f->memmap_len); + if (!f->ahb_addr) { + dev_err(f->dev, "ioremap failed\n"); + return; + } + } else if (f->start_addr + op->addr.val < f->memmap_offs + || f->start_addr + op->addr.val + len > + f->memmap_offs + f->memmap_len) { + + iounmap(f->ahb_addr); + + f->memmap_offs = f->start_addr + op->addr.val; + f->memmap_len = len > FSPI_MIN_IOMAP ? len : FSPI_MIN_IOMAP; + f->ahb_addr = ioremap_nocache(f->memmap_phy + f->memmap_offs, + f->memmap_len); + if (!f->ahb_addr) { + dev_err(f->dev, "ioremap failed\n"); + return; + } + } + memcpy_fromio(op->data.buf.in, (f->ahb_addr + f->start_addr + + op->addr.val - f->memmap_offs), len); +} + +static void nxp_fspi_fill_txfifo(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int i, j; + int size, tmp_size; + u32 data = 0; + u32 *txbuf = (u32 *) op->data.buf.out; + + /* clear the TX FIFO. */ + f->write(FSPI_IPTXFCR_CLR_MASK, base + FSPI_IPTXFCR); + + size = op->data.nbytes / 8; + for (i = 0; i < size; i++) { + /* Wait for TXFIFO empty */ + while (!(f->read(base + FSPI_INTR) & FSPI_INTR_IPTXWE_MASK)) + ; + + j = 0; + tmp_size = 8; + while (tmp_size > 0) { + data = 0; + memcpy(&data, txbuf, 4); + f->write(data, base + FSPI_TFDR + j * 4); + tmp_size -= 4; + j++; + txbuf += 1; + } + f->write(FSPI_INTR_IPTXWE_MASK, base + FSPI_INTR); + } + + size = op->data.nbytes % 8; + if (size) { + /* Wait for TXFIFO empty */ + while (!(f->read(base + FSPI_INTR) & FSPI_INTR_IPTXWE_MASK)) + ; + j = 0; + tmp_size = 0; + while (size > 0) { + data = 0; + tmp_size = (size < 4) ? size : 4; + memcpy(&data, txbuf, tmp_size); + f->write(data, base + FSPI_TFDR + j * 4); + size -= tmp_size; + j++; + txbuf += 1; + } + f->write(FSPI_INTR_IPTXWE_MASK, base + FSPI_INTR); + } +} + +static void nxp_fspi_read_rxfifo(struct nxp_fspi *f, + const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int i, j; + int size, tmp_size; + u32 tmp = 0; + u8 *buf = op->data.buf.in; + u32 len = op->data.nbytes; + + while (len > 0) { + size = len / 8; + + for (i = 0; i < size; i++) { + /* Wait for RXFIFO available */ + while (!(f->read(base + FSPI_INTR) + & FSPI_INTR_IPRXWA_MASK)) + ; + + j = 0; + tmp_size = 8; + while (tmp_size > 0) { + tmp = 0; + tmp = f->read(base + FSPI_RFDR + j * 4); + memcpy(buf, &tmp, 4); + tmp_size -= 4; + j++; + buf += 4; + } + /* move the FIFO pointer */ + f->write(FSPI_INTR_IPRXWA_MASK, base + FSPI_INTR); + len -= 8; + } + + size = len % 8; + + j = 0; + if (size) { + /* Wait for RXFIFO available */ + while (!(f->read(base + FSPI_INTR) + & FSPI_INTR_IPRXWA_MASK)) + ; + + while (len > 0) { + tmp = 0; + size = (len < 4) ? len : 4; + tmp = f->read(base + FSPI_RFDR + j * 4); + memcpy(buf, &tmp, size); + len -= size; + j++; + buf += size; + } + } + + /* invalid the RXFIFO */ + f->write(FSPI_IPRXFCR_CLR_MASK, base + FSPI_IPRXFCR); + /* move the FIFO pointer */ + f->write(FSPI_INTR_IPRXWA_MASK, base + FSPI_INTR); + } +} + +static int nxp_fspi_do_op(struct nxp_fspi *f, const struct spi_mem_op *op) +{ + void __iomem *base = f->iobase; + int seqnum = 0; + int err = 0; + u32 reg; + + reg = f->read(base + FSPI_IPRXFCR); + /* invalid RXFIFO first */ + reg &= ~FSPI_IPRXFCR_DMA_EN_MASK; + reg = reg | FSPI_IPRXFCR_CLR_MASK; + f->write(reg, base + FSPI_IPRXFCR); + + init_completion(&f->c); + + f->write(f->start_addr + op->addr.val, base + FSPI_IPCR0); + /* + * Always start the sequence at the same index since we update + * the LUT at each exec_op() call. And also specify the DATA + * length, since it's has not been specified in the LUT. + */ + f->write(op->data.nbytes | + (SEQID_LUT << FSPI_IPCR1_SEQID_SHIFT) | + (seqnum << FSPI_IPCR1_SEQNUM_SHIFT), + base + FSPI_IPCR1); + + /* trigger the LUT now */ + f->write(FSPI_IPCMD_TRG_MASK, base + FSPI_IPCMD); + + /* Wait for the interrupt. */ + if (!wait_for_completion_timeout(&f->c, msecs_to_jiffies(1000))) + err = -ETIMEDOUT; + + if (!err && op->data.nbytes && op->data.dir == SPI_MEM_DATA_IN) + nxp_fspi_read_rxfifo(f, op); + + return err; +} + +static int nxp_fspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + void __iomem *base = f->iobase; + int err = 0; + unsigned int timeout = 1000; + + mutex_lock(&f->lock); + + /* wait for the controller being ready */ + do { + u32 status; + + status = f->read(base + FSPI_STS0); + if ((status & FSPI_STS0_ARB_IDLE_MASK) && + (status & FSPI_STS0_SEQ_IDLE_MASK)) + break; + udelay(1); + dev_dbg(f->dev, "The controller is busy, 0x%x\n", status); + } while (--timeout); + + nxp_fspi_select_mem(f, mem->spi); + + nxp_fspi_prepare_lut(f, op); + /* + * If we have large chunks of data, we read them through the AHB bus + * by accessing the mapped memory. In all other cases we use + * IP commands to access the flash. + */ + if (op->data.nbytes > (f->devtype_data->rxfifo - 4) && + op->data.dir == SPI_MEM_DATA_IN) { + nxp_fspi_read_ahb(f, op); + } else { + if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT) + nxp_fspi_fill_txfifo(f, op); + + err = nxp_fspi_do_op(f, op); + + /* Invalidate the data in the AHB buffer. */ + if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT) + nxp_fspi_invalid(f); + } + + mutex_unlock(&f->lock); + + return err; +} + +static int nxp_fspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op) +{ + struct nxp_fspi *f = spi_controller_get_devdata(mem->spi->master); + + if (op->data.dir == SPI_MEM_DATA_OUT) { + if (op->data.nbytes > f->devtype_data->txfifo) + op->data.nbytes = f->devtype_data->txfifo; + } else { + if (op->data.nbytes > f->devtype_data->ahb_buf_size) + op->data.nbytes = f->devtype_data->ahb_buf_size; + else if (op->data.nbytes > (f->devtype_data->rxfifo - 4)) + op->data.nbytes = ALIGN_DOWN(op->data.nbytes, 8); + } + + return 0; +} + +static int nxp_fspi_default_setup(struct nxp_fspi *f) +{ + void __iomem *base = f->iobase; + int ret, i; + u32 reg; + + /* disable and unprepare clock to avoid glitch pass to controller */ + nxp_fspi_clk_disable_unprep(f); + + /* the default frequency, we will change it later if necessary. */ + ret = clk_set_rate(f->clk, 20000000); + if (ret) + return ret; + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) + return ret; + + /* Reset the module */ + f->write(FSPI_MCR0_SWRST_MASK, base + FSPI_MCR0); + do { + udelay(1); + } while (f->read(f->iobase + FSPI_MCR0) & FSPI_MCR0_SWRST_MASK); + + /* Disable the module */ + f->write(FSPI_MCR0_MDIS_MASK, base + FSPI_MCR0); + + /* Reset the DLL register to default value */ + f->write(FSPI_DLLACR_OVRDEN_MASK, base + FSPI_DLLACR); + f->write(FSPI_DLLBCR_OVRDEN_MASK, base + FSPI_DLLBCR); + + /* enable module */ + f->write(FSPI_MCR0_AHB_TIMEOUT_MASK | FSPI_MCR0_IP_TIMEOUT_MASK, + base + FSPI_MCR0); + + /* + * Disable same device enable bit and configure all slave devices + * independently. + */ + reg = f->read(f->iobase + FSPI_MCR2); + reg = reg & ~(1 << (FSPI_MCR2_SAMEDEVICEEN_SHIFT)); + f->write(reg, base + FSPI_MCR2); + + /* AHB configuration for access buffer 0~7. */ + for (i = 0; i < 7; i++) + f->write(0, base + FSPI_AHBRX_BUF0CR0 + 4 * i); + + /* + * Set ADATSZ with the maximum AHB buffer size to improve the read + * performance. + */ + f->write((f->devtype_data->ahb_buf_size / 8 | + FSPI_AHBRXBUF0CR7_PREF_MASK), base + FSPI_AHBRX_BUF7CR0); + + /* prefetch and no start address alignment limitation */ + f->write(FSPI_AHBCR_PREF_EN_MASK | FSPI_AHBCR_RDADDROPT_MASK, + base + FSPI_AHBCR); + + /* Set lut sequence ID for AHB Read. */ + f->write(SEQID_LUT, base + FSPI_FLSHA1CR2); + + f->selected = -1; + f->seq = 0; + + /* enable the interrupt */ + f->write(FSPI_INTEN_IPCMDDONE_MASK, base + FSPI_INTEN); + + return 0; +} + +static const struct spi_controller_mem_ops nxp_fspi_mem_ops = { + .adjust_op_size = nxp_fspi_adjust_op_size, + .supports_op = nxp_fspi_supports_op, + .exec_op = nxp_fspi_exec_op, +}; + +static int nxp_fspi_probe(struct platform_device *pdev) +{ + struct spi_controller *ctlr; + struct device *dev = &pdev->dev; + struct device_node *np = dev->of_node; + struct resource *res; + struct nxp_fspi *f; + int ret; + + ctlr = spi_alloc_master(&pdev->dev, sizeof(*f)); + if (!ctlr) + return -ENOMEM; + + ctlr->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD | SPI_RX_OCTAL | + SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL; + + f = spi_controller_get_devdata(ctlr); + f->dev = dev; + f->devtype_data = of_device_get_match_data(dev); + if (!f->devtype_data) { + ret = -ENODEV; + goto err_put_ctrl; + } + + platform_set_drvdata(pdev, f); + + /* find the resources - configuration register address space */ + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_base"); + f->iobase = devm_ioremap_resource(dev, res); + if (IS_ERR(f->iobase)) { + ret = PTR_ERR(f->iobase); + goto err_put_ctrl; + } + + /* + * R/W functions for big- or little-endian registers: + * The FSPI controller's endianness is independent of + * the CPU core's endianness. So far, although the CPU + * core is little-endian the FSPI controller can use + * big-endian or little-endian. + */ + if (of_property_read_bool(np, "big-endian")) { + f->write = fspi_writel_be; + f->read = fspi_readl_be; + } else { + f->write = fspi_writel; + f->read = fspi_readl; + } + + /* find the resources - controller memory mapped space */ + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "fspi_mmap"); + + if (!devm_request_mem_region(dev, res->start, resource_size(res), + res->name)) { + dev_err(dev, "can't request region for resource %pR\n", res); + ret = -EBUSY; + goto err_put_ctrl; + } + + f->memmap_phy = res->start; + + /* find the clocks */ + f->clk_en = devm_clk_get(dev, "fspi_en"); + if (IS_ERR(f->clk_en)) { + ret = PTR_ERR(f->clk_en); + goto err_put_ctrl; + } + + f->clk = devm_clk_get(dev, "fspi"); + if (IS_ERR(f->clk)) { + ret = PTR_ERR(f->clk); + goto err_put_ctrl; + } + + ret = nxp_fspi_clk_prep_enable(f); + if (ret) { + dev_err(dev, "can not enable the clock\n"); + goto err_put_ctrl; + } + + /* find the irq */ + ret = platform_get_irq(pdev, 0); + if (ret < 0) { + dev_err(dev, "failed to get the irq: %d\n", ret); + goto err_disable_clk; + } + + ret = devm_request_irq(dev, ret, + nxp_fspi_irq_handler, 0, pdev->name, f); + if (ret) { + dev_err(dev, "failed to request irq: %d\n", ret); + goto err_disable_clk; + } + + mutex_init(&f->lock); + + ctlr->bus_num = -1; + ctlr->num_chipselect = NXP_FSPI_MAX_CHIPSELECT; + ctlr->mem_ops = &nxp_fspi_mem_ops; + + nxp_fspi_default_setup(f); + + ctlr->dev.of_node = np; + + ret = spi_register_controller(ctlr); + if (ret) + goto err_destroy_mutex; + + return 0; + +err_destroy_mutex: + mutex_destroy(&f->lock); + +err_disable_clk: + nxp_fspi_clk_disable_unprep(f); + +err_put_ctrl: + spi_controller_put(ctlr); + + dev_err(dev, "NXP FSPI probe failed\n"); + return ret; +} + +static int nxp_fspi_remove(struct platform_device *pdev) +{ + struct nxp_fspi *f = platform_get_drvdata(pdev); + + /* disable the hardware */ + f->write(FSPI_MCR0_MDIS_MASK, f->iobase + FSPI_MCR0); + + nxp_fspi_clk_disable_unprep(f); + + mutex_destroy(&f->lock); + + if (f->ahb_addr) + iounmap(f->ahb_addr); + + return 0; +} + +static int nxp_fspi_suspend(struct device *dev) +{ + return 0; +} + +static int nxp_fspi_resume(struct device *dev) +{ + struct nxp_fspi *f = dev_get_drvdata(dev); + + nxp_fspi_default_setup(f); + + return 0; +} + +static const struct of_device_id nxp_fspi_dt_ids[] = { + { .compatible = "nxp,lx2160a-fspi", .data = (void *)&lx2160a_data, }, + { /* sentinel */ } +}; +MODULE_DEVICE_TABLE(of, nxp_fspi_dt_ids); + +static const struct dev_pm_ops nxp_fspi_pm_ops = { + .suspend = nxp_fspi_suspend, + .resume = nxp_fspi_resume, +}; + +static struct platform_driver nxp_fspi_driver = { + .driver = { + .name = "nxp-fspi", + .of_match_table = nxp_fspi_dt_ids, + .pm = &nxp_fspi_pm_ops, + }, + .probe = nxp_fspi_probe, + .remove = nxp_fspi_remove, +}; +module_platform_driver(nxp_fspi_driver); + +MODULE_DESCRIPTION("NXP FSPI Controller Driver"); +MODULE_AUTHOR("NXP Semiconductors"); +MODULE_LICENSE("GPL v2"); -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-08-31 10:30 ` Yogesh Gaur @ 2018-09-04 14:58 ` Boris Brezillon -1 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 14:58 UTC (permalink / raw) To: Yogesh Gaur Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Yogesh, On Fri, 31 Aug 2018 16:00:00 +0530 Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > - Add a driver for NXP FlexSPI host controller > > (0) What is the FlexSPI controller? > FlexSPI is a flexsible SPI host controller which supports two SPI > channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data > transfer (1/2/4/8 bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, > maximum 4, each with up to 8 bidirectional data lines. > > It uses new SPI memory interface of the SPI framework to issue flash > memory operations to up to four connected flash chips (2 buses with > 2 CS each). > Chipselect for each flash can be selected as per address assigned in > controller specific registers. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. Yep, I had a quick look at the code and they really look similar. Why not extending the existing driver instead of creating a new one from scratch? > > (1) The FlexSPI controller is driven by the LUT(Look-up Table) > registers. > The LUT registers are a look-up-table for sequences of instructions. > A valid sequence consists of four LUT registers. > Maximum 32 LUT sequences can be programmed simultaneously. > > (2) The definition of the LUT register shows below: > --------------------------------------------------- > | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | > --------------------------------------------------- > > There are several types of INSTRx, such as: > CMD : the SPI NOR command. > ADDR : the address for the SPI NOR command. > DUMMY : the dummy cycles needed by the SPI NOR command. > .... > > There are several types of PADx, such as: > PAD1 : use a singe I/O line. > PAD2 : use two I/O lines. > PAD4 : use quad I/O lines. > PAD8 : use octal I/O lines. > .... > > (3) LUTs are being created at run-time based on the commands passed > from the spi-mem framework. Thus, using single LUT index. > > (4) Software triggered Flash read/write access by IP Bus. > > (5) Memory mapped read access by AHB Bus. Do we really want to have this level of details in the commit message? I mean, this is something you can document in the driver, but not here. BTW, you might want to have a look at [1]. I think we can get rid of the ->size field you're adding if this driver implements the dirmap hooks. > > (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility > on NXP LX2160ARDB and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512ab, [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] Ok, that's good to have in the commit message. > > - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. But this one is useless. If you add a new driver, you have no other choice but to add a new entry in the Kconfig file. > > - Add entry in the 'spi-nor/Makefile'. > Ditto. Before you re-send a new version, I'd like to understand why you think you need to create a new driver, and I want you to try to implement the dirmap hook and check if you can get rid of the ->size field when doing that. I also seem one extra benefit to having a single driver for both FlexSPI and QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported on the new QuadSPI driver :-P. Thanks, Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-04 14:58 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 14:58 UTC (permalink / raw) To: linux-arm-kernel Hi Yogesh, On Fri, 31 Aug 2018 16:00:00 +0530 Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > - Add a driver for NXP FlexSPI host controller > > (0) What is the FlexSPI controller? > FlexSPI is a flexsible SPI host controller which supports two SPI > channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data > transfer (1/2/4/8 bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, > maximum 4, each with up to 8 bidirectional data lines. > > It uses new SPI memory interface of the SPI framework to issue flash > memory operations to up to four connected flash chips (2 buses with > 2 CS each). > Chipselect for each flash can be selected as per address assigned in > controller specific registers. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. Yep, I had a quick look at the code and they really look similar. Why not extending the existing driver instead of creating a new one from scratch? > > (1) The FlexSPI controller is driven by the LUT(Look-up Table) > registers. > The LUT registers are a look-up-table for sequences of instructions. > A valid sequence consists of four LUT registers. > Maximum 32 LUT sequences can be programmed simultaneously. > > (2) The definition of the LUT register shows below: > --------------------------------------------------- > | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | > --------------------------------------------------- > > There are several types of INSTRx, such as: > CMD : the SPI NOR command. > ADDR : the address for the SPI NOR command. > DUMMY : the dummy cycles needed by the SPI NOR command. > .... > > There are several types of PADx, such as: > PAD1 : use a singe I/O line. > PAD2 : use two I/O lines. > PAD4 : use quad I/O lines. > PAD8 : use octal I/O lines. > .... > > (3) LUTs are being created at run-time based on the commands passed > from the spi-mem framework. Thus, using single LUT index. > > (4) Software triggered Flash read/write access by IP Bus. > > (5) Memory mapped read access by AHB Bus. Do we really want to have this level of details in the commit message? I mean, this is something you can document in the driver, but not here. BTW, you might want to have a look at [1]. I think we can get rid of the ->size field you're adding if this driver implements the dirmap hooks. > > (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility > on NXP LX2160ARDB and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512ab, [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] Ok, that's good to have in the commit message. > > - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. But this one is useless. If you add a new driver, you have no other choice but to add a new entry in the Kconfig file. > > - Add entry in the 'spi-nor/Makefile'. > Ditto. Before you re-send a new version, I'd like to understand why you think you need to create a new driver, and I want you to try to implement the dirmap hook and check if you can get rid of the ->size field when doing that. I also seem one extra benefit to having a single driver for both FlexSPI and QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported on the new QuadSPI driver :-P. Thanks, Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-09-04 14:58 ` Boris Brezillon (?) @ 2018-09-05 10:07 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-05 10:07 UTC (permalink / raw) To: Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Tuesday, September 4, 2018 8:29 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > Hi Yogesh, > > On Fri, 31 Aug 2018 16:00:00 +0530 > Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > - Add a driver for NXP FlexSPI host controller > > > > (0) What is the FlexSPI controller? > > FlexSPI is a flexsible SPI host controller which supports two SPI > > channels and up to 4 external devices. > > Each channel supports Single/Dual/Quad/Octal mode data transfer > > (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface > > to external devices, maximum 4, each with up to 8 bidirectional data > > lines. > > > > It uses new SPI memory interface of the SPI framework to issue flash > > memory operations to up to four connected flash chips (2 buses with > > 2 CS each). > > Chipselect for each flash can be selected as per address assigned in > > controller specific registers. > > > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > > controller with advanced features. > > Yep, I had a quick look at the code and they really look similar. Why not > extending the existing driver instead of creating a new one from scratch? > FlexSPI is different controller not related to the QuadSPI controller in its working behavior Both these controller are having * Different registers name, registers address, registers functionality etc, section 30.5.2[1] * Different programming sequence for initialization of the controller, section 30.8.1[1] * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode * Different programming sequence for checking controller current state like busy or not * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] There are few similarities between these two like LUT programming logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > > > > (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > registers. > > The LUT registers are a look-up-table for sequences of instructions. > > A valid sequence consists of four LUT registers. > > Maximum 32 LUT sequences can be programmed simultaneously. > > > > (2) The definition of the LUT register shows below: > > --------------------------------------------------- > > | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | > > --------------------------------------------------- > > > > There are several types of INSTRx, such as: > > CMD : the SPI NOR command. > > ADDR : the address for the SPI NOR command. > > DUMMY : the dummy cycles needed by the SPI NOR command. > > .... > > > > There are several types of PADx, such as: > > PAD1 : use a singe I/O line. > > PAD2 : use two I/O lines. > > PAD4 : use quad I/O lines. > > PAD8 : use octal I/O lines. > > .... > > > > (3) LUTs are being created at run-time based on the commands passed > > from the spi-mem framework. Thus, using single LUT index. > > > > (4) Software triggered Flash read/write access by IP Bus. > > > > (5) Memory mapped read access by AHB Bus. > > Do we really want to have this level of details in the commit message? > I mean, this is something you can document in the driver, but not here. > > BTW, you might want to have a look at [1]. I think we can get rid of the ->size > field you're adding if this driver implements the dirmap hooks. > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. Link for reference of the driver implementing dirmap hooks was missing in mail, please share. > > > > (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility > > on NXP LX2160ARDB and LX2160AQDS targets. > > LX2160ARDB is having two NOR slave device connected on single bus A > > i.e. A0 and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses > > one flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > > Micron, mt35xu512ab, [Read - 1 bit mode] > > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Ok, that's good to have in the commit message. > > > > > - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > > But this one is useless. If you add a new driver, you have no other choice but to > add a new entry in the Kconfig file. > > > > > - Add entry in the 'spi-nor/Makefile'. > > > > Ditto. > > Before you re-send a new version, I'd like to understand why you think you need > to create a new driver, and I want you to try to implement the dirmap hook and > check if you can get rid of the ->size field when doing that. > > I also seem one extra benefit to having a single driver for both FlexSPI and > QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported > on the new QuadSPI driver :-P. Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf -- Regards Yogesh Gaur > > Thanks, > > Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-05 10:07 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-05 10:07 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon at bootlin.com] > Sent: Tuesday, September 4, 2018 8:29 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd at lists.infradead.org; marek.vasut at gmail.com; linux- > spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; > mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- > kernel at lists.infradead.org; computersforpeace at gmail.com; > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > Hi Yogesh, > > On Fri, 31 Aug 2018 16:00:00 +0530 > Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > - Add a driver for NXP FlexSPI host controller > > > > (0) What is the FlexSPI controller? > > FlexSPI is a flexsible SPI host controller which supports two SPI > > channels and up to 4 external devices. > > Each channel supports Single/Dual/Quad/Octal mode data transfer > > (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface > > to external devices, maximum 4, each with up to 8 bidirectional data > > lines. > > > > It uses new SPI memory interface of the SPI framework to issue flash > > memory operations to up to four connected flash chips (2 buses with > > 2 CS each). > > Chipselect for each flash can be selected as per address assigned in > > controller specific registers. > > > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > > controller with advanced features. > > Yep, I had a quick look at the code and they really look similar. Why not > extending the existing driver instead of creating a new one from scratch? > FlexSPI is different controller not related to the QuadSPI controller in its working behavior Both these controller are having * Different registers name, registers address, registers functionality etc, section 30.5.2[1] * Different programming sequence for initialization of the controller, section 30.8.1[1] * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode * Different programming sequence for checking controller current state like busy or not * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] There are few similarities between these two like LUT programming logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > > > > (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > registers. > > The LUT registers are a look-up-table for sequences of instructions. > > A valid sequence consists of four LUT registers. > > Maximum 32 LUT sequences can be programmed simultaneously. > > > > (2) The definition of the LUT register shows below: > > --------------------------------------------------- > > | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | > > --------------------------------------------------- > > > > There are several types of INSTRx, such as: > > CMD : the SPI NOR command. > > ADDR : the address for the SPI NOR command. > > DUMMY : the dummy cycles needed by the SPI NOR command. > > .... > > > > There are several types of PADx, such as: > > PAD1 : use a singe I/O line. > > PAD2 : use two I/O lines. > > PAD4 : use quad I/O lines. > > PAD8 : use octal I/O lines. > > .... > > > > (3) LUTs are being created at run-time based on the commands passed > > from the spi-mem framework. Thus, using single LUT index. > > > > (4) Software triggered Flash read/write access by IP Bus. > > > > (5) Memory mapped read access by AHB Bus. > > Do we really want to have this level of details in the commit message? > I mean, this is something you can document in the driver, but not here. > > BTW, you might want to have a look at [1]. I think we can get rid of the ->size > field you're adding if this driver implements the dirmap hooks. > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. Link for reference of the driver implementing dirmap hooks was missing in mail, please share. > > > > (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility > > on NXP LX2160ARDB and LX2160AQDS targets. > > LX2160ARDB is having two NOR slave device connected on single bus A > > i.e. A0 and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses > > one flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > > Micron, mt35xu512ab, [Read - 1 bit mode] > > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Ok, that's good to have in the commit message. > > > > > - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > > But this one is useless. If you add a new driver, you have no other choice but to > add a new entry in the Kconfig file. > > > > > - Add entry in the 'spi-nor/Makefile'. > > > > Ditto. > > Before you re-send a new version, I'd like to understand why you think you need > to create a new driver, and I want you to try to implement the dirmap hook and > check if you can get rid of the ->size field when doing that. > > I also seem one extra benefit to having a single driver for both FlexSPI and > QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported > on the new QuadSPI driver :-P. Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf -- Regards Yogesh Gaur > > Thanks, > > Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-05 10:07 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-05 10:07 UTC (permalink / raw) To: Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Tuesday, September 4, 2018 8:29 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > Hi Yogesh, > > On Fri, 31 Aug 2018 16:00:00 +0530 > Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > - Add a driver for NXP FlexSPI host controller > > > > (0) What is the FlexSPI controller? > > FlexSPI is a flexsible SPI host controller which supports two SPI > > channels and up to 4 external devices. > > Each channel supports Single/Dual/Quad/Octal mode data transfer > > (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface > > to external devices, maximum 4, each with up to 8 bidirectional data > > lines. > > > > It uses new SPI memory interface of the SPI framework to issue flash > > memory operations to up to four connected flash chips (2 buses with > > 2 CS each). > > Chipselect for each flash can be selected as per address assigned in > > controller specific registers. > > > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > > controller with advanced features. > > Yep, I had a quick look at the code and they really look similar. Why not > extending the existing driver instead of creating a new one from scratch? > FlexSPI is different controller not related to the QuadSPI controller in its working behavior Both these controller are having * Different registers name, registers address, registers functionality etc, section 30.5.2[1] * Different programming sequence for initialization of the controller, section 30.8.1[1] * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode * Different programming sequence for checking controller current state like busy or not * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] There are few similarities between these two like LUT programming logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > > > > (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > registers. > > The LUT registers are a look-up-table for sequences of instructions. > > A valid sequence consists of four LUT registers. > > Maximum 32 LUT sequences can be programmed simultaneously. > > > > (2) The definition of the LUT register shows below: > > --------------------------------------------------- > > | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | > > --------------------------------------------------- > > > > There are several types of INSTRx, such as: > > CMD : the SPI NOR command. > > ADDR : the address for the SPI NOR command. > > DUMMY : the dummy cycles needed by the SPI NOR command. > > .... > > > > There are several types of PADx, such as: > > PAD1 : use a singe I/O line. > > PAD2 : use two I/O lines. > > PAD4 : use quad I/O lines. > > PAD8 : use octal I/O lines. > > .... > > > > (3) LUTs are being created at run-time based on the commands passed > > from the spi-mem framework. Thus, using single LUT index. > > > > (4) Software triggered Flash read/write access by IP Bus. > > > > (5) Memory mapped read access by AHB Bus. > > Do we really want to have this level of details in the commit message? > I mean, this is something you can document in the driver, but not here. > > BTW, you might want to have a look at [1]. I think we can get rid of the ->size > field you're adding if this driver implements the dirmap hooks. > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. Link for reference of the driver implementing dirmap hooks was missing in mail, please share. > > > > (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility > > on NXP LX2160ARDB and LX2160AQDS targets. > > LX2160ARDB is having two NOR slave device connected on single bus A > > i.e. A0 and A1 (CS0 and CS1). > > LX2160AQDS is having two NOR slave device connected on separate buses > > one flash on A0 and second on B1 i.e. (CS0 and CS3). > > Verified this driver on following SPI NOR flashes: > > Micron, mt35xu512ab, [Read - 1 bit mode] > > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Ok, that's good to have in the commit message. > > > > > - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > > But this one is useless. If you add a new driver, you have no other choice but to > add a new entry in the Kconfig file. > > > > > - Add entry in the 'spi-nor/Makefile'. > > > > Ditto. > > Before you re-send a new version, I'd like to understand why you think you need > to create a new driver, and I want you to try to implement the dirmap hook and > check if you can get rid of the ->size field when doing that. > > I also seem one extra benefit to having a single driver for both FlexSPI and > QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported > on the new QuadSPI driver :-P. Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf -- Regards Yogesh Gaur > > Thanks, > > Boris ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-09-05 10:07 ` Yogesh Narayan Gaur (?) (?) @ 2018-09-06 8:26 ` Frieder Schrempf -1 siblings, 0 replies; 64+ messages in thread From: Frieder Schrempf @ 2018-09-06 8:26 UTC (permalink / raw) To: Yogesh Narayan Gaur, Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Yogesh, On 05.09.2018 12:07, Yogesh Narayan Gaur wrote: > Hi Boris, > >> -----Original Message----- >> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] >> Sent: Tuesday, September 4, 2018 8:29 PM >> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> >> Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- >> spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; >> mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- >> kernel@lists.infradead.org; computersforpeace@gmail.com; >> frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller >> >> Hi Yogesh, >> >> On Fri, 31 Aug 2018 16:00:00 +0530 >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: >> >>> - Add a driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>> FlexSPI is a flexsible SPI host controller which supports two SPI >>> channels and up to 4 external devices. >>> Each channel supports Single/Dual/Quad/Octal mode data transfer >>> (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface >>> to external devices, maximum 4, each with up to 8 bidirectional data >>> lines. >>> >>> It uses new SPI memory interface of the SPI framework to issue flash >>> memory operations to up to four connected flash chips (2 buses with >>> 2 CS each). >>> Chipselect for each flash can be selected as per address assigned in >>> controller specific registers. >>> >>> FlexSPI controller is similar to the existing Freescale/NXP QuadSPI >>> controller with advanced features. >> >> Yep, I had a quick look at the code and they really look similar. Why not >> extending the existing driver instead of creating a new one from scratch? >> > > FlexSPI is different controller not related to the QuadSPI controller in its working behavior > Both these controller are having > * Different registers name, registers address, registers functionality etc, section 30.5.2[1] > * Different programming sequence for initialization of the controller, section 30.8.1[1] > * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode > * Different programming sequence for checking controller current state like busy or not > * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] > > There are few similarities between these two like LUT programming logic is same > i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. > > Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > >>> >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) >>> registers. >>> The LUT registers are a look-up-table for sequences of instructions. >>> A valid sequence consists of four LUT registers. >>> Maximum 32 LUT sequences can be programmed simultaneously. >>> >>> (2) The definition of the LUT register shows below: >>> --------------------------------------------------- >>> | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | >>> --------------------------------------------------- >>> >>> There are several types of INSTRx, such as: >>> CMD : the SPI NOR command. >>> ADDR : the address for the SPI NOR command. >>> DUMMY : the dummy cycles needed by the SPI NOR command. >>> .... >>> >>> There are several types of PADx, such as: >>> PAD1 : use a singe I/O line. >>> PAD2 : use two I/O lines. >>> PAD4 : use quad I/O lines. >>> PAD8 : use octal I/O lines. >>> .... >>> >>> (3) LUTs are being created at run-time based on the commands passed >>> from the spi-mem framework. Thus, using single LUT index. >>> >>> (4) Software triggered Flash read/write access by IP Bus. >>> >>> (5) Memory mapped read access by AHB Bus. >> >> Do we really want to have this level of details in the commit message? >> I mean, this is something you can document in the driver, but not here. >> >> BTW, you might want to have a look at [1]. I think we can get rid of the ->size >> field you're adding if this driver implements the dirmap hooks. >> > > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. It's the same situation we had with the QSPI driver before. We decided to **not** pass information about flash size directly to the controller for now. That's why we currently don't support mapping the flash device in the implementation of the QSPI driver. I think we should not start this discussion all over again for the FlexSPI driver, but stick to what we decided for QSPI. > > Link for reference of the driver implementing dirmap hooks was missing in mail, please share. I guess Boris meant to link to his PoC implementation of the direct mapping API [1]. When this is available we can easily add support for direct memory mappings to the QuadSPI and FlexSPI drivers. > >>> >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>> on NXP LX2160ARDB and LX2160AQDS targets. >>> LX2160ARDB is having two NOR slave device connected on single bus A >>> i.e. A0 and A1 (CS0 and CS1). >>> LX2160AQDS is having two NOR slave device connected on separate buses >>> one flash on A0 and second on B1 i.e. (CS0 and CS3). >>> Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >> >> Ok, that's good to have in the commit message. >> >>> >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. >> >> But this one is useless. If you add a new driver, you have no other choice but to >> add a new entry in the Kconfig file. >> >>> >>> - Add entry in the 'spi-nor/Makefile'. >>> >> >> Ditto. >> >> Before you re-send a new version, I'd like to understand why you think you need >> to create a new driver, and I want you to try to implement the dirmap hook and >> check if you can get rid of the ->size field when doing that. >> >> I also seem one extra benefit to having a single driver for both FlexSPI and >> QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported >> on the new QuadSPI driver :-P. > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. > > Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. > I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. Yes you posted your changes to make the driver work for your board. The problem is, that I don't yet understand why they are needed and how they actually fix the chip select issue. Han has pointed out the reason why ioremap() was added to the driver [2] in the first place and this seems unrelated to the CS selection issue. Therefore Boris and I have requested more information about how the IP works and more tests from other people. As long as we don't get more information about the questions posted before [3][4], we are kind of blocked. [1] https://github.com/bbrezillon/linux/commits/spi-mem-dirmap [2] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083218.html [3] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083209.html [4] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083233.html Thanks, Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 8:26 ` Frieder Schrempf 0 siblings, 0 replies; 64+ messages in thread From: Frieder Schrempf @ 2018-09-06 8:26 UTC (permalink / raw) To: linux-arm-kernel Hi Yogesh, On 05.09.2018 12:07, Yogesh Narayan Gaur wrote: > Hi Boris, > >> -----Original Message----- >> From: Boris Brezillon [mailto:boris.brezillon at bootlin.com] >> Sent: Tuesday, September 4, 2018 8:29 PM >> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> >> Cc: linux-mtd at lists.infradead.org; marek.vasut at gmail.com; linux- >> spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; >> mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- >> kernel at lists.infradead.org; computersforpeace at gmail.com; >> frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org >> Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller >> >> Hi Yogesh, >> >> On Fri, 31 Aug 2018 16:00:00 +0530 >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: >> >>> - Add a driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>> FlexSPI is a flexsible SPI host controller which supports two SPI >>> channels and up to 4 external devices. >>> Each channel supports Single/Dual/Quad/Octal mode data transfer >>> (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface >>> to external devices, maximum 4, each with up to 8 bidirectional data >>> lines. >>> >>> It uses new SPI memory interface of the SPI framework to issue flash >>> memory operations to up to four connected flash chips (2 buses with >>> 2 CS each). >>> Chipselect for each flash can be selected as per address assigned in >>> controller specific registers. >>> >>> FlexSPI controller is similar to the existing Freescale/NXP QuadSPI >>> controller with advanced features. >> >> Yep, I had a quick look at the code and they really look similar. Why not >> extending the existing driver instead of creating a new one from scratch? >> > > FlexSPI is different controller not related to the QuadSPI controller in its working behavior > Both these controller are having > * Different registers name, registers address, registers functionality etc, section 30.5.2[1] > * Different programming sequence for initialization of the controller, section 30.8.1[1] > * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode > * Different programming sequence for checking controller current state like busy or not > * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] > > There are few similarities between these two like LUT programming logic is same > i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. > > Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > >>> >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) >>> registers. >>> The LUT registers are a look-up-table for sequences of instructions. >>> A valid sequence consists of four LUT registers. >>> Maximum 32 LUT sequences can be programmed simultaneously. >>> >>> (2) The definition of the LUT register shows below: >>> --------------------------------------------------- >>> | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | >>> --------------------------------------------------- >>> >>> There are several types of INSTRx, such as: >>> CMD : the SPI NOR command. >>> ADDR : the address for the SPI NOR command. >>> DUMMY : the dummy cycles needed by the SPI NOR command. >>> .... >>> >>> There are several types of PADx, such as: >>> PAD1 : use a singe I/O line. >>> PAD2 : use two I/O lines. >>> PAD4 : use quad I/O lines. >>> PAD8 : use octal I/O lines. >>> .... >>> >>> (3) LUTs are being created at run-time based on the commands passed >>> from the spi-mem framework. Thus, using single LUT index. >>> >>> (4) Software triggered Flash read/write access by IP Bus. >>> >>> (5) Memory mapped read access by AHB Bus. >> >> Do we really want to have this level of details in the commit message? >> I mean, this is something you can document in the driver, but not here. >> >> BTW, you might want to have a look at [1]. I think we can get rid of the ->size >> field you're adding if this driver implements the dirmap hooks. >> > > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. It's the same situation we had with the QSPI driver before. We decided to **not** pass information about flash size directly to the controller for now. That's why we currently don't support mapping the flash device in the implementation of the QSPI driver. I think we should not start this discussion all over again for the FlexSPI driver, but stick to what we decided for QSPI. > > Link for reference of the driver implementing dirmap hooks was missing in mail, please share. I guess Boris meant to link to his PoC implementation of the direct mapping API [1]. When this is available we can easily add support for direct memory mappings to the QuadSPI and FlexSPI drivers. > >>> >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>> on NXP LX2160ARDB and LX2160AQDS targets. >>> LX2160ARDB is having two NOR slave device connected on single bus A >>> i.e. A0 and A1 (CS0 and CS1). >>> LX2160AQDS is having two NOR slave device connected on separate buses >>> one flash on A0 and second on B1 i.e. (CS0 and CS3). >>> Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >> >> Ok, that's good to have in the commit message. >> >>> >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. >> >> But this one is useless. If you add a new driver, you have no other choice but to >> add a new entry in the Kconfig file. >> >>> >>> - Add entry in the 'spi-nor/Makefile'. >>> >> >> Ditto. >> >> Before you re-send a new version, I'd like to understand why you think you need >> to create a new driver, and I want you to try to implement the dirmap hook and >> check if you can get rid of the ->size field when doing that. >> >> I also seem one extra benefit to having a single driver for both FlexSPI and >> QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported >> on the new QuadSPI driver :-P. > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. > > Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. > I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. Yes you posted your changes to make the driver work for your board. The problem is, that I don't yet understand why they are needed and how they actually fix the chip select issue. Han has pointed out the reason why ioremap() was added to the driver [2] in the first place and this seems unrelated to the CS selection issue. Therefore Boris and I have requested more information about how the IP works and more tests from other people. As long as we don't get more information about the questions posted before [3][4], we are kind of blocked. [1] https://github.com/bbrezillon/linux/commits/spi-mem-dirmap [2] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083218.html [3] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083209.html [4] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083233.html Thanks, Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 8:26 ` Frieder Schrempf 0 siblings, 0 replies; 64+ messages in thread From: Frieder Schrempf @ 2018-09-06 8:26 UTC (permalink / raw) To: Yogesh Narayan Gaur, Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Yogesh, On 05.09.2018 12:07, Yogesh Narayan Gaur wrote: > Hi Boris, > >> -----Original Message----- >> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] >> Sent: Tuesday, September 4, 2018 8:29 PM >> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> >> Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- >> spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; >> mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- >> kernel@lists.infradead.org; computersforpeace@gmail.com; >> frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller >> >> Hi Yogesh, >> >> On Fri, 31 Aug 2018 16:00:00 +0530 >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: >> >>> - Add a driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>> FlexSPI is a flexsible SPI host controller which supports two SPI >>> channels and up to 4 external devices. >>> Each channel supports Single/Dual/Quad/Octal mode data transfer >>> (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface >>> to external devices, maximum 4, each with up to 8 bidirectional data >>> lines. >>> >>> It uses new SPI memory interface of the SPI framework to issue flash >>> memory operations to up to four connected flash chips (2 buses with >>> 2 CS each). >>> Chipselect for each flash can be selected as per address assigned in >>> controller specific registers. >>> >>> FlexSPI controller is similar to the existing Freescale/NXP QuadSPI >>> controller with advanced features. >> >> Yep, I had a quick look at the code and they really look similar. Why not >> extending the existing driver instead of creating a new one from scratch? >> > > FlexSPI is different controller not related to the QuadSPI controller in its working behavior > Both these controller are having > * Different registers name, registers address, registers functionality etc, section 30.5.2[1] > * Different programming sequence for initialization of the controller, section 30.8.1[1] > * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode > * Different programming sequence for checking controller current state like busy or not > * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] > > There are few similarities between these two like LUT programming logic is same > i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. > > Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > >>> >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) >>> registers. >>> The LUT registers are a look-up-table for sequences of instructions. >>> A valid sequence consists of four LUT registers. >>> Maximum 32 LUT sequences can be programmed simultaneously. >>> >>> (2) The definition of the LUT register shows below: >>> --------------------------------------------------- >>> | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | >>> --------------------------------------------------- >>> >>> There are several types of INSTRx, such as: >>> CMD : the SPI NOR command. >>> ADDR : the address for the SPI NOR command. >>> DUMMY : the dummy cycles needed by the SPI NOR command. >>> .... >>> >>> There are several types of PADx, such as: >>> PAD1 : use a singe I/O line. >>> PAD2 : use two I/O lines. >>> PAD4 : use quad I/O lines. >>> PAD8 : use octal I/O lines. >>> .... >>> >>> (3) LUTs are being created at run-time based on the commands passed >>> from the spi-mem framework. Thus, using single LUT index. >>> >>> (4) Software triggered Flash read/write access by IP Bus. >>> >>> (5) Memory mapped read access by AHB Bus. >> >> Do we really want to have this level of details in the commit message? >> I mean, this is something you can document in the driver, but not here. >> >> BTW, you might want to have a look at [1]. I think we can get rid of the ->size >> field you're adding if this driver implements the dirmap hooks. >> > > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. It's the same situation we had with the QSPI driver before. We decided to **not** pass information about flash size directly to the controller for now. That's why we currently don't support mapping the flash device in the implementation of the QSPI driver. I think we should not start this discussion all over again for the FlexSPI driver, but stick to what we decided for QSPI. > > Link for reference of the driver implementing dirmap hooks was missing in mail, please share. I guess Boris meant to link to his PoC implementation of the direct mapping API [1]. When this is available we can easily add support for direct memory mappings to the QuadSPI and FlexSPI drivers. > >>> >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>> on NXP LX2160ARDB and LX2160AQDS targets. >>> LX2160ARDB is having two NOR slave device connected on single bus A >>> i.e. A0 and A1 (CS0 and CS1). >>> LX2160AQDS is having two NOR slave device connected on separate buses >>> one flash on A0 and second on B1 i.e. (CS0 and CS3). >>> Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >> >> Ok, that's good to have in the commit message. >> >>> >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. >> >> But this one is useless. If you add a new driver, you have no other choice but to >> add a new entry in the Kconfig file. >> >>> >>> - Add entry in the 'spi-nor/Makefile'. >>> >> >> Ditto. >> >> Before you re-send a new version, I'd like to understand why you think you need >> to create a new driver, and I want you to try to implement the dirmap hook and >> check if you can get rid of the ->size field when doing that. >> >> I also seem one extra benefit to having a single driver for both FlexSPI and >> QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported >> on the new QuadSPI driver :-P. > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. > > Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. > I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. Yes you posted your changes to make the driver work for your board. The problem is, that I don't yet understand why they are needed and how they actually fix the chip select issue. Han has pointed out the reason why ioremap() was added to the driver [2] in the first place and this seems unrelated to the CS selection issue. Therefore Boris and I have requested more information about how the IP works and more tests from other people. As long as we don't get more information about the questions posted before [3][4], we are kind of blocked. [1] https://github.com/bbrezillon/linux/commits/spi-mem-dirmap [2] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083218.html [3] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083209.html [4] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083233.html Thanks, Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 8:26 ` Frieder Schrempf 0 siblings, 0 replies; 64+ messages in thread From: Frieder Schrempf @ 2018-09-06 8:26 UTC (permalink / raw) To: Yogesh Narayan Gaur, Boris Brezillon Cc: mark.rutland, devicetree, robh, linux-kernel, linux-spi, marek.vasut, linux-mtd, computersforpeace, shawnguo, linux-arm-kernel Hi Yogesh, On 05.09.2018 12:07, Yogesh Narayan Gaur wrote: > Hi Boris, > >> -----Original Message----- >> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] >> Sent: Tuesday, September 4, 2018 8:29 PM >> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> >> Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- >> spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; >> mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- >> kernel@lists.infradead.org; computersforpeace@gmail.com; >> frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org >> Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller >> >> Hi Yogesh, >> >> On Fri, 31 Aug 2018 16:00:00 +0530 >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: >> >>> - Add a driver for NXP FlexSPI host controller >>> >>> (0) What is the FlexSPI controller? >>> FlexSPI is a flexsible SPI host controller which supports two SPI >>> channels and up to 4 external devices. >>> Each channel supports Single/Dual/Quad/Octal mode data transfer >>> (1/2/4/8 bidirectional data lines) i.e. FlexSPI acts as an interface >>> to external devices, maximum 4, each with up to 8 bidirectional data >>> lines. >>> >>> It uses new SPI memory interface of the SPI framework to issue flash >>> memory operations to up to four connected flash chips (2 buses with >>> 2 CS each). >>> Chipselect for each flash can be selected as per address assigned in >>> controller specific registers. >>> >>> FlexSPI controller is similar to the existing Freescale/NXP QuadSPI >>> controller with advanced features. >> >> Yep, I had a quick look at the code and they really look similar. Why not >> extending the existing driver instead of creating a new one from scratch? >> > > FlexSPI is different controller not related to the QuadSPI controller in its working behavior > Both these controller are having > * Different registers name, registers address, registers functionality etc, section 30.5.2[1] > * Different programming sequence for initialization of the controller, section 30.8.1[1] > * Different programming sequence for performing Read and Write operation using IP, section 30.7.9[1] and AHB mode > * Different programming sequence for checking controller current state like busy or not > * New mechanism to program for the connected slave device i.e. flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > * New entries added for FlexSPI controller for LUT_XX mode for various commands, section 30.7.8[1] > > There are few similarities between these two like LUT programming logic is same > i.e. LUT needs to be programmed in same sequence of 'INSTR PAD OPCODE', but again LUT register address and LUT command mode values are different. > > Creating common driver for both FlexSPI and QuadSPI controller, would involve creation of one more layer between driver/spi/spi-xxx and the actual controller driver, this layer would going to have less functionality like doing LUT creation programming and then would re-direct calls to the respective controller driver functionality to perform desired programming sequence. > >>> >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) >>> registers. >>> The LUT registers are a look-up-table for sequences of instructions. >>> A valid sequence consists of four LUT registers. >>> Maximum 32 LUT sequences can be programmed simultaneously. >>> >>> (2) The definition of the LUT register shows below: >>> --------------------------------------------------- >>> | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 | >>> --------------------------------------------------- >>> >>> There are several types of INSTRx, such as: >>> CMD : the SPI NOR command. >>> ADDR : the address for the SPI NOR command. >>> DUMMY : the dummy cycles needed by the SPI NOR command. >>> .... >>> >>> There are several types of PADx, such as: >>> PAD1 : use a singe I/O line. >>> PAD2 : use two I/O lines. >>> PAD4 : use quad I/O lines. >>> PAD8 : use octal I/O lines. >>> .... >>> >>> (3) LUTs are being created at run-time based on the commands passed >>> from the spi-mem framework. Thus, using single LUT index. >>> >>> (4) Software triggered Flash read/write access by IP Bus. >>> >>> (5) Memory mapped read access by AHB Bus. >> >> Do we really want to have this level of details in the commit message? >> I mean, this is something you can document in the driver, but not here. >> >> BTW, you might want to have a look at [1]. I think we can get rid of the ->size >> field you're adding if this driver implements the dirmap hooks. >> > > I need size information for the connected device to program the controller register FLSHXXCRO as Flash Chip select is determined by flash access address and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. It's the same situation we had with the QSPI driver before. We decided to **not** pass information about flash size directly to the controller for now. That's why we currently don't support mapping the flash device in the implementation of the QSPI driver. I think we should not start this discussion all over again for the FlexSPI driver, but stick to what we decided for QSPI. > > Link for reference of the driver implementing dirmap hooks was missing in mail, please share. I guess Boris meant to link to his PoC implementation of the direct mapping API [1]. When this is available we can easily add support for direct memory mappings to the QuadSPI and FlexSPI drivers. > >>> >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem utility >>> on NXP LX2160ARDB and LX2160AQDS targets. >>> LX2160ARDB is having two NOR slave device connected on single bus A >>> i.e. A0 and A1 (CS0 and CS1). >>> LX2160AQDS is having two NOR slave device connected on separate buses >>> one flash on A0 and second on B1 i.e. (CS0 and CS3). >>> Verified this driver on following SPI NOR flashes: >>> Micron, mt35xu512ab, [Read - 1 bit mode] >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] >> >> Ok, that's good to have in the commit message. >> >>> >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. >> >> But this one is useless. If you add a new driver, you have no other choice but to >> add a new entry in the Kconfig file. >> >>> >>> - Add entry in the 'spi-nor/Makefile'. >>> >> >> Ditto. >> >> Before you re-send a new version, I'd like to understand why you think you need >> to create a new driver, and I want you to try to implement the dirmap hook and >> check if you can get rid of the ->size field when doing that. >> >> I also seem one extra benefit to having a single driver for both FlexSPI and >> QuadSPI IPs: you'll help Frieder debug the last remaining problems you reported >> on the new QuadSPI driver :-P. > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already given suggestions to the Frieder and my local changes using which flash connected at CS0 and CS1 starts working for read/write/erase commands on ls1088ardb target. > > Current v2 which has been shared, data operation for the slave flash device connected at CS1 is not working. > I have to make changes for the calculation of flash base address for the requested chip select and changes in address remapping the buffer in AHB read case for CS1 access to work. Yes you posted your changes to make the driver work for your board. The problem is, that I don't yet understand why they are needed and how they actually fix the chip select issue. Han has pointed out the reason why ioremap() was added to the driver [2] in the first place and this seems unrelated to the CS selection issue. Therefore Boris and I have requested more information about how the IP works and more tests from other people. As long as we don't get more information about the questions posted before [3][4], we are kind of blocked. [1] https://github.com/bbrezillon/linux/commits/spi-mem-dirmap [2] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083218.html [3] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083209.html [4] http://lists.infradead.org/pipermail/linux-mtd/2018-August/083233.html Thanks, Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-09-06 8:26 ` Frieder Schrempf (?) @ 2018-09-06 11:35 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 11:35 UTC (permalink / raw) To: Frieder Schrempf, Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Frieder, > -----Original Message----- > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > Sent: Thursday, September 6, 2018 1:56 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris Brezillon > <boris.brezillon@bootlin.com> > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > >> Hi Yogesh, > >> > >> On Fri, 31 Aug 2018 16:00:00 +0530 > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > >> > >>> - Add a driver for NXP FlexSPI host controller > >>> > >> > >> Yep, I had a quick look at the code and they really look similar. Why > >> not extending the existing driver instead of creating a new one from scratch? > >> > > > > FlexSPI is different controller not related to the QuadSPI controller > > in its working behavior Both these controller are having > > * Different registers name, registers address, registers functionality > > etc, section 30.5.2[1] > > * Different programming sequence for initialization of the controller, > > section 30.8.1[1] > > * Different programming sequence for performing Read and Write > > operation using IP, section 30.7.9[1] and AHB mode > > * Different programming sequence for checking controller current state > > like busy or not > > * New mechanism to program for the connected slave device i.e. flash > > access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > * New entries added for FlexSPI controller for LUT_XX mode for various > > commands, section 30.7.8[1] > > > > There are few similarities between these two like LUT programming > > logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR > PAD OPCODE', but again LUT register address and LUT command mode values > are different. > > > > Creating common driver for both FlexSPI and QuadSPI controller, would > involve creation of one more layer between driver/spi/spi-xxx and the actual > controller driver, this layer would going to have less functionality like doing LUT > creation programming and then would re-direct calls to the respective controller > driver functionality to perform desired programming sequence. > > > >>> > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > >>> registers. > >>> The LUT registers are a look-up-table for sequences of instructions. > >>> A valid sequence consists of four LUT registers. > >>> Maximum 32 LUT sequences can be programmed simultaneously. > >>> > >> > >> Do we really want to have this level of details in the commit message? > >> I mean, this is something you can document in the driver, but not here. > >> > >> BTW, you might want to have a look at [1]. I think we can get rid of > >> the ->size field you're adding if this driver implements the dirmap hooks. > >> > > > > I need size information for the connected device to program the controller > register FLSHXXCRO as Flash Chip select is determined by flash access address > and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. > > It's the same situation we had with the QSPI driver before. We decided to > **not** pass information about flash size directly to the controller for now. > That's why we currently don't support mapping the flash device in the > implementation of the QSPI driver. > > I think we should not start this discussion all over again for the FlexSPI driver, but > stick to what we decided for QSPI. > There is difference between FlexSPI and QuadSPI controller functionality in detecting the current CS. As per table-10.32[1] for QuadSPI controller, access to flash is being assigned as per the address values provided i.e. it would be CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. But for case of FlexSPI controller, section 30.7.5[2], CS is being defined as per the address value lies in below range - Flash A1 address range: 0x00000000 ~ FA1_SIZE - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE) - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from register FLSHxxCR0[FLASHSZ] Thus, for QuadSPI controller we can actually go away with the flash size requirement and with the code logic which you have introduced, of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD register, things are working fine. But for FlexSPI controller its required to have the connected slave device size to detect the current CS. I have tried the quadspi driver logic in flexspi driver code, but it gives me failure. Due, to this reason and requirement I have come-up with this solution of getting the connected device size and programming correct value in FLSHxxCR0[FLASHSZ] register > > > > Link for reference of the driver implementing dirmap hooks was missing in mail, > please share. > > I guess Boris meant to link to his PoC implementation of the direct mapping API > [1]. When this is available we can easily add support for direct memory > mappings to the QuadSPI and FlexSPI drivers. > I have checked the link, found that size value is being derived from spi_nor.mtd.size variable. Same being performed in this patch series to detect the size of the slave device. As per my understanding developed with Boris's code implementation, when direct mapping API interface are available then both QuadSPI and FlexSPI driver needs to be changed as per new introduced ops structure. [1] https://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf [2] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf Regards, Yogesh Gaur > > > >>> > >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem > >>> utility on NXP LX2160ARDB and LX2160AQDS targets. > >>> LX2160ARDB is having two NOR slave device connected on single bus > >>> A i.e. A0 and A1 (CS0 and CS1). > >>> LX2160AQDS is having two NOR slave device connected on separate > >>> buses one flash on A0 and second on B1 i.e. (CS0 and CS3). > >>> Verified this driver on following SPI NOR flashes: > >>> Micron, mt35xu512ab, [Read - 1 bit mode] > >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] > >> > >> Ok, that's good to have in the commit message. > >> > >>> > >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > >> > >> But this one is useless. If you add a new driver, you have no other > >> choice but to add a new entry in the Kconfig file. > >> > >>> > >>> - Add entry in the 'spi-nor/Makefile'. > >>> > >> > >> Ditto. > >> > >> Before you re-send a new version, I'd like to understand why you > >> think you need to create a new driver, and I want you to try to > >> implement the dirmap hook and check if you can get rid of the ->size field > when doing that. > >> > >> I also seem one extra benefit to having a single driver for both > >> FlexSPI and QuadSPI IPs: you'll help Frieder debug the last remaining > >> problems you reported on the new QuadSPI driver :-P. > > > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already > given suggestions to the Frieder and my local changes using which flash > connected at CS0 and CS1 starts working for read/write/erase commands on > ls1088ardb target. > > > > Current v2 which has been shared, data operation for the slave flash device > connected at CS1 is not working. > > I have to make changes for the calculation of flash base address for the > requested chip select and changes in address remapping the buffer in AHB read > case for CS1 access to work. > > Yes you posted your changes to make the driver work for your board. The > problem is, that I don't yet understand why they are needed and how they > actually fix the chip select issue. > > Han has pointed out the reason why ioremap() was added to the driver [2] in the > first place and this seems unrelated to the CS selection issue. > > Therefore Boris and I have requested more information about how the IP works > and more tests from other people. > > As long as we don't get more information about the questions posted before > [3][4], we are kind of blocked. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fbbrezillon%2Flinux%2Fcommits%2Fspi-mem- > dirmap&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Ca2b9f169 > 9b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 > C0%7C636718191692315469&sdata=3QnzkYXNq53eHWcUnpzUMNILtHyA > TEemtiU0O9rRUA4%3D&reserved=0 > [2] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083218.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692315469&sdata=D6oroCChTr8oHFGI > 9GHuTU8aQLcponHdbOw9UE2C7Og%3D&reserved=0 > [3] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083209.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=lKK7dxIyRGbLNeHW > LjkwQ9m%2Bs9y9sI8dsZYy3BjIxlQ%3D&reserved=0 > [4] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083233.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=6kieWJ7zUX2u%2FfE > BiWiNEqroHoBwh1GeCOPRoHWSQ7U%3D&reserved=0 > > Thanks, > Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 11:35 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 11:35 UTC (permalink / raw) To: linux-arm-kernel Hi Frieder, > -----Original Message----- > From: Frieder Schrempf [mailto:frieder.schrempf at exceet.de] > Sent: Thursday, September 6, 2018 1:56 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris Brezillon > <boris.brezillon@bootlin.com> > Cc: linux-mtd at lists.infradead.org; marek.vasut at gmail.com; linux- > spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; > mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- > kernel at lists.infradead.org; computersforpeace at gmail.com; linux- > kernel at vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > >> Hi Yogesh, > >> > >> On Fri, 31 Aug 2018 16:00:00 +0530 > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > >> > >>> - Add a driver for NXP FlexSPI host controller > >>> > >> > >> Yep, I had a quick look at the code and they really look similar. Why > >> not extending the existing driver instead of creating a new one from scratch? > >> > > > > FlexSPI is different controller not related to the QuadSPI controller > > in its working behavior Both these controller are having > > * Different registers name, registers address, registers functionality > > etc, section 30.5.2[1] > > * Different programming sequence for initialization of the controller, > > section 30.8.1[1] > > * Different programming sequence for performing Read and Write > > operation using IP, section 30.7.9[1] and AHB mode > > * Different programming sequence for checking controller current state > > like busy or not > > * New mechanism to program for the connected slave device i.e. flash > > access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > * New entries added for FlexSPI controller for LUT_XX mode for various > > commands, section 30.7.8[1] > > > > There are few similarities between these two like LUT programming > > logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR > PAD OPCODE', but again LUT register address and LUT command mode values > are different. > > > > Creating common driver for both FlexSPI and QuadSPI controller, would > involve creation of one more layer between driver/spi/spi-xxx and the actual > controller driver, this layer would going to have less functionality like doing LUT > creation programming and then would re-direct calls to the respective controller > driver functionality to perform desired programming sequence. > > > >>> > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > >>> registers. > >>> The LUT registers are a look-up-table for sequences of instructions. > >>> A valid sequence consists of four LUT registers. > >>> Maximum 32 LUT sequences can be programmed simultaneously. > >>> > >> > >> Do we really want to have this level of details in the commit message? > >> I mean, this is something you can document in the driver, but not here. > >> > >> BTW, you might want to have a look at [1]. I think we can get rid of > >> the ->size field you're adding if this driver implements the dirmap hooks. > >> > > > > I need size information for the connected device to program the controller > register FLSHXXCRO as Flash Chip select is determined by flash access address > and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. > > It's the same situation we had with the QSPI driver before. We decided to > **not** pass information about flash size directly to the controller for now. > That's why we currently don't support mapping the flash device in the > implementation of the QSPI driver. > > I think we should not start this discussion all over again for the FlexSPI driver, but > stick to what we decided for QSPI. > There is difference between FlexSPI and QuadSPI controller functionality in detecting the current CS. As per table-10.32[1] for QuadSPI controller, access to flash is being assigned as per the address values provided i.e. it would be CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. But for case of FlexSPI controller, section 30.7.5[2], CS is being defined as per the address value lies in below range - Flash A1 address range: 0x00000000 ~ FA1_SIZE - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE) - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from register FLSHxxCR0[FLASHSZ] Thus, for QuadSPI controller we can actually go away with the flash size requirement and with the code logic which you have introduced, of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD register, things are working fine. But for FlexSPI controller its required to have the connected slave device size to detect the current CS. I have tried the quadspi driver logic in flexspi driver code, but it gives me failure. Due, to this reason and requirement I have come-up with this solution of getting the connected device size and programming correct value in FLSHxxCR0[FLASHSZ] register > > > > Link for reference of the driver implementing dirmap hooks was missing in mail, > please share. > > I guess Boris meant to link to his PoC implementation of the direct mapping API > [1]. When this is available we can easily add support for direct memory > mappings to the QuadSPI and FlexSPI drivers. > I have checked the link, found that size value is being derived from spi_nor.mtd.size variable. Same being performed in this patch series to detect the size of the slave device. As per my understanding developed with Boris's code implementation, when direct mapping API interface are available then both QuadSPI and FlexSPI driver needs to be changed as per new introduced ops structure. [1] https://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf [2] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf Regards, Yogesh Gaur > > > >>> > >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem > >>> utility on NXP LX2160ARDB and LX2160AQDS targets. > >>> LX2160ARDB is having two NOR slave device connected on single bus > >>> A i.e. A0 and A1 (CS0 and CS1). > >>> LX2160AQDS is having two NOR slave device connected on separate > >>> buses one flash on A0 and second on B1 i.e. (CS0 and CS3). > >>> Verified this driver on following SPI NOR flashes: > >>> Micron, mt35xu512ab, [Read - 1 bit mode] > >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] > >> > >> Ok, that's good to have in the commit message. > >> > >>> > >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > >> > >> But this one is useless. If you add a new driver, you have no other > >> choice but to add a new entry in the Kconfig file. > >> > >>> > >>> - Add entry in the 'spi-nor/Makefile'. > >>> > >> > >> Ditto. > >> > >> Before you re-send a new version, I'd like to understand why you > >> think you need to create a new driver, and I want you to try to > >> implement the dirmap hook and check if you can get rid of the ->size field > when doing that. > >> > >> I also seem one extra benefit to having a single driver for both > >> FlexSPI and QuadSPI IPs: you'll help Frieder debug the last remaining > >> problems you reported on the new QuadSPI driver :-P. > > > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already > given suggestions to the Frieder and my local changes using which flash > connected at CS0 and CS1 starts working for read/write/erase commands on > ls1088ardb target. > > > > Current v2 which has been shared, data operation for the slave flash device > connected at CS1 is not working. > > I have to make changes for the calculation of flash base address for the > requested chip select and changes in address remapping the buffer in AHB read > case for CS1 access to work. > > Yes you posted your changes to make the driver work for your board. The > problem is, that I don't yet understand why they are needed and how they > actually fix the chip select issue. > > Han has pointed out the reason why ioremap() was added to the driver [2] in the > first place and this seems unrelated to the CS selection issue. > > Therefore Boris and I have requested more information about how the IP works > and more tests from other people. > > As long as we don't get more information about the questions posted before > [3][4], we are kind of blocked. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fbbrezillon%2Flinux%2Fcommits%2Fspi-mem- > dirmap&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Ca2b9f169 > 9b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 > C0%7C636718191692315469&sdata=3QnzkYXNq53eHWcUnpzUMNILtHyA > TEemtiU0O9rRUA4%3D&reserved=0 > [2] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083218.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692315469&sdata=D6oroCChTr8oHFGI > 9GHuTU8aQLcponHdbOw9UE2C7Og%3D&reserved=0 > [3] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083209.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=lKK7dxIyRGbLNeHW > LjkwQ9m%2Bs9y9sI8dsZYy3BjIxlQ%3D&reserved=0 > [4] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083233.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=6kieWJ7zUX2u%2FfE > BiWiNEqroHoBwh1GeCOPRoHWSQ7U%3D&reserved=0 > > Thanks, > Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 11:35 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 11:35 UTC (permalink / raw) To: Frieder Schrempf, Boris Brezillon Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Frieder, > -----Original Message----- > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > Sent: Thursday, September 6, 2018 1:56 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris Brezillon > <boris.brezillon@bootlin.com> > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > >> Hi Yogesh, > >> > >> On Fri, 31 Aug 2018 16:00:00 +0530 > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > >> > >>> - Add a driver for NXP FlexSPI host controller > >>> > >> > >> Yep, I had a quick look at the code and they really look similar. Why > >> not extending the existing driver instead of creating a new one from scratch? > >> > > > > FlexSPI is different controller not related to the QuadSPI controller > > in its working behavior Both these controller are having > > * Different registers name, registers address, registers functionality > > etc, section 30.5.2[1] > > * Different programming sequence for initialization of the controller, > > section 30.8.1[1] > > * Different programming sequence for performing Read and Write > > operation using IP, section 30.7.9[1] and AHB mode > > * Different programming sequence for checking controller current state > > like busy or not > > * New mechanism to program for the connected slave device i.e. flash > > access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > * New entries added for FlexSPI controller for LUT_XX mode for various > > commands, section 30.7.8[1] > > > > There are few similarities between these two like LUT programming > > logic is same i.e. LUT needs to be programmed in same sequence of 'INSTR > PAD OPCODE', but again LUT register address and LUT command mode values > are different. > > > > Creating common driver for both FlexSPI and QuadSPI controller, would > involve creation of one more layer between driver/spi/spi-xxx and the actual > controller driver, this layer would going to have less functionality like doing LUT > creation programming and then would re-direct calls to the respective controller > driver functionality to perform desired programming sequence. > > > >>> > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > >>> registers. > >>> The LUT registers are a look-up-table for sequences of instructions. > >>> A valid sequence consists of four LUT registers. > >>> Maximum 32 LUT sequences can be programmed simultaneously. > >>> > >> > >> Do we really want to have this level of details in the commit message? > >> I mean, this is something you can document in the driver, but not here. > >> > >> BTW, you might want to have a look at [1]. I think we can get rid of > >> the ->size field you're adding if this driver implements the dirmap hooks. > >> > > > > I need size information for the connected device to program the controller > register FLSHXXCRO as Flash Chip select is determined by flash access address > and Flash size setting in register FLSHXXCR0[FLSHz], section 30.7.9[1]. > > It's the same situation we had with the QSPI driver before. We decided to > **not** pass information about flash size directly to the controller for now. > That's why we currently don't support mapping the flash device in the > implementation of the QSPI driver. > > I think we should not start this discussion all over again for the FlexSPI driver, but > stick to what we decided for QSPI. > There is difference between FlexSPI and QuadSPI controller functionality in detecting the current CS. As per table-10.32[1] for QuadSPI controller, access to flash is being assigned as per the address values provided i.e. it would be CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. But for case of FlexSPI controller, section 30.7.5[2], CS is being defined as per the address value lies in below range - Flash A1 address range: 0x00000000 ~ FA1_SIZE - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE) - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from register FLSHxxCR0[FLASHSZ] Thus, for QuadSPI controller we can actually go away with the flash size requirement and with the code logic which you have introduced, of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD register, things are working fine. But for FlexSPI controller its required to have the connected slave device size to detect the current CS. I have tried the quadspi driver logic in flexspi driver code, but it gives me failure. Due, to this reason and requirement I have come-up with this solution of getting the connected device size and programming correct value in FLSHxxCR0[FLASHSZ] register > > > > Link for reference of the driver implementing dirmap hooks was missing in mail, > please share. > > I guess Boris meant to link to his PoC implementation of the direct mapping API > [1]. When this is available we can easily add support for direct memory > mappings to the QuadSPI and FlexSPI drivers. > I have checked the link, found that size value is being derived from spi_nor.mtd.size variable. Same being performed in this patch series to detect the size of the slave device. As per my understanding developed with Boris's code implementation, when direct mapping API interface are available then both QuadSPI and FlexSPI driver needs to be changed as per new introduced ops structure. [1] https://www.nxp.com/docs/en/reference-manual/VFXXXRM.pdf [2] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf Regards, Yogesh Gaur > > > >>> > >>> (6) Tested this driver with the mtd_debug and JFFS2 filesystem > >>> utility on NXP LX2160ARDB and LX2160AQDS targets. > >>> LX2160ARDB is having two NOR slave device connected on single bus > >>> A i.e. A0 and A1 (CS0 and CS1). > >>> LX2160AQDS is having two NOR slave device connected on separate > >>> buses one flash on A0 and second on B1 i.e. (CS0 and CS3). > >>> Verified this driver on following SPI NOR flashes: > >>> Micron, mt35xu512ab, [Read - 1 bit mode] > >>> Cypress, s25fl512s, [Read - 1/2/4 bit mode] > >> > >> Ok, that's good to have in the commit message. > >> > >>> > >>> - Add config option entry in 'spi-nor/Kconfig' for FlexSPI driver. > >> > >> But this one is useless. If you add a new driver, you have no other > >> choice but to add a new entry in the Kconfig file. > >> > >>> > >>> - Add entry in the 'spi-nor/Makefile'. > >>> > >> > >> Ditto. > >> > >> Before you re-send a new version, I'd like to understand why you > >> think you need to create a new driver, and I want you to try to > >> implement the dirmap hook and check if you can get rid of the ->size field > when doing that. > >> > >> I also seem one extra benefit to having a single driver for both > >> FlexSPI and QuadSPI IPs: you'll help Frieder debug the last remaining > >> problems you reported on the new QuadSPI driver :-P. > > > > Regarding testing of the QuadSPI driver on spi-mem framework, I have already > given suggestions to the Frieder and my local changes using which flash > connected at CS0 and CS1 starts working for read/write/erase commands on > ls1088ardb target. > > > > Current v2 which has been shared, data operation for the slave flash device > connected at CS1 is not working. > > I have to make changes for the calculation of flash base address for the > requested chip select and changes in address remapping the buffer in AHB read > case for CS1 access to work. > > Yes you posted your changes to make the driver work for your board. The > problem is, that I don't yet understand why they are needed and how they > actually fix the chip select issue. > > Han has pointed out the reason why ioremap() was added to the driver [2] in the > first place and this seems unrelated to the CS selection issue. > > Therefore Boris and I have requested more information about how the IP works > and more tests from other people. > > As long as we don't get more information about the questions posted before > [3][4], we are kind of blocked. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > com%2Fbbrezillon%2Flinux%2Fcommits%2Fspi-mem- > dirmap&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7Ca2b9f169 > 9b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 > C0%7C636718191692315469&sdata=3QnzkYXNq53eHWcUnpzUMNILtHyA > TEemtiU0O9rRUA4%3D&reserved=0 > [2] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083218.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692315469&sdata=D6oroCChTr8oHFGI > 9GHuTU8aQLcponHdbOw9UE2C7Og%3D&reserved=0 > [3] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083209.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=lKK7dxIyRGbLNeHW > LjkwQ9m%2Bs9y9sI8dsZYy3BjIxlQ%3D&reserved=0 > [4] > https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr > adead.org%2Fpipermail%2Flinux-mtd%2F2018- > August%2F083233.html&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.c > om%7Ca2b9f1699b2c41dff6f208d613d26342%7C686ea1d3bc2b4c6fa92cd99c5 > c301635%7C0%7C0%7C636718191692325482&sdata=6kieWJ7zUX2u%2FfE > BiWiNEqroHoBwh1GeCOPRoHWSQ7U%3D&reserved=0 > > Thanks, > Frieder ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-09-06 11:35 ` Yogesh Narayan Gaur (?) @ 2018-09-06 11:43 ` Boris Brezillon -1 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-06 11:43 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Frieder Schrempf, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel On Thu, 6 Sep 2018 11:35:13 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Frieder, > > > -----Original Message----- > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > > Sent: Thursday, September 6, 2018 1:56 PM > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > Brezillon <boris.brezillon@bootlin.com> > > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > > kernel@vger.kernel.org > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > controller > > >> Hi Yogesh, > > >> > > >> On Fri, 31 Aug 2018 16:00:00 +0530 > > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > >> > > >>> - Add a driver for NXP FlexSPI host controller > > >>> > > >> > > >> Yep, I had a quick look at the code and they really look > > >> similar. Why not extending the existing driver instead of > > >> creating a new one from scratch? > > > > > > FlexSPI is different controller not related to the QuadSPI > > > controller in its working behavior Both these controller are > > > having > > > * Different registers name, registers address, registers > > > functionality etc, section 30.5.2[1] > > > * Different programming sequence for initialization of the > > > controller, section 30.8.1[1] > > > * Different programming sequence for performing Read and Write > > > operation using IP, section 30.7.9[1] and AHB mode > > > * Different programming sequence for checking controller current > > > state like busy or not > > > * New mechanism to program for the connected slave device i.e. > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > various commands, section 30.7.8[1] > > > > > > There are few similarities between these two like LUT programming > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > 'INSTR > > PAD OPCODE', but again LUT register address and LUT command mode > > values are different. > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > would > > involve creation of one more layer between driver/spi/spi-xxx and > > the actual controller driver, this layer would going to have less > > functionality like doing LUT creation programming and then would > > re-direct calls to the respective controller driver functionality > > to perform desired programming sequence. > > > > > >>> > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > >>> registers. > > >>> The LUT registers are a look-up-table for sequences of > > >>> instructions. A valid sequence consists of four LUT registers. > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > >>> > > >> > > >> Do we really want to have this level of details in the commit > > >> message? I mean, this is something you can document in the > > >> driver, but not here. > > >> > > >> BTW, you might want to have a look at [1]. I think we can get > > >> rid of the ->size field you're adding if this driver implements > > >> the dirmap hooks. > > > > > > I need size information for the connected device to program the > > > controller > > register FLSHXXCRO as Flash Chip select is determined by flash > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > section 30.7.9[1]. > > > > It's the same situation we had with the QSPI driver before. We > > decided to **not** pass information about flash size directly to > > the controller for now. That's why we currently don't support > > mapping the flash device in the implementation of the QSPI driver. > > > > I think we should not start this discussion all over again for the > > FlexSPI driver, but stick to what we decided for QSPI. > > > > There is difference between FlexSPI and QuadSPI controller > functionality in detecting the current CS. > > As per table-10.32[1] for QuadSPI controller, access to flash is > being assigned as per the address values provided i.e. it would be > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > defined as per the address value lies in below range > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + > FA2_SIZE + FB1_SIZE) > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > register FLSHxxCR0[FLASHSZ] > > Thus, for QuadSPI controller we can actually go away with the flash > size requirement and with the code logic which you have introduced, > of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > register, things are working fine. > > But for FlexSPI controller its required to have the connected slave > device size to detect the current CS. I don't see why. You should be able to take an arbitrary (big enough) size at first, and only extend it on-the-fly when a dirmap request is done. > I have tried the quadspi driver > logic in flexspi driver code, but it gives me failure. Can you detail a bit what's failing? > Due, to this > reason and requirement I have come-up with this solution of getting > the connected device size and programming correct value in > FLSHxxCR0[FLASHSZ] register Alternatively, what we could do is split the memory map in 4 regions of the same size and stick to it. That works if you can define an offset to apply to the address when an access is done through the direct mapping area. > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > missing in mail, > > please share. > > > > I guess Boris meant to link to his PoC implementation of the direct > > mapping API [1]. When this is available we can easily add support > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > I have checked the link, found that size value is being derived from > spi_nor.mtd.size variable. Same being performed in this patch series > to detect the size of the slave device. Well, yes, the result is the same, except it does not require adding a new field to spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which your implementation is lacking BTW). > As per my understanding > developed with Boris's code implementation, when direct mapping API > interface are available then both QuadSPI and FlexSPI driver needs to > be changed as per new introduced ops structure. It's not a hard requirement, but they would definitely benefit from this extension (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 11:43 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-06 11:43 UTC (permalink / raw) To: linux-arm-kernel On Thu, 6 Sep 2018 11:35:13 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Frieder, > > > -----Original Message----- > > From: Frieder Schrempf [mailto:frieder.schrempf at exceet.de] > > Sent: Thursday, September 6, 2018 1:56 PM > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > Brezillon <boris.brezillon@bootlin.com> > > Cc: linux-mtd at lists.infradead.org; marek.vasut at gmail.com; linux- > > spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; > > mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- > > kernel at lists.infradead.org; computersforpeace at gmail.com; linux- > > kernel at vger.kernel.org > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > controller > > >> Hi Yogesh, > > >> > > >> On Fri, 31 Aug 2018 16:00:00 +0530 > > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > >> > > >>> - Add a driver for NXP FlexSPI host controller > > >>> > > >> > > >> Yep, I had a quick look at the code and they really look > > >> similar. Why not extending the existing driver instead of > > >> creating a new one from scratch? > > > > > > FlexSPI is different controller not related to the QuadSPI > > > controller in its working behavior Both these controller are > > > having > > > * Different registers name, registers address, registers > > > functionality etc, section 30.5.2[1] > > > * Different programming sequence for initialization of the > > > controller, section 30.8.1[1] > > > * Different programming sequence for performing Read and Write > > > operation using IP, section 30.7.9[1] and AHB mode > > > * Different programming sequence for checking controller current > > > state like busy or not > > > * New mechanism to program for the connected slave device i.e. > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > various commands, section 30.7.8[1] > > > > > > There are few similarities between these two like LUT programming > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > 'INSTR > > PAD OPCODE', but again LUT register address and LUT command mode > > values are different. > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > would > > involve creation of one more layer between driver/spi/spi-xxx and > > the actual controller driver, this layer would going to have less > > functionality like doing LUT creation programming and then would > > re-direct calls to the respective controller driver functionality > > to perform desired programming sequence. > > > > > >>> > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > >>> registers. > > >>> The LUT registers are a look-up-table for sequences of > > >>> instructions. A valid sequence consists of four LUT registers. > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > >>> > > >> > > >> Do we really want to have this level of details in the commit > > >> message? I mean, this is something you can document in the > > >> driver, but not here. > > >> > > >> BTW, you might want to have a look at [1]. I think we can get > > >> rid of the ->size field you're adding if this driver implements > > >> the dirmap hooks. > > > > > > I need size information for the connected device to program the > > > controller > > register FLSHXXCRO as Flash Chip select is determined by flash > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > section 30.7.9[1]. > > > > It's the same situation we had with the QSPI driver before. We > > decided to **not** pass information about flash size directly to > > the controller for now. That's why we currently don't support > > mapping the flash device in the implementation of the QSPI driver. > > > > I think we should not start this discussion all over again for the > > FlexSPI driver, but stick to what we decided for QSPI. > > > > There is difference between FlexSPI and QuadSPI controller > functionality in detecting the current CS. > > As per table-10.32[1] for QuadSPI controller, access to flash is > being assigned as per the address values provided i.e. it would be > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > defined as per the address value lies in below range > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + > FA2_SIZE + FB1_SIZE) > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > register FLSHxxCR0[FLASHSZ] > > Thus, for QuadSPI controller we can actually go away with the flash > size requirement and with the code logic which you have introduced, > of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > register, things are working fine. > > But for FlexSPI controller its required to have the connected slave > device size to detect the current CS. I don't see why. You should be able to take an arbitrary (big enough) size at first, and only extend it on-the-fly when a dirmap request is done. > I have tried the quadspi driver > logic in flexspi driver code, but it gives me failure. Can you detail a bit what's failing? > Due, to this > reason and requirement I have come-up with this solution of getting > the connected device size and programming correct value in > FLSHxxCR0[FLASHSZ] register Alternatively, what we could do is split the memory map in 4 regions of the same size and stick to it. That works if you can define an offset to apply to the address when an access is done through the direct mapping area. > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > missing in mail, > > please share. > > > > I guess Boris meant to link to his PoC implementation of the direct > > mapping API [1]. When this is available we can easily add support > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > I have checked the link, found that size value is being derived from > spi_nor.mtd.size variable. Same being performed in this patch series > to detect the size of the slave device. Well, yes, the result is the same, except it does not require adding a new field to spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which your implementation is lacking BTW). > As per my understanding > developed with Boris's code implementation, when direct mapping API > interface are available then both QuadSPI and FlexSPI driver needs to > be changed as per new introduced ops structure. It's not a hard requirement, but they would definitely benefit from this extension (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 11:43 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-06 11:43 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Frieder Schrempf, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel On Thu, 6 Sep 2018 11:35:13 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Frieder, > > > -----Original Message----- > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > > Sent: Thursday, September 6, 2018 1:56 PM > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > Brezillon <boris.brezillon@bootlin.com> > > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > > kernel@vger.kernel.org > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > controller > > >> Hi Yogesh, > > >> > > >> On Fri, 31 Aug 2018 16:00:00 +0530 > > >> Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > >> > > >>> - Add a driver for NXP FlexSPI host controller > > >>> > > >> > > >> Yep, I had a quick look at the code and they really look > > >> similar. Why not extending the existing driver instead of > > >> creating a new one from scratch? > > > > > > FlexSPI is different controller not related to the QuadSPI > > > controller in its working behavior Both these controller are > > > having > > > * Different registers name, registers address, registers > > > functionality etc, section 30.5.2[1] > > > * Different programming sequence for initialization of the > > > controller, section 30.8.1[1] > > > * Different programming sequence for performing Read and Write > > > operation using IP, section 30.7.9[1] and AHB mode > > > * Different programming sequence for checking controller current > > > state like busy or not > > > * New mechanism to program for the connected slave device i.e. > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > various commands, section 30.7.8[1] > > > > > > There are few similarities between these two like LUT programming > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > 'INSTR > > PAD OPCODE', but again LUT register address and LUT command mode > > values are different. > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > would > > involve creation of one more layer between driver/spi/spi-xxx and > > the actual controller driver, this layer would going to have less > > functionality like doing LUT creation programming and then would > > re-direct calls to the respective controller driver functionality > > to perform desired programming sequence. > > > > > >>> > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > >>> registers. > > >>> The LUT registers are a look-up-table for sequences of > > >>> instructions. A valid sequence consists of four LUT registers. > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > >>> > > >> > > >> Do we really want to have this level of details in the commit > > >> message? I mean, this is something you can document in the > > >> driver, but not here. > > >> > > >> BTW, you might want to have a look at [1]. I think we can get > > >> rid of the ->size field you're adding if this driver implements > > >> the dirmap hooks. > > > > > > I need size information for the connected device to program the > > > controller > > register FLSHXXCRO as Flash Chip select is determined by flash > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > section 30.7.9[1]. > > > > It's the same situation we had with the QSPI driver before. We > > decided to **not** pass information about flash size directly to > > the controller for now. That's why we currently don't support > > mapping the flash device in the implementation of the QSPI driver. > > > > I think we should not start this discussion all over again for the > > FlexSPI driver, but stick to what we decided for QSPI. > > > > There is difference between FlexSPI and QuadSPI controller > functionality in detecting the current CS. > > As per table-10.32[1] for QuadSPI controller, access to flash is > being assigned as per the address values provided i.e. it would be > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > defined as per the address value lies in below range > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + > FA2_SIZE + FB1_SIZE) > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > register FLSHxxCR0[FLASHSZ] > > Thus, for QuadSPI controller we can actually go away with the flash > size requirement and with the code logic which you have introduced, > of using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > register, things are working fine. > > But for FlexSPI controller its required to have the connected slave > device size to detect the current CS. I don't see why. You should be able to take an arbitrary (big enough) size at first, and only extend it on-the-fly when a dirmap request is done. > I have tried the quadspi driver > logic in flexspi driver code, but it gives me failure. Can you detail a bit what's failing? > Due, to this > reason and requirement I have come-up with this solution of getting > the connected device size and programming correct value in > FLSHxxCR0[FLASHSZ] register Alternatively, what we could do is split the memory map in 4 regions of the same size and stick to it. That works if you can define an offset to apply to the address when an access is done through the direct mapping area. > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > missing in mail, > > please share. > > > > I guess Boris meant to link to his PoC implementation of the direct > > mapping API [1]. When this is available we can easily add support > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > I have checked the link, found that size value is being derived from > spi_nor.mtd.size variable. Same being performed in this patch series > to detect the size of the slave device. Well, yes, the result is the same, except it does not require adding a new field to spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which your implementation is lacking BTW). > As per my understanding > developed with Boris's code implementation, when direct mapping API > interface are available then both QuadSPI and FlexSPI driver needs to > be changed as per new introduced ops structure. It's not a hard requirement, but they would definitely benefit from this extension (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-09-06 11:43 ` Boris Brezillon (?) @ 2018-09-06 12:23 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 12:23 UTC (permalink / raw) To: Boris Brezillon Cc: Frieder Schrempf, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Thursday, September 6, 2018 5:14 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; linux- > mtd@lists.infradead.org; marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com; > shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org; > computersforpeace@gmail.com; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > On Thu, 6 Sep 2018 11:35:13 +0000 > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > Hi Frieder, > > > > > -----Original Message----- > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > > > Sent: Thursday, September 6, 2018 1:56 PM > > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > > Brezillon <boris.brezillon@bootlin.com> > > > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > > > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > > > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > > > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > > > kernel@vger.kernel.org > > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > > controller > > > >> Hi Yogesh, > > > >> > > > >> On Fri, 31 Aug 2018 16:00:00 +0530 Yogesh Gaur > > > >> <yogeshnarayan.gaur@nxp.com> wrote: > > > >> > > > >>> - Add a driver for NXP FlexSPI host controller > > > >>> > > > >> > > > >> Yep, I had a quick look at the code and they really look similar. > > > >> Why not extending the existing driver instead of creating a new > > > >> one from scratch? > > > > > > > > FlexSPI is different controller not related to the QuadSPI > > > > controller in its working behavior Both these controller are > > > > having > > > > * Different registers name, registers address, registers > > > > functionality etc, section 30.5.2[1] > > > > * Different programming sequence for initialization of the > > > > controller, section 30.8.1[1] > > > > * Different programming sequence for performing Read and Write > > > > operation using IP, section 30.7.9[1] and AHB mode > > > > * Different programming sequence for checking controller current > > > > state like busy or not > > > > * New mechanism to program for the connected slave device i.e. > > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > > various commands, section 30.7.8[1] > > > > > > > > There are few similarities between these two like LUT programming > > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > > 'INSTR > > > PAD OPCODE', but again LUT register address and LUT command mode > > > values are different. > > > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > > would > > > involve creation of one more layer between driver/spi/spi-xxx and > > > the actual controller driver, this layer would going to have less > > > functionality like doing LUT creation programming and then would > > > re-direct calls to the respective controller driver functionality to > > > perform desired programming sequence. > > > > > > > >>> > > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > > >>> registers. > > > >>> The LUT registers are a look-up-table for sequences of > > > >>> instructions. A valid sequence consists of four LUT registers. > > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > > >>> > > > >> > > > >> Do we really want to have this level of details in the commit > > > >> message? I mean, this is something you can document in the > > > >> driver, but not here. > > > >> > > > >> BTW, you might want to have a look at [1]. I think we can get rid > > > >> of the ->size field you're adding if this driver implements the > > > >> dirmap hooks. > > > > > > > > I need size information for the connected device to program the > > > > controller > > > register FLSHXXCRO as Flash Chip select is determined by flash > > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > > section 30.7.9[1]. > > > > > > It's the same situation we had with the QSPI driver before. We > > > decided to **not** pass information about flash size directly to the > > > controller for now. That's why we currently don't support mapping > > > the flash device in the implementation of the QSPI driver. > > > > > > I think we should not start this discussion all over again for the > > > FlexSPI driver, but stick to what we decided for QSPI. > > > > > > > There is difference between FlexSPI and QuadSPI controller > > functionality in detecting the current CS. > > > > As per table-10.32[1] for QuadSPI controller, access to flash is being > > assigned as per the address values provided i.e. it would be > > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if > > access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > > defined as per the address value lies in below range > > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE > > + FB1_SIZE) > > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > > register FLSHxxCR0[FLASHSZ] > > > > Thus, for QuadSPI controller we can actually go away with the flash > > size requirement and with the code logic which you have introduced, of > > using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > > register, things are working fine. > > > > But for FlexSPI controller its required to have the connected slave > > device size to detect the current CS. > > I don't see why. You should be able to take an arbitrary (big enough) size at first, > and only extend it on-the-fly when a dirmap request is done. > > > I have tried the quadspi driver > > logic in flexspi driver code, but it gives me failure. > > Can you detail a bit what's failing? > > > Due, to this > > reason and requirement I have come-up with this solution of getting > > the connected device size and programming correct value in > > FLSHxxCR0[FLASHSZ] register > > Alternatively, what we could do is split the memory map in 4 regions of the same > size and stick to it. That works if you can define an offset to apply to the address > when an access is done through the direct mapping area. Ok. I would try this and share the result and the failure point, if any. Meanwhile, can you please review the rest of the driver except _select_mem() functionality and provide your feedback. Also, as question asked for AHB RX buffer flush when using both IP and AHB mode in quadspi driver. Same logic has been used in the FlexSPI driver as it's required to flush the AHB RX buffer after using IP mode write operation. But, in FlexSPI, SWRESET register bit is w1c i.e. it automatically get reset to zero, after setting to 1, after 64 clock cycle. Thus, no explicitly udelay() needs to be added when doing AHB RX buffer invalidation. Thanks Yogesh Gaur. > > > > > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > > missing in mail, > > > please share. > > > > > > I guess Boris meant to link to his PoC implementation of the direct > > > mapping API [1]. When this is available we can easily add support > > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > > > > I have checked the link, found that size value is being derived from > > spi_nor.mtd.size variable. Same being performed in this patch series > > to detect the size of the slave device. > > Well, yes, the result is the same, except it does not require adding a new field to > spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which > your implementation is lacking BTW). > > > As per my understanding > > developed with Boris's code implementation, when direct mapping API > > interface are available then both QuadSPI and FlexSPI driver needs to > > be changed as per new introduced ops structure. > > It's not a hard requirement, but they would definitely benefit from this extension > (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 12:23 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 12:23 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon at bootlin.com] > Sent: Thursday, September 6, 2018 5:14 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; linux- > mtd at lists.infradead.org; marek.vasut at gmail.com; linux-spi at vger.kernel.org; > devicetree at vger.kernel.org; robh at kernel.org; mark.rutland at arm.com; > shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org; > computersforpeace at gmail.com; linux-kernel at vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > On Thu, 6 Sep 2018 11:35:13 +0000 > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > Hi Frieder, > > > > > -----Original Message----- > > > From: Frieder Schrempf [mailto:frieder.schrempf at exceet.de] > > > Sent: Thursday, September 6, 2018 1:56 PM > > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > > Brezillon <boris.brezillon@bootlin.com> > > > Cc: linux-mtd at lists.infradead.org; marek.vasut at gmail.com; linux- > > > spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; > > > mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- > > > kernel at lists.infradead.org; computersforpeace at gmail.com; linux- > > > kernel at vger.kernel.org > > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > > controller > > > >> Hi Yogesh, > > > >> > > > >> On Fri, 31 Aug 2018 16:00:00 +0530 Yogesh Gaur > > > >> <yogeshnarayan.gaur@nxp.com> wrote: > > > >> > > > >>> - Add a driver for NXP FlexSPI host controller > > > >>> > > > >> > > > >> Yep, I had a quick look at the code and they really look similar. > > > >> Why not extending the existing driver instead of creating a new > > > >> one from scratch? > > > > > > > > FlexSPI is different controller not related to the QuadSPI > > > > controller in its working behavior Both these controller are > > > > having > > > > * Different registers name, registers address, registers > > > > functionality etc, section 30.5.2[1] > > > > * Different programming sequence for initialization of the > > > > controller, section 30.8.1[1] > > > > * Different programming sequence for performing Read and Write > > > > operation using IP, section 30.7.9[1] and AHB mode > > > > * Different programming sequence for checking controller current > > > > state like busy or not > > > > * New mechanism to program for the connected slave device i.e. > > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > > various commands, section 30.7.8[1] > > > > > > > > There are few similarities between these two like LUT programming > > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > > 'INSTR > > > PAD OPCODE', but again LUT register address and LUT command mode > > > values are different. > > > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > > would > > > involve creation of one more layer between driver/spi/spi-xxx and > > > the actual controller driver, this layer would going to have less > > > functionality like doing LUT creation programming and then would > > > re-direct calls to the respective controller driver functionality to > > > perform desired programming sequence. > > > > > > > >>> > > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > > >>> registers. > > > >>> The LUT registers are a look-up-table for sequences of > > > >>> instructions. A valid sequence consists of four LUT registers. > > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > > >>> > > > >> > > > >> Do we really want to have this level of details in the commit > > > >> message? I mean, this is something you can document in the > > > >> driver, but not here. > > > >> > > > >> BTW, you might want to have a look at [1]. I think we can get rid > > > >> of the ->size field you're adding if this driver implements the > > > >> dirmap hooks. > > > > > > > > I need size information for the connected device to program the > > > > controller > > > register FLSHXXCRO as Flash Chip select is determined by flash > > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > > section 30.7.9[1]. > > > > > > It's the same situation we had with the QSPI driver before. We > > > decided to **not** pass information about flash size directly to the > > > controller for now. That's why we currently don't support mapping > > > the flash device in the implementation of the QSPI driver. > > > > > > I think we should not start this discussion all over again for the > > > FlexSPI driver, but stick to what we decided for QSPI. > > > > > > > There is difference between FlexSPI and QuadSPI controller > > functionality in detecting the current CS. > > > > As per table-10.32[1] for QuadSPI controller, access to flash is being > > assigned as per the address values provided i.e. it would be > > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if > > access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > > defined as per the address value lies in below range > > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE > > + FB1_SIZE) > > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > > register FLSHxxCR0[FLASHSZ] > > > > Thus, for QuadSPI controller we can actually go away with the flash > > size requirement and with the code logic which you have introduced, of > > using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > > register, things are working fine. > > > > But for FlexSPI controller its required to have the connected slave > > device size to detect the current CS. > > I don't see why. You should be able to take an arbitrary (big enough) size at first, > and only extend it on-the-fly when a dirmap request is done. > > > I have tried the quadspi driver > > logic in flexspi driver code, but it gives me failure. > > Can you detail a bit what's failing? > > > Due, to this > > reason and requirement I have come-up with this solution of getting > > the connected device size and programming correct value in > > FLSHxxCR0[FLASHSZ] register > > Alternatively, what we could do is split the memory map in 4 regions of the same > size and stick to it. That works if you can define an offset to apply to the address > when an access is done through the direct mapping area. Ok. I would try this and share the result and the failure point, if any. Meanwhile, can you please review the rest of the driver except _select_mem() functionality and provide your feedback. Also, as question asked for AHB RX buffer flush when using both IP and AHB mode in quadspi driver. Same logic has been used in the FlexSPI driver as it's required to flush the AHB RX buffer after using IP mode write operation. But, in FlexSPI, SWRESET register bit is w1c i.e. it automatically get reset to zero, after setting to 1, after 64 clock cycle. Thus, no explicitly udelay() needs to be added when doing AHB RX buffer invalidation. Thanks Yogesh Gaur. > > > > > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > > missing in mail, > > > please share. > > > > > > I guess Boris meant to link to his PoC implementation of the direct > > > mapping API [1]. When this is available we can easily add support > > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > > > > I have checked the link, found that size value is being derived from > > spi_nor.mtd.size variable. Same being performed in this patch series > > to detect the size of the slave device. > > Well, yes, the result is the same, except it does not require adding a new field to > spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which > your implementation is lacking BTW). > > > As per my understanding > > developed with Boris's code implementation, when direct mapping API > > interface are available then both QuadSPI and FlexSPI driver needs to > > be changed as per new introduced ops structure. > > It's not a hard requirement, but they would definitely benefit from this extension > (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-06 12:23 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-06 12:23 UTC (permalink / raw) To: Boris Brezillon Cc: Frieder Schrempf, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, linux-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Thursday, September 6, 2018 5:14 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; linux- > mtd@lists.infradead.org; marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org; robh@kernel.org; mark.rutland@arm.com; > shawnguo@kernel.org; linux-arm-kernel@lists.infradead.org; > computersforpeace@gmail.com; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller > > On Thu, 6 Sep 2018 11:35:13 +0000 > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > Hi Frieder, > > > > > -----Original Message----- > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de] > > > Sent: Thursday, September 6, 2018 1:56 PM > > > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; Boris > > > Brezillon <boris.brezillon@bootlin.com> > > > Cc: linux-mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > > > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > > > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > > > kernel@lists.infradead.org; computersforpeace@gmail.com; linux- > > > kernel@vger.kernel.org > > > Subject: Re: [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI > > > controller > > > >> Hi Yogesh, > > > >> > > > >> On Fri, 31 Aug 2018 16:00:00 +0530 Yogesh Gaur > > > >> <yogeshnarayan.gaur@nxp.com> wrote: > > > >> > > > >>> - Add a driver for NXP FlexSPI host controller > > > >>> > > > >> > > > >> Yep, I had a quick look at the code and they really look similar. > > > >> Why not extending the existing driver instead of creating a new > > > >> one from scratch? > > > > > > > > FlexSPI is different controller not related to the QuadSPI > > > > controller in its working behavior Both these controller are > > > > having > > > > * Different registers name, registers address, registers > > > > functionality etc, section 30.5.2[1] > > > > * Different programming sequence for initialization of the > > > > controller, section 30.8.1[1] > > > > * Different programming sequence for performing Read and Write > > > > operation using IP, section 30.7.9[1] and AHB mode > > > > * Different programming sequence for checking controller current > > > > state like busy or not > > > > * New mechanism to program for the connected slave device i.e. > > > > flash access mode and flash memory map 30.7.4[1] and 30.7.5[1] > > > > * New entries added for FlexSPI controller for LUT_XX mode for > > > > various commands, section 30.7.8[1] > > > > > > > > There are few similarities between these two like LUT programming > > > > logic is same i.e. LUT needs to be programmed in same sequence of > > > > 'INSTR > > > PAD OPCODE', but again LUT register address and LUT command mode > > > values are different. > > > > > > > > Creating common driver for both FlexSPI and QuadSPI controller, > > > > would > > > involve creation of one more layer between driver/spi/spi-xxx and > > > the actual controller driver, this layer would going to have less > > > functionality like doing LUT creation programming and then would > > > re-direct calls to the respective controller driver functionality to > > > perform desired programming sequence. > > > > > > > >>> > > > >>> (1) The FlexSPI controller is driven by the LUT(Look-up Table) > > > >>> registers. > > > >>> The LUT registers are a look-up-table for sequences of > > > >>> instructions. A valid sequence consists of four LUT registers. > > > >>> Maximum 32 LUT sequences can be programmed simultaneously. > > > >>> > > > >> > > > >> Do we really want to have this level of details in the commit > > > >> message? I mean, this is something you can document in the > > > >> driver, but not here. > > > >> > > > >> BTW, you might want to have a look at [1]. I think we can get rid > > > >> of the ->size field you're adding if this driver implements the > > > >> dirmap hooks. > > > > > > > > I need size information for the connected device to program the > > > > controller > > > register FLSHXXCRO as Flash Chip select is determined by flash > > > access address and Flash size setting in register FLSHXXCR0[FLSHz], > > > section 30.7.9[1]. > > > > > > It's the same situation we had with the QSPI driver before. We > > > decided to **not** pass information about flash size directly to the > > > controller for now. That's why we currently don't support mapping > > > the flash device in the implementation of the QSPI driver. > > > > > > I think we should not start this discussion all over again for the > > > FlexSPI driver, but stick to what we decided for QSPI. > > > > > > > There is difference between FlexSPI and QuadSPI controller > > functionality in detecting the current CS. > > > > As per table-10.32[1] for QuadSPI controller, access to flash is being > > assigned as per the address values provided i.e. it would be > > CS0 if address is between TOP_ADDR_MEMXX and QSPI_AMBA_BASE and CS1 > if > > access is in between TOP_ADDR_MEMA2 and TOP_ADDR_MEMA1. > > > > But for case of FlexSPI controller, section 30.7.5[2], CS is being > > defined as per the address value lies in below range > > - Flash A1 address range: 0x00000000 ~ FA1_SIZE > > - Flash A2 address range: FA1_SIZE ~ (FA1_SIZE + FA2_SIZE) > > - Flash B1 address range: (FA1_SIZE + FA2_SIZE) ~ (FA1_SIZE + FA2_SIZE > > + FB1_SIZE) > > - Flash B2 address range: FA1_SIZE + FA2_SIZE + FB1_SIZE) ~ (FA1_SIZE > > + FA2_SIZE + FB1_SIZE + FB2_SIZE) and FAx_SIZE is determined from > > register FLSHxxCR0[FLASHSZ] > > > > Thus, for QuadSPI controller we can actually go away with the flash > > size requirement and with the code logic which you have introduced, of > > using 2 * ahb_buf_size data size for TOP_ADDR_MEMXX bits in SFxxD > > register, things are working fine. > > > > But for FlexSPI controller its required to have the connected slave > > device size to detect the current CS. > > I don't see why. You should be able to take an arbitrary (big enough) size at first, > and only extend it on-the-fly when a dirmap request is done. > > > I have tried the quadspi driver > > logic in flexspi driver code, but it gives me failure. > > Can you detail a bit what's failing? > > > Due, to this > > reason and requirement I have come-up with this solution of getting > > the connected device size and programming correct value in > > FLSHxxCR0[FLASHSZ] register > > Alternatively, what we could do is split the memory map in 4 regions of the same > size and stick to it. That works if you can define an offset to apply to the address > when an access is done through the direct mapping area. Ok. I would try this and share the result and the failure point, if any. Meanwhile, can you please review the rest of the driver except _select_mem() functionality and provide your feedback. Also, as question asked for AHB RX buffer flush when using both IP and AHB mode in quadspi driver. Same logic has been used in the FlexSPI driver as it's required to flush the AHB RX buffer after using IP mode write operation. But, in FlexSPI, SWRESET register bit is w1c i.e. it automatically get reset to zero, after setting to 1, after 64 clock cycle. Thus, no explicitly udelay() needs to be added when doing AHB RX buffer invalidation. Thanks Yogesh Gaur. > > > > > > > > > > > Link for reference of the driver implementing dirmap hooks was > > > > missing in mail, > > > please share. > > > > > > I guess Boris meant to link to his PoC implementation of the direct > > > mapping API [1]. When this is available we can easily add support > > > for direct memory mappings to the QuadSPI and FlexSPI drivers. > > > > > > > I have checked the link, found that size value is being derived from > > spi_nor.mtd.size variable. Same being performed in this patch series > > to detect the size of the slave device. > > Well, yes, the result is the same, except it does not require adding a new field to > spi_mem and ->attach/detach() hooks to the spi_mem_ops interface (which > your implementation is lacking BTW). > > > As per my understanding > > developed with Boris's code implementation, when direct mapping API > > interface are available then both QuadSPI and FlexSPI driver needs to > > be changed as per new introduced ops structure. > > It's not a hard requirement, but they would definitely benefit from this extension > (mainly a perf improvement). ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:30 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Add binding file for NXP FlexSPI driver. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt new file mode 100644 index 0000000..9f07116 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt @@ -0,0 +1,42 @@ +* NXP Flex Serial Peripheral Interface (FSPI) + +Required properties: + - compatible : Should be "nxp,lx2160a-fspi" + - reg : First contains the register location and length, + Second contains the memory mapping address and length + - reg-names : Should contain the resource reg names: + - fspi_base: iconfiguration register address space + - fspi_mmap: memory mapped address space + - interrupts : Should contain the interrupt for the device + +Optional properties: + - big-endian : See common-properties.txt. + +Required SPI slave node properties: + - reg : There are two buses (A and B) with two chip selects each. + This encodes to which bus and CS the flash is connected: + - <0>: Bus A, CS 0 + - <1>: Bus A, CS 1 + - <2>: Bus B, CS 0 + - <3>: Bus B, CS 1 + +Example showing the usage of two SPI NOR slave devices on bus A: + +fspi0: flexspi@20c0000 { + compatible = "nxp,lx2160a-fspi"; + reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; + reg-names = "fspi_base", "fspi_mmap"; + interrupts = <0 25 0x4>; /* Level high type */ + clocks = <&clockgen 4 3>, <&clockgen 4 3>; + clock-names = "fspi_en", "fspi"; + + flash0: mt35xu512aba@0 { + reg = <0>; + .... + }; + + flash1: mt35xu512aba@1 { + reg = <1>; + .... + }; +}; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-08-31 10:30 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-arm-kernel Add binding file for NXP FlexSPI driver. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt new file mode 100644 index 0000000..9f07116 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt @@ -0,0 +1,42 @@ +* NXP Flex Serial Peripheral Interface (FSPI) + +Required properties: + - compatible : Should be "nxp,lx2160a-fspi" + - reg : First contains the register location and length, + Second contains the memory mapping address and length + - reg-names : Should contain the resource reg names: + - fspi_base: iconfiguration register address space + - fspi_mmap: memory mapped address space + - interrupts : Should contain the interrupt for the device + +Optional properties: + - big-endian : See common-properties.txt. + +Required SPI slave node properties: + - reg : There are two buses (A and B) with two chip selects each. + This encodes to which bus and CS the flash is connected: + - <0>: Bus A, CS 0 + - <1>: Bus A, CS 1 + - <2>: Bus B, CS 0 + - <3>: Bus B, CS 1 + +Example showing the usage of two SPI NOR slave devices on bus A: + +fspi0: flexspi at 20c0000 { + compatible = "nxp,lx2160a-fspi"; + reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; + reg-names = "fspi_base", "fspi_mmap"; + interrupts = <0 25 0x4>; /* Level high type */ + clocks = <&clockgen 4 3>, <&clockgen 4 3>; + clock-names = "fspi_en", "fspi"; + + flash0: mt35xu512aba at 0 { + reg = <0>; + .... + }; + + flash1: mt35xu512aba at 1 { + reg = <1>; + .... + }; +}; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-08-31 10:30 ` Yogesh Gaur (?) (?) @ 2018-09-03 9:54 ` Prabhakar Kushwaha -1 siblings, 0 replies; 64+ messages in thread From: Prabhakar Kushwaha @ 2018-09-03 9:54 UTC (permalink / raw) To: Yogesh Narayan Gaur, linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Narayan Gaur Dear Yogesh, > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > Sent: Friday, August 31, 2018 4:00 PM > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Add binding file for NXP FlexSPI driver. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length Why are we overriding reg property. Is there any special requirement. Can we use "reg" and "ranges" property in device tree. Here "reg" represents controller registers and "ranges" represent the memory address of flash. --pk ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-03 9:54 ` Prabhakar Kushwaha 0 siblings, 0 replies; 64+ messages in thread From: Prabhakar Kushwaha @ 2018-09-03 9:54 UTC (permalink / raw) To: linux-arm-kernel Dear Yogesh, > -----Original Message----- > From: linux-kernel-owner at vger.kernel.org <linux-kernel- > owner at vger.kernel.org> On Behalf Of Yogesh Gaur > Sent: Friday, August 31, 2018 4:00 PM > To: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > devicetree at vger.kernel.org > Cc: robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; linux- > arm-kernel at lists.infradead.org; computersforpeace at gmail.com; > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org; Yogesh > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Add binding file for NXP FlexSPI driver. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length Why are we overriding reg property. Is there any special requirement. Can we use "reg" and "ranges" property in device tree. Here "reg" represents controller registers and "ranges" represent the memory address of flash. --pk ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-03 9:54 ` Prabhakar Kushwaha 0 siblings, 0 replies; 64+ messages in thread From: Prabhakar Kushwaha @ 2018-09-03 9:54 UTC (permalink / raw) To: Yogesh Narayan Gaur, linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Narayan Gaur Dear Yogesh, > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > Sent: Friday, August 31, 2018 4:00 PM > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Add binding file for NXP FlexSPI driver. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length Why are we overriding reg property. Is there any special requirement. Can we use "reg" and "ranges" property in device tree. Here "reg" represents controller registers and "ranges" represent the memory address of flash. --pk ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-03 9:54 ` Prabhakar Kushwaha 0 siblings, 0 replies; 64+ messages in thread From: Prabhakar Kushwaha @ 2018-09-03 9:54 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Narayan Gaur Dear Yogesh, > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > Sent: Friday, August 31, 2018 4:00 PM > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > devicetree@vger.kernel.org > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Add binding file for NXP FlexSPI driver. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length Why are we overriding reg property. Is there any special requirement. Can we use "reg" and "ranges" property in device tree. Here "reg" represents controller registers and "ranges" represent the memory address of flash. --pk ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-09-03 9:54 ` Prabhakar Kushwaha (?) @ 2018-09-04 5:37 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-04 5:37 UTC (permalink / raw) To: Prabhakar Kushwaha, Shawn Guo Cc: robh, mark.rutland, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Hi Prabhakar, > -----Original Message----- > From: Prabhakar Kushwaha > Sent: Monday, September 3, 2018 3:24 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd@lists.infradead.org; boris.brezillon@bootlin.com; marek.vasut@gmail.com; > linux-spi@vger.kernel.org; devicetree@vger.kernel.org > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh Narayan > Gaur <yogeshnarayan.gaur@nxp.com> > Subject: RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > devicetree@vger.kernel.org > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and > > +length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory > address of flash. 'reg' property is being mentioned in the file './Documentation/devicetree/bindings/spi/spi-bus.txt' No mention has been given for the 'ranges' property. Shawn, Please suggest, did we add different property node 'reg' for the configuration register address space and 'ranges' for memory mapped address space. -- Regards Yogesh Gaur > > --pk > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 5:37 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-04 5:37 UTC (permalink / raw) To: linux-arm-kernel Hi Prabhakar, > -----Original Message----- > From: Prabhakar Kushwaha > Sent: Monday, September 3, 2018 3:24 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd at lists.infradead.org; boris.brezillon at bootlin.com; marek.vasut at gmail.com; > linux-spi at vger.kernel.org; devicetree at vger.kernel.org > Cc: robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; linux- > arm-kernel at lists.infradead.org; computersforpeace at gmail.com; > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org; Yogesh Narayan > Gaur <yogeshnarayan.gaur@nxp.com> > Subject: RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner at vger.kernel.org <linux-kernel- > > owner at vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > > devicetree at vger.kernel.org > > Cc: robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; linux- > > arm-kernel at lists.infradead.org; computersforpeace at gmail.com; > > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and > > +length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory > address of flash. 'reg' property is being mentioned in the file './Documentation/devicetree/bindings/spi/spi-bus.txt' No mention has been given for the 'ranges' property. Shawn, Please suggest, did we add different property node 'reg' for the configuration register address space and 'ranges' for memory mapped address space. -- Regards Yogesh Gaur > > --pk > ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 5:37 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Narayan Gaur @ 2018-09-04 5:37 UTC (permalink / raw) To: Prabhakar Kushwaha, Shawn Guo Cc: robh, mark.rutland, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Hi Prabhakar, > -----Original Message----- > From: Prabhakar Kushwaha > Sent: Monday, September 3, 2018 3:24 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd@lists.infradead.org; boris.brezillon@bootlin.com; marek.vasut@gmail.com; > linux-spi@vger.kernel.org; devicetree@vger.kernel.org > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh Narayan > Gaur <yogeshnarayan.gaur@nxp.com> > Subject: RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > devicetree@vger.kernel.org > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and > > +length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory > address of flash. 'reg' property is being mentioned in the file './Documentation/devicetree/bindings/spi/spi-bus.txt' No mention has been given for the 'ranges' property. Shawn, Please suggest, did we add different property node 'reg' for the configuration register address space and 'ranges' for memory mapped address space. -- Regards Yogesh Gaur > > --pk > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-09-03 9:54 ` Prabhakar Kushwaha (?) @ 2018-09-04 12:46 ` Boris Brezillon -1 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 12:46 UTC (permalink / raw) To: Prabhakar Kushwaha Cc: Yogesh Narayan Gaur, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel On Mon, 3 Sep 2018 09:54:08 +0000 Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > devicetree@vger.kernel.org > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory address of flash. No, ranges is not used for that. It's used when you need to convert from one address space to another, which is not what you're describing here. Check section 2.38 of this document [1] for more details. [1]https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 12:46 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 12:46 UTC (permalink / raw) To: linux-arm-kernel On Mon, 3 Sep 2018 09:54:08 +0000 Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner at vger.kernel.org <linux-kernel- > > owner at vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > > devicetree at vger.kernel.org > > Cc: robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; linux- > > arm-kernel at lists.infradead.org; computersforpeace at gmail.com; > > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory address of flash. No, ranges is not used for that. It's used when you need to convert from one address space to another, which is not what you're describing here. Check section 2.38 of this document [1] for more details. [1]https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 12:46 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 12:46 UTC (permalink / raw) To: Prabhakar Kushwaha Cc: Yogesh Narayan Gaur, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel On Mon, 3 Sep 2018 09:54:08 +0000 Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > Dear Yogesh, > > > -----Original Message----- > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > Sent: Friday, August 31, 2018 4:00 PM > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > devicetree@vger.kernel.org > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; linux- > > arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver > > > > Add binding file for NXP FlexSPI driver. > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > --- > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > ++++++++++++++++++++++ > > 1 file changed, 42 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > fspi.txt > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > new file mode 100644 > > index 0000000..9f07116 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > @@ -0,0 +1,42 @@ > > +* NXP Flex Serial Peripheral Interface (FSPI) > > + > > +Required properties: > > + - compatible : Should be "nxp,lx2160a-fspi" > > + - reg : First contains the register location and length, > > + Second contains the memory mapping address and length > > Why are we overriding reg property. Is there any special requirement. > > Can we use "reg" and "ranges" property in device tree. > Here "reg" represents controller registers and "ranges" represent the memory address of flash. No, ranges is not used for that. It's used when you need to convert from one address space to another, which is not what you're describing here. Check section 2.38 of this document [1] for more details. [1]https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-09-04 12:46 ` Boris Brezillon (?) @ 2018-09-06 7:08 ` Jagdish Gediya -1 siblings, 0 replies; 64+ messages in thread From: Jagdish Gediya @ 2018-09-06 7:08 UTC (permalink / raw) To: Boris Brezillon, Prabhakar Kushwaha Cc: Yogesh Narayan Gaur, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Boris, Currently FlexSPI controller is present in ARM SoC but NXP is coming with PowerPC SoC with same FlexSPI controller. We are trying to use same binding as defined in this patch-set(tested on ARM64 processors) for PowerPC. Unfortunately, It is showing issue when driver tries to parse 'fspi_mmap'. We did some investigation and figured out that for ARM device trees Peripherals nodes inside 'soc' node have absolute addresses. For in general NXP's PowerPC device trees, Peripheral nodes have the relative addresses to the unit-address of the parent 'soc' node. This creates issue for PowerPC if we follow implementation in this patch-set. Example of device tree used for upcoming PowerPC SoC with FlexSPI controller. soc@f8000000 { ranges = <0x0 0x0 0xf8000000 0x4000000>; . fspi0: flexspi@20c0000 { compatible = "nxp,XXX-fspi"; reg = <0x20c0000 0x10000>, <0xC0000000 0x10000000>; reg-names = "fspi_base", "fspi_mmap"; . . } } As we can see, Final address of 'fspi_base' (0xf8000000 + 0x20c0000) falls into the parent 'soc' range(CCSR) but for 'fspi_mmap', It is outside of 'soc' range(CCSR). It creates issue when driver tries to parse 'fspi_mmap'. As per definition of ranges, this field can't be used to solve this problem. Please suggest how to implement the "fspi_mmap"(memory mapping address and length) in case of PowerPC. Thanks, Jagdish > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > owner@vger.kernel.org> On Behalf Of Boris Brezillon > Sent: Tuesday, September 4, 2018 6:16 PM > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI > driver > > On Mon, 3 Sep 2018 09:54:08 +0000 > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > > > Dear Yogesh, > > > > > -----Original Message----- > > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > > Sent: Friday, August 31, 2018 4:00 PM > > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > > devicetree@vger.kernel.org > > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; > > > linux- arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > > FlexSPI driver > > > > > > Add binding file for NXP FlexSPI driver. > > > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > > --- > > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > > ++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > > fspi.txt > > > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > new file mode 100644 > > > index 0000000..9f07116 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > @@ -0,0 +1,42 @@ > > > +* NXP Flex Serial Peripheral Interface (FSPI) > > > + > > > +Required properties: > > > + - compatible : Should be "nxp,lx2160a-fspi" > > > + - reg : First contains the register location and length, > > > + Second contains the memory mapping address and > > > +length > > > > Why are we overriding reg property. Is there any special requirement. > > > > Can we use "reg" and "ranges" property in device tree. > > Here "reg" represents controller registers and "ranges" represent the > memory address of flash. > > No, ranges is not used for that. It's used when you need to convert from one > address space to another, which is not what you're describing here. Check > section 2.38 of this document [1] for more details. > > [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fe > linux.org%2Fimages%2Fc%2Fcf%2FPower_ePAPR_APPROVED_v1.1.pdf& > data=02%7C01%7Cjagdish.gediya%40nxp.com%7C5bdb57713bd4403a39e90 > 8d6126472a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63671 > 6619958727753&sdata=TB4mbWEm0opk58oPAVEOQFM0xeAFxCsqdzw > 37BPuE3A%3D&reserved=0 ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-06 7:08 ` Jagdish Gediya 0 siblings, 0 replies; 64+ messages in thread From: Jagdish Gediya @ 2018-09-06 7:08 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, Currently FlexSPI controller is present in ARM SoC but NXP is coming with PowerPC SoC with same FlexSPI controller. We are trying to use same binding as defined in this patch-set(tested on ARM64 processors) for PowerPC. Unfortunately, It is showing issue when driver tries to parse 'fspi_mmap'. We did some investigation and figured out that for ARM device trees Peripherals nodes inside 'soc' node have absolute addresses. For in general NXP's PowerPC device trees, Peripheral nodes have the relative addresses to the unit-address of the parent 'soc' node. This creates issue for PowerPC if we follow implementation in this patch-set. Example of device tree used for upcoming PowerPC SoC with FlexSPI controller. soc at f8000000 { ranges = <0x0 0x0 0xf8000000 0x4000000>; . fspi0: flexspi at 20c0000 { compatible = "nxp,XXX-fspi"; reg = <0x20c0000 0x10000>, <0xC0000000 0x10000000>; reg-names = "fspi_base", "fspi_mmap"; . . } } As we can see, Final address of 'fspi_base' (0xf8000000 + 0x20c0000) falls into the parent 'soc' range(CCSR) but for 'fspi_mmap', It is outside of 'soc' range(CCSR). It creates issue when driver tries to parse 'fspi_mmap'. As per definition of ranges, this field can't be used to solve this problem. Please suggest how to implement the "fspi_mmap"(memory mapping address and length) in case of PowerPC. Thanks, Jagdish > -----Original Message----- > From: linux-kernel-owner at vger.kernel.org <linux-kernel- > owner at vger.kernel.org> On Behalf Of Boris Brezillon > Sent: Tuesday, September 4, 2018 6:16 PM > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd at lists.infradead.org; marek.vasut at gmail.com; linux- > spi at vger.kernel.org; devicetree at vger.kernel.org; robh at kernel.org; > mark.rutland at arm.com; shawnguo at kernel.org; linux-arm- > kernel at lists.infradead.org; computersforpeace at gmail.com; > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org > Subject: Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI > driver > > On Mon, 3 Sep 2018 09:54:08 +0000 > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > > > Dear Yogesh, > > > > > -----Original Message----- > > > From: linux-kernel-owner at vger.kernel.org <linux-kernel- > > > owner at vger.kernel.org> On Behalf Of Yogesh Gaur > > > Sent: Friday, August 31, 2018 4:00 PM > > > To: linux-mtd at lists.infradead.org; boris.brezillon at bootlin.com; > > > marek.vasut at gmail.com; linux-spi at vger.kernel.org; > > > devicetree at vger.kernel.org > > > Cc: robh at kernel.org; mark.rutland at arm.com; shawnguo at kernel.org; > > > linux- arm-kernel at lists.infradead.org; computersforpeace at gmail.com; > > > frieder.schrempf at exceet.de; linux-kernel at vger.kernel.org; Yogesh > > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > > FlexSPI driver > > > > > > Add binding file for NXP FlexSPI driver. > > > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > > --- > > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > > ++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > > fspi.txt > > > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > new file mode 100644 > > > index 0000000..9f07116 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > @@ -0,0 +1,42 @@ > > > +* NXP Flex Serial Peripheral Interface (FSPI) > > > + > > > +Required properties: > > > + - compatible : Should be "nxp,lx2160a-fspi" > > > + - reg : First contains the register location and length, > > > + Second contains the memory mapping address and > > > +length > > > > Why are we overriding reg property. Is there any special requirement. > > > > Can we use "reg" and "ranges" property in device tree. > > Here "reg" represents controller registers and "ranges" represent the > memory address of flash. > > No, ranges is not used for that. It's used when you need to convert from one > address space to another, which is not what you're describing here. Check > section 2.38 of this document [1] for more details. > > [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fe > linux.org%2Fimages%2Fc%2Fcf%2FPower_ePAPR_APPROVED_v1.1.pdf& > data=02%7C01%7Cjagdish.gediya%40nxp.com%7C5bdb57713bd4403a39e90 > 8d6126472a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63671 > 6619958727753&sdata=TB4mbWEm0opk58oPAVEOQFM0xeAFxCsqdzw > 37BPuE3A%3D&reserved=0 ^ permalink raw reply [flat|nested] 64+ messages in thread
* RE: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-06 7:08 ` Jagdish Gediya 0 siblings, 0 replies; 64+ messages in thread From: Jagdish Gediya @ 2018-09-06 7:08 UTC (permalink / raw) To: Boris Brezillon, Prabhakar Kushwaha Cc: Yogesh Narayan Gaur, linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Boris, Currently FlexSPI controller is present in ARM SoC but NXP is coming with PowerPC SoC with same FlexSPI controller. We are trying to use same binding as defined in this patch-set(tested on ARM64 processors) for PowerPC. Unfortunately, It is showing issue when driver tries to parse 'fspi_mmap'. We did some investigation and figured out that for ARM device trees Peripherals nodes inside 'soc' node have absolute addresses. For in general NXP's PowerPC device trees, Peripheral nodes have the relative addresses to the unit-address of the parent 'soc' node. This creates issue for PowerPC if we follow implementation in this patch-set. Example of device tree used for upcoming PowerPC SoC with FlexSPI controller. soc@f8000000 { ranges = <0x0 0x0 0xf8000000 0x4000000>; . fspi0: flexspi@20c0000 { compatible = "nxp,XXX-fspi"; reg = <0x20c0000 0x10000>, <0xC0000000 0x10000000>; reg-names = "fspi_base", "fspi_mmap"; . . } } As we can see, Final address of 'fspi_base' (0xf8000000 + 0x20c0000) falls into the parent 'soc' range(CCSR) but for 'fspi_mmap', It is outside of 'soc' range(CCSR). It creates issue when driver tries to parse 'fspi_mmap'. As per definition of ranges, this field can't be used to solve this problem. Please suggest how to implement the "fspi_mmap"(memory mapping address and length) in case of PowerPC. Thanks, Jagdish > -----Original Message----- > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > owner@vger.kernel.org> On Behalf Of Boris Brezillon > Sent: Tuesday, September 4, 2018 6:16 PM > To: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> > Cc: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>; linux- > mtd@lists.infradead.org; marek.vasut@gmail.com; linux- > spi@vger.kernel.org; devicetree@vger.kernel.org; robh@kernel.org; > mark.rutland@arm.com; shawnguo@kernel.org; linux-arm- > kernel@lists.infradead.org; computersforpeace@gmail.com; > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI > driver > > On Mon, 3 Sep 2018 09:54:08 +0000 > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com> wrote: > > > Dear Yogesh, > > > > > -----Original Message----- > > > From: linux-kernel-owner@vger.kernel.org <linux-kernel- > > > owner@vger.kernel.org> On Behalf Of Yogesh Gaur > > > Sent: Friday, August 31, 2018 4:00 PM > > > To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; > > > marek.vasut@gmail.com; linux-spi@vger.kernel.org; > > > devicetree@vger.kernel.org > > > Cc: robh@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; > > > linux- arm-kernel@lists.infradead.org; computersforpeace@gmail.com; > > > frieder.schrempf@exceet.de; linux-kernel@vger.kernel.org; Yogesh > > > Narayan Gaur <yogeshnarayan.gaur@nxp.com> > > > Subject: [PATCH 4/7] dt-bindings: spi: add binding file for NXP > > > FlexSPI driver > > > > > > Add binding file for NXP FlexSPI driver. > > > > > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > > > --- > > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 > > > ++++++++++++++++++++++ > > > 1 file changed, 42 insertions(+) > > > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp- > > > fspi.txt > > > > > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > new file mode 100644 > > > index 0000000..9f07116 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > > @@ -0,0 +1,42 @@ > > > +* NXP Flex Serial Peripheral Interface (FSPI) > > > + > > > +Required properties: > > > + - compatible : Should be "nxp,lx2160a-fspi" > > > + - reg : First contains the register location and length, > > > + Second contains the memory mapping address and > > > +length > > > > Why are we overriding reg property. Is there any special requirement. > > > > Can we use "reg" and "ranges" property in device tree. > > Here "reg" represents controller registers and "ranges" represent the > memory address of flash. > > No, ranges is not used for that. It's used when you need to convert from one > address space to another, which is not what you're describing here. Check > section 2.38 of this document [1] for more details. > > [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fe > linux.org%2Fimages%2Fc%2Fcf%2FPower_ePAPR_APPROVED_v1.1.pdf& > data=02%7C01%7Cjagdish.gediya%40nxp.com%7C5bdb57713bd4403a39e90 > 8d6126472a0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63671 > 6619958727753&sdata=TB4mbWEm0opk58oPAVEOQFM0xeAFxCsqdzw > 37BPuE3A%3D&reserved=0 ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver 2018-08-31 10:30 ` Yogesh Gaur (?) @ 2018-09-04 1:33 ` Rob Herring -1 siblings, 0 replies; 64+ messages in thread From: Rob Herring @ 2018-09-04 1:33 UTC (permalink / raw) To: Yogesh Gaur Cc: mark.rutland, devicetree, marek.vasut, linux-kernel, linux-spi, boris.brezillon, frieder.schrempf, linux-mtd, computersforpeace, shawnguo, linux-arm-kernel On Fri, Aug 31, 2018 at 04:00:01PM +0530, Yogesh Gaur wrote: > Add binding file for NXP FlexSPI driver. Bindings are for h/w, not drivers. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length > + - reg-names : Should contain the resource reg names: > + - fspi_base: iconfiguration register address space > + - fspi_mmap: memory mapped address space > + - interrupts : Should contain the interrupt for the device > + > +Optional properties: > + - big-endian : See common-properties.txt. > + > +Required SPI slave node properties: > + - reg : There are two buses (A and B) with two chip selects each. > + This encodes to which bus and CS the flash is connected: > + - <0>: Bus A, CS 0 > + - <1>: Bus A, CS 1 > + - <2>: Bus B, CS 0 > + - <3>: Bus B, CS 1 > + > +Example showing the usage of two SPI NOR slave devices on bus A: > + > +fspi0: flexspi@20c0000 { spi@... > + compatible = "nxp,lx2160a-fspi"; > + reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; > + reg-names = "fspi_base", "fspi_mmap"; > + interrupts = <0 25 0x4>; /* Level high type */ > + clocks = <&clockgen 4 3>, <&clockgen 4 3>; > + clock-names = "fspi_en", "fspi"; > + > + flash0: mt35xu512aba@0 { flash@0 > + reg = <0>; > + .... > + }; > + > + flash1: mt35xu512aba@1 { flash@1 Make sure to fix the dts patch too. > + reg = <1>; > + .... > + }; > +}; > -- > 2.7.4 > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 1:33 ` Rob Herring 0 siblings, 0 replies; 64+ messages in thread From: Rob Herring @ 2018-09-04 1:33 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 31, 2018 at 04:00:01PM +0530, Yogesh Gaur wrote: > Add binding file for NXP FlexSPI driver. Bindings are for h/w, not drivers. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length > + - reg-names : Should contain the resource reg names: > + - fspi_base: iconfiguration register address space > + - fspi_mmap: memory mapped address space > + - interrupts : Should contain the interrupt for the device > + > +Optional properties: > + - big-endian : See common-properties.txt. > + > +Required SPI slave node properties: > + - reg : There are two buses (A and B) with two chip selects each. > + This encodes to which bus and CS the flash is connected: > + - <0>: Bus A, CS 0 > + - <1>: Bus A, CS 1 > + - <2>: Bus B, CS 0 > + - <3>: Bus B, CS 1 > + > +Example showing the usage of two SPI NOR slave devices on bus A: > + > +fspi0: flexspi at 20c0000 { spi at ... > + compatible = "nxp,lx2160a-fspi"; > + reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; > + reg-names = "fspi_base", "fspi_mmap"; > + interrupts = <0 25 0x4>; /* Level high type */ > + clocks = <&clockgen 4 3>, <&clockgen 4 3>; > + clock-names = "fspi_en", "fspi"; > + > + flash0: mt35xu512aba at 0 { flash at 0 > + reg = <0>; > + .... > + }; > + > + flash1: mt35xu512aba at 1 { flash at 1 Make sure to fix the dts patch too. > + reg = <1>; > + .... > + }; > +}; > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver @ 2018-09-04 1:33 ` Rob Herring 0 siblings, 0 replies; 64+ messages in thread From: Rob Herring @ 2018-09-04 1:33 UTC (permalink / raw) To: Yogesh Gaur Cc: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel On Fri, Aug 31, 2018 at 04:00:01PM +0530, Yogesh Gaur wrote: > Add binding file for NXP FlexSPI driver. Bindings are for h/w, not drivers. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 ++++++++++++++++++++++ > 1 file changed, 42 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > > diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > new file mode 100644 > index 0000000..9f07116 > --- /dev/null > +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > @@ -0,0 +1,42 @@ > +* NXP Flex Serial Peripheral Interface (FSPI) > + > +Required properties: > + - compatible : Should be "nxp,lx2160a-fspi" > + - reg : First contains the register location and length, > + Second contains the memory mapping address and length > + - reg-names : Should contain the resource reg names: > + - fspi_base: iconfiguration register address space > + - fspi_mmap: memory mapped address space > + - interrupts : Should contain the interrupt for the device > + > +Optional properties: > + - big-endian : See common-properties.txt. > + > +Required SPI slave node properties: > + - reg : There are two buses (A and B) with two chip selects each. > + This encodes to which bus and CS the flash is connected: > + - <0>: Bus A, CS 0 > + - <1>: Bus A, CS 1 > + - <2>: Bus B, CS 0 > + - <3>: Bus B, CS 1 > + > +Example showing the usage of two SPI NOR slave devices on bus A: > + > +fspi0: flexspi@20c0000 { spi@... > + compatible = "nxp,lx2160a-fspi"; > + reg = <0x0 0x20c0000 0x0 0x10000>, <0x0 0x20000000 0x0 0x10000000>; > + reg-names = "fspi_base", "fspi_mmap"; > + interrupts = <0 25 0x4>; /* Level high type */ > + clocks = <&clockgen 4 3>, <&clockgen 4 3>; > + clock-names = "fspi_en", "fspi"; > + > + flash0: mt35xu512aba@0 { flash@0 > + reg = <0>; > + .... > + }; > + > + flash1: mt35xu512aba@1 { flash@1 Make sure to fix the dts patch too. > + reg = <1>; > + .... > + }; > +}; > -- > 2.7.4 > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 5/7] arm64: dts: lx2160a: add fspi node property 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:30 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Add fspi node property for LX2160A SoC for FlexSPI driver. Property added for the FlexSPI controller and for the connected slave device for the LX2160ARDB target. This is having two SPI-NOR flash device, mt35xu512aba, connected at CS0 and CS1. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +++++++++++++++++++++ arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 ++++++++++++ 2 files changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts index 70fad20..3646315 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts @@ -32,6 +32,27 @@ status = "okay"; }; +&fspi { + status = "okay"; + flash0: mt35xu512aba@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "m25p80"; + m25p,fast-read; + spi-max-frequency = <20000000>; + reg = <0>; + }; + + flash1: mt35xu512aba@1 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "m25p80"; + m25p,fast-read; + spi-max-frequency = <20000000>; + reg = <1>; + }; +}; + &i2c0 { status = "okay"; pca9547@77 { diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi index e35e494..031eb26 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi @@ -568,5 +568,17 @@ timeout-sec = <30>; }; + fspi: flexspi@20c0000 { + status = "disabled"; + compatible = "nxp,lx2160a-fspi"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x0 0x20c0000 0x0 0x10000>, + <0x0 0x20000000 0x0 0x10000000>; + reg-names = "fspi_base", "fspi_mmap"; + interrupts = <0 25 0x4>; /* Level high type */ + clocks = <&clockgen 4 3>, <&clockgen 4 3>; + clock-names = "fspi_en", "fspi"; + }; }; }; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 5/7] arm64: dts: lx2160a: add fspi node property @ 2018-08-31 10:30 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-arm-kernel Add fspi node property for LX2160A SoC for FlexSPI driver. Property added for the FlexSPI controller and for the connected slave device for the LX2160ARDB target. This is having two SPI-NOR flash device, mt35xu512aba, connected at CS0 and CS1. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +++++++++++++++++++++ arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 ++++++++++++ 2 files changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts index 70fad20..3646315 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts @@ -32,6 +32,27 @@ status = "okay"; }; +&fspi { + status = "okay"; + flash0: mt35xu512aba at 0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "m25p80"; + m25p,fast-read; + spi-max-frequency = <20000000>; + reg = <0>; + }; + + flash1: mt35xu512aba at 1 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "m25p80"; + m25p,fast-read; + spi-max-frequency = <20000000>; + reg = <1>; + }; +}; + &i2c0 { status = "okay"; pca9547 at 77 { diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi index e35e494..031eb26 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi @@ -568,5 +568,17 @@ timeout-sec = <30>; }; + fspi: flexspi at 20c0000 { + status = "disabled"; + compatible = "nxp,lx2160a-fspi"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x0 0x20c0000 0x0 0x10000>, + <0x0 0x20000000 0x0 0x10000000>; + reg-names = "fspi_base", "fspi_mmap"; + interrupts = <0 25 0x4>; /* Level high type */ + clocks = <&clockgen 4 3>, <&clockgen 4 3>; + clock-names = "fspi_en", "fspi"; + }; }; }; -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH 5/7] arm64: dts: lx2160a: add fspi node property 2018-08-31 10:30 ` Yogesh Gaur @ 2018-09-03 3:01 ` Shawn Guo -1 siblings, 0 replies; 64+ messages in thread From: Shawn Guo @ 2018-09-03 3:01 UTC (permalink / raw) To: Yogesh Gaur Cc: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree, mark.rutland, robh, linux-kernel, frieder.schrempf, computersforpeace, linux-arm-kernel On Fri, Aug 31, 2018 at 04:00:02PM +0530, Yogesh Gaur wrote: > Add fspi node property for LX2160A SoC for FlexSPI driver. > Property added for the FlexSPI controller and for the connected > slave device for the LX2160ARDB target. > This is having two SPI-NOR flash device, mt35xu512aba, connected > at CS0 and CS1. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +++++++++++++++++++++ > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 ++++++++++++ > 2 files changed, 33 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > index 70fad20..3646315 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > @@ -32,6 +32,27 @@ > status = "okay"; > }; > > +&fspi { > + status = "okay"; Have a newline between property and child node. > + flash0: mt35xu512aba@0 { Generic name for node, and specific name for label. > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "m25p80"; Please take a look at bindings doc jedec,spi-nor.txt on how compatible should be written. > + m25p,fast-read; > + spi-max-frequency = <20000000>; > + reg = <0>; > + }; > + > + flash1: mt35xu512aba@1 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "m25p80"; > + m25p,fast-read; > + spi-max-frequency = <20000000>; > + reg = <1>; > + }; > +}; > + > &i2c0 { > status = "okay"; > pca9547@77 { > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > index e35e494..031eb26 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > @@ -568,5 +568,17 @@ > timeout-sec = <30>; > }; > > + fspi: flexspi@20c0000 { > + status = "disabled"; We conventionally put 'status' line at the end of property list. Shawn > + compatible = "nxp,lx2160a-fspi"; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x0 0x20c0000 0x0 0x10000>, > + <0x0 0x20000000 0x0 0x10000000>; > + reg-names = "fspi_base", "fspi_mmap"; > + interrupts = <0 25 0x4>; /* Level high type */ > + clocks = <&clockgen 4 3>, <&clockgen 4 3>; > + clock-names = "fspi_en", "fspi"; > + }; > }; > }; > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 5/7] arm64: dts: lx2160a: add fspi node property @ 2018-09-03 3:01 ` Shawn Guo 0 siblings, 0 replies; 64+ messages in thread From: Shawn Guo @ 2018-09-03 3:01 UTC (permalink / raw) To: linux-arm-kernel On Fri, Aug 31, 2018 at 04:00:02PM +0530, Yogesh Gaur wrote: > Add fspi node property for LX2160A SoC for FlexSPI driver. > Property added for the FlexSPI controller and for the connected > slave device for the LX2160ARDB target. > This is having two SPI-NOR flash device, mt35xu512aba, connected > at CS0 and CS1. > > Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> > --- > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 +++++++++++++++++++++ > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 ++++++++++++ > 2 files changed, 33 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > index 70fad20..3646315 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts > @@ -32,6 +32,27 @@ > status = "okay"; > }; > > +&fspi { > + status = "okay"; Have a newline between property and child node. > + flash0: mt35xu512aba at 0 { Generic name for node, and specific name for label. > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "m25p80"; Please take a look at bindings doc jedec,spi-nor.txt on how compatible should be written. > + m25p,fast-read; > + spi-max-frequency = <20000000>; > + reg = <0>; > + }; > + > + flash1: mt35xu512aba at 1 { > + #address-cells = <1>; > + #size-cells = <1>; > + compatible = "m25p80"; > + m25p,fast-read; > + spi-max-frequency = <20000000>; > + reg = <1>; > + }; > +}; > + > &i2c0 { > status = "okay"; > pca9547 at 77 { > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > index e35e494..031eb26 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi > @@ -568,5 +568,17 @@ > timeout-sec = <30>; > }; > > + fspi: flexspi at 20c0000 { > + status = "disabled"; We conventionally put 'status' line at the end of property list. Shawn > + compatible = "nxp,lx2160a-fspi"; > + #address-cells = <1>; > + #size-cells = <0>; > + reg = <0x0 0x20c0000 0x0 0x10000>, > + <0x0 0x20000000 0x0 0x10000000>; > + reg-names = "fspi_base", "fspi_mmap"; > + interrupts = <0 25 0x4>; /* Level high type */ > + clocks = <&clockgen 4 3>, <&clockgen 4 3>; > + clock-names = "fspi_en", "fspi"; > + }; > }; > }; > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 6/7] arm64: defconfig: enable NXP FlexSPI driver 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:30 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Enable driver support of NXP FlexSPI controller. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 3cfa8ca..75ceddf 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -335,6 +335,7 @@ CONFIG_SPI_QUP=y CONFIG_SPI_ROCKCHIP=y CONFIG_SPI_S3C64XX=y CONFIG_SPI_SPIDEV=m +CONFIG_SPI_NXP_FLEXSPI=y CONFIG_SPMI=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_SINGLE=y -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] arm64: defconfig: enable NXP FlexSPI driver @ 2018-08-31 10:30 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-arm-kernel Enable driver support of NXP FlexSPI controller. Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 3cfa8ca..75ceddf 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -335,6 +335,7 @@ CONFIG_SPI_QUP=y CONFIG_SPI_ROCKCHIP=y CONFIG_SPI_S3C64XX=y CONFIG_SPI_SPIDEV=m +CONFIG_SPI_NXP_FLEXSPI=y CONFIG_SPMI=y CONFIG_PINCTRL_IPQ8074=y CONFIG_PINCTRL_SINGLE=y -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 7/7] MAINTAINERS: add maintainers for the NXP FlexSPI driver 2018-08-31 10:29 ` Yogesh Gaur @ 2018-08-31 10:30 ` Yogesh Gaur -1 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-mtd, boris.brezillon, marek.vasut, linux-spi, devicetree Cc: robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel, Yogesh Gaur Add maintainers for the NXP FlexSPI driver Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff..2696898 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10228,6 +10228,12 @@ L: linux-nfc@lists.01.org (moderated for non-subscribers) S: Supported F: drivers/nfc/nxp-nci +NXP FSPI DRIVER +M: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> +L: linux-spi@vger.kernel.org +S: Maintained +F: drivers/spi/spi-nxp-fspi.c + OBJTOOL M: Josh Poimboeuf <jpoimboe@redhat.com> M: Peter Zijlstra <peterz@infradead.org> -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 7/7] MAINTAINERS: add maintainers for the NXP FlexSPI driver @ 2018-08-31 10:30 ` Yogesh Gaur 0 siblings, 0 replies; 64+ messages in thread From: Yogesh Gaur @ 2018-08-31 10:30 UTC (permalink / raw) To: linux-arm-kernel Add maintainers for the NXP FlexSPI driver Signed-off-by: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> --- MAINTAINERS | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff..2696898 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10228,6 +10228,12 @@ L: linux-nfc at lists.01.org (moderated for non-subscribers) S: Supported F: drivers/nfc/nxp-nci +NXP FSPI DRIVER +M: Yogesh Gaur <yogeshnarayan.gaur@nxp.com> +L: linux-spi at vger.kernel.org +S: Maintained +F: drivers/spi/spi-nxp-fspi.c + OBJTOOL M: Josh Poimboeuf <jpoimboe@redhat.com> M: Peter Zijlstra <peterz@infradead.org> -- 2.7.4 ^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller 2018-08-31 10:29 ` Yogesh Gaur @ 2018-09-04 12:43 ` Boris Brezillon -1 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 12:43 UTC (permalink / raw) To: Yogesh Gaur Cc: linux-mtd, marek.vasut, linux-spi, devicetree, robh, mark.rutland, shawnguo, linux-arm-kernel, computersforpeace, frieder.schrempf, linux-kernel Hi Yogesh, On Fri, 31 Aug 2018 15:59:57 +0530 Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > - Add a driver for NXP FlexSPI host controller > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > which supports two SPI channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8 > bidirectional data lines. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512aba[3], [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Patch 1 adds variable size in spi_device struct, to save the > size of connected slave device. > Patch 2 adds flags for octal I/O data transfer. > Support for octal flash commands and other framework changes would going to be done in different > patch set. > Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on > new spi-mem framework. Can we please omit octa mode support for now and focus on single/dual/quad SPI support? That is, drop patch 2, and do not set the OCTAL flags in patch 3. Regards, Boris > Patch 4 add binding file for this driver. > Patch 5 add device node property for FlexSPI driver for lx2160 SoC. > Patch 6 enables the config option. > Patch 7 add MAINTAINERS file. > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721 > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445 > > This series adds below patches: > Yogesh Gaur (7): > spi: add slave device size in spi_device struct > spi: add flags for octal I/O data transfer > spi: spi-mem: Add a driver for NXP FlexSPI controller > dt-bindings: spi: add binding file for NXP FlexSPI driver > arm64: dts: lx2160a: add fspi node property > arm64: defconfig: enable NXP FlexSPI driver > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 + > MAINTAINERS | 6 + > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 + > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > arch/arm64/configs/defconfig | 1 + > drivers/mtd/devices/m25p80.c | 6 + > drivers/mtd/spi-nor/spi-nor.c | 2 + > drivers/spi/Kconfig | 10 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++ > include/linux/spi/spi.h | 4 + > 11 files changed, 1347 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > create mode 100644 drivers/spi/spi-nxp-fspi.c > ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller @ 2018-09-04 12:43 ` Boris Brezillon 0 siblings, 0 replies; 64+ messages in thread From: Boris Brezillon @ 2018-09-04 12:43 UTC (permalink / raw) To: linux-arm-kernel Hi Yogesh, On Fri, 31 Aug 2018 15:59:57 +0530 Yogesh Gaur <yogeshnarayan.gaur@nxp.com> wrote: > - Add a driver for NXP FlexSPI host controller > > FlexSPI is a flexsible SPI host controller [1], Chapter 30 page 1475, > which supports two SPI channels and up to 4 external devices. > Each channel supports Single/Dual/Quad/Octal mode data transfer (1/2/4/8 bidirectional data lines) > i.e. FlexSPI acts as an interface to external devices, maximum 4, each with up to 8 > bidirectional data lines. > > FlexSPI controller is similar to the existing Freescale/NXP QuadSPI > controller with advanced features. > > - Tested this driver with mtd_debug(Erase/Write/Read) utility and JFFS2 > filesystem mounting and booting on NXP LX2160ARDB[2] and LX2160AQDS targets. > LX2160ARDB is having two NOR slave device connected on single bus A > i.e. A0 and A1 (CS0 and CS1). > LX2160AQDS is having two NOR slave device connected on separate buses > one flash on A0 and second on B1 i.e. (CS0 and CS3). > Verified this driver on following SPI NOR flashes: > Micron, mt35xu512aba[3], [Read - 1 bit mode] > Cypress, s25fl512s, [Read - 1/2/4 bit mode] > > Patch 1 adds variable size in spi_device struct, to save the > size of connected slave device. > Patch 2 adds flags for octal I/O data transfer. > Support for octal flash commands and other framework changes would going to be done in different > patch set. > Patch 3 adds a driver for the NXP FlexSPI controller, driver is based on > new spi-mem framework. Can we please omit octa mode support for now and focus on single/dual/quad SPI support? That is, drop patch 2, and do not set the OCTAL flags in patch 3. Regards, Boris > Patch 4 add binding file for this driver. > Patch 5 add device node property for FlexSPI driver for lx2160 SoC. > Patch 6 enables the config option. > Patch 7 add MAINTAINERS file. > > [1] https://www.nxp.com/docs/en/reference-manual/IMXRT1050RM.pdf > [2] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=9721 > [3] https://patchwork.ozlabs.org/project/linux-mtd/list/?series=63445 > > This series adds below patches: > Yogesh Gaur (7): > spi: add slave device size in spi_device struct > spi: add flags for octal I/O data transfer > spi: spi-mem: Add a driver for NXP FlexSPI controller > dt-bindings: spi: add binding file for NXP FlexSPI driver > arm64: dts: lx2160a: add fspi node property > arm64: defconfig: enable NXP FlexSPI driver > MAINTAINERS: add maintainers for the NXP FlexSPI driver > > .../devicetree/bindings/spi/spi-nxp-fspi.txt | 42 + > MAINTAINERS | 6 + > arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 21 + > arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 12 + > arch/arm64/configs/defconfig | 1 + > drivers/mtd/devices/m25p80.c | 6 + > drivers/mtd/spi-nor/spi-nor.c | 2 + > drivers/spi/Kconfig | 10 + > drivers/spi/Makefile | 1 + > drivers/spi/spi-nxp-fspi.c | 1242 ++++++++++++++++++++ > include/linux/spi/spi.h | 4 + > 11 files changed, 1347 insertions(+) > create mode 100644 Documentation/devicetree/bindings/spi/spi-nxp-fspi.txt > create mode 100644 drivers/spi/spi-nxp-fspi.c > ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2018-09-06 12:24 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-31 10:29 [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller Yogesh Gaur 2018-08-31 10:29 ` Yogesh Gaur 2018-08-31 10:29 ` [PATCH 1/7] spi: add slave device size in spi_device struct Yogesh Gaur 2018-08-31 10:29 ` Yogesh Gaur 2018-08-31 11:41 ` Geert Uytterhoeven 2018-08-31 11:41 ` Geert Uytterhoeven 2018-08-31 11:41 ` Geert Uytterhoeven 2018-08-31 11:58 ` Lothar Waßmann 2018-08-31 11:58 ` Lothar Waßmann 2018-09-03 4:47 ` Yogesh Narayan Gaur 2018-09-03 4:47 ` Yogesh Narayan Gaur 2018-09-03 4:47 ` Yogesh Narayan Gaur 2018-09-03 8:36 ` Boris Brezillon 2018-09-03 8:36 ` Boris Brezillon 2018-08-31 10:29 ` [PATCH 2/7] spi: add flags for octal I/O data transfer Yogesh Gaur 2018-08-31 10:29 ` Yogesh Gaur 2018-08-31 10:30 ` [PATCH 3/7] spi: spi-mem: Add a driver for NXP FlexSPI controller Yogesh Gaur 2018-08-31 10:30 ` Yogesh Gaur 2018-09-04 14:58 ` Boris Brezillon 2018-09-04 14:58 ` Boris Brezillon 2018-09-05 10:07 ` Yogesh Narayan Gaur 2018-09-05 10:07 ` Yogesh Narayan Gaur 2018-09-05 10:07 ` Yogesh Narayan Gaur 2018-09-06 8:26 ` Frieder Schrempf 2018-09-06 8:26 ` Frieder Schrempf 2018-09-06 8:26 ` Frieder Schrempf 2018-09-06 8:26 ` Frieder Schrempf 2018-09-06 11:35 ` Yogesh Narayan Gaur 2018-09-06 11:35 ` Yogesh Narayan Gaur 2018-09-06 11:35 ` Yogesh Narayan Gaur 2018-09-06 11:43 ` Boris Brezillon 2018-09-06 11:43 ` Boris Brezillon 2018-09-06 11:43 ` Boris Brezillon 2018-09-06 12:23 ` Yogesh Narayan Gaur 2018-09-06 12:23 ` Yogesh Narayan Gaur 2018-09-06 12:23 ` Yogesh Narayan Gaur 2018-08-31 10:30 ` [PATCH 4/7] dt-bindings: spi: add binding file for NXP FlexSPI driver Yogesh Gaur 2018-08-31 10:30 ` Yogesh Gaur 2018-09-03 9:54 ` Prabhakar Kushwaha 2018-09-03 9:54 ` Prabhakar Kushwaha 2018-09-03 9:54 ` Prabhakar Kushwaha 2018-09-03 9:54 ` Prabhakar Kushwaha 2018-09-04 5:37 ` Yogesh Narayan Gaur 2018-09-04 5:37 ` Yogesh Narayan Gaur 2018-09-04 5:37 ` Yogesh Narayan Gaur 2018-09-04 12:46 ` Boris Brezillon 2018-09-04 12:46 ` Boris Brezillon 2018-09-04 12:46 ` Boris Brezillon 2018-09-06 7:08 ` Jagdish Gediya 2018-09-06 7:08 ` Jagdish Gediya 2018-09-06 7:08 ` Jagdish Gediya 2018-09-04 1:33 ` Rob Herring 2018-09-04 1:33 ` Rob Herring 2018-09-04 1:33 ` Rob Herring 2018-08-31 10:30 ` [PATCH 5/7] arm64: dts: lx2160a: add fspi node property Yogesh Gaur 2018-08-31 10:30 ` Yogesh Gaur 2018-09-03 3:01 ` Shawn Guo 2018-09-03 3:01 ` Shawn Guo 2018-08-31 10:30 ` [PATCH 6/7] arm64: defconfig: enable NXP FlexSPI driver Yogesh Gaur 2018-08-31 10:30 ` Yogesh Gaur 2018-08-31 10:30 ` [PATCH 7/7] MAINTAINERS: add maintainers for the " Yogesh Gaur 2018-08-31 10:30 ` Yogesh Gaur 2018-09-04 12:43 ` [PATCH 0/7] spi: spi-mem: Add a driver for NXP FlexSPI controller Boris Brezillon 2018-09-04 12:43 ` Boris Brezillon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.