[PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Frieder Schrempf]

Now that the SPI memory interface was introduced by Boris [1], it is
possible to move drivers from mtd/spi-nor to the SPI framework in order
to use them for different type of SPI memory chips.

Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
and a ->name field to struct spi_mem.
Patch 2 uses it in m25p80.c to make it possible for SPI controller
drivers to provide a custom naming scheme for the flash chip.
This is needed to avoid breaking compatibility of mtdparts when switching
from the old to the new driver.

Patch 3 adds a driver for the Freescale QSPI controller to the SPI
framework. Together with m25p80.c it can be used to interface SPI
NOR flashes just as the old driver did. For this to work properly a few
minor changes to the devicetrees are necessary (see patches 5 to 7).

Patch 8 changes the defconfigs to use the new driver and patch 9 removes
the old driver.

Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
Patch 12 adjusts the MAINTAINERS file.

The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
The read performance of the new driver is almost the same or even better
than the old driver, depending on the block size.
The write performance is a bit slower on average (~10-15%).

The new driver was also tested with the SPI NAND framework [2] and a
Winbond W25M02GV flash.

If someone has a board that uses both chips selects and/or both busses,
it would be really nice to have the driver be tested on such a setup.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-4.18&id=c36ff266dc82f4ae797a6f3513c6ffa344f7f1c7
[2] https://patchwork.ozlabs.org/cover/913728/

Changes in v2:
==============
* Rebase on top of nand/next
* Add a name field to struct spi_mem and fill it while probing
* Add Yogesh Gaur and Suresh Gupta as authors
* Use GENMASK() for generating bitmasks
* Use callback functions for read/write of registers
* Attach the seq variable to the selected CS
* Avoid using conditional in read/write loop
* Avoid infinite loop and use a timeout instead
* Return error pointer when allocation in fsl_qspi_get_name() fails
* Remove redundant iounmap()
* Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver
* Split the moving and editing of the dt-bindings in two patches

Frieder Schrempf (12):
  spi: spi-mem: Extend the SPI mem interface to set a custom memory name
  mtd: m25p80: Call spi_mem_get_name() to let controller set a custom
    name
  spi: Add a driver for the Freescale/NXP QuadSPI controller
  dt-bindings: spi: Move the bindings for the FSL QSPI driver
  dt-bindings: spi: Adjust the bindings for the FSL QSPI driver
  ARM: dts: Reflect change of FSL QSPI driver and remove unused
    properties
  arm64: dts: Reflect change of FSL QSPI driver and remove unused
    properties
  ARM: defconfig: Use the new FSL QSPI driver under the SPI framework
  mtd: fsl-quadspi: Remove the driver as it was replaced by
    spi-fsl-qspi.c
  ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used
  ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used
  MAINTAINERS: Move the Freescale QSPI driver to the SPI framework

 .../devicetree/bindings/mtd/fsl-quadspi.txt     |   65 -
 .../devicetree/bindings/spi/spi-fsl-qspi.txt    |   65 +
 MAINTAINERS                                     |    4 +-
 arch/arm/boot/dts/imx6sx-sdb-reva.dts           |    8 +-
 arch/arm/boot/dts/imx6sx-sdb.dts                |    8 +-
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi         |    2 +
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts     |    6 +-
 arch/arm/configs/imx_v6_v7_defconfig            |    2 +-
 arch/arm/configs/multi_v7_defconfig             |    2 +-
 .../boot/dts/freescale/fsl-ls1043a-qds.dts      |    3 +-
 .../boot/dts/freescale/fsl-ls1046a-qds.dts      |    4 +-
 .../boot/dts/freescale/fsl-ls1046a-rdb.dts      |    6 +-
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi  |    1 -
 .../boot/dts/freescale/fsl-ls208xa-qds.dtsi     |    4 +
 drivers/mtd/devices/m25p80.c                    |    3 +-
 drivers/mtd/spi-nor/Kconfig                     |    9 -
 drivers/mtd/spi-nor/Makefile                    |    1 -
 drivers/mtd/spi-nor/fsl-quadspi.c               | 1217 ------------------
 drivers/spi/Kconfig                             |   11 +
 drivers/spi/Makefile                            |    1 +
 drivers/spi/spi-fsl-qspi.c                      |  954 ++++++++++++++
 drivers/spi/spi-mem.c                           |   30 +
 include/linux/spi/spi-mem.h                     |    7 +-
 23 files changed, 1100 insertions(+), 1313 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
 delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c
 create mode 100644 drivers/spi/spi-fsl-qspi.c

-- 
2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Frieder Schrempf]

Now that the SPI memory interface was introduced by Boris [1], it is
possible to move drivers from mtd/spi-nor to the SPI framework in order
to use them for different type of SPI memory chips.

Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
and a ->name field to struct spi_mem.
Patch 2 uses it in m25p80.c to make it possible for SPI controller
drivers to provide a custom naming scheme for the flash chip.
This is needed to avoid breaking compatibility of mtdparts when switching
from the old to the new driver.

Patch 3 adds a driver for the Freescale QSPI controller to the SPI
framework. Together with m25p80.c it can be used to interface SPI
NOR flashes just as the old driver did. For this to work properly a few
minor changes to the devicetrees are necessary (see patches 5 to 7).

Patch 8 changes the defconfigs to use the new driver and patch 9 removes
the old driver.

Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
Patch 12 adjusts the MAINTAINERS file.

The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
The read performance of the new driver is almost the same or even better
than the old driver, depending on the block size.
The write performance is a bit slower on average (~10-15%).

The new driver was also tested with the SPI NAND framework [2] and a
Winbond W25M02GV flash.

If someone has a board that uses both chips selects and/or both busses,
it would be really nice to have the driver be tested on such a setup.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git/commit/?h=for-4.18&id=c36ff266dc82f4ae797a6f3513c6ffa344f7f1c7
[2] https://patchwork.ozlabs.org/cover/913728/

Changes in v2:
==============
* Rebase on top of nand/next
* Add a name field to struct spi_mem and fill it while probing
* Add Yogesh Gaur and Suresh Gupta as authors
* Use GENMASK() for generating bitmasks
* Use callback functions for read/write of registers
* Attach the seq variable to the selected CS
* Avoid using conditional in read/write loop
* Avoid infinite loop and use a timeout instead
* Return error pointer when allocation in fsl_qspi_get_name() fails
* Remove redundant iounmap()
* Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver
* Split the moving and editing of the dt-bindings in two patches

Frieder Schrempf (12):
  spi: spi-mem: Extend the SPI mem interface to set a custom memory name
  mtd: m25p80: Call spi_mem_get_name() to let controller set a custom
    name
  spi: Add a driver for the Freescale/NXP QuadSPI controller
  dt-bindings: spi: Move the bindings for the FSL QSPI driver
  dt-bindings: spi: Adjust the bindings for the FSL QSPI driver
  ARM: dts: Reflect change of FSL QSPI driver and remove unused
    properties
  arm64: dts: Reflect change of FSL QSPI driver and remove unused
    properties
  ARM: defconfig: Use the new FSL QSPI driver under the SPI framework
  mtd: fsl-quadspi: Remove the driver as it was replaced by
    spi-fsl-qspi.c
  ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used
  ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used
  MAINTAINERS: Move the Freescale QSPI driver to the SPI framework

 .../devicetree/bindings/mtd/fsl-quadspi.txt     |   65 -
 .../devicetree/bindings/spi/spi-fsl-qspi.txt    |   65 +
 MAINTAINERS                                     |    4 +-
 arch/arm/boot/dts/imx6sx-sdb-reva.dts           |    8 +-
 arch/arm/boot/dts/imx6sx-sdb.dts                |    8 +-
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi         |    2 +
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts     |    6 +-
 arch/arm/configs/imx_v6_v7_defconfig            |    2 +-
 arch/arm/configs/multi_v7_defconfig             |    2 +-
 .../boot/dts/freescale/fsl-ls1043a-qds.dts      |    3 +-
 .../boot/dts/freescale/fsl-ls1046a-qds.dts      |    4 +-
 .../boot/dts/freescale/fsl-ls1046a-rdb.dts      |    6 +-
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi  |    1 -
 .../boot/dts/freescale/fsl-ls208xa-qds.dtsi     |    4 +
 drivers/mtd/devices/m25p80.c                    |    3 +-
 drivers/mtd/spi-nor/Kconfig                     |    9 -
 drivers/mtd/spi-nor/Makefile                    |    1 -
 drivers/mtd/spi-nor/fsl-quadspi.c               | 1217 ------------------
 drivers/spi/Kconfig                             |   11 +
 drivers/spi/Makefile                            |    1 +
 drivers/spi/spi-fsl-qspi.c                      |  954 ++++++++++++++
 drivers/spi/spi-mem.c                           |   30 +
 include/linux/spi/spi-mem.h                     |    7 +-
 23 files changed, 1100 insertions(+), 1313 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
 delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c
 create mode 100644 drivers/spi/spi-fsl-qspi.c

-- 
2.7.4

[PATCH v2 01/12] spi: spi-mem: Extend the SPI mem interface to set a custom memory name

[Frieder Schrempf]

When porting (Q)SPI controller drivers from the MTD layer to the SPI
layer, the naming scheme for the memory devices changes. To be able
to keep compatibility with the old drivers naming scheme, a function
is added to the SPI mem interface to let controller drivers set a
custom name for the memory.

Example for the FSL QSPI driver:

Name with the old driver: 21e0000.qspi,
or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ...

Name with the new driver without spi_mem_get_name: spi4.0

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
Changes in v2:
==============
* Add a name field to struct spi_mem and fill it while probing

 drivers/spi/spi-mem.c       | 30 ++++++++++++++++++++++++++++++
 include/linux/spi/spi-mem.h |  7 ++++++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 990770d..048101c 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -311,6 +311,26 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
 EXPORT_SYMBOL_GPL(spi_mem_exec_op);
 
 /**
+ * spi_mem_get_name() - Let drivers using the SPI mem interface specify a
+ *			custom name for the memory to avoid compatibility
+ *			issues with ported drivers.
+ * @mem: the SPI memory
+ *
+ * When porting (Q)SPI controller drivers from the MTD layer to the SPI
+ * layer, the naming scheme for the memory devices changes. To be able to
+ * keep compatibility with the old drivers naming scheme, this function can
+ * be used to get a custom name from the controller driver.
+ * If no custom name is available, the name of the SPI device is returned.
+ *
+ * Return: a char array that contains the name for the flash memory
+ */
+const char *spi_mem_get_name(struct spi_mem *mem)
+{
+	return mem->name;
+}
+EXPORT_SYMBOL_GPL(spi_mem_get_name);
+
+/**
  * spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
  *			      match controller limitations
  * @mem: the SPI memory
@@ -344,6 +364,7 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
 static int spi_mem_probe(struct spi_device *spi)
 {
 	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
+	struct spi_controller *ctlr = spi->controller;
 	struct spi_mem *mem;
 
 	mem = devm_kzalloc(&spi->dev, sizeof(*mem), GFP_KERNEL);
@@ -351,6 +372,15 @@ static int spi_mem_probe(struct spi_device *spi)
 		return -ENOMEM;
 
 	mem->spi = spi;
+
+	if (ctlr->mem_ops && ctlr->mem_ops->get_name)
+		mem->name = ctlr->mem_ops->get_name(mem);
+	else
+		mem->name = dev_name(&spi->dev);
+
+	if (IS_ERR_OR_NULL(mem->name))
+		return PTR_ERR(mem->name);
+
 	spi_set_drvdata(spi, mem);
 
 	return memdrv->probe(mem);
diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
index 4fa34a2..c3f82d1 100644
--- a/include/linux/spi/spi-mem.h
+++ b/include/linux/spi/spi-mem.h
@@ -124,7 +124,8 @@ struct spi_mem_op {
 /**
  * struct spi_mem - describes a SPI memory device
  * @spi: the underlying SPI device
- * @drvpriv: spi_mem_drviver private data
+ * @drvpriv: spi_mem_driver private data
+ * @name: name of the SPI memory device
  *
  * Extra information that describe the SPI memory device and may be needed by
  * the controller to properly handle this device should be placed here.
@@ -135,6 +136,7 @@ struct spi_mem_op {
 struct spi_mem {
 	struct spi_device *spi;
 	void *drvpriv;
+	char *name;
 };
 
 /**
@@ -178,6 +180,7 @@ struct spi_controller_mem_ops {
 			    const struct spi_mem_op *op);
 	int (*exec_op)(struct spi_mem *mem,
 		       const struct spi_mem_op *op);
+	const char *(*get_name)(struct spi_mem *mem);
 };
 
 /**
@@ -236,6 +239,8 @@ bool spi_mem_supports_op(struct spi_mem *mem,
 int spi_mem_exec_op(struct spi_mem *mem,
 		    const struct spi_mem_op *op);
 
+const char *spi_mem_get_name(struct spi_mem *mem);
+
 int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
 				       struct module *owner);
 
-- 
2.7.4

Re: [PATCH v2 01/12] spi: spi-mem: Extend the SPI mem interface to set a custom memory name

[Boris Brezillon]

Hi Frieder,

On Thu,  5 Jul 2018 13:14:57 +0200
Frieder Schrempf <frieder.schrempf@exceet.de> wrote:

> When porting (Q)SPI controller drivers from the MTD layer to the SPI
> layer, the naming scheme for the memory devices changes. To be able
> to keep compatibility with the old drivers naming scheme, a function
> is added to the SPI mem interface to let controller drivers set a
> custom name for the memory.
> 
> Example for the FSL QSPI driver:
> 
> Name with the old driver: 21e0000.qspi,
> or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ...
> 
> Name with the new driver without spi_mem_get_name: spi4.0
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
> Changes in v2:
> ==============
> * Add a name field to struct spi_mem and fill it while probing
> 
>  drivers/spi/spi-mem.c       | 30 ++++++++++++++++++++++++++++++
>  include/linux/spi/spi-mem.h |  7 ++++++-
>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index 990770d..048101c 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -311,6 +311,26 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
>  EXPORT_SYMBOL_GPL(spi_mem_exec_op);
>  
>  /**
> + * spi_mem_get_name() - Let drivers using the SPI mem interface specify a
> + *			custom name for the memory to avoid compatibility
> + *			issues with ported drivers.

You're not describing what this function does, but why it was
introduced. Not sure the spi-mem user/driver cares about that, these are
just internal details. Probably something you should put in the
->get_name() hook doc.

> + * @mem: the SPI memory
> + *
> + * When porting (Q)SPI controller drivers from the MTD layer to the SPI
> + * layer, the naming scheme for the memory devices changes. To be able to
> + * keep compatibility with the old drivers naming scheme, this function can
> + * be used to get a custom name from the controller driver.
> + * If no custom name is available, the name of the SPI device is returned.

Ditto. Just say that this function returns the spi-mem device name which
can be used by the upper layer if they need to expose a user-friendly
name.

> + *
> + * Return: a char array that contains the name for the flash memory

	      ^ a string?

     Return: a string containing the name of the memory device to be
	     used by the spi-mem user

> + */
> +const char *spi_mem_get_name(struct spi_mem *mem)
> +{
> +	return mem->name;
> +}
> +EXPORT_SYMBOL_GPL(spi_mem_get_name);
> +
> +/**
>   * spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
>   *			      match controller limitations
>   * @mem: the SPI memory
> @@ -344,6 +364,7 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>  static int spi_mem_probe(struct spi_device *spi)
>  {
>  	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
> +	struct spi_controller *ctlr = spi->controller;
>  	struct spi_mem *mem;
>  
>  	mem = devm_kzalloc(&spi->dev, sizeof(*mem), GFP_KERNEL);
> @@ -351,6 +372,15 @@ static int spi_mem_probe(struct spi_device *spi)
>  		return -ENOMEM;
>  
>  	mem->spi = spi;
> +
> +	if (ctlr->mem_ops && ctlr->mem_ops->get_name)
> +		mem->name = ctlr->mem_ops->get_name(mem);
> +	else
> +		mem->name = dev_name(&spi->dev);
> +
> +	if (IS_ERR_OR_NULL(mem->name))
> +		return PTR_ERR(mem->name);
> +
>  	spi_set_drvdata(spi, mem);
>  
>  	return memdrv->probe(mem);
> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index 4fa34a2..c3f82d1 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h
> @@ -124,7 +124,8 @@ struct spi_mem_op {
>  /**
>   * struct spi_mem - describes a SPI memory device
>   * @spi: the underlying SPI device
> - * @drvpriv: spi_mem_drviver private data
> + * @drvpriv: spi_mem_driver private data

Can you fix this typo in a separate patch?

> + * @name: name of the SPI memory device
>   *
>   * Extra information that describe the SPI memory device and may be needed by
>   * the controller to properly handle this device should be placed here.
> @@ -135,6 +136,7 @@ struct spi_mem_op {
>  struct spi_mem {
>  	struct spi_device *spi;
>  	void *drvpriv;
> +	char *name;
>  };
>  
>  /**
> @@ -178,6 +180,7 @@ struct spi_controller_mem_ops {
>  			    const struct spi_mem_op *op);
>  	int (*exec_op)(struct spi_mem *mem,
>  		       const struct spi_mem_op *op);
> +	const char *(*get_name)(struct spi_mem *mem);

You forgot to document this hook. Also, it's important to mention that
if the name returned by this function is dynamically allocated, it
should be allocated with devm_xxxx(), because we don't have a
->free_name() function.

>  };
>  
>  /**
> @@ -236,6 +239,8 @@ bool spi_mem_supports_op(struct spi_mem *mem,
>  int spi_mem_exec_op(struct spi_mem *mem,
>  		    const struct spi_mem_op *op);
>  
> +const char *spi_mem_get_name(struct spi_mem *mem);
> +
>  int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>  				       struct module *owner);
>  

Thanks,

Boris

Re: [PATCH v2 01/12] spi: spi-mem: Extend the SPI mem interface to set a custom memory name

[Frieder Schrempf]

Hi Boris,

On 05.07.2018 14:39, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu,  5 Jul 2018 13:14:57 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> When porting (Q)SPI controller drivers from the MTD layer to the SPI
>> layer, the naming scheme for the memory devices changes. To be able
>> to keep compatibility with the old drivers naming scheme, a function
>> is added to the SPI mem interface to let controller drivers set a
>> custom name for the memory.
>>
>> Example for the FSL QSPI driver:
>>
>> Name with the old driver: 21e0000.qspi,
>> or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ...
>>
>> Name with the new driver without spi_mem_get_name: spi4.0
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Add a name field to struct spi_mem and fill it while probing
>>
>>   drivers/spi/spi-mem.c       | 30 ++++++++++++++++++++++++++++++
>>   include/linux/spi/spi-mem.h |  7 ++++++-
>>   2 files changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
>> index 990770d..048101c 100644
>> --- a/drivers/spi/spi-mem.c
>> +++ b/drivers/spi/spi-mem.c
>> @@ -311,6 +311,26 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
>>   EXPORT_SYMBOL_GPL(spi_mem_exec_op);
>>   
>>   /**
>> + * spi_mem_get_name() - Let drivers using the SPI mem interface specify a
>> + *			custom name for the memory to avoid compatibility
>> + *			issues with ported drivers.
> 
> You're not describing what this function does, but why it was
> introduced. Not sure the spi-mem user/driver cares about that, these are
> just internal details. Probably something you should put in the
> ->get_name() hook doc.

Ok. You're right.

> 
>> + * @mem: the SPI memory
>> + *
>> + * When porting (Q)SPI controller drivers from the MTD layer to the SPI
>> + * layer, the naming scheme for the memory devices changes. To be able to
>> + * keep compatibility with the old drivers naming scheme, this function can
>> + * be used to get a custom name from the controller driver.
>> + * If no custom name is available, the name of the SPI device is returned.
> 
> Ditto. Just say that this function returns the spi-mem device name which
> can be used by the upper layer if they need to expose a user-friendly
> name.

Ok.

> 
>> + *
>> + * Return: a char array that contains the name for the flash memory
> 
> 	      ^ a string?
> 
>       Return: a string containing the name of the memory device to be
> 	     used by the spi-mem user

Ok.

> 
>> + */
>> +const char *spi_mem_get_name(struct spi_mem *mem)
>> +{
>> +	return mem->name;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_mem_get_name);
>> +
>> +/**
>>    * spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
>>    *			      match controller limitations
>>    * @mem: the SPI memory
>> @@ -344,6 +364,7 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>>   static int spi_mem_probe(struct spi_device *spi)
>>   {
>>   	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
>> +	struct spi_controller *ctlr = spi->controller;
>>   	struct spi_mem *mem;
>>   
>>   	mem = devm_kzalloc(&spi->dev, sizeof(*mem), GFP_KERNEL);
>> @@ -351,6 +372,15 @@ static int spi_mem_probe(struct spi_device *spi)
>>   		return -ENOMEM;
>>   
>>   	mem->spi = spi;
>> +
>> +	if (ctlr->mem_ops && ctlr->mem_ops->get_name)
>> +		mem->name = ctlr->mem_ops->get_name(mem);
>> +	else
>> +		mem->name = dev_name(&spi->dev);
>> +
>> +	if (IS_ERR_OR_NULL(mem->name))
>> +		return PTR_ERR(mem->name);
>> +
>>   	spi_set_drvdata(spi, mem);
>>   
>>   	return memdrv->probe(mem);
>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> index 4fa34a2..c3f82d1 100644
>> --- a/include/linux/spi/spi-mem.h
>> +++ b/include/linux/spi/spi-mem.h
>> @@ -124,7 +124,8 @@ struct spi_mem_op {
>>   /**
>>    * struct spi_mem - describes a SPI memory device
>>    * @spi: the underlying SPI device
>> - * @drvpriv: spi_mem_drviver private data
>> + * @drvpriv: spi_mem_driver private data
> 
> Can you fix this typo in a separate patch?

Ok. I'll move it to a separate patch.

> 
>> + * @name: name of the SPI memory device
>>    *
>>    * Extra information that describe the SPI memory device and may be needed by
>>    * the controller to properly handle this device should be placed here.
>> @@ -135,6 +136,7 @@ struct spi_mem_op {
>>   struct spi_mem {
>>   	struct spi_device *spi;
>>   	void *drvpriv;
>> +	char *name;
>>   };
>>   
>>   /**
>> @@ -178,6 +180,7 @@ struct spi_controller_mem_ops {
>>   			    const struct spi_mem_op *op);
>>   	int (*exec_op)(struct spi_mem *mem,
>>   		       const struct spi_mem_op *op);
>> +	const char *(*get_name)(struct spi_mem *mem);
> 
> You forgot to document this hook. Also, it's important to mention that
> if the name returned by this function is dynamically allocated, it
> should be allocated with devm_xxxx(), because we don't have a
> ->free_name() function.

Indeed. I'll add the documentation.

Thanks,
Frieder

> 
>>   };
>>   
>>   /**
>> @@ -236,6 +239,8 @@ bool spi_mem_supports_op(struct spi_mem *mem,
>>   int spi_mem_exec_op(struct spi_mem *mem,
>>   		    const struct spi_mem_op *op);
>>   
>> +const char *spi_mem_get_name(struct spi_mem *mem);
>> +
>>   int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>>   				       struct module *owner);
>>   
> 
> Thanks,
> 
> Boris
> 

Re: [PATCH v2 01/12] spi: spi-mem: Extend the SPI mem interface to set a custom memory name

[Frieder Schrempf]

Hi Boris,

On 05.07.2018 14:39, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu,  5 Jul 2018 13:14:57 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> When porting (Q)SPI controller drivers from the MTD layer to the SPI
>> layer, the naming scheme for the memory devices changes. To be able
>> to keep compatibility with the old drivers naming scheme, a function
>> is added to the SPI mem interface to let controller drivers set a
>> custom name for the memory.
>>
>> Example for the FSL QSPI driver:
>>
>> Name with the old driver: 21e0000.qspi,
>> or with multiple devices: 21e0000.qspi-0, 21e0000.qspi-1, ...
>>
>> Name with the new driver without spi_mem_get_name: spi4.0
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Add a name field to struct spi_mem and fill it while probing
>>
>>   drivers/spi/spi-mem.c       | 30 ++++++++++++++++++++++++++++++
>>   include/linux/spi/spi-mem.h |  7 ++++++-
>>   2 files changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
>> index 990770d..048101c 100644
>> --- a/drivers/spi/spi-mem.c
>> +++ b/drivers/spi/spi-mem.c
>> @@ -311,6 +311,26 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
>>   EXPORT_SYMBOL_GPL(spi_mem_exec_op);
>>   
>>   /**
>> + * spi_mem_get_name() - Let drivers using the SPI mem interface specify a
>> + *			custom name for the memory to avoid compatibility
>> + *			issues with ported drivers.
> 
> You're not describing what this function does, but why it was
> introduced. Not sure the spi-mem user/driver cares about that, these are
> just internal details. Probably something you should put in the
> ->get_name() hook doc.

Ok. You're right.

> 
>> + * @mem: the SPI memory
>> + *
>> + * When porting (Q)SPI controller drivers from the MTD layer to the SPI
>> + * layer, the naming scheme for the memory devices changes. To be able to
>> + * keep compatibility with the old drivers naming scheme, this function can
>> + * be used to get a custom name from the controller driver.
>> + * If no custom name is available, the name of the SPI device is returned.
> 
> Ditto. Just say that this function returns the spi-mem device name which
> can be used by the upper layer if they need to expose a user-friendly
> name.

Ok.

> 
>> + *
>> + * Return: a char array that contains the name for the flash memory
> 
> 	      ^ a string?
> 
>       Return: a string containing the name of the memory device to be
> 	     used by the spi-mem user

Ok.

> 
>> + */
>> +const char *spi_mem_get_name(struct spi_mem *mem)
>> +{
>> +	return mem->name;
>> +}
>> +EXPORT_SYMBOL_GPL(spi_mem_get_name);
>> +
>> +/**
>>    * spi_mem_adjust_op_size() - Adjust the data size of a SPI mem operation to
>>    *			      match controller limitations
>>    * @mem: the SPI memory
>> @@ -344,6 +364,7 @@ static inline struct spi_mem_driver *to_spi_mem_drv(struct device_driver *drv)
>>   static int spi_mem_probe(struct spi_device *spi)
>>   {
>>   	struct spi_mem_driver *memdrv = to_spi_mem_drv(spi->dev.driver);
>> +	struct spi_controller *ctlr = spi->controller;
>>   	struct spi_mem *mem;
>>   
>>   	mem = devm_kzalloc(&spi->dev, sizeof(*mem), GFP_KERNEL);
>> @@ -351,6 +372,15 @@ static int spi_mem_probe(struct spi_device *spi)
>>   		return -ENOMEM;
>>   
>>   	mem->spi = spi;
>> +
>> +	if (ctlr->mem_ops && ctlr->mem_ops->get_name)
>> +		mem->name = ctlr->mem_ops->get_name(mem);
>> +	else
>> +		mem->name = dev_name(&spi->dev);
>> +
>> +	if (IS_ERR_OR_NULL(mem->name))
>> +		return PTR_ERR(mem->name);
>> +
>>   	spi_set_drvdata(spi, mem);
>>   
>>   	return memdrv->probe(mem);
>> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
>> index 4fa34a2..c3f82d1 100644
>> --- a/include/linux/spi/spi-mem.h
>> +++ b/include/linux/spi/spi-mem.h
>> @@ -124,7 +124,8 @@ struct spi_mem_op {
>>   /**
>>    * struct spi_mem - describes a SPI memory device
>>    * @spi: the underlying SPI device
>> - * @drvpriv: spi_mem_drviver private data
>> + * @drvpriv: spi_mem_driver private data
> 
> Can you fix this typo in a separate patch?

Ok. I'll move it to a separate patch.

> 
>> + * @name: name of the SPI memory device
>>    *
>>    * Extra information that describe the SPI memory device and may be needed by
>>    * the controller to properly handle this device should be placed here.
>> @@ -135,6 +136,7 @@ struct spi_mem_op {
>>   struct spi_mem {
>>   	struct spi_device *spi;
>>   	void *drvpriv;
>> +	char *name;
>>   };
>>   
>>   /**
>> @@ -178,6 +180,7 @@ struct spi_controller_mem_ops {
>>   			    const struct spi_mem_op *op);
>>   	int (*exec_op)(struct spi_mem *mem,
>>   		       const struct spi_mem_op *op);
>> +	const char *(*get_name)(struct spi_mem *mem);
> 
> You forgot to document this hook. Also, it's important to mention that
> if the name returned by this function is dynamically allocated, it
> should be allocated with devm_xxxx(), because we don't have a
> ->free_name() function.

Indeed. I'll add the documentation.

Thanks,
Frieder

> 
>>   };
>>   
>>   /**
>> @@ -236,6 +239,8 @@ bool spi_mem_supports_op(struct spi_mem *mem,
>>   int spi_mem_exec_op(struct spi_mem *mem,
>>   		    const struct spi_mem_op *op);
>>   
>> +const char *spi_mem_get_name(struct spi_mem *mem);
>> +
>>   int spi_mem_driver_register_with_owner(struct spi_mem_driver *drv,
>>   				       struct module *owner);
>>   
> 
> Thanks,
> 
> Boris
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 02/12] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name

[Frieder Schrempf]

By calling spi_mem_get_name(), the driver of the (Q)SPI controller can
set a custom name for the memory device if necessary.
This is useful to keep mtdparts compatible when controller drivers are
ported from the MTD to the SPI layer.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 drivers/mtd/devices/m25p80.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index e84563d..482f0ef 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -199,8 +199,7 @@ static int m25p_probe(struct spi_mem *spimem)
 			hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
 	}
 
-	if (data && data->name)
-		nor->mtd.name = data->name;
+	nor->mtd.name = spi_mem_get_name(spimem);
 
 	/* For some (historical?) reason many platforms provide two different
 	 * names in flash_platform_data: "name" and "type". Quite often name is
-- 
2.7.4

Re: [PATCH v2 02/12] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name

[Boris Brezillon]

On Thu,  5 Jul 2018 13:14:58 +0200
Frieder Schrempf <frieder.schrempf@exceet.de> wrote:

> By calling spi_mem_get_name(), the driver of the (Q)SPI controller can
> set a custom name for the memory device if necessary.
> This is useful to keep mtdparts compatible when controller drivers are
> ported from the MTD to the SPI layer.
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
>  drivers/mtd/devices/m25p80.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index e84563d..482f0ef 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -199,8 +199,7 @@ static int m25p_probe(struct spi_mem *spimem)
>  			hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
>  	}
>  
> -	if (data && data->name)
> -		nor->mtd.name = data->name;
> +	nor->mtd.name = spi_mem_get_name(spimem);

Hm, not sure you can do that without breaking setup that pass a
flash_platform_data object with a name.

Also, you should keep the name extracted from the label property if any
(this is done earlier, when spi_nor_set_flash_node() is called).

	if (data && data->name)
		nor->mtd.name = data->name;

	if (!nor->mtd.name)
		nor->mtd.name = spi_mem_get_name(spimem);

>  
>  	/* For some (historical?) reason many platforms provide two different
>  	 * names in flash_platform_data: "name" and "type". Quite often name is

Re: [PATCH v2 02/12] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name

[Frieder Schrempf]

Hi Boris,

On 05.07.2018 14:56, Boris Brezillon wrote:
> On Thu,  5 Jul 2018 13:14:58 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> By calling spi_mem_get_name(), the driver of the (Q)SPI controller can
>> set a custom name for the memory device if necessary.
>> This is useful to keep mtdparts compatible when controller drivers are
>> ported from the MTD to the SPI layer.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>>   drivers/mtd/devices/m25p80.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index e84563d..482f0ef 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -199,8 +199,7 @@ static int m25p_probe(struct spi_mem *spimem)
>>   			hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
>>   	}
>>   
>> -	if (data && data->name)
>> -		nor->mtd.name = data->name;
>> +	nor->mtd.name = spi_mem_get_name(spimem);
> 
> Hm, not sure you can do that without breaking setup that pass a
> flash_platform_data object with a name.
> 
> Also, you should keep the name extracted from the label property if any
> (this is done earlier, when spi_nor_set_flash_node() is called).
> 
> 	if (data && data->name)
> 		nor->mtd.name = data->name;
> 
> 	if (!nor->mtd.name)
> 		nor->mtd.name = spi_mem_get_name(spimem);

I missed both facts, that data could be passed with a name assigned 
already and that spi_nor_set_flash_node() might assign a name from dt.
I should have looked at the code more closely.

Thanks for pointing that out. I'll fix it.

Frieder

> 
>>   
>>   	/* For some (historical?) reason many platforms provide two different
>>   	 * names in flash_platform_data: "name" and "type". Quite often name is
> 

Re: [PATCH v2 02/12] mtd: m25p80: Call spi_mem_get_name() to let controller set a custom name

[Frieder Schrempf]

Hi Boris,

On 05.07.2018 14:56, Boris Brezillon wrote:
> On Thu,  5 Jul 2018 13:14:58 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> By calling spi_mem_get_name(), the driver of the (Q)SPI controller can
>> set a custom name for the memory device if necessary.
>> This is useful to keep mtdparts compatible when controller drivers are
>> ported from the MTD to the SPI layer.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>>   drivers/mtd/devices/m25p80.c | 3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index e84563d..482f0ef 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -199,8 +199,7 @@ static int m25p_probe(struct spi_mem *spimem)
>>   			hwcaps.mask |= SNOR_HWCAPS_READ_1_2_2;
>>   	}
>>   
>> -	if (data && data->name)
>> -		nor->mtd.name = data->name;
>> +	nor->mtd.name = spi_mem_get_name(spimem);
> 
> Hm, not sure you can do that without breaking setup that pass a
> flash_platform_data object with a name.
> 
> Also, you should keep the name extracted from the label property if any
> (this is done earlier, when spi_nor_set_flash_node() is called).
> 
> 	if (data && data->name)
> 		nor->mtd.name = data->name;
> 
> 	if (!nor->mtd.name)
> 		nor->mtd.name = spi_mem_get_name(spimem);

I missed both facts, that data could be passed with a name assigned 
already and that spi_nor_set_flash_node() might assign a name from dt.
I should have looked at the code more closely.

Thanks for pointing that out. I'll fix it.

Frieder

> 
>>   
>>   	/* For some (historical?) reason many platforms provide two different
>>   	 * names in flash_platform_data: "name" and "type". Quite often name is
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 03/12] spi: Add a driver for the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

This driver is derived from the SPI NOR driver at
mtd/spi-nor/fsl-quadspi.c. It uses the 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).

The controller does not support generic SPI messages.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
Changes in v2:
==============
* Add Yogesh Gaur and Suresh Gupta as authors
* Use GENMASK() for generating bitmasks
* Use callback functions for read/write of registers
* Attach the seq variable to the selected CS
* Avoid using conditional in read/write loop
* Avoid infinite loop and use a timeout instead
* Return error pointer when allocation in fsl_qspi_get_name() fails
* Remove redundant iounmap()
* Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver

 drivers/spi/Kconfig        |  11 +
 drivers/spi/Makefile       |   1 +
 drivers/spi/spi-fsl-qspi.c | 954 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 966 insertions(+)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index ad5d68e..5e95ffc 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -251,6 +251,17 @@ config SPI_FSL_LPSPI
 	help
 	  This enables Freescale i.MX LPSPI controllers in master mode.
 
+config SPI_FSL_QSPI
+	tristate "Freescale QSPI controller"
+	depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
+	depends on HAS_IOMEM
+	help
+	  This enables support for the Quad SPI controller in master mode.
+	  Up to four flash chips can be connected on two buses with two
+	  chipselects each.
+	  This controller does not support generic SPI messages. It 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..a8f7fda 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -43,6 +43,7 @@ obj-$(CONFIG_SPI_FSL_DSPI)		+= spi-fsl-dspi.o
 obj-$(CONFIG_SPI_FSL_LIB)		+= spi-fsl-lib.o
 obj-$(CONFIG_SPI_FSL_ESPI)		+= spi-fsl-espi.o
 obj-$(CONFIG_SPI_FSL_LPSPI)		+= spi-fsl-lpspi.o
+obj-$(CONFIG_SPI_FSL_QSPI)		+= spi-fsl-qspi.o
 obj-$(CONFIG_SPI_FSL_SPI)		+= spi-fsl-spi.o
 obj-$(CONFIG_SPI_GPIO)			+= spi-gpio.o
 obj-$(CONFIG_SPI_IMG_SPFI)		+= spi-img-spfi.o
diff --git a/drivers/spi/spi-fsl-qspi.c b/drivers/spi/spi-fsl-qspi.c
new file mode 100644
index 0000000..3e17209
--- /dev/null
+++ b/drivers/spi/spi-fsl-qspi.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * Freescale QuadSPI driver.
+ *
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ * Copyright (C) 2018 Bootlin
+ * Copyright (C) 2018 Exceet Electronics GmbH
+ *
+ * Transition to SPI MEM interface:
+ * Author:
+ *     Boris Brezillion <boris.brezillon@bootlin.com>
+ *     Frieder Schrempf <frieder.schrempf@exceet.de>
+ *     Yogesh Gaur <yogeshnarayan.gaur@nxp.com>
+ *     Suresh Gupta <suresh.gupta@nxp.com>
+ *
+ * Based on the original fsl-quadspi.c spi-nor driver:
+ * Author: Freescale Semiconductor, Inc.
+ *
+ */
+
+#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 (15).
+ */
+#define	SEQID_LUT			15
+
+/* Registers used by the driver */
+#define QUADSPI_MCR			0x00
+#define QUADSPI_MCR_RESERVED_MASK	GENMASK(19, 16)
+#define QUADSPI_MCR_MDIS_MASK		BIT(14)
+#define QUADSPI_MCR_CLR_TXF_MASK	BIT(11)
+#define QUADSPI_MCR_CLR_RXF_MASK	BIT(10)
+#define QUADSPI_MCR_DDR_EN_MASK		BIT(7)
+#define QUADSPI_MCR_END_CFG_MASK	GENMASK(3, 2)
+#define QUADSPI_MCR_SWRSTHD_MASK	BIT(1)
+#define QUADSPI_MCR_SWRSTSD_MASK	BIT(0)
+
+#define QUADSPI_IPCR			0x08
+#define QUADSPI_IPCR_SEQID_SHIFT	24
+
+#define QUADSPI_BUF3CR			0x1c
+#define QUADSPI_BUF3CR_ALLMST_MASK	BIT(31)
+#define QUADSPI_BUF3CR_ADATSZ_SHIFT	8
+#define QUADSPI_BUF3CR_ADATSZ_MASK	(0xFF << QUADSPI_BUF3CR_ADATSZ_SHIFT)
+
+#define QUADSPI_BFGENCR			0x20
+#define QUADSPI_BFGENCR_SEQID_SHIFT	12
+
+#define QUADSPI_BUF0IND			0x30
+#define QUADSPI_BUF1IND			0x34
+#define QUADSPI_BUF2IND			0x38
+#define QUADSPI_SFAR			0x100
+
+#define QUADSPI_SMPR			0x108
+#define QUADSPI_SMPR_DDRSMP_MASK	GENMASK(18, 16)
+#define QUADSPI_SMPR_FSDLY_MASK		BIT(6)
+#define QUADSPI_SMPR_FSPHS_MASK		BIT(5)
+#define QUADSPI_SMPR_HSENA_MASK		BIT(0)
+
+#define QUADSPI_RBCT			0x110
+#define QUADSPI_RBCT_WMRK_MASK		GENMASK(4, 0)
+#define QUADSPI_RBCT_RXBRD_USEIPS	BIT(8)
+
+#define QUADSPI_TBDR			0x154
+
+#define QUADSPI_SR			0x15c
+#define QUADSPI_SR_IP_ACC_MASK		BIT(1)
+#define QUADSPI_SR_AHB_ACC_MASK		BIT(2)
+
+#define QUADSPI_FR			0x160
+#define QUADSPI_FR_TFF_MASK		BIT(0)
+
+#define QUADSPI_SPTRCLR			0x16c
+#define QUADSPI_SPTRCLR_IPPTRC		BIT(8)
+#define QUADSPI_SPTRCLR_BFPTRC		BIT(0)
+
+#define QUADSPI_SFA1AD			0x180
+#define QUADSPI_SFA2AD			0x184
+#define QUADSPI_SFB1AD			0x188
+#define QUADSPI_SFB2AD			0x18c
+#define QUADSPI_RBDR(x)			(0x200 + ((x) * 4))
+
+#define QUADSPI_LUTKEY			0x300
+#define QUADSPI_LUTKEY_VALUE		0x5AF05AF0
+
+#define QUADSPI_LCKCR			0x304
+#define QUADSPI_LCKER_LOCK		BIT(0)
+#define QUADSPI_LCKER_UNLOCK		BIT(1)
+
+#define QUADSPI_RSER			0x164
+#define QUADSPI_RSER_TFIE		BIT(0)
+
+#define QUADSPI_LUT_BASE		0x310
+#define QUADSPI_LUT_OFFSET		(SEQID_LUT * 4 * 4)
+#define QUADSPI_LUT_REG(idx) \
+	(QUADSPI_LUT_BASE + QUADSPI_LUT_OFFSET + (idx) * 4)
+
+/* Instruction set for the LUT register */
+#define LUT_STOP		0
+#define LUT_CMD			1
+#define LUT_ADDR		2
+#define LUT_DUMMY		3
+#define LUT_MODE		4
+#define LUT_MODE2		5
+#define LUT_MODE4		6
+#define LUT_FSL_READ		7
+#define LUT_FSL_WRITE		8
+#define LUT_JMP_ON_CS		9
+#define LUT_ADDR_DDR		10
+#define LUT_MODE_DDR		11
+#define LUT_MODE2_DDR		12
+#define LUT_MODE4_DDR		13
+#define LUT_FSL_READ_DDR	14
+#define LUT_FSL_WRITE_DDR	15
+#define LUT_DATA_LEARN		16
+
+/*
+ * The PAD definitions for LUT register.
+ *
+ * The pad stands for the number of IO lines [0:3].
+ * For example, the quad read needs four IO lines,
+ * so you should use LUT_PAD(4).
+ */
+#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 LUT_DEF(idx, ins, pad, opr)					\
+	((((ins) << 10) | ((pad) << 8) | (opr)) << (((idx) % 2) * 16))
+
+/* Controller needs driver to swap endianness */
+#define QUADSPI_QUIRK_SWAP_ENDIAN	BIT(0)
+
+/* Controller needs 4x internal clock */
+#define QUADSPI_QUIRK_4X_INT_CLK	BIT(1)
+
+/*
+ * TKT253890, the controller needs the driver to fill the txfifo with
+ * 16 bytes at least to trigger a data transfer, even though the extra
+ * data won't be transferred.
+ */
+#define QUADSPI_QUIRK_TKT253890		BIT(2)
+
+/* TKT245618, the controller cannot wake up from wait mode */
+#define QUADSPI_QUIRK_TKT245618		BIT(3)
+
+enum fsl_qspi_devtype {
+	FSL_QUADSPI_VYBRID,
+	FSL_QUADSPI_IMX6SX,
+	FSL_QUADSPI_IMX7D,
+	FSL_QUADSPI_IMX6UL,
+	FSL_QUADSPI_LS1021A,
+	FSL_QUADSPI_LS2080A,
+};
+
+struct fsl_qspi_devtype_data {
+	enum fsl_qspi_devtype devtype;
+	unsigned int rxfifo;
+	unsigned int txfifo;
+	unsigned int ahb_buf_size;
+	unsigned int quirks;
+};
+
+static const struct fsl_qspi_devtype_data vybrid_data = {
+	.devtype = FSL_QUADSPI_VYBRID,
+	.rxfifo = SZ_128,
+	.txfifo = SZ_64,
+	.ahb_buf_size = SZ_1K,
+	.quirks = QUADSPI_QUIRK_SWAP_ENDIAN,
+};
+
+static const struct fsl_qspi_devtype_data imx6sx_data = {
+	.devtype = FSL_QUADSPI_IMX6SX,
+	.rxfifo = SZ_128,
+	.txfifo = SZ_512,
+	.ahb_buf_size = SZ_1K,
+	.quirks = QUADSPI_QUIRK_4X_INT_CLK | QUADSPI_QUIRK_TKT245618,
+};
+
+static const struct fsl_qspi_devtype_data imx7d_data = {
+	.devtype = FSL_QUADSPI_IMX7D,
+	.rxfifo = SZ_512,
+	.txfifo = SZ_512,
+	.ahb_buf_size = SZ_1K,
+	.quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK,
+};
+
+static const struct fsl_qspi_devtype_data imx6ul_data = {
+	.devtype = FSL_QUADSPI_IMX6UL,
+	.rxfifo = SZ_128,
+	.txfifo = SZ_512,
+	.ahb_buf_size = SZ_1K,
+	.quirks = QUADSPI_QUIRK_TKT253890 | QUADSPI_QUIRK_4X_INT_CLK,
+};
+
+static const struct fsl_qspi_devtype_data ls1021a_data = {
+	.devtype = FSL_QUADSPI_LS1021A,
+	.rxfifo = SZ_128,
+	.txfifo = SZ_64,
+	.ahb_buf_size = SZ_1K,
+	.quirks = 0,
+};
+
+static const struct fsl_qspi_devtype_data ls2080a_data = {
+	.devtype = FSL_QUADSPI_LS2080A,
+	.rxfifo = SZ_128,
+	.txfifo = SZ_64,
+	.ahb_buf_size = SZ_1K,
+	.quirks = QUADSPI_QUIRK_TKT253890,
+};
+
+struct fsl_qspi {
+	void __iomem *iobase;
+	void __iomem *ahb_addr;
+	u32 memmap_phy;
+	struct clk *clk, *clk_en;
+	struct device *dev;
+	struct completion c;
+	const struct fsl_qspi_devtype_data *devtype_data;
+	bool big_endian;
+	struct mutex lock;
+	struct pm_qos_request pm_qos_req;
+	int selected;
+	u8 seq;
+	void (*write)(u32 val, void __iomem *addr);
+	u32 (*read)(void __iomem *addr);
+};
+
+static inline int needs_swap_endian(struct fsl_qspi *q)
+{
+	return q->devtype_data->quirks & QUADSPI_QUIRK_SWAP_ENDIAN;
+}
+
+static inline int needs_4x_clock(struct fsl_qspi *q)
+{
+	return q->devtype_data->quirks & QUADSPI_QUIRK_4X_INT_CLK;
+}
+
+static inline int needs_fill_txfifo(struct fsl_qspi *q)
+{
+	return q->devtype_data->quirks & QUADSPI_QUIRK_TKT253890;
+}
+
+static inline int needs_wakeup_wait_mode(struct fsl_qspi *q)
+{
+	return q->devtype_data->quirks & QUADSPI_QUIRK_TKT245618;
+}
+
+/*
+ * An IC bug makes it necessary to rearrange the 32-bit data.
+ * Later chips, such as IMX6SLX, have fixed this bug.
+ */
+static inline u32 fsl_qspi_endian_xchg(struct fsl_qspi *q, u32 a)
+{
+	return needs_swap_endian(q) ? __swab32(a) : a;
+}
+
+static void qspi_writel_be(u32 val, void __iomem *addr)
+{
+	iowrite32be(val, addr);
+}
+
+static void qspi_writel(u32 val, void __iomem *addr)
+{
+	iowrite32(val, addr);
+}
+
+static u32 qspi_readl_be(void __iomem *addr)
+{
+	return ioread32be(addr);
+}
+
+static u32 qspi_readl(void __iomem *addr)
+{
+	return ioread32(addr);
+}
+
+static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
+{
+	struct fsl_qspi *q = dev_id;
+	u32 reg;
+
+	/* clear interrupt */
+	reg = q->read(q->iobase + QUADSPI_FR);
+	q->write(reg, q->iobase + QUADSPI_FR);
+
+	if (reg & QUADSPI_FR_TFF_MASK)
+		complete(&q->c);
+
+	dev_dbg(q->dev, "QUADSPI_FR : 0x%.8x:0x%.8x\n", 0, reg);
+	return IRQ_HANDLED;
+}
+
+static int fsl_qspi_check_buswidth(struct fsl_qspi *q, u8 width)
+{
+	switch (width) {
+	case 1:
+	case 2:
+	case 4:
+		return 0;
+	}
+
+	return -ENOTSUPP;
+}
+
+static bool fsl_qspi_supports_op(struct spi_mem *mem,
+				 const struct spi_mem_op *op)
+{
+	struct fsl_qspi *q = spi_controller_get_devdata(mem->spi->master);
+	int ret;
+
+	ret = fsl_qspi_check_buswidth(q, op->cmd.buswidth);
+
+	if (op->addr.nbytes)
+		ret |= fsl_qspi_check_buswidth(q, op->addr.buswidth);
+
+	if (op->dummy.nbytes)
+		ret |= fsl_qspi_check_buswidth(q, op->dummy.buswidth);
+
+	if (op->data.nbytes)
+		ret |= fsl_qspi_check_buswidth(q, 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 > q->devtype_data->ahb_buf_size ||
+	     (op->data.nbytes > q->devtype_data->rxfifo - 4 &&
+	      !IS_ALIGNED(op->data.nbytes, 8))))
+		return false;
+
+	if (op->data.dir == SPI_MEM_DATA_OUT &&
+	    op->data.nbytes > q->devtype_data->txfifo)
+		return false;
+
+	return true;
+}
+
+static void fsl_qspi_prepare_lut(struct fsl_qspi *q,
+				 const struct spi_mem_op *op)
+{
+	void __iomem *base = q->iobase;
+	u32 lutval[4] = {};
+	int lutidx = 1, i;
+
+	lutval[0] |= LUT_DEF(0, LUT_CMD, LUT_PAD(op->cmd.buswidth),
+			     op->cmd.opcode);
+
+	/*
+	 * For some unknown reason, using LUT_ADDR doesn't work in some
+	 * cases (at least with only one byte long addresses), so
+	 * let's use LUT_MODE to write the address bytes one by one
+	 */
+	for (i = 0; i < op->addr.nbytes; i++) {
+		u8 addrbyte = op->addr.val >> (8 * (op->addr.nbytes - i - 1));
+
+		lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_MODE,
+					      LUT_PAD(op->addr.buswidth),
+					      addrbyte);
+		lutidx++;
+	}
+
+	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++;
+	}
+
+	if (op->data.nbytes) {
+		lutval[lutidx / 2] |= LUT_DEF(lutidx,
+					      op->data.dir == SPI_MEM_DATA_IN ?
+					      LUT_FSL_READ : LUT_FSL_WRITE,
+					      LUT_PAD(op->data.buswidth),
+					      0);
+		lutidx++;
+	}
+
+	lutval[lutidx / 2] |= LUT_DEF(lutidx, LUT_STOP, 0, 0);
+
+	/* unlock LUT */
+	q->write(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+	q->write(QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
+
+	/* fill LUT */
+	for (i = 0; i < ARRAY_SIZE(lutval); i++)
+		q->write(lutval[i], base + QUADSPI_LUT_REG(i));
+
+	/* lock LUT */
+	q->write(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+	q->write(QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
+}
+
+static int fsl_qspi_clk_prep_enable(struct fsl_qspi *q)
+{
+	int ret;
+
+	ret = clk_prepare_enable(q->clk_en);
+	if (ret)
+		return ret;
+
+	ret = clk_prepare_enable(q->clk);
+	if (ret) {
+		clk_disable_unprepare(q->clk_en);
+		return ret;
+	}
+
+	if (needs_wakeup_wait_mode(q))
+		pm_qos_add_request(&q->pm_qos_req, PM_QOS_CPU_DMA_LATENCY, 0);
+
+	return 0;
+}
+
+static void fsl_qspi_clk_disable_unprep(struct fsl_qspi *q)
+{
+	if (needs_wakeup_wait_mode(q))
+		pm_qos_remove_request(&q->pm_qos_req);
+
+	clk_disable_unprepare(q->clk);
+	clk_disable_unprepare(q->clk_en);
+}
+
+static void fsl_qspi_select_mem(struct fsl_qspi *q, struct spi_device *spi)
+{
+	unsigned long rate = spi->max_speed_hz;
+	int ret, i;
+	u32 map_addr;
+
+	if (q->selected == spi->chip_select)
+		return;
+
+	/*
+	 * In HW there can be a maximum of four chips on two buses with
+	 * two chip selects on each bus. We use four chip selects in SW
+	 * to differentiate between the four chips.
+	 * We use the SFA1AD, SFA2AD, SFB1AD, SFB2AD registers to select
+	 * the chip we want to access.
+	 */
+	for (i = 0; i < 4; i++) {
+		if (i < spi->chip_select)
+			map_addr = q->memmap_phy;
+		else
+			map_addr = q->memmap_phy +
+				   2 * q->devtype_data->ahb_buf_size;
+
+		q->write(map_addr, q->iobase + QUADSPI_SFA1AD + (i * 4));
+	}
+
+	if (needs_4x_clock(q))
+		rate *= 4;
+
+	fsl_qspi_clk_disable_unprep(q);
+
+	ret = clk_set_rate(q->clk, rate);
+	if (ret)
+		return;
+
+	ret = fsl_qspi_clk_prep_enable(q);
+	if (ret)
+		return;
+
+	q->selected = spi->chip_select;
+}
+
+static void fsl_qspi_read_ahb(struct fsl_qspi *q, const struct spi_mem_op *op)
+{
+	/*
+	 * We want to avoid needing to invalidate the cache by issueing
+	 * a reset to the AHB and Serial Flash domain, as this needs
+	 * time. So we change the address on each read to trigger an
+	 * actual read operation on the flash. The actual address for
+	 * the flash memory is set by programming the LUT.
+	 */
+	memcpy_fromio(op->data.buf.in,
+		      q->ahb_addr +
+		      (((q->seq & (1 << q->selected)) == 0 ? 0:1) *
+		       q->devtype_data->ahb_buf_size),
+		      op->data.nbytes);
+
+	q->seq ^= 1 << q->selected;
+}
+
+static void fsl_qspi_fill_txfifo(struct fsl_qspi *q,
+				 const struct spi_mem_op *op)
+{
+	void __iomem *base = q->iobase;
+	int i;
+	u32 val;
+
+	for (i = 0; i < ALIGN_DOWN(op->data.nbytes, 4); i += 4) {
+		memcpy(&val, op->data.buf.out + i, 4);
+		val = fsl_qspi_endian_xchg(q, val);
+		q->write(val, base + QUADSPI_TBDR);
+	}
+
+	if (i < op->data.nbytes) {
+		memcpy(&val, op->data.buf.out + i, op->data.nbytes - i);
+		val = fsl_qspi_endian_xchg(q, val);
+		q->write(val, base + QUADSPI_TBDR);
+	}
+
+	if (needs_fill_txfifo(q)) {
+		for (i = op->data.nbytes; i < 16; i += 4)
+			q->write(0, base + QUADSPI_TBDR);
+	}
+}
+
+static void fsl_qspi_read_rxfifo(struct fsl_qspi *q,
+			  const struct spi_mem_op *op)
+{
+	void __iomem *base = q->iobase;
+	int i;
+	u8 *buf = op->data.buf.in;
+	u32 val;
+
+	for (i = 0; i < ALIGN_DOWN(op->data.nbytes, 4); i += 4) {
+		val = q->read(base + QUADSPI_RBDR(i / 4));
+		val = fsl_qspi_endian_xchg(q, val);
+		memcpy(buf + i, &val, 4);
+	}
+
+	if (i < op->data.nbytes) {
+		val = q->read(base + QUADSPI_RBDR(i / 4));
+		val = fsl_qspi_endian_xchg(q, val);
+		memcpy(buf + i, &val, op->data.nbytes - i);
+	}
+}
+
+static int fsl_qspi_do_op(struct fsl_qspi *q, const struct spi_mem_op *op)
+{
+	void __iomem *base = q->iobase;
+	int err = 0;
+
+	init_completion(&q->c);
+
+	/*
+	 * 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.
+	 */
+	q->write(op->data.nbytes |
+		    (SEQID_LUT << QUADSPI_IPCR_SEQID_SHIFT),
+		    base + QUADSPI_IPCR);
+
+	/* Wait for the interrupt. */
+	if (!wait_for_completion_timeout(&q->c, msecs_to_jiffies(1000)))
+		err = -ETIMEDOUT;
+
+	if (!err && op->data.nbytes && op->data.dir == SPI_MEM_DATA_IN)
+		fsl_qspi_read_rxfifo(q, op);
+
+	return err;
+}
+
+static int fsl_qspi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
+{
+	struct fsl_qspi *q = spi_controller_get_devdata(mem->spi->master);
+	void __iomem *base = q->iobase;
+	int err = 0;
+	unsigned int timeout = 1000;
+
+	mutex_lock(&q->lock);
+
+	/* wait for the controller being ready */
+	do {
+		u32 status;
+
+		status = q->read(base + QUADSPI_SR);
+		if (status &
+		    (QUADSPI_SR_IP_ACC_MASK | QUADSPI_SR_AHB_ACC_MASK)) {
+			udelay(1);
+			dev_dbg(q->dev, "The controller is busy, 0x%x\n",
+				status);
+			continue;
+		}
+		break;
+	} while (--timeout);
+
+	fsl_qspi_select_mem(q, mem->spi);
+
+	q->write(q->memmap_phy, base + QUADSPI_SFAR);
+
+	q->write(q->read(base + QUADSPI_MCR) |
+		 QUADSPI_MCR_CLR_RXF_MASK | QUADSPI_MCR_CLR_TXF_MASK,
+		 base + QUADSPI_MCR);
+
+	q->write(QUADSPI_SPTRCLR_BFPTRC | QUADSPI_SPTRCLR_IPPTRC,
+		    base + QUADSPI_SPTRCLR);
+
+	fsl_qspi_prepare_lut(q, 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 > (q->devtype_data->rxfifo - 4) &&
+	    op->data.dir == SPI_MEM_DATA_IN) {
+		fsl_qspi_read_ahb(q, op);
+	} else {
+		q->write(QUADSPI_RBCT_WMRK_MASK | QUADSPI_RBCT_RXBRD_USEIPS,
+			 base + QUADSPI_RBCT);
+
+		if (op->data.nbytes && op->data.dir == SPI_MEM_DATA_OUT)
+			fsl_qspi_fill_txfifo(q, op);
+
+		err = fsl_qspi_do_op(q, op);
+	}
+
+	mutex_unlock(&q->lock);
+
+	return err;
+}
+
+static int fsl_qspi_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
+{
+	struct fsl_qspi *q = spi_controller_get_devdata(mem->spi->master);
+
+	if (op->data.dir == SPI_MEM_DATA_OUT) {
+		if (op->data.nbytes > q->devtype_data->txfifo)
+			op->data.nbytes = q->devtype_data->txfifo;
+	} else {
+		if (op->data.nbytes > q->devtype_data->ahb_buf_size)
+			op->data.nbytes = q->devtype_data->ahb_buf_size;
+		else if (op->data.nbytes > (q->devtype_data->rxfifo - 4))
+			op->data.nbytes = ALIGN_DOWN(op->data.nbytes, 8);
+	}
+
+	return 0;
+}
+
+static int fsl_qspi_default_setup(struct fsl_qspi *q)
+{
+	void __iomem *base = q->iobase;
+	u32 reg;
+	int ret;
+
+	/* disable and unprepare clock to avoid glitch pass to controller */
+	fsl_qspi_clk_disable_unprep(q);
+
+	/* the default frequency, we will change it later if necessary. */
+	ret = clk_set_rate(q->clk, 66000000);
+	if (ret)
+		return ret;
+
+	ret = fsl_qspi_clk_prep_enable(q);
+	if (ret)
+		return ret;
+
+	/* Reset the module */
+	q->write(QUADSPI_MCR_SWRSTSD_MASK | QUADSPI_MCR_SWRSTHD_MASK,
+		 base + QUADSPI_MCR);
+	udelay(1);
+
+	/* Disable the module */
+	q->write(QUADSPI_MCR_MDIS_MASK | QUADSPI_MCR_RESERVED_MASK,
+		 base + QUADSPI_MCR);
+
+	reg = q->read(base + QUADSPI_SMPR);
+	q->write(reg & ~(QUADSPI_SMPR_FSDLY_MASK
+			| QUADSPI_SMPR_FSPHS_MASK
+			| QUADSPI_SMPR_HSENA_MASK
+			| QUADSPI_SMPR_DDRSMP_MASK), base + QUADSPI_SMPR);
+
+	/* We only use the buffer3 for AHB read */
+	q->write(0, base + QUADSPI_BUF0IND);
+	q->write(0, base + QUADSPI_BUF1IND);
+	q->write(0, base + QUADSPI_BUF2IND);
+
+	q->write(SEQID_LUT << QUADSPI_BFGENCR_SEQID_SHIFT,
+		 q->iobase + QUADSPI_BFGENCR);
+	q->write(QUADSPI_RBCT_WMRK_MASK, base + QUADSPI_RBCT);
+	q->write(QUADSPI_BUF3CR_ALLMST_MASK |
+		 ((q->devtype_data->ahb_buf_size / 8) <<
+		  QUADSPI_BUF3CR_ADATSZ_SHIFT),
+		 base + QUADSPI_BUF3CR);
+
+	q->selected = -1;
+	q->seq = 0;
+
+	/* Enable the module */
+	q->write(QUADSPI_MCR_RESERVED_MASK | QUADSPI_MCR_END_CFG_MASK,
+		 base + QUADSPI_MCR);
+
+	/* clear all interrupt status */
+	q->write(0xffffffff, q->iobase + QUADSPI_FR);
+
+	/* enable the interrupt */
+	q->write(QUADSPI_RSER_TFIE, q->iobase + QUADSPI_RSER);
+
+	return 0;
+}
+
+static const char *fsl_qspi_get_name(struct spi_mem *mem)
+{
+	struct fsl_qspi *q = spi_controller_get_devdata(mem->spi->master);
+	struct device *dev = &mem->spi->dev;
+	const char *name;
+
+	/*
+	 * In order to keep mtdparts compatible with the old MTD driver at
+	 * mtd/spi-nor/fsl-quadspi.c, we set a custom name derived from the
+	 * platform_device of the controller.
+	 */
+	if (of_get_available_child_count(q->dev->of_node) == 1)
+		return dev_name(q->dev);
+
+	name = devm_kasprintf(dev, GFP_KERNEL,
+			      "%s-%d", dev_name(q->dev),
+			      mem->spi->chip_select);
+
+	if (!name) {
+		dev_err(dev, "failed to get memory for custom flash name\n");
+		return ERR_PTR(-ENOMEM);
+	}
+
+	return name;
+}
+
+static const struct spi_controller_mem_ops fsl_qspi_mem_ops = {
+	.adjust_op_size = fsl_qspi_adjust_op_size,
+	.supports_op = fsl_qspi_supports_op,
+	.exec_op = fsl_qspi_exec_op,
+	.get_name = fsl_qspi_get_name,
+};
+
+static int fsl_qspi_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 fsl_qspi *q;
+	int ret;
+
+	ctlr = spi_alloc_master(&pdev->dev, sizeof(*q));
+	if (!ctlr)
+		return -ENOMEM;
+
+	ctlr->mode_bits = SPI_RX_DUAL | SPI_RX_QUAD |
+			  SPI_TX_DUAL | SPI_TX_QUAD;
+
+	q = spi_controller_get_devdata(ctlr);
+	q->dev = dev;
+	q->devtype_data = of_device_get_match_data(dev);
+	if (!q->devtype_data) {
+		ret = -ENODEV;
+		goto err_put_ctrl;
+	}
+
+	platform_set_drvdata(pdev, q);
+
+	/* find the resources */
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "QuadSPI");
+	q->iobase = devm_ioremap_resource(dev, res);
+	if (IS_ERR(q->iobase)) {
+		ret = PTR_ERR(q->iobase);
+		goto err_put_ctrl;
+	}
+
+	/*
+	 * R/W functions for big- or little-endian registers:
+	 * The QSPI controller's endianness is independent of
+	 * the CPU core's endianness. So far, although the CPU
+	 * core is little-endian the QSPI controller can use
+	 * big-endian or little-endian.
+	 */
+	if (of_property_read_bool(np, "big-endian")) {
+		q->write = qspi_writel_be;
+		q->read = qspi_readl_be;
+	} else {
+		q->write = qspi_writel;
+		q->read = qspi_readl;
+	}
+
+	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+					"QuadSPI-memory");
+	q->ahb_addr = devm_ioremap_resource(dev, res);
+	if (IS_ERR(q->ahb_addr)) {
+		ret = PTR_ERR(q->ahb_addr);
+		goto err_put_ctrl;
+	}
+
+	q->memmap_phy = res->start;
+
+	/* find the clocks */
+	q->clk_en = devm_clk_get(dev, "qspi_en");
+	if (IS_ERR(q->clk_en)) {
+		ret = PTR_ERR(q->clk_en);
+		goto err_put_ctrl;
+	}
+
+	q->clk = devm_clk_get(dev, "qspi");
+	if (IS_ERR(q->clk)) {
+		ret = PTR_ERR(q->clk);
+		goto err_put_ctrl;
+	}
+
+	ret = fsl_qspi_clk_prep_enable(q);
+	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,
+			fsl_qspi_irq_handler, 0, pdev->name, q);
+	if (ret) {
+		dev_err(dev, "failed to request irq: %d\n", ret);
+		goto err_disable_clk;
+	}
+
+	mutex_init(&q->lock);
+
+	ctlr->bus_num = -1;
+	ctlr->num_chipselect = 4;
+	ctlr->mem_ops = &fsl_qspi_mem_ops;
+
+	fsl_qspi_default_setup(q);
+
+	ctlr->dev.of_node = np;
+
+	ret = spi_register_controller(ctlr);
+	if (ret)
+		goto err_destroy_mutex;
+
+	return 0;
+
+err_destroy_mutex:
+	mutex_destroy(&q->lock);
+
+err_disable_clk:
+	fsl_qspi_clk_disable_unprep(q);
+
+err_put_ctrl:
+	spi_controller_put(ctlr);
+
+	dev_err(dev, "Freescale QuadSPI probe failed\n");
+	return ret;
+}
+
+static int fsl_qspi_remove(struct platform_device *pdev)
+{
+	struct fsl_qspi *q = platform_get_drvdata(pdev);
+
+	/* disable the hardware */
+	q->write(QUADSPI_MCR_MDIS_MASK, q->iobase + QUADSPI_MCR);
+	q->write(0x0, q->iobase + QUADSPI_RSER);
+
+	fsl_qspi_clk_disable_unprep(q);
+
+	mutex_destroy(&q->lock);
+
+	return 0;
+}
+
+static int fsl_qspi_suspend(struct device *dev)
+{
+	return 0;
+}
+
+static int fsl_qspi_resume(struct device *dev)
+{
+	struct fsl_qspi *q = dev_get_drvdata(dev);
+
+	fsl_qspi_default_setup(q);
+
+	return 0;
+}
+
+static const struct of_device_id fsl_qspi_dt_ids[] = {
+	{ .compatible = "fsl,vf610-qspi", .data = &vybrid_data, },
+	{ .compatible = "fsl,imx6sx-qspi", .data = &imx6sx_data, },
+	{ .compatible = "fsl,imx7d-qspi", .data = &imx7d_data, },
+	{ .compatible = "fsl,imx6ul-qspi", .data = &imx6ul_data, },
+	{ .compatible = "fsl,ls1021a-qspi", .data = &ls1021a_data, },
+	{ .compatible = "fsl,ls2080a-qspi", .data = &ls2080a_data, },
+	{ /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
+
+static const struct dev_pm_ops fsl_qspi_pm_ops = {
+	.suspend	= fsl_qspi_suspend,
+	.resume		= fsl_qspi_resume,
+};
+
+static struct platform_driver fsl_qspi_driver = {
+	.driver = {
+		.name	= "fsl-quadspi",
+		.of_match_table = fsl_qspi_dt_ids,
+		.pm =   &fsl_qspi_pm_ops,
+	},
+	.probe          = fsl_qspi_probe,
+	.remove		= fsl_qspi_remove,
+};
+module_platform_driver(fsl_qspi_driver);
+
+MODULE_DESCRIPTION("Freescale QuadSPI Controller Driver");
+MODULE_AUTHOR("Freescale Semiconductor Inc.");
+MODULE_AUTHOR("Boris Brezillion <boris.brezillon@bootlin.com>");
+MODULE_AUTHOR("Frieder Schrempf <frieder.schrempf@exceet.de>");
+MODULE_AUTHOR("Yogesh Gaur <yogeshnarayan.gaur@nxp.com>");
+MODULE_AUTHOR("Suresh Gupta <suresh.gupta@nxp.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Ping.

I'm not sure if my message below went out to you at all. At least I 
can't find it in the ML archive.

I still hope someone can help with the questions below.

Meanwhile for the second point I did some tests myself with one chip on 
each of the two buses and it worked fine with my latest v2 patches.
So I'm not sure at all why Yogesh has problems with his setup (two chips 
on the first bus).

Thanks,
Frieder

On 11.07.2018 14:13, Frieder Schrempf wrote:
> Hi guys from NXP,
> 
> we still have some issues/questions concerning the FSL QSPI IP, that 
> somehow block the new driver under the SPI memory framework [1].
> 
> If anyone of you could comment on these, or help finding solutions, this 
> would be very much appreciated.
> 
> 1. The SPI NOR driver was using a reset of the flash and AHB domain to 
> invalidate the AHB buffer [2]. But this needs quite a lot of time, so we 
> have a hack to use two regions in memory and switch between them 
> alternately to invalidate the cache [3]. As this is not so nice, do you 
> know of any other possibility to invalidate the flash?
> 
> 2. We tried to reuse the mapped memory to access different chips on 
> different CS, by switching the QUADSPI_SFA1AD, QUADSPI_SFA2AD, etc. 
> accordingly [4]. This doesn't work as expected, but Yogesh found out, 
> that it works with a fixed memory map for each CS and by adding a 
> ioremap(), as the SPI NOR driver does [5]. Can someone explain this 
> behavior and why the ioremap is needed?
> 
> 3. In case of a NOR page program operation, the driver is expected to 
> write the full page, even if it's larger than the TX buffer size. Boris 
> explained this here: [6].
> So we need to find a way of triggering a refill of the TX buffer by CPU 
> or DMA if possible.
> 
> Thank you in advance for your help,
> 
> Frieder
> 
> [1] https://patchwork.ozlabs.org/cover/939864/
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4#n591 
> 
> [3] 
> https://github.com/fschrempf/linux/blob/fsl-qspi-next-2/drivers/spi/spi-fsl-qspi.c#L511 
> 
> [4] 
> https://github.com/fschrempf/linux/blob/fsl-qspi-next-2/drivers/spi/spi-fsl-qspi.c#L476 
> 
> [5] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4#n906 
> 
> [6] https://patchwork.ozlabs.org/patch/928677/#1950278

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Ping.

I'm not sure if my message below went out to you at all. At least I 
can't find it in the ML archive.

I still hope someone can help with the questions below.

Meanwhile for the second point I did some tests myself with one chip on 
each of the two buses and it worked fine with my latest v2 patches.
So I'm not sure at all why Yogesh has problems with his setup (two chips 
on the first bus).

Thanks,
Frieder

On 11.07.2018 14:13, Frieder Schrempf wrote:
> Hi guys from NXP,
> 
> we still have some issues/questions concerning the FSL QSPI IP, that 
> somehow block the new driver under the SPI memory framework [1].
> 
> If anyone of you could comment on these, or help finding solutions, this 
> would be very much appreciated.
> 
> 1. The SPI NOR driver was using a reset of the flash and AHB domain to 
> invalidate the AHB buffer [2]. But this needs quite a lot of time, so we 
> have a hack to use two regions in memory and switch between them 
> alternately to invalidate the cache [3]. As this is not so nice, do you 
> know of any other possibility to invalidate the flash?
> 
> 2. We tried to reuse the mapped memory to access different chips on 
> different CS, by switching the QUADSPI_SFA1AD, QUADSPI_SFA2AD, etc. 
> accordingly [4]. This doesn't work as expected, but Yogesh found out, 
> that it works with a fixed memory map for each CS and by adding a 
> ioremap(), as the SPI NOR driver does [5]. Can someone explain this 
> behavior and why the ioremap is needed?
> 
> 3. In case of a NOR page program operation, the driver is expected to 
> write the full page, even if it's larger than the TX buffer size. Boris 
> explained this here: [6].
> So we need to find a way of triggering a refill of the TX buffer by CPU 
> or DMA if possible.
> 
> Thank you in advance for your help,
> 
> Frieder
> 
> [1] https://patchwork.ozlabs.org/cover/939864/
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4#n591 
> 
> [3] 
> https://github.com/fschrempf/linux/blob/fsl-qspi-next-2/drivers/spi/spi-fsl-qspi.c#L511 
> 
> [4] 
> https://github.com/fschrempf/linux/blob/fsl-qspi-next-2/drivers/spi/spi-fsl-qspi.c#L476 
> 
> [5] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4#n906 
> 
> [6] https://patchwork.ozlabs.org/patch/928677/#1950278

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Thursday, August 2, 2018 8:09 AM
> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org
> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Ping.
> 
> I'm not sure if my message below went out to you at all. At least I can't find it
> in the ML archive.
> 
> I still hope someone can help with the questions below.
> 
> Meanwhile for the second point I did some tests myself with one chip on
> each of the two buses and it worked fine with my latest v2 patches.
> So I'm not sure at all why Yogesh has problems with his setup (two chips on
> the first bus).

Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.

[    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
[    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
[    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12

This is the reason why dynamic ioremap added in previous driver, please refer to
 https://patchwork.ozlabs.org/patch/503655/

I cannot really test the functionality in this case, will get another platform without such issue and retry.

> 
> Thanks,
> Frieder
> 
> On 11.07.2018 14:13, Frieder Schrempf wrote:
> > Hi guys from NXP,
> >
> > we still have some issues/questions concerning the FSL QSPI IP, that
> > somehow block the new driver under the SPI memory framework [1].
> >
> > If anyone of you could comment on these, or help finding solutions,
> > this would be very much appreciated.
> >
> > 1. The SPI NOR driver was using a reset of the flash and AHB domain to
> > invalidate the AHB buffer [2]. But this needs quite a lot of time, so
> > we have a hack to use two regions in memory and switch between them
> > alternately to invalidate the cache [3]. As this is not so nice, do
> > you know of any other possibility to invalidate the flash?
> >
> > 2. We tried to reuse the mapped memory to access different chips on
> > different CS, by switching the QUADSPI_SFA1AD, QUADSPI_SFA2AD, etc.
> > accordingly [4]. This doesn't work as expected, but Yogesh found out,
> > that it works with a fixed memory map for each CS and by adding a
> > ioremap(), as the SPI NOR driver does [5]. Can someone explain this
> > behavior and why the ioremap is needed?
> >
> > 3. In case of a NOR page program operation, the driver is expected to
> > write the full page, even if it's larger than the TX buffer size.
> > Boris explained this here: [6].
> > So we need to find a way of triggering a refill of the TX buffer by
> > CPU or DMA if possible.
> >
> > Thank you in advance for your help,
> >
> > Frieder
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fcover%2F939864%2F&amp;data=02%7C01%7Chan.xu
> %40nxp.
> >
> com%7C567dbf7050bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301
> >
> 635%7C0%7C0%7C636688121577481337&amp;sdata=d%2BRazwVOV0z0wJ%
> 2BHrOthM6a
> > 50W0o8omAUOQ%2F3Ji%2Fs6M%3D&amp;reserved=0
> > [2]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > .kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.g
> it%
> > 2Ftree%2Fdrivers%2Fmtd%2Fspi-nor%2Ffsl-quadspi.c%3Fh%3Dv4.18-
> rc4%23n59
> >
> 1&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf7050bc4b38dbea0
> 8d5f87925
> >
> db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63668812157748
> 1337&amp
> > ;sdata=48yLzR8tBHRgLh1rN1Nw1L45%2FNCe4m6idmzvpbi5jpc%3D&amp;re
> served=0
> >
> > [3]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Ffschrempf%2Flinux%2Fblob%2Ffsl-qspi-next-
> 2%2Fdrivers%2Fspi%2
> > Fspi-fsl-
> qspi.c%23L511&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf705
> >
> 0bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C6
> >
> 36688121577481337&amp;sdata=lf0Xwxr6RYrs5YHIIf9TO5RbyEgtr1qMus7p0
> vfUgh
> > c%3D&amp;reserved=0
> >
> > [4]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Ffschrempf%2Flinux%2Fblob%2Ffsl-qspi-next-
> 2%2Fdrivers%2Fspi%2
> > Fspi-fsl-
> qspi.c%23L476&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf705
> >
> 0bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C6
> >
> 36688121577481337&amp;sdata=NYmMKaTsff7%2FZ%2BO7nRjnsIWDFDrAN
> dXZfgpn0H
> > b6Nmw%3D&amp;reserved=0
> >
> > [5]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > .kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.g
> it%
> > 2Ftree%2Fdrivers%2Fmtd%2Fspi-nor%2Ffsl-quadspi.c%3Fh%3Dv4.18-
> rc4%23n90
> >
> 6&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf7050bc4b38dbea0
> 8d5f87925
> >
> db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63668812157748
> 1337&amp
> > ;sdata=BSLjT%2BlwxocGJT3eJ1pUIYxsrBP%2FCdSt0Mthb%2Bx3ySE%3D&am
> p;reserv
> > ed=0
> >
> > [6]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fpatch%2F928677%2F%231950278&amp;data=02%7C0
> 1%7Chan
> > .xu%40nxp.com%7C567dbf7050bc4b38dbea08d5f87925db%7C686ea1d3bc
> 2b4c6fa92
> >
> cd99c5c301635%7C0%7C0%7C636688121577491349&amp;sdata=LPUHvPVnX
> Qvp7OfIl
> > yH26FADDXqJI7%2B%2FsUClsfrGx7k%3D&amp;reserved=0
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Thursday, August 2, 2018 8:09 AM
> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org
> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Ping.
> 
> I'm not sure if my message below went out to you at all. At least I can't find it
> in the ML archive.
> 
> I still hope someone can help with the questions below.
> 
> Meanwhile for the second point I did some tests myself with one chip on
> each of the two buses and it worked fine with my latest v2 patches.
> So I'm not sure at all why Yogesh has problems with his setup (two chips on
> the first bus).

Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.

[    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
[    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
[    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12

This is the reason why dynamic ioremap added in previous driver, please refer to
 https://patchwork.ozlabs.org/patch/503655/

I cannot really test the functionality in this case, will get another platform without such issue and retry.

> 
> Thanks,
> Frieder
> 
> On 11.07.2018 14:13, Frieder Schrempf wrote:
> > Hi guys from NXP,
> >
> > we still have some issues/questions concerning the FSL QSPI IP, that
> > somehow block the new driver under the SPI memory framework [1].
> >
> > If anyone of you could comment on these, or help finding solutions,
> > this would be very much appreciated.
> >
> > 1. The SPI NOR driver was using a reset of the flash and AHB domain to
> > invalidate the AHB buffer [2]. But this needs quite a lot of time, so
> > we have a hack to use two regions in memory and switch between them
> > alternately to invalidate the cache [3]. As this is not so nice, do
> > you know of any other possibility to invalidate the flash?
> >
> > 2. We tried to reuse the mapped memory to access different chips on
> > different CS, by switching the QUADSPI_SFA1AD, QUADSPI_SFA2AD, etc.
> > accordingly [4]. This doesn't work as expected, but Yogesh found out,
> > that it works with a fixed memory map for each CS and by adding a
> > ioremap(), as the SPI NOR driver does [5]. Can someone explain this
> > behavior and why the ioremap is needed?
> >
> > 3. In case of a NOR page program operation, the driver is expected to
> > write the full page, even if it's larger than the TX buffer size.
> > Boris explained this here: [6].
> > So we need to find a way of triggering a refill of the TX buffer by
> > CPU or DMA if possible.
> >
> > Thank you in advance for your help,
> >
> > Frieder
> >
> > [1]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fcover%2F939864%2F&amp;data=02%7C01%7Chan.xu
> %40nxp.
> >
> com%7C567dbf7050bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301
> >
> 635%7C0%7C0%7C636688121577481337&amp;sdata=d%2BRazwVOV0z0wJ%
> 2BHrOthM6a
> > 50W0o8omAUOQ%2F3Ji%2Fs6M%3D&amp;reserved=0
> > [2]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > .kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.g
> it%
> > 2Ftree%2Fdrivers%2Fmtd%2Fspi-nor%2Ffsl-quadspi.c%3Fh%3Dv4.18-
> rc4%23n59
> >
> 1&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf7050bc4b38dbea0
> 8d5f87925
> >
> db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63668812157748
> 1337&amp
> > ;sdata=48yLzR8tBHRgLh1rN1Nw1L45%2FNCe4m6idmzvpbi5jpc%3D&amp;re
> served=0
> >
> > [3]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Ffschrempf%2Flinux%2Fblob%2Ffsl-qspi-next-
> 2%2Fdrivers%2Fspi%2
> > Fspi-fsl-
> qspi.c%23L511&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf705
> >
> 0bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C6
> >
> 36688121577481337&amp;sdata=lf0Xwxr6RYrs5YHIIf9TO5RbyEgtr1qMus7p0
> vfUgh
> > c%3D&amp;reserved=0
> >
> > [4]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Ffschrempf%2Flinux%2Fblob%2Ffsl-qspi-next-
> 2%2Fdrivers%2Fspi%2
> > Fspi-fsl-
> qspi.c%23L476&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf705
> >
> 0bc4b38dbea08d5f87925db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7C6
> >
> 36688121577481337&amp;sdata=NYmMKaTsff7%2FZ%2BO7nRjnsIWDFDrAN
> dXZfgpn0H
> > b6Nmw%3D&amp;reserved=0
> >
> > [5]
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > .kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.g
> it%
> > 2Ftree%2Fdrivers%2Fmtd%2Fspi-nor%2Ffsl-quadspi.c%3Fh%3Dv4.18-
> rc4%23n90
> >
> 6&amp;data=02%7C01%7Chan.xu%40nxp.com%7C567dbf7050bc4b38dbea0
> 8d5f87925
> >
> db%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63668812157748
> 1337&amp
> > ;sdata=BSLjT%2BlwxocGJT3eJ1pUIYxsrBP%2FCdSt0Mthb%2Bx3ySE%3D&am
> p;reserv
> > ed=0
> >
> > [6]
> >
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fpatch%2F928677%2F%231950278&amp;data=02%7C0
> 1%7Chan
> > .xu%40nxp.com%7C567dbf7050bc4b38dbea08d5f87925db%7C686ea1d3bc
> 2b4c6fa92
> >
> cd99c5c301635%7C0%7C0%7C636688121577491349&amp;sdata=LPUHvPVnX
> Qvp7OfIl
> > yH26FADDXqJI7%2B%2FsUClsfrGx7k%3D&amp;reserved=0

Re: Questions about the Freescale/NXP QuadSPI controller

[Boris Brezillon]

Hi Han,

On Thu, 2 Aug 2018 21:58:48 +0000
Han Xu <han.xu@nxp.com> wrote:

> > -----Original Message-----
> > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > Sent: Thursday, August 2, 2018 8:09 AM
> > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > shawnguo@kernel.org
> > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> > spi@vger.kernel.org; dwmw2@infradead.org;
> > computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> > miquel.raynal@bootlin.com; broonie@kernel.org
> > Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> > 
> > Ping.
> > 
> > I'm not sure if my message below went out to you at all. At least I can't find it
> > in the ML archive.
> > 
> > I still hope someone can help with the questions below.
> > 
> > Meanwhile for the second point I did some tests myself with one chip on
> > each of the two buses and it worked fine with my latest v2 patches.
> > So I'm not sure at all why Yogesh has problems with his setup (two chips on
> > the first bus).  
> 
> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.
> 
> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> 
> This is the reason why dynamic ioremap added in previous driver, please refer to
>  https://patchwork.ozlabs.org/patch/503655/

We can reduce the size of the iomap to 2k * 4, since this is all we use
currently. Can you try to change the size of the ioremap call to 16k and
tell us if it works.

Unrelated to this issue, we still have 2 questions left unanswered:

1/ is there an easy way to invalidate AHB buffers? I mean, not
   something that implies a full reset + several milliseconds of delay
   after the reset. Right now we trick the caching logic by mapping a
   portion that is twice the size of the buffer and switching from one
   sub-portion to this other to trigger a real read on each read
   access, but that's hack-ish, and I'd be surprised if HW
   engineers hadn't planned for this "manual AHB buffer flush" case.

2/ if we use DMA, do you know what happens when the TX FIFO runs out
   of data while the TX request is not finished yet. In PIO mode, it
   seems the engine sends garbage on the bus when that happens, and we
   definitely don't want that.

While #1 is not blocking us, #2 is if we don't have those patches
[1][2] applied, and Marek wanted to be sure there was no other
ways to solve the "TX FIFO starvation" issue before considering these
changes. So that'd be great if someone from NXP could have a look/ask
around and give us answers to those 2 questions.

Thanks,

Boris

[1]http://patchwork.ozlabs.org/patch/928677/
[2]http://patchwork.ozlabs.org/patch/928678/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Boris Brezillon]

Hi Han,

On Thu, 2 Aug 2018 21:58:48 +0000
Han Xu <han.xu@nxp.com> wrote:

> > -----Original Message-----
> > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > Sent: Thursday, August 2, 2018 8:09 AM
> > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > shawnguo@kernel.org
> > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> > spi@vger.kernel.org; dwmw2@infradead.org;
> > computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> > miquel.raynal@bootlin.com; broonie@kernel.org
> > Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> > 
> > Ping.
> > 
> > I'm not sure if my message below went out to you at all. At least I can't find it
> > in the ML archive.
> > 
> > I still hope someone can help with the questions below.
> > 
> > Meanwhile for the second point I did some tests myself with one chip on
> > each of the two buses and it worked fine with my latest v2 patches.
> > So I'm not sure at all why Yogesh has problems with his setup (two chips on
> > the first bus).  
> 
> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.
> 
> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> 
> This is the reason why dynamic ioremap added in previous driver, please refer to
>  https://patchwork.ozlabs.org/patch/503655/

We can reduce the size of the iomap to 2k * 4, since this is all we use
currently. Can you try to change the size of the ioremap call to 16k and
tell us if it works.

Unrelated to this issue, we still have 2 questions left unanswered:

1/ is there an easy way to invalidate AHB buffers? I mean, not
   something that implies a full reset + several milliseconds of delay
   after the reset. Right now we trick the caching logic by mapping a
   portion that is twice the size of the buffer and switching from one
   sub-portion to this other to trigger a real read on each read
   access, but that's hack-ish, and I'd be surprised if HW
   engineers hadn't planned for this "manual AHB buffer flush" case.

2/ if we use DMA, do you know what happens when the TX FIFO runs out
   of data while the TX request is not finished yet. In PIO mode, it
   seems the engine sends garbage on the bus when that happens, and we
   definitely don't want that.

While #1 is not blocking us, #2 is if we don't have those patches
[1][2] applied, and Marek wanted to be sure there was no other
ways to solve the "TX FIFO starvation" issue before considering these
changes. So that'd be great if someone from NXP could have a look/ask
around and give us answers to those 2 questions.

Thanks,

Boris

[1]http://patchwork.ozlabs.org/patch/928677/
[2]http://patchwork.ozlabs.org/patch/928678/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 04.08.2018 15:37, Boris Brezillon wrote:
> Hi Han,
> 
> On Thu, 2 Aug 2018 21:58:48 +0000
> Han Xu <han.xu@nxp.com> wrote:
> 
>>> -----Original Message-----
>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>> Sent: Thursday, August 2, 2018 8:09 AM
>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>> shawnguo@kernel.org
>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
>>> spi@vger.kernel.org; dwmw2@infradead.org;
>>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>
>>> Ping.
>>>
>>> I'm not sure if my message below went out to you at all. At least I can't find it
>>> in the ML archive.
>>>
>>> I still hope someone can help with the questions below.
>>>
>>> Meanwhile for the second point I did some tests myself with one chip on
>>> each of the two buses and it worked fine with my latest v2 patches.
>>> So I'm not sure at all why Yogesh has problems with his setup (two chips on
>>> the first bus).
>>
>> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.
>>
>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>
>> This is the reason why dynamic ioremap added in previous driver, please refer to
>>   https://patchwork.ozlabs.org/patch/503655/
> 
> We can reduce the size of the iomap to 2k * 4, since this is all we use
> currently. Can you try to change the size of the ioremap call to 16k and
> tell us if it works.

Were you able to test with the reduced iomap size?
It would be great to know if it works on your board.

Thanks,
Frieder

> 
> Unrelated to this issue, we still have 2 questions left unanswered:
> 
> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>     something that implies a full reset + several milliseconds of delay
>     after the reset. Right now we trick the caching logic by mapping a
>     portion that is twice the size of the buffer and switching from one
>     sub-portion to this other to trigger a real read on each read
>     access, but that's hack-ish, and I'd be surprised if HW
>     engineers hadn't planned for this "manual AHB buffer flush" case.
> 
> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>     of data while the TX request is not finished yet. In PIO mode, it
>     seems the engine sends garbage on the bus when that happens, and we
>     definitely don't want that.
> 
> While #1 is not blocking us, #2 is if we don't have those patches
> [1][2] applied, and Marek wanted to be sure there was no other
> ways to solve the "TX FIFO starvation" issue before considering these
> changes. So that'd be great if someone from NXP could have a look/ask
> around and give us answers to those 2 questions.
> 
> Thanks,
> 
> Boris
> 
> [1]http://patchwork.ozlabs.org/patch/928677/
> [2]http://patchwork.ozlabs.org/patch/928678/
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 04.08.2018 15:37, Boris Brezillon wrote:
> Hi Han,
> 
> On Thu, 2 Aug 2018 21:58:48 +0000
> Han Xu <han.xu@nxp.com> wrote:
> 
>>> -----Original Message-----
>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>> Sent: Thursday, August 2, 2018 8:09 AM
>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>> shawnguo@kernel.org
>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
>>> spi@vger.kernel.org; dwmw2@infradead.org;
>>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>
>>> Ping.
>>>
>>> I'm not sure if my message below went out to you at all. At least I can't find it
>>> in the ML archive.
>>>
>>> I still hope someone can help with the questions below.
>>>
>>> Meanwhile for the second point I did some tests myself with one chip on
>>> each of the two buses and it worked fine with my latest v2 patches.
>>> So I'm not sure at all why Yogesh has problems with his setup (two chips on
>>> the first bus).
>>
>> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map failure.
>>
>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem 0x70000000-0x7fffffff]
>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>
>> This is the reason why dynamic ioremap added in previous driver, please refer to
>>   https://patchwork.ozlabs.org/patch/503655/
> 
> We can reduce the size of the iomap to 2k * 4, since this is all we use
> currently. Can you try to change the size of the ioremap call to 16k and
> tell us if it works.

Were you able to test with the reduced iomap size?
It would be great to know if it works on your board.

Thanks,
Frieder

> 
> Unrelated to this issue, we still have 2 questions left unanswered:
> 
> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>     something that implies a full reset + several milliseconds of delay
>     after the reset. Right now we trick the caching logic by mapping a
>     portion that is twice the size of the buffer and switching from one
>     sub-portion to this other to trigger a real read on each read
>     access, but that's hack-ish, and I'd be surprised if HW
>     engineers hadn't planned for this "manual AHB buffer flush" case.
> 
> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>     of data while the TX request is not finished yet. In PIO mode, it
>     seems the engine sends garbage on the bus when that happens, and we
>     definitely don't want that.
> 
> While #1 is not blocking us, #2 is if we don't have those patches
> [1][2] applied, and Marek wanted to be sure there was no other
> ways to solve the "TX FIFO starvation" issue before considering these
> changes. So that'd be great if someone from NXP could have a look/ask
> around and give us answers to those 2 questions.
> 
> Thanks,
> 
> Boris
> 
> [1]http://patchwork.ozlabs.org/patch/928677/
> [2]http://patchwork.ozlabs.org/patch/928678/
> 

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Monday, September 3, 2018 4:02 AM
> To: Han Xu <han.xu@nxp.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On 04.08.2018 15:37, Boris Brezillon wrote:
> > Hi Han,
> >
> > On Thu, 2 Aug 2018 21:58:48 +0000
> > Han Xu <han.xu@nxp.com> wrote:
> >
> >>> -----Original Message-----
> >>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>> Sent: Thursday, August 2, 2018 8:09 AM
> >>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>> shawnguo@kernel.org
> >>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> >>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
> >>> computersforpeace@gmail.com; marek.vasut@gmail.com;
> richard@nod.at;
> >>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>
> >>> Ping.
> >>>
> >>> I'm not sure if my message below went out to you at all. At least I
> >>> can't find it in the ML archive.
> >>>
> >>> I still hope someone can help with the questions below.
> >>>
> >>> Meanwhile for the second point I did some tests myself with one chip
> >>> on each of the two buses and it worked fine with my latest v2 patches.
> >>> So I'm not sure at all why Yogesh has problems with his setup (two
> >>> chips on the first bus).
> >>
> >> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory
> map failure.
> >>
> >> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
> 0x70000000-0x7fffffff]
> >> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> >> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >>
> >> This is the reason why dynamic ioremap added in previous driver, please
> refer to
> >>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >>
> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
> %40nx
> >>
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c
> >>
> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
> mNPe179D0
> >> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
> >
> > We can reduce the size of the iomap to 2k * 4, since this is all we
> > use currently. Can you try to change the size of the ioremap call to
> > 16k and tell us if it works.
> 
> Were you able to test with the reduced iomap size?
> It would be great to know if it works on your board.
> 
> Thanks,
> Frieder

Test the code on i.MX6SX sabreauto board with two micron n25q256a chips on two CS.
First issue found is __div0 kernel dump with these code
/* Max 64 dummy clock cycles supported */
if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64)
dummy.buswidth was not set during read id.

Second issue is the second part failed to be probed, tried both buswidth 4 and buswidth 1.

[    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
[    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
[    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff

These are the DT settings:
&qspi1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_qspi1_1>;
        status = "okay";

        flash0: n25q256a@0 {
        ¦       #address-cells = <1>;
        ¦       #size-cells = <1>;
        ¦       compatible = "micron,m25p80";
        ¦       spi-max-frequency = <29000000>;
                spi-rx-bus-width = <4>;
                spi-tx-bus-width = <4>;
        ¦       reg = <0>;
        };

        flash1: n25q256a@1 {
        ¦       #address-cells = <1>;
        ¦       #size-cells = <1>;
        ¦       compatible = "micron,m25p80";
        ¦       spi-max-frequency = <29000000>;
                spi-rx-bus-width = <4>;
                spi-tx-bus-width = <4>;
        ¦       reg = <1>;
        };
};

> 
> >
> > Unrelated to this issue, we still have 2 questions left unanswered:
> >
> > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >     something that implies a full reset + several milliseconds of delay
> >     after the reset. Right now we trick the caching logic by mapping a
> >     portion that is twice the size of the buffer and switching from one
> >     sub-portion to this other to trigger a real read on each read
> >     access, but that's hack-ish, and I'd be surprised if HW
> >     engineers hadn't planned for this "manual AHB buffer flush" case.
> >
> > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> >     of data while the TX request is not finished yet. In PIO mode, it
> >     seems the engine sends garbage on the bus when that happens, and we
> >     definitely don't want that.
> >
> > While #1 is not blocking us, #2 is if we don't have those patches
> > [1][2] applied, and Marek wanted to be sure there was no other ways to
> > solve the "TX FIFO starvation" issue before considering these changes.
> > So that'd be great if someone from NXP could have a look/ask around
> > and give us answers to those 2 questions.
> >
> > Thanks,
> >
> > Boris
> >
> >
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=p%2FJBfxNd2Swlmrrr
> H9Xk2R2
> > DDl%2BshfXdUoyXAy4bXBc%3D&amp;reserved=0
> >
> [2]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928678%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=xo2l3Ld3n9mkO5PTW
> 5DOqP7u0
> > %2Bgch0cXs7jEjHVokqQ%3D&amp;reserved=0
> >
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Monday, September 3, 2018 4:02 AM
> To: Han Xu <han.xu@nxp.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On 04.08.2018 15:37, Boris Brezillon wrote:
> > Hi Han,
> >
> > On Thu, 2 Aug 2018 21:58:48 +0000
> > Han Xu <han.xu@nxp.com> wrote:
> >
> >>> -----Original Message-----
> >>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>> Sent: Thursday, August 2, 2018 8:09 AM
> >>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>> shawnguo@kernel.org
> >>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> >>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
> >>> computersforpeace@gmail.com; marek.vasut@gmail.com;
> richard@nod.at;
> >>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>
> >>> Ping.
> >>>
> >>> I'm not sure if my message below went out to you at all. At least I
> >>> can't find it in the ML archive.
> >>>
> >>> I still hope someone can help with the questions below.
> >>>
> >>> Meanwhile for the second point I did some tests myself with one chip
> >>> on each of the two buses and it worked fine with my latest v2 patches.
> >>> So I'm not sure at all why Yogesh has problems with his setup (two
> >>> chips on the first bus).
> >>
> >> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory
> map failure.
> >>
> >> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
> 0x70000000-0x7fffffff]
> >> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> >> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >>
> >> This is the reason why dynamic ioremap added in previous driver, please
> refer to
> >>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpa
> >>
> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
> %40nx
> >>
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c
> >>
> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
> mNPe179D0
> >> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
> >
> > We can reduce the size of the iomap to 2k * 4, since this is all we
> > use currently. Can you try to change the size of the ioremap call to
> > 16k and tell us if it works.
> 
> Were you able to test with the reduced iomap size?
> It would be great to know if it works on your board.
> 
> Thanks,
> Frieder

Test the code on i.MX6SX sabreauto board with two micron n25q256a chips on two CS.
First issue found is __div0 kernel dump with these code
/* Max 64 dummy clock cycles supported */
if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64)
dummy.buswidth was not set during read id.

Second issue is the second part failed to be probed, tried both buswidth 4 and buswidth 1.

[    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
[    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
[    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff

These are the DT settings:
&qspi1 {
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_qspi1_1>;
        status = "okay";

        flash0: n25q256a@0 {
        ¦       #address-cells = <1>;
        ¦       #size-cells = <1>;
        ¦       compatible = "micron,m25p80";
        ¦       spi-max-frequency = <29000000>;
                spi-rx-bus-width = <4>;
                spi-tx-bus-width = <4>;
        ¦       reg = <0>;
        };

        flash1: n25q256a@1 {
        ¦       #address-cells = <1>;
        ¦       #size-cells = <1>;
        ¦       compatible = "micron,m25p80";
        ¦       spi-max-frequency = <29000000>;
                spi-rx-bus-width = <4>;
                spi-tx-bus-width = <4>;
        ¦       reg = <1>;
        };
};

> 
> >
> > Unrelated to this issue, we still have 2 questions left unanswered:
> >
> > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >     something that implies a full reset + several milliseconds of delay
> >     after the reset. Right now we trick the caching logic by mapping a
> >     portion that is twice the size of the buffer and switching from one
> >     sub-portion to this other to trigger a real read on each read
> >     access, but that's hack-ish, and I'd be surprised if HW
> >     engineers hadn't planned for this "manual AHB buffer flush" case.
> >
> > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> >     of data while the TX request is not finished yet. In PIO mode, it
> >     seems the engine sends garbage on the bus when that happens, and we
> >     definitely don't want that.
> >
> > While #1 is not blocking us, #2 is if we don't have those patches
> > [1][2] applied, and Marek wanted to be sure there was no other ways to
> > solve the "TX FIFO starvation" issue before considering these changes.
> > So that'd be great if someone from NXP could have a look/ask around
> > and give us answers to those 2 questions.
> >
> > Thanks,
> >
> > Boris
> >
> >
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=p%2FJBfxNd2Swlmrrr
> H9Xk2R2
> > DDl%2BshfXdUoyXAy4bXBc%3D&amp;reserved=0
> >
> [2]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fp
> >
> atchwork.ozlabs.org%2Fpatch%2F928678%2F&amp;data=02%7C01%7Chan.x
> u%40nx
> >
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> 9c5c3
> >
> 01635%7C0%7C0%7C636715621426190473&amp;sdata=xo2l3Ld3n9mkO5PTW
> 5DOqP7u0
> > %2Bgch0cXs7jEjHVokqQ%3D&amp;reserved=0
> >

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 12.09.2018 19:04, Han Xu wrote:
> 
> 
>> -----Original Message-----
>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>> Sent: Monday, September 3, 2018 4:02 AM
>> To: Han Xu <han.xu@nxp.com>
>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>> miquel.raynal@bootlin.com; broonie@kernel.org
>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>
>> Hi Han,
>>
>> On 04.08.2018 15:37, Boris Brezillon wrote:
>>> Hi Han,
>>>
>>> On Thu, 2 Aug 2018 21:58:48 +0000
>>> Han Xu <han.xu@nxp.com> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>>> Sent: Thursday, August 2, 2018 8:09 AM
>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>>>> shawnguo@kernel.org
>>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
>>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
>>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
>> richard@nod.at;
>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>>
>>>>> Ping.
>>>>>
>>>>> I'm not sure if my message below went out to you at all. At least I
>>>>> can't find it in the ML archive.
>>>>>
>>>>> I still hope someone can help with the questions below.
>>>>>
>>>>> Meanwhile for the second point I did some tests myself with one chip
>>>>> on each of the two buses and it worked fine with my latest v2 patches.
>>>>> So I'm not sure at all why Yogesh has problems with his setup (two
>>>>> chips on the first bus).
>>>>
>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory
>> map failure.
>>>>
>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
>> 0x70000000-0x7fffffff]
>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>>>
>>>> This is the reason why dynamic ioremap added in previous driver, please
>> refer to
>>>>
>>>>
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fpa&umid=d6cc1014-1848-42fb-92fd-9626d45c8050&auth=541e45255b6517100d80c2b1b80b6933b203c492-5aa8e1977a9db94300a9f61f5446e7a21b175f56
>>>>
>> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
>> %40nx
>>>>
>> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
>> 9c5c
>>>>
>> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
>> mNPe179D0
>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
>>>
>>> We can reduce the size of the iomap to 2k * 4, since this is all we
>>> use currently. Can you try to change the size of the ioremap call to
>>> 16k and tell us if it works.
>>
>> Were you able to test with the reduced iomap size?
>> It would be great to know if it works on your board.
>>
>> Thanks,
>> Frieder
> 
> Test the code on i.MX6SX sabreauto board with two micron n25q256a chips on two CS.
> First issue found is __div0 kernel dump with these code
> /* Max 64 dummy clock cycles supported */
> if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64)
> dummy.buswidth was not set during read id.

First, thank you for coming back to this and doing the test.
I'm currently not sure about the reason for this, but I guess Boris will 
figure it out easily ;)

> 
> Second issue is the second part failed to be probed, tried both buswidth 4 and buswidth 1.
> 
> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
> 
> These are the DT settings:
> &qspi1 {
>          pinctrl-names = "default";
>          pinctrl-0 = <&pinctrl_qspi1_1>;
>          status = "okay";
> 
>          flash0: n25q256a@0 {
>          ¦       #address-cells = <1>;
>          ¦       #size-cells = <1>;
>          ¦       compatible = "micron,m25p80";
>          ¦       spi-max-frequency = <29000000>;
>                  spi-rx-bus-width = <4>;
>                  spi-tx-bus-width = <4>;
>          ¦       reg = <0>;
>          };
> 
>          flash1: n25q256a@1 {
>          ¦       #address-cells = <1>;
>          ¦       #size-cells = <1>;
>          ¦       compatible = "micron,m25p80";
>          ¦       spi-max-frequency = <29000000>;
>                  spi-rx-bus-width = <4>;
>                  spi-tx-bus-width = <4>;
>          ¦       reg = <1>;
>          };
> };

First, I think you should add "jedec,spi-nor" to your compatible properties.

Second, are you sure, that the two chips are both on QSPIA using the two 
chip selects?
I have no schematics of the board, but if I look at the devicetree in 
the linux-imx kernel [1] it seems to me that one chip is on QSPIA CS0 
and the other on QSPIB CS0.
If this is the case, then you have to set reg = <2> for the second chip.

Thanks,
Frieder

[1] 
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/tree/arch/arm/boot/dts/imx6sx-sabreauto.dts?h=imx_4.9.11_1.0.0_ga#n771

>>>
>>> Unrelated to this issue, we still have 2 questions left unanswered:
>>>
>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>>>      something that implies a full reset + several milliseconds of delay
>>>      after the reset. Right now we trick the caching logic by mapping a
>>>      portion that is twice the size of the buffer and switching from one
>>>      sub-portion to this other to trigger a real read on each read
>>>      access, but that's hack-ish, and I'd be surprised if HW
>>>      engineers hadn't planned for this "manual AHB buffer flush" case.
>>>
>>> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>>>      of data while the TX request is not finished yet. In PIO mode, it
>>>      seems the engine sends garbage on the bus when that happens, and we
>>>      definitely don't want that.
>>>
>>> While #1 is not blocking us, #2 is if we don't have those patches
>>> [1][2] applied, and Marek wanted to be sure there was no other ways to
>>> solve the "TX FIFO starvation" issue before considering these changes.
>>> So that'd be great if someone from NXP could have a look/ask around
>>> and give us answers to those 2 questions.
>>>
>>> Thanks,
>>>
>>> Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 12.09.2018 19:04, Han Xu wrote:
> 
> 
>> -----Original Message-----
>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>> Sent: Monday, September 3, 2018 4:02 AM
>> To: Han Xu <han.xu@nxp.com>
>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>> miquel.raynal@bootlin.com; broonie@kernel.org
>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>
>> Hi Han,
>>
>> On 04.08.2018 15:37, Boris Brezillon wrote:
>>> Hi Han,
>>>
>>> On Thu, 2 Aug 2018 21:58:48 +0000
>>> Han Xu <han.xu@nxp.com> wrote:
>>>
>>>>> -----Original Message-----
>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>>> Sent: Thursday, August 2, 2018 8:09 AM
>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>>>> shawnguo@kernel.org
>>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
>>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
>>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
>> richard@nod.at;
>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>>
>>>>> Ping.
>>>>>
>>>>> I'm not sure if my message below went out to you at all. At least I
>>>>> can't find it in the ML archive.
>>>>>
>>>>> I still hope someone can help with the questions below.
>>>>>
>>>>> Meanwhile for the second point I did some tests myself with one chip
>>>>> on each of the two buses and it worked fine with my latest v2 patches.
>>>>> So I'm not sure at all why Yogesh has problems with his setup (two
>>>>> chips on the first bus).
>>>>
>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the memory
>> map failure.
>>>>
>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
>> 0x70000000-0x7fffffff]
>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>>>
>>>> This is the reason why dynamic ioremap added in previous driver, please
>> refer to
>>>>
>>>>
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fpa&umid=d6cc1014-1848-42fb-92fd-9626d45c8050&auth=541e45255b6517100d80c2b1b80b6933b203c492-5aa8e1977a9db94300a9f61f5446e7a21b175f56
>>>>
>> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
>> %40nx
>>>>
>> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
>> 9c5c
>>>>
>> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
>> mNPe179D0
>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
>>>
>>> We can reduce the size of the iomap to 2k * 4, since this is all we
>>> use currently. Can you try to change the size of the ioremap call to
>>> 16k and tell us if it works.
>>
>> Were you able to test with the reduced iomap size?
>> It would be great to know if it works on your board.
>>
>> Thanks,
>> Frieder
> 
> Test the code on i.MX6SX sabreauto board with two micron n25q256a chips on two CS.
> First issue found is __div0 kernel dump with these code
> /* Max 64 dummy clock cycles supported */
> if (op->dummy.nbytes * 8 / op->dummy.buswidth > 64)
> dummy.buswidth was not set during read id.

First, thank you for coming back to this and doing the test.
I'm currently not sure about the reason for this, but I guess Boris will 
figure it out easily ;)

> 
> Second issue is the second part failed to be probed, tried both buswidth 4 and buswidth 1.
> 
> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
> 
> These are the DT settings:
> &qspi1 {
>          pinctrl-names = "default";
>          pinctrl-0 = <&pinctrl_qspi1_1>;
>          status = "okay";
> 
>          flash0: n25q256a@0 {
>          ¦       #address-cells = <1>;
>          ¦       #size-cells = <1>;
>          ¦       compatible = "micron,m25p80";
>          ¦       spi-max-frequency = <29000000>;
>                  spi-rx-bus-width = <4>;
>                  spi-tx-bus-width = <4>;
>          ¦       reg = <0>;
>          };
> 
>          flash1: n25q256a@1 {
>          ¦       #address-cells = <1>;
>          ¦       #size-cells = <1>;
>          ¦       compatible = "micron,m25p80";
>          ¦       spi-max-frequency = <29000000>;
>                  spi-rx-bus-width = <4>;
>                  spi-tx-bus-width = <4>;
>          ¦       reg = <1>;
>          };
> };

First, I think you should add "jedec,spi-nor" to your compatible properties.

Second, are you sure, that the two chips are both on QSPIA using the two 
chip selects?
I have no schematics of the board, but if I look at the devicetree in 
the linux-imx kernel [1] it seems to me that one chip is on QSPIA CS0 
and the other on QSPIB CS0.
If this is the case, then you have to set reg = <2> for the second chip.

Thanks,
Frieder

[1] 
http://git.freescale.com/git/cgit.cgi/imx/linux-imx.git/tree/arch/arm/boot/dts/imx6sx-sabreauto.dts?h=imx_4.9.11_1.0.0_ga#n771

>>>
>>> Unrelated to this issue, we still have 2 questions left unanswered:
>>>
>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>>>      something that implies a full reset + several milliseconds of delay
>>>      after the reset. Right now we trick the caching logic by mapping a
>>>      portion that is twice the size of the buffer and switching from one
>>>      sub-portion to this other to trigger a real read on each read
>>>      access, but that's hack-ish, and I'd be surprised if HW
>>>      engineers hadn't planned for this "manual AHB buffer flush" case.
>>>
>>> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>>>      of data while the TX request is not finished yet. In PIO mode, it
>>>      seems the engine sends garbage on the bus when that happens, and we
>>>      definitely don't want that.
>>>
>>> While #1 is not blocking us, #2 is if we don't have those patches
>>> [1][2] applied, and Marek wanted to be sure there was no other ways to
>>> solve the "TX FIFO starvation" issue before considering these changes.
>>> So that'd be great if someone from NXP could have a look/ask around
>>> and give us answers to those 2 questions.
>>>
>>> Thanks,
>>>
>>> Boris

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Wednesday, September 12, 2018 1:41 PM
> To: Han Xu <han.xu@nxp.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On 12.09.2018 19:04, Han Xu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >> Sent: Monday, September 3, 2018 4:02 AM
> >> To: Han Xu <han.xu@nxp.com>
> >> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur
> >> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >> dwmw2@infradead.org; computersforpeace@gmail.com;
> >> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >> broonie@kernel.org
> >> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>
> >> Hi Han,
> >>
> >> On 04.08.2018 15:37, Boris Brezillon wrote:
> >>> Hi Han,
> >>>
> >>> On Thu, 2 Aug 2018 21:58:48 +0000
> >>> Han Xu <han.xu@nxp.com> wrote:
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>>> Sent: Thursday, August 2, 2018 8:09 AM
> >>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>>>> shawnguo@kernel.org
> >>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> >>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
> >>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
> >> richard@nod.at;
> >>>>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>>>
> >>>>> Ping.
> >>>>>
> >>>>> I'm not sure if my message below went out to you at all. At least
> >>>>> I can't find it in the ML archive.
> >>>>>
> >>>>> I still hope someone can help with the questions below.
> >>>>>
> >>>>> Meanwhile for the second point I did some tests myself with one
> >>>>> chip on each of the two buses and it worked fine with my latest v2
> patches.
> >>>>> So I'm not sure at all why Yogesh has problems with his setup (two
> >>>>> chips on the first bus).
> >>>>
> >>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
> >>>> memory
> >> map failure.
> >>>>
> >>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource
> [mem
> >> 0x70000000-0x7fffffff]
> >>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> >>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >>>>
> >>>> This is the reason why dynamic ioremap added in previous driver,
> >>>> please
> >> refer to
> >>>>
> >>>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsm
> >> ex12-5-en-
> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu
> >>
> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
> f
> >> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-
> 1848-42fb
> >> -92fd-
> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-
> >>
> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
> u%40
> >>
> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
> d99c
> >>
> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
> lcICuV
> >> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0
> >>>>
> >>
> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
> >> %40nx
> >>>>
> >>
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> >> 9c5c
> >>>>
> >>
> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
> >> mNPe179D0
> >>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
> >>>
> >>> We can reduce the size of the iomap to 2k * 4, since this is all we
> >>> use currently. Can you try to change the size of the ioremap call to
> >>> 16k and tell us if it works.
> >>
> >> Were you able to test with the reduced iomap size?
> >> It would be great to know if it works on your board.
> >>
> >> Thanks,
> >> Frieder
> >
> > Test the code on i.MX6SX sabreauto board with two micron n25q256a chips
> on two CS.
> > First issue found is __div0 kernel dump with these code
> > /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes * 8 /
> > op->dummy.buswidth > 64) dummy.buswidth was not set during read id.
> 
> First, thank you for coming back to this and doing the test.
> I'm currently not sure about the reason for this, but I guess Boris will figure it
> out easily ;)
> 
> >
> > Second issue is the second part failed to be probed, tried both buswidth 4
> and buswidth 1.
> >
> > [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> > [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> > [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
> >
> > These are the DT settings:
> > &qspi1 {
> >          pinctrl-names = "default";
> >          pinctrl-0 = <&pinctrl_qspi1_1>;
> >          status = "okay";
> >
> >          flash0: n25q256a@0 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <0>;
> >          };
> >
> >          flash1: n25q256a@1 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <1>;
> >          };
> > };
> 
> First, I think you should add "jedec,spi-nor" to your compatible properties.
> 
> Second, are you sure, that the two chips are both on QSPIA using the two
> chip selects?
> I have no schematics of the board, but if I look at the devicetree in the linux-
> imx kernel [1] it seems to me that one chip is on QSPIA CS0 and the other on
> QSPIB CS0.
> If this is the case, then you have to set reg = <2> for the second chip.

Yes, you are right, the second chip connects to QSPIB CS0, with the DT change, both of them work fine with __div0 issue workaround.

> 
> Thanks,
> Frieder
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.f
> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
> ved=0
> 
> >>>
> >>> Unrelated to this issue, we still have 2 questions left unanswered:
> >>>
> >>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >>>      something that implies a full reset + several milliseconds of delay
> >>>      after the reset. Right now we trick the caching logic by mapping a
> >>>      portion that is twice the size of the buffer and switching from one
> >>>      sub-portion to this other to trigger a real read on each read
> >>>      access, but that's hack-ish, and I'd be surprised if HW
> >>>      engineers hadn't planned for this "manual AHB buffer flush" case.
> >>>
> >>> 2/ if we use DMA, do you know what happens when the TX FIFO runs
> out
> >>>      of data while the TX request is not finished yet. In PIO mode, it
> >>>      seems the engine sends garbage on the bus when that happens, and
> we
> >>>      definitely don't want that.
> >>>
> >>> While #1 is not blocking us, #2 is if we don't have those patches
> >>> [1][2] applied, and Marek wanted to be sure there was no other ways
> >>> to solve the "TX FIFO starvation" issue before considering these changes.
> >>> So that'd be great if someone from NXP could have a look/ask around
> >>> and give us answers to those 2 questions.
> >>>
> >>> Thanks,
> >>>
> >>> Boris
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: Questions about the Freescale/NXP QuadSPI controller

[Han Xu]

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Wednesday, September 12, 2018 1:41 PM
> To: Han Xu <han.xu@nxp.com>
> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On 12.09.2018 19:04, Han Xu wrote:
> >
> >
> >> -----Original Message-----
> >> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >> Sent: Monday, September 3, 2018 4:02 AM
> >> To: Han Xu <han.xu@nxp.com>
> >> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur
> >> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >> dwmw2@infradead.org; computersforpeace@gmail.com;
> >> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >> broonie@kernel.org
> >> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>
> >> Hi Han,
> >>
> >> On 04.08.2018 15:37, Boris Brezillon wrote:
> >>> Hi Han,
> >>>
> >>> On Thu, 2 Aug 2018 21:58:48 +0000
> >>> Han Xu <han.xu@nxp.com> wrote:
> >>>
> >>>>> -----Original Message-----
> >>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>>> Sent: Thursday, August 2, 2018 8:09 AM
> >>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>>>> shawnguo@kernel.org
> >>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> >>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
> >>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
> >> richard@nod.at;
> >>>>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>>>
> >>>>> Ping.
> >>>>>
> >>>>> I'm not sure if my message below went out to you at all. At least
> >>>>> I can't find it in the ML archive.
> >>>>>
> >>>>> I still hope someone can help with the questions below.
> >>>>>
> >>>>> Meanwhile for the second point I did some tests myself with one
> >>>>> chip on each of the two buses and it worked fine with my latest v2
> patches.
> >>>>> So I'm not sure at all why Yogesh has problems with his setup (two
> >>>>> chips on the first bus).
> >>>>
> >>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
> >>>> memory
> >> map failure.
> >>>>
> >>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource
> [mem
> >> 0x70000000-0x7fffffff]
> >>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> >>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >>>>
> >>>> This is the reason why dynamic ioremap added in previous driver,
> >>>> please
> >> refer to
> >>>>
> >>>>
> >>
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsm
> >> ex12-5-en-
> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu
> >>
> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
> f
> >> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-
> 1848-42fb
> >> -92fd-
> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-
> >>
> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
> u%40
> >>
> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
> d99c
> >>
> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
> lcICuV
> >> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0
> >>>>
> >>
> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
> >> %40nx
> >>>>
> >>
> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
> >> 9c5c
> >>>>
> >>
> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
> >> mNPe179D0
> >>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
> >>>
> >>> We can reduce the size of the iomap to 2k * 4, since this is all we
> >>> use currently. Can you try to change the size of the ioremap call to
> >>> 16k and tell us if it works.
> >>
> >> Were you able to test with the reduced iomap size?
> >> It would be great to know if it works on your board.
> >>
> >> Thanks,
> >> Frieder
> >
> > Test the code on i.MX6SX sabreauto board with two micron n25q256a chips
> on two CS.
> > First issue found is __div0 kernel dump with these code
> > /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes * 8 /
> > op->dummy.buswidth > 64) dummy.buswidth was not set during read id.
> 
> First, thank you for coming back to this and doing the test.
> I'm currently not sure about the reason for this, but I guess Boris will figure it
> out easily ;)
> 
> >
> > Second issue is the second part failed to be probed, tried both buswidth 4
> and buswidth 1.
> >
> > [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> > [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> > [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
> >
> > These are the DT settings:
> > &qspi1 {
> >          pinctrl-names = "default";
> >          pinctrl-0 = <&pinctrl_qspi1_1>;
> >          status = "okay";
> >
> >          flash0: n25q256a@0 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <0>;
> >          };
> >
> >          flash1: n25q256a@1 {
> >          ¦       #address-cells = <1>;
> >          ¦       #size-cells = <1>;
> >          ¦       compatible = "micron,m25p80";
> >          ¦       spi-max-frequency = <29000000>;
> >                  spi-rx-bus-width = <4>;
> >                  spi-tx-bus-width = <4>;
> >          ¦       reg = <1>;
> >          };
> > };
> 
> First, I think you should add "jedec,spi-nor" to your compatible properties.
> 
> Second, are you sure, that the two chips are both on QSPIA using the two
> chip selects?
> I have no schematics of the board, but if I look at the devicetree in the linux-
> imx kernel [1] it seems to me that one chip is on QSPIA CS0 and the other on
> QSPIB CS0.
> If this is the case, then you have to set reg = <2> for the second chip.

Yes, you are right, the second chip connects to QSPIB CS0, with the DT change, both of them work fine with __div0 issue workaround.

> 
> Thanks,
> Frieder
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.f
> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
> ved=0
> 
> >>>
> >>> Unrelated to this issue, we still have 2 questions left unanswered:
> >>>
> >>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >>>      something that implies a full reset + several milliseconds of delay
> >>>      after the reset. Right now we trick the caching logic by mapping a
> >>>      portion that is twice the size of the buffer and switching from one
> >>>      sub-portion to this other to trigger a real read on each read
> >>>      access, but that's hack-ish, and I'd be surprised if HW
> >>>      engineers hadn't planned for this "manual AHB buffer flush" case.
> >>>
> >>> 2/ if we use DMA, do you know what happens when the TX FIFO runs
> out
> >>>      of data while the TX request is not finished yet. In PIO mode, it
> >>>      seems the engine sends garbage on the bus when that happens, and
> we
> >>>      definitely don't want that.
> >>>
> >>> While #1 is not blocking us, #2 is if we don't have those patches
> >>> [1][2] applied, and Marek wanted to be sure there was no other ways
> >>> to solve the "TX FIFO starvation" issue before considering these changes.
> >>> So that'd be great if someone from NXP could have a look/ask around
> >>> and give us answers to those 2 questions.
> >>>
> >>> Thanks,
> >>>
> >>> Boris

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 12.09.2018 23:04, Han Xu wrote:
> 
> 
>> -----Original Message-----
>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>> Sent: Wednesday, September 12, 2018 1:41 PM
>> To: Han Xu <han.xu@nxp.com>
>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>> miquel.raynal@bootlin.com; broonie@kernel.org
>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>
>> Hi Han,
>>
>> On 12.09.2018 19:04, Han Xu wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>> Sent: Monday, September 3, 2018 4:02 AM
>>>> To: Han Xu <han.xu@nxp.com>
>>>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>>>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>>>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur
>>>> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>>>> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
>>>> dwmw2@infradead.org; computersforpeace@gmail.com;
>>>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
>>>> broonie@kernel.org
>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>
>>>> Hi Han,
>>>>
>>>> On 04.08.2018 15:37, Boris Brezillon wrote:
>>>>> Hi Han,
>>>>>
>>>>> On Thu, 2 Aug 2018 21:58:48 +0000
>>>>> Han Xu <han.xu@nxp.com> wrote:
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>>>>> Sent: Thursday, August 2, 2018 8:09 AM
>>>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>>>>>> shawnguo@kernel.org
>>>>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
>>>>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
>>>>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
>>>> richard@nod.at;
>>>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>>>>
>>>>>>> Ping.
>>>>>>>
>>>>>>> I'm not sure if my message below went out to you at all. At least
>>>>>>> I can't find it in the ML archive.
>>>>>>>
>>>>>>> I still hope someone can help with the questions below.
>>>>>>>
>>>>>>> Meanwhile for the second point I did some tests myself with one
>>>>>>> chip on each of the two buses and it worked fine with my latest v2
>> patches.
>>>>>>> So I'm not sure at all why Yogesh has problems with his setup (two
>>>>>>> chips on the first bus).
>>>>>>
>>>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
>>>>>> memory
>>>> map failure.
>>>>>>
>>>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource
>> [mem
>>>> 0x70000000-0x7fffffff]
>>>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>>>>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>>>>>
>>>>>> This is the reason why dynamic ioremap added in previous driver,
>>>>>> please
>>>> refer to
>>>>>>
>>>>>>
>>>>
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fsm&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-cefb4275e4aea35bf0c475f6bd6da9e9a8c877a0
>>>> ex12-5-en-
>> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu
>>>>
>> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
>> f
>>>> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-
>> 1848-42fb
>>>> -92fd-
>> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-
>>>>
>> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
>> u%40
>>>>
>> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
>> d99c
>>>>
>> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
>> lcICuV
>>>> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0
>>>>>>
>>>>
>> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
>>>> %40nx
>>>>>>
>>>>
>> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
>>>> 9c5c
>>>>>>
>>>>
>> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
>>>> mNPe179D0
>>>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
>>>>>
>>>>> We can reduce the size of the iomap to 2k * 4, since this is all we
>>>>> use currently. Can you try to change the size of the ioremap call to
>>>>> 16k and tell us if it works.
>>>>
>>>> Were you able to test with the reduced iomap size?
>>>> It would be great to know if it works on your board.
>>>>
>>>> Thanks,
>>>> Frieder
>>>
>>> Test the code on i.MX6SX sabreauto board with two micron n25q256a chips
>> on two CS.
>>> First issue found is __div0 kernel dump with these code
>>> /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes * 8 /
>>> op->dummy.buswidth > 64) dummy.buswidth was not set during read id.
>>
>> First, thank you for coming back to this and doing the test.
>> I'm currently not sure about the reason for this, but I guess Boris will figure it
>> out easily ;)

Ok, on a closer look it is obvious that the reason is this commit [1]. 
My last test was before this change, when dummy.buswidth was still set 
to 1 even if dummy.n_bytes is 0.
Now both are 0 and I need to handle this in the FSL QSPI driver.

>>
>>>
>>> Second issue is the second part failed to be probed, tried both buswidth 4
>> and buswidth 1.
>>>
>>> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
>>> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
>>> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
>>>
>>> These are the DT settings:
>>> &qspi1 {
>>>           pinctrl-names = "default";
>>>           pinctrl-0 = <&pinctrl_qspi1_1>;
>>>           status = "okay";
>>>
>>>           flash0: n25q256a@0 {
>>>           ¦       #address-cells = <1>;
>>>           ¦       #size-cells = <1>;
>>>           ¦       compatible = "micron,m25p80";
>>>           ¦       spi-max-frequency = <29000000>;
>>>                   spi-rx-bus-width = <4>;
>>>                   spi-tx-bus-width = <4>;
>>>           ¦       reg = <0>;
>>>           };
>>>
>>>           flash1: n25q256a@1 {
>>>           ¦       #address-cells = <1>;
>>>           ¦       #size-cells = <1>;
>>>           ¦       compatible = "micron,m25p80";
>>>           ¦       spi-max-frequency = <29000000>;
>>>                   spi-rx-bus-width = <4>;
>>>                   spi-tx-bus-width = <4>;
>>>           ¦       reg = <1>;
>>>           };
>>> };
>>
>> First, I think you should add "jedec,spi-nor" to your compatible properties.
>>
>> Second, are you sure, that the two chips are both on QSPIA using the two
>> chip selects?
>> I have no schematics of the board, but if I look at the devicetree in the linux-
>> imx kernel [1] it seems to me that one chip is on QSPIA CS0 and the other on
>> QSPIB CS0.
>> If this is the case, then you have to set reg = <2> for the second chip.
> 
> Yes, you are right, the second chip connects to QSPIB CS0, with the DT change, both of them work fine with __div0 issue workaround.

Ok, great. Thanks for your test.

As Yogesh reported problems with his LS1088ARDB board, where both chips 
are connected to QSPIA, I was hoping someone could confirm this by 
testing on a similar setup.

So if you have a board around, that uses this setup, it would be great 
if you can try on that. If not we have to find other ways to investigate 
this.

Thanks,
Frieder

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9882b5375df532acb2c2399a90d882461112e612

> 
>>
>> Thanks,
>> Frieder
>>
>> [1]
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttp%253A%252F%252Fgit.f&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-54ce7888db3c2cb56ff686a840c4d0fa657a3cdb
>> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
>> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
>> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
>> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
>> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
>> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
>> ved=0
>>
>>>>>
>>>>> Unrelated to this issue, we still have 2 questions left unanswered:
>>>>>
>>>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>>>>>       something that implies a full reset + several milliseconds of delay
>>>>>       after the reset. Right now we trick the caching logic by mapping a
>>>>>       portion that is twice the size of the buffer and switching from one
>>>>>       sub-portion to this other to trigger a real read on each read
>>>>>       access, but that's hack-ish, and I'd be surprised if HW
>>>>>       engineers hadn't planned for this "manual AHB buffer flush" case.
>>>>>
>>>>> 2/ if we use DMA, do you know what happens when the TX FIFO runs
>> out
>>>>>       of data while the TX request is not finished yet. In PIO mode, it
>>>>>       seems the engine sends garbage on the bus when that happens, and
>> we
>>>>>       definitely don't want that.
>>>>>
>>>>> While #1 is not blocking us, #2 is if we don't have those patches
>>>>> [1][2] applied, and Marek wanted to be sure there was no other ways
>>>>> to solve the "TX FIFO starvation" issue before considering these changes.
>>>>> So that'd be great if someone from NXP could have a look/ask around
>>>>> and give us answers to those 2 questions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Han,

On 12.09.2018 23:04, Han Xu wrote:
> 
> 
>> -----Original Message-----
>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>> Sent: Wednesday, September 12, 2018 1:41 PM
>> To: Han Xu <han.xu@nxp.com>
>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
>> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
>> miquel.raynal@bootlin.com; broonie@kernel.org
>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>
>> Hi Han,
>>
>> On 12.09.2018 19:04, Han Xu wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>> Sent: Monday, September 3, 2018 4:02 AM
>>>> To: Han Xu <han.xu@nxp.com>
>>>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
>>>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
>>>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
>> Gaur
>>>> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
>>>> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
>>>> dwmw2@infradead.org; computersforpeace@gmail.com;
>>>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
>>>> broonie@kernel.org
>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>
>>>> Hi Han,
>>>>
>>>> On 04.08.2018 15:37, Boris Brezillon wrote:
>>>>> Hi Han,
>>>>>
>>>>> On Thu, 2 Aug 2018 21:58:48 +0000
>>>>> Han Xu <han.xu@nxp.com> wrote:
>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
>>>>>>> Sent: Thursday, August 2, 2018 8:09 AM
>>>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>>>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>>>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>>>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>>>>>>> shawnguo@kernel.org
>>>>>>> Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
>>>>>>> linux- spi@vger.kernel.org; dwmw2@infradead.org;
>>>>>>> computersforpeace@gmail.com; marek.vasut@gmail.com;
>>>> richard@nod.at;
>>>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
>>>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
>>>>>>>
>>>>>>> Ping.
>>>>>>>
>>>>>>> I'm not sure if my message below went out to you at all. At least
>>>>>>> I can't find it in the ML archive.
>>>>>>>
>>>>>>> I still hope someone can help with the questions below.
>>>>>>>
>>>>>>> Meanwhile for the second point I did some tests myself with one
>>>>>>> chip on each of the two buses and it worked fine with my latest v2
>> patches.
>>>>>>> So I'm not sure at all why Yogesh has problems with his setup (two
>>>>>>> chips on the first bus).
>>>>>>
>>>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
>>>>>> memory
>>>> map failure.
>>>>>>
>>>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource
>> [mem
>>>> 0x70000000-0x7fffffff]
>>>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
>>>>>> [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
>>>>>>
>>>>>> This is the reason why dynamic ioremap added in previous driver,
>>>>>> please
>>>> refer to
>>>>>>
>>>>>>
>>>>
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fsm&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-cefb4275e4aea35bf0c475f6bd6da9e9a8c877a0
>>>> ex12-5-en-
>> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu
>>>>
>> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
>> f
>>>> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-
>> 1848-42fb
>>>> -92fd-
>> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-
>>>>
>> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
>> u%40
>>>>
>> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
>> d99c
>>>>
>> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
>> lcICuV
>>>> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0
>>>>>>
>>>>
>> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu
>>>> %40nx
>>>>>>
>>>>
>> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9
>>>> 9c5c
>>>>>>
>>>>
>> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW
>>>> mNPe179D0
>>>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0
>>>>>
>>>>> We can reduce the size of the iomap to 2k * 4, since this is all we
>>>>> use currently. Can you try to change the size of the ioremap call to
>>>>> 16k and tell us if it works.
>>>>
>>>> Were you able to test with the reduced iomap size?
>>>> It would be great to know if it works on your board.
>>>>
>>>> Thanks,
>>>> Frieder
>>>
>>> Test the code on i.MX6SX sabreauto board with two micron n25q256a chips
>> on two CS.
>>> First issue found is __div0 kernel dump with these code
>>> /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes * 8 /
>>> op->dummy.buswidth > 64) dummy.buswidth was not set during read id.
>>
>> First, thank you for coming back to this and doing the test.
>> I'm currently not sure about the reason for this, but I guess Boris will figure it
>> out easily ;)

Ok, on a closer look it is obvious that the reason is this commit [1]. 
My last test was before this change, when dummy.buswidth was still set 
to 1 even if dummy.n_bytes is 0.
Now both are 0 and I need to handle this in the FSL QSPI driver.

>>
>>>
>>> Second issue is the second part failed to be probed, tried both buswidth 4
>> and buswidth 1.
>>>
>>> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
>>> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
>>> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff, ff, ff
>>>
>>> These are the DT settings:
>>> &qspi1 {
>>>           pinctrl-names = "default";
>>>           pinctrl-0 = <&pinctrl_qspi1_1>;
>>>           status = "okay";
>>>
>>>           flash0: n25q256a@0 {
>>>           ¦       #address-cells = <1>;
>>>           ¦       #size-cells = <1>;
>>>           ¦       compatible = "micron,m25p80";
>>>           ¦       spi-max-frequency = <29000000>;
>>>                   spi-rx-bus-width = <4>;
>>>                   spi-tx-bus-width = <4>;
>>>           ¦       reg = <0>;
>>>           };
>>>
>>>           flash1: n25q256a@1 {
>>>           ¦       #address-cells = <1>;
>>>           ¦       #size-cells = <1>;
>>>           ¦       compatible = "micron,m25p80";
>>>           ¦       spi-max-frequency = <29000000>;
>>>                   spi-rx-bus-width = <4>;
>>>                   spi-tx-bus-width = <4>;
>>>           ¦       reg = <1>;
>>>           };
>>> };
>>
>> First, I think you should add "jedec,spi-nor" to your compatible properties.
>>
>> Second, are you sure, that the two chips are both on QSPIA using the two
>> chip selects?
>> I have no schematics of the board, but if I look at the devicetree in the linux-
>> imx kernel [1] it seems to me that one chip is on QSPIA CS0 and the other on
>> QSPIB CS0.
>> If this is the case, then you have to set reg = <2> for the second chip.
> 
> Yes, you are right, the second chip connects to QSPIB CS0, with the DT change, both of them work fine with __div0 issue workaround.

Ok, great. Thanks for your test.

As Yogesh reported problems with his LS1088ARDB board, where both chips 
are connected to QSPIA, I was hoping someone could confirm this by 
testing on a similar setup.

So if you have a board around, that uses this setup, it would be great 
if you can try on that. If not we have to find other ways to investigate 
this.

Thanks,
Frieder

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9882b5375df532acb2c2399a90d882461112e612

> 
>>
>> Thanks,
>> Frieder
>>
>> [1]
>> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttp%253A%252F%252Fgit.f&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-54ce7888db3c2cb56ff686a840c4d0fa657a3cdb
>> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
>> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
>> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
>> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
>> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
>> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
>> ved=0
>>
>>>>>
>>>>> Unrelated to this issue, we still have 2 questions left unanswered:
>>>>>
>>>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>>>>>       something that implies a full reset + several milliseconds of delay
>>>>>       after the reset. Right now we trick the caching logic by mapping a
>>>>>       portion that is twice the size of the buffer and switching from one
>>>>>       sub-portion to this other to trigger a real read on each read
>>>>>       access, but that's hack-ish, and I'd be surprised if HW
>>>>>       engineers hadn't planned for this "manual AHB buffer flush" case.
>>>>>
>>>>> 2/ if we use DMA, do you know what happens when the TX FIFO runs
>> out
>>>>>       of data while the TX request is not finished yet. In PIO mode, it
>>>>>       seems the engine sends garbage on the bus when that happens, and
>> we
>>>>>       definitely don't want that.
>>>>>
>>>>> While #1 is not blocking us, #2 is if we don't have those patches
>>>>> [1][2] applied, and Marek wanted to be sure there was no other ways
>>>>> to solve the "TX FIFO starvation" issue before considering these changes.
>>>>> So that'd be great if someone from NXP could have a look/ask around
>>>>> and give us answers to those 2 questions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Boris

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 12231 bytes --]

Dear All,

Maybe I do jump a bit off topic here, but...

I've read through the following thread:
https://patchwork.ozlabs.org/patch/939885/

And it mentions some issues with reading AHB content (buffers) in
fsl-quadspi.c driver discovered when new QuadSPI driver was developed.

I do have a setup with qspi0 having two SPI memories connected (2x16
MiB), and I'm wondering if anybody has some more info regarding:

(What's more is that there is a bug in
 * the "IP Command Read" in the Vybrid.) found here:
https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671

I've googled for some errata or known issues for vybryd's QSPI IP block
(vf610) but without luck so far ...

Thanks in advance,

> Hi Han,
> 
> On 12.09.2018 23:04, Han Xu wrote:
> > 
> >   
> >> -----Original Message-----
> >> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >> Sent: Wednesday, September 12, 2018 1:41 PM
> >> To: Han Xu <han.xu@nxp.com>
> >> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> >> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >> dwmw2@infradead.org; computersforpeace@gmail.com;
> >> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >> broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> >> QuadSPI controller
> >>
> >> Hi Han,
> >>
> >> On 12.09.2018 19:04, Han Xu wrote:  
> >>>
> >>>  
> >>>> -----Original Message-----
> >>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>> Sent: Monday, September 3, 2018 4:02 AM
> >>>> To: Han Xu <han.xu@nxp.com>
> >>>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >>>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >>>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan  
> >> Gaur  
> >>>> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >>>> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >>>> dwmw2@infradead.org; computersforpeace@gmail.com;
> >>>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >>>> broonie@kernel.org
> >>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>>
> >>>> Hi Han,
> >>>>
> >>>> On 04.08.2018 15:37, Boris Brezillon wrote:  
> >>>>> Hi Han,
> >>>>>
> >>>>> On Thu, 2 Aug 2018 21:58:48 +0000
> >>>>> Han Xu <han.xu@nxp.com> wrote:
> >>>>>  
> >>>>>>> -----Original Message-----
> >>>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>>>>> Sent: Thursday, August 2, 2018 8:09 AM
> >>>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>>>>>> shawnguo@kernel.org
> >>>>>>> Cc: linux-mtd@lists.infradead.org;
> >>>>>>> boris.brezillon@bootlin.com; linux- spi@vger.kernel.org;
> >>>>>>> dwmw2@infradead.org; computersforpeace@gmail.com;
> >>>>>>> marek.vasut@gmail.com;  
> >>>> richard@nod.at;  
> >>>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI
> >>>>>>> controller
> >>>>>>>
> >>>>>>> Ping.
> >>>>>>>
> >>>>>>> I'm not sure if my message below went out to you at all. At
> >>>>>>> least I can't find it in the ML archive.
> >>>>>>>
> >>>>>>> I still hope someone can help with the questions below.
> >>>>>>>
> >>>>>>> Meanwhile for the second point I did some tests myself with
> >>>>>>> one chip on each of the two buses and it worked fine with my
> >>>>>>> latest v2  
> >> patches.  
> >>>>>>> So I'm not sure at all why Yogesh has problems with his setup
> >>>>>>> (two chips on the first bus).  
> >>>>>>
> >>>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
> >>>>>> memory  
> >>>> map failure.  
> >>>>>>
> >>>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> >>>>>> resource  
> >> [mem  
> >>>> 0x70000000-0x7fffffff]  
> >>>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI
> >>>>>> probe failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi
> >>>>>> failed with error -12
> >>>>>>
> >>>>>> This is the reason why dynamic ioremap added in previous
> >>>>>> driver, please  
> >>>> refer to  
> >>>>>>
> >>>>>>  
> >>>>  
> >> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fsm&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-cefb4275e4aea35bf0c475f6bd6da9e9a8c877a0  
> >>>> ex12-5-en-  
> >> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu  
> >>>>  
> >> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
> >> f  
> >>>> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-  
> >> 1848-42fb  
> >>>> -92fd-  
> >> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-  
> >>>>  
> >> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
> >> u%40  
> >>>>  
> >> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
> >> d99c  
> >>>>  
> >> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
> >> lcICuV  
> >>>> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0  
> >>>>>>  
> >>>>  
> >> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu  
> >>>> %40nx  
> >>>>>>  
> >>>>  
> >> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9  
> >>>> 9c5c  
> >>>>>>  
> >>>>  
> >> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW  
> >>>> mNPe179D0  
> >>>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0  
> >>>>>
> >>>>> We can reduce the size of the iomap to 2k * 4, since this is
> >>>>> all we use currently. Can you try to change the size of the
> >>>>> ioremap call to 16k and tell us if it works.  
> >>>>
> >>>> Were you able to test with the reduced iomap size?
> >>>> It would be great to know if it works on your board.
> >>>>
> >>>> Thanks,
> >>>> Frieder  
> >>>
> >>> Test the code on i.MX6SX sabreauto board with two micron n25q256a
> >>> chips  
> >> on two CS.  
> >>> First issue found is __div0 kernel dump with these code
> >>> /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes *
> >>> 8 / op->dummy.buswidth > 64) dummy.buswidth was not set during
> >>> read id.  
> >>
> >> First, thank you for coming back to this and doing the test.
> >> I'm currently not sure about the reason for this, but I guess
> >> Boris will figure it out easily ;)  
> 
> Ok, on a closer look it is obvious that the reason is this commit
> [1]. My last test was before this change, when dummy.buswidth was
> still set to 1 even if dummy.n_bytes is 0.
> Now both are 0 and I need to handle this in the FSL QSPI driver.
> 
> >>  
> >>>
> >>> Second issue is the second part failed to be probed, tried both
> >>> buswidth 4  
> >> and buswidth 1.  
> >>>
> >>> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> >>> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> >>> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff,
> >>> ff, ff
> >>>
> >>> These are the DT settings:
> >>> &qspi1 {
> >>>           pinctrl-names = "default";
> >>>           pinctrl-0 = <&pinctrl_qspi1_1>;
> >>>           status = "okay";
> >>>
> >>>           flash0: n25q256a@0 {
> >>>           ¦       #address-cells = <1>;
> >>>           ¦       #size-cells = <1>;
> >>>           ¦       compatible = "micron,m25p80";
> >>>           ¦       spi-max-frequency = <29000000>;
> >>>                   spi-rx-bus-width = <4>;
> >>>                   spi-tx-bus-width = <4>;
> >>>           ¦       reg = <0>;
> >>>           };
> >>>
> >>>           flash1: n25q256a@1 {
> >>>           ¦       #address-cells = <1>;
> >>>           ¦       #size-cells = <1>;
> >>>           ¦       compatible = "micron,m25p80";
> >>>           ¦       spi-max-frequency = <29000000>;
> >>>                   spi-rx-bus-width = <4>;
> >>>                   spi-tx-bus-width = <4>;
> >>>           ¦       reg = <1>;
> >>>           };
> >>> };  
> >>
> >> First, I think you should add "jedec,spi-nor" to your compatible
> >> properties.
> >>
> >> Second, are you sure, that the two chips are both on QSPIA using
> >> the two chip selects?
> >> I have no schematics of the board, but if I look at the devicetree
> >> in the linux- imx kernel [1] it seems to me that one chip is on
> >> QSPIA CS0 and the other on QSPIB CS0.
> >> If this is the case, then you have to set reg = <2> for the second
> >> chip.  
> > 
> > Yes, you are right, the second chip connects to QSPIB CS0, with the
> > DT change, both of them work fine with __div0 issue workaround.  
> 
> Ok, great. Thanks for your test.
> 
> As Yogesh reported problems with his LS1088ARDB board, where both
> chips are connected to QSPIA, I was hoping someone could confirm this
> by testing on a similar setup.
> 
> So if you have a board around, that uses this setup, it would be
> great if you can try on that. If not we have to find other ways to
> investigate this.
> 
> Thanks,
> Frieder
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9882b5375df532acb2c2399a90d882461112e612
> 
> >   
> >>
> >> Thanks,
> >> Frieder
> >>
> >> [1]
> >> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttp%253A%252F%252Fgit.f&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-54ce7888db3c2cb56ff686a840c4d0fa657a3cdb
> >> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
> >> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
> >> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
> >> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
> >> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
> >> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
> >> ved=0
> >>  
> >>>>>
> >>>>> Unrelated to this issue, we still have 2 questions left
> >>>>> unanswered:
> >>>>>
> >>>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >>>>>       something that implies a full reset + several
> >>>>> milliseconds of delay after the reset. Right now we trick the
> >>>>> caching logic by mapping a portion that is twice the size of
> >>>>> the buffer and switching from one sub-portion to this other to
> >>>>> trigger a real read on each read access, but that's hack-ish,
> >>>>> and I'd be surprised if HW engineers hadn't planned for this
> >>>>> "manual AHB buffer flush" case.
> >>>>>
> >>>>> 2/ if we use DMA, do you know what happens when the TX FIFO
> >>>>> runs  
> >> out  
> >>>>>       of data while the TX request is not finished yet. In PIO
> >>>>> mode, it seems the engine sends garbage on the bus when that
> >>>>> happens, and  
> >> we  
> >>>>>       definitely don't want that.
> >>>>>
> >>>>> While #1 is not blocking us, #2 is if we don't have those
> >>>>> patches [1][2] applied, and Marek wanted to be sure there was
> >>>>> no other ways to solve the "TX FIFO starvation" issue before
> >>>>> considering these changes. So that'd be great if someone from
> >>>>> NXP could have a look/ask around and give us answers to those 2
> >>>>> questions.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Boris  
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 12231 bytes --]

Dear All,

Maybe I do jump a bit off topic here, but...

I've read through the following thread:
https://patchwork.ozlabs.org/patch/939885/

And it mentions some issues with reading AHB content (buffers) in
fsl-quadspi.c driver discovered when new QuadSPI driver was developed.

I do have a setup with qspi0 having two SPI memories connected (2x16
MiB), and I'm wondering if anybody has some more info regarding:

(What's more is that there is a bug in
 * the "IP Command Read" in the Vybrid.) found here:
https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671

I've googled for some errata or known issues for vybryd's QSPI IP block
(vf610) but without luck so far ...

Thanks in advance,

> Hi Han,
> 
> On 12.09.2018 23:04, Han Xu wrote:
> > 
> >   
> >> -----Original Message-----
> >> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >> Sent: Wednesday, September 12, 2018 1:41 PM
> >> To: Han Xu <han.xu@nxp.com>
> >> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> >> Gaur <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >> dwmw2@infradead.org; computersforpeace@gmail.com;
> >> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >> broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> >> QuadSPI controller
> >>
> >> Hi Han,
> >>
> >> On 12.09.2018 19:04, Han Xu wrote:  
> >>>
> >>>  
> >>>> -----Original Message-----
> >>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>> Sent: Monday, September 3, 2018 4:02 AM
> >>>> To: Han Xu <han.xu@nxp.com>
> >>>> Cc: Boris Brezillon <boris.brezillon@bootlin.com>; David Wolfe
> >>>> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> >>>> Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan  
> >> Gaur  
> >>>> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> >>>> mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> >>>> dwmw2@infradead.org; computersforpeace@gmail.com;
> >>>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> >>>> broonie@kernel.org
> >>>> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> >>>>
> >>>> Hi Han,
> >>>>
> >>>> On 04.08.2018 15:37, Boris Brezillon wrote:  
> >>>>> Hi Han,
> >>>>>
> >>>>> On Thu, 2 Aug 2018 21:58:48 +0000
> >>>>> Han Xu <han.xu@nxp.com> wrote:
> >>>>>  
> >>>>>>> -----Original Message-----
> >>>>>>> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> >>>>>>> Sent: Thursday, August 2, 2018 8:09 AM
> >>>>>>> To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> >>>>>>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> >>>>>>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> >>>>>>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> >>>>>>> shawnguo@kernel.org
> >>>>>>> Cc: linux-mtd@lists.infradead.org;
> >>>>>>> boris.brezillon@bootlin.com; linux- spi@vger.kernel.org;
> >>>>>>> dwmw2@infradead.org; computersforpeace@gmail.com;
> >>>>>>> marek.vasut@gmail.com;  
> >>>> richard@nod.at;  
> >>>>>>> miquel.raynal@bootlin.com; broonie@kernel.org
> >>>>>>> Subject: Re: Questions about the Freescale/NXP QuadSPI
> >>>>>>> controller
> >>>>>>>
> >>>>>>> Ping.
> >>>>>>>
> >>>>>>> I'm not sure if my message below went out to you at all. At
> >>>>>>> least I can't find it in the ML archive.
> >>>>>>>
> >>>>>>> I still hope someone can help with the questions below.
> >>>>>>>
> >>>>>>> Meanwhile for the second point I did some tests myself with
> >>>>>>> one chip on each of the two buses and it worked fine with my
> >>>>>>> latest v2  
> >> patches.  
> >>>>>>> So I'm not sure at all why Yogesh has problems with his setup
> >>>>>>> (two chips on the first bus).  
> >>>>>>
> >>>>>> Tried to test the v2 patch set on i.MX6SX SDB board but get the
> >>>>>> memory  
> >>>> map failure.  
> >>>>>>
> >>>>>> [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> >>>>>> resource  
> >> [mem  
> >>>> 0x70000000-0x7fffffff]  
> >>>>>> [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI
> >>>>>> probe failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi
> >>>>>> failed with error -12
> >>>>>>
> >>>>>> This is the reason why dynamic ioremap added in previous
> >>>>>> driver, please  
> >>>> refer to  
> >>>>>>
> >>>>>>  
> >>>>  
> >> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttps%253A%252F%252Fsm&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-cefb4275e4aea35bf0c475f6bd6da9e9a8c877a0  
> >>>> ex12-5-en-  
> >> ctp.trendmicro.com%3A443%2Fwis%2Fclicktime%2Fv1%2Fquery%3Fu  
> >>>>  
> >> rl%3Dhttps%253a%252f%252femea01.safelinks.protection.outlook.com%252
> >> f  
> >>>> %253furl%253dhttps%25253A%25252F%25252Fpa%26umid%3Dd6cc1014-  
> >> 1848-42fb  
> >>>> -92fd-  
> >> 9626d45c8050%26auth%3D541e45255b6517100d80c2b1b80b6933b203c492-  
> >>>>  
> >> 5aa8e1977a9db94300a9f61f5446e7a21b175f56&amp;data=02%7C01%7Chan.x
> >> u%40  
> >>>>  
> >> nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d3bc2b4c6fa92c
> >> d99c  
> >>>>  
> >> 5c301635%7C0%7C0%7C636723744426896223&amp;sdata=Y32I9H9adPn%2Bn
> >> lcICuV  
> >>>> M8Uoozsig%2BM3F0rNAhkIF5ZE%3D&amp;reserved=0  
> >>>>>>  
> >>>>  
> >> tchwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Chan.xu  
> >>>> %40nx  
> >>>>>>  
> >>>>  
> >> p.com%7C9f45a8b666d3478f065408d6117bf524%7C686ea1d3bc2b4c6fa92cd9  
> >>>> 9c5c  
> >>>>>>  
> >>>>  
> >> 301635%7C0%7C0%7C636715621426190473&amp;sdata=XWPfWe%2Fu2ePW  
> >>>> mNPe179D0  
> >>>>>> vjTp6eLp0%2FJRF2vRayDwug%3D&amp;reserved=0  
> >>>>>
> >>>>> We can reduce the size of the iomap to 2k * 4, since this is
> >>>>> all we use currently. Can you try to change the size of the
> >>>>> ioremap call to 16k and tell us if it works.  
> >>>>
> >>>> Were you able to test with the reduced iomap size?
> >>>> It would be great to know if it works on your board.
> >>>>
> >>>> Thanks,
> >>>> Frieder  
> >>>
> >>> Test the code on i.MX6SX sabreauto board with two micron n25q256a
> >>> chips  
> >> on two CS.  
> >>> First issue found is __div0 kernel dump with these code
> >>> /* Max 64 dummy clock cycles supported */ if (op->dummy.nbytes *
> >>> 8 / op->dummy.buswidth > 64) dummy.buswidth was not set during
> >>> read id.  
> >>
> >> First, thank you for coming back to this and doing the test.
> >> I'm currently not sure about the reason for this, but I guess
> >> Boris will figure it out easily ;)  
> 
> Ok, on a closer look it is obvious that the reason is this commit
> [1]. My last test was before this change, when dummy.buswidth was
> still set to 1 even if dummy.n_bytes is 0.
> Now both are 0 and I need to handle this in the FSL QSPI driver.
> 
> >>  
> >>>
> >>> Second issue is the second part failed to be probed, tried both
> >>> buswidth 4  
> >> and buswidth 1.  
> >>>
> >>> [    1.364979] m25p80 spi5.0: found n25q256a, expected m25p80
> >>> [    1.370986] m25p80 spi5.0: n25q256a (32768 Kbytes)
> >>> [    1.381020] m25p80 spi5.1: unrecognized JEDEC id bytes: ff,
> >>> ff, ff
> >>>
> >>> These are the DT settings:
> >>> &qspi1 {
> >>>           pinctrl-names = "default";
> >>>           pinctrl-0 = <&pinctrl_qspi1_1>;
> >>>           status = "okay";
> >>>
> >>>           flash0: n25q256a@0 {
> >>>           ¦       #address-cells = <1>;
> >>>           ¦       #size-cells = <1>;
> >>>           ¦       compatible = "micron,m25p80";
> >>>           ¦       spi-max-frequency = <29000000>;
> >>>                   spi-rx-bus-width = <4>;
> >>>                   spi-tx-bus-width = <4>;
> >>>           ¦       reg = <0>;
> >>>           };
> >>>
> >>>           flash1: n25q256a@1 {
> >>>           ¦       #address-cells = <1>;
> >>>           ¦       #size-cells = <1>;
> >>>           ¦       compatible = "micron,m25p80";
> >>>           ¦       spi-max-frequency = <29000000>;
> >>>                   spi-rx-bus-width = <4>;
> >>>                   spi-tx-bus-width = <4>;
> >>>           ¦       reg = <1>;
> >>>           };
> >>> };  
> >>
> >> First, I think you should add "jedec,spi-nor" to your compatible
> >> properties.
> >>
> >> Second, are you sure, that the two chips are both on QSPIA using
> >> the two chip selects?
> >> I have no schematics of the board, but if I look at the devicetree
> >> in the linux- imx kernel [1] it seems to me that one chip is on
> >> QSPIA CS0 and the other on QSPIB CS0.
> >> If this is the case, then you have to set reg = <2> for the second
> >> chip.  
> > 
> > Yes, you are right, the second chip connects to QSPIB CS0, with the
> > DT change, both of them work fine with __div0 issue workaround.  
> 
> Ok, great. Thanks for your test.
> 
> As Yogesh reported problems with his LS1088ARDB board, where both
> chips are connected to QSPIA, I was hoping someone could confirm this
> by testing on a similar setup.
> 
> So if you have a board around, that uses this setup, it would be
> great if you can try on that. If not we have to find other ways to
> investigate this.
> 
> Thanks,
> Frieder
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=9882b5375df532acb2c2399a90d882461112e612
> 
> >   
> >>
> >> Thanks,
> >> Frieder
> >>
> >> [1]
> >> https://smex12-5-en-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2femea01.safelinks.protection.outlook.com%2f%3furl%3dhttp%253A%252F%252Fgit.f&umid=aac77072-ee97-4b8a-b8b9-55765e276aec&auth=78a0452d0eda3018cc3487ba1bec995089e109a2-54ce7888db3c2cb56ff686a840c4d0fa657a3cdb
> >> reescale.com%2Fgit%2Fcgit.cgi%2Fimx%2Flinux-
> >> imx.git%2Ftree%2Farch%2Farm%2Fboot%2Fdts%2Fimx6sx-
> >> sabreauto.dts%3Fh%3Dimx_4.9.11_1.0.0_ga%23n771&amp;data=02%7C01%
> >> 7Chan.xu%40nxp.com%7C9d43e9b29a82419a36c408d618df3dc3%7C686ea1d
> >> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636723744426896223&amp;sdata
> >> =038DdgMLjO23Io3CTHoSVrJL2Ho%2BgxyHlx9%2BLMrLWkQ%3D&amp;reser
> >> ved=0
> >>  
> >>>>>
> >>>>> Unrelated to this issue, we still have 2 questions left
> >>>>> unanswered:
> >>>>>
> >>>>> 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >>>>>       something that implies a full reset + several
> >>>>> milliseconds of delay after the reset. Right now we trick the
> >>>>> caching logic by mapping a portion that is twice the size of
> >>>>> the buffer and switching from one sub-portion to this other to
> >>>>> trigger a real read on each read access, but that's hack-ish,
> >>>>> and I'd be surprised if HW engineers hadn't planned for this
> >>>>> "manual AHB buffer flush" case.
> >>>>>
> >>>>> 2/ if we use DMA, do you know what happens when the TX FIFO
> >>>>> runs  
> >> out  
> >>>>>       of data while the TX request is not finished yet. In PIO
> >>>>> mode, it seems the engine sends garbage on the bus when that
> >>>>> happens, and  
> >> we  
> >>>>>       definitely don't want that.
> >>>>>
> >>>>> While #1 is not blocking us, #2 is if we don't have those
> >>>>> patches [1][2] applied, and Marek wanted to be sure there was
> >>>>> no other ways to solve the "TX FIFO starvation" issue before
> >>>>> considering these changes. So that'd be great if someone from
> >>>>> NXP could have a look/ask around and give us answers to those 2
> >>>>> questions.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Boris  
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 19.09.2018 00:42, Lukasz Majewski wrote:
> Dear All,
> 
> Maybe I do jump a bit off topic here, but...
> 
> I've read through the following thread:
> https://patchwork.ozlabs.org/patch/939885/
> 
> And it mentions some issues with reading AHB content (buffers) in
> fsl-quadspi.c driver discovered when new QuadSPI driver was developed.

The only setup with two chips that is known to be problematic with the 
new driver, is when both chips are connected to the same bus (e.g. 
QSPIA) using separate chip selects.

Does your board use this kind of setup, or are the two chips connected 
two different buses (QSPIA and QSPIB)?

Have you tested the new driver? It would be great to receive some more 
feedback.

> I do have a setup with qspi0 having two SPI memories connected (2x16
> MiB), and I'm wondering if anybody has some more info regarding:
> 
> (What's more is that there is a bug in
>   * the "IP Command Read" in the Vybrid.) found here:
> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> 
> I've googled for some errata or known issues for vybryd's QSPI IP block
> (vf610) but without luck so far ...

Unfortunately I don't know the background for this comment. Is your 
board using VF610? Do you experience problems?

Regards,
Frieder

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 19.09.2018 00:42, Lukasz Majewski wrote:
> Dear All,
> 
> Maybe I do jump a bit off topic here, but...
> 
> I've read through the following thread:
> https://patchwork.ozlabs.org/patch/939885/
> 
> And it mentions some issues with reading AHB content (buffers) in
> fsl-quadspi.c driver discovered when new QuadSPI driver was developed.

The only setup with two chips that is known to be problematic with the 
new driver, is when both chips are connected to the same bus (e.g. 
QSPIA) using separate chip selects.

Does your board use this kind of setup, or are the two chips connected 
two different buses (QSPIA and QSPIB)?

Have you tested the new driver? It would be great to receive some more 
feedback.

> I do have a setup with qspi0 having two SPI memories connected (2x16
> MiB), and I'm wondering if anybody has some more info regarding:
> 
> (What's more is that there is a bug in
>   * the "IP Command Read" in the Vybrid.) found here:
> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> 
> I've googled for some errata or known issues for vybryd's QSPI IP block
> (vf610) but without luck so far ...

Unfortunately I don't know the background for this comment. Is your 
board using VF610? Do you experience problems?

Regards,
Frieder

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 2658 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 19.09.2018 00:42, Lukasz Majewski wrote:
> > Dear All,
> > 
> > Maybe I do jump a bit off topic here, but...
> > 
> > I've read through the following thread:
> > https://patchwork.ozlabs.org/patch/939885/
> > 
> > And it mentions some issues with reading AHB content (buffers) in
> > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > developed.  
> 
> The only setup with two chips that is known to be problematic with
> the new driver, is when both chips are connected to the same bus
> (e.g. QSPIA) using separate chip selects.

I'm using QSPI0 controller, with two memories connected to QSPI0_A and
QSPI0_B lines.

> 
> Does your board use this kind of setup, or are the two chips
> connected two different buses (QSPIA and QSPIB)?
> 
> Have you tested the new driver? It would be great to receive some
> more feedback.

I will check (test) this new driver. No problem.

> 
> > I do have a setup with qspi0 having two SPI memories connected (2x16
> > MiB), and I'm wondering if anybody has some more info regarding:
> > 
> > (What's more is that there is a bug in
> >   * the "IP Command Read" in the Vybrid.) found here:
> > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> > 
> > I've googled for some errata or known issues for vybryd's QSPI IP
> > block (vf610) but without luck so far ...  
> 
> Unfortunately I don't know the background for this comment.

The comment was added by some Freescale employee when the driver was
added to Linux (by Huang - CC'ed).

> Is your 
> board using VF610?

Yes, it uses vf610 (A5 + M4 cores).

> Do you experience problems?

I've already observed following issue:

For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
of the AHB buffer is valid. When I do read the whole one - I do see read
data corruption (on UBI or raw memory). 

This was pointed out in the patch:
https://patchwork.ozlabs.org/patch/675401/

Unfortunately, I did not found any info regarding this problem (in
NXP's errata or other doc).

I will check if this issue shows up on new patches.

Thanks in advance for your help.

> 
> Regards,
> Frieder
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 19.09.2018 00:42, Lukasz Majewski wrote:
> > Dear All,
> > 
> > Maybe I do jump a bit off topic here, but...
> > 
> > I've read through the following thread:
> > https://patchwork.ozlabs.org/patch/939885/
> > 
> > And it mentions some issues with reading AHB content (buffers) in
> > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > developed.  
> 
> The only setup with two chips that is known to be problematic with
> the new driver, is when both chips are connected to the same bus
> (e.g. QSPIA) using separate chip selects.

I'm using QSPI0 controller, with two memories connected to QSPI0_A and
QSPI0_B lines.

> 
> Does your board use this kind of setup, or are the two chips
> connected two different buses (QSPIA and QSPIB)?
> 
> Have you tested the new driver? It would be great to receive some
> more feedback.

I will check (test) this new driver. No problem.

> 
> > I do have a setup with qspi0 having two SPI memories connected (2x16
> > MiB), and I'm wondering if anybody has some more info regarding:
> > 
> > (What's more is that there is a bug in
> >   * the "IP Command Read" in the Vybrid.) found here:
> > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> > 
> > I've googled for some errata or known issues for vybryd's QSPI IP
> > block (vf610) but without luck so far ...  
> 
> Unfortunately I don't know the background for this comment.

The comment was added by some Freescale employee when the driver was
added to Linux (by Huang - CC'ed).

> Is your 
> board using VF610?

Yes, it uses vf610 (A5 + M4 cores).

> Do you experience problems?

I've already observed following issue:

For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
of the AHB buffer is valid. When I do read the whole one - I do see read
data corruption (on UBI or raw memory). 

This was pointed out in the patch:
https://patchwork.ozlabs.org/patch/675401/

Unfortunately, I did not found any info regarding this problem (in
NXP's errata or other doc).

I will check if this issue shows up on new patches.

Thanks in advance for your help.

> 
> Regards,
> Frieder
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Questions about the Freescale/NXP QuadSPI controller

[Huang Shijie]

On Wed, Sep 19, 2018 at 01:02:11PM +0200, Lukasz Majewski wrote:
> Hi Frieder,
> 
> > Hi Lukasz,
> > 
> > On 19.09.2018 00:42, Lukasz Majewski wrote:
> > > Dear All,
> > > 
> > > Maybe I do jump a bit off topic here, but...
> > > 
> > > I've read through the following thread:
> > > https://patchwork.ozlabs.org/patch/939885/
> > > 
> > > And it mentions some issues with reading AHB content (buffers) in
> > > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > > developed.  
> > 
> > The only setup with two chips that is known to be problematic with
> > the new driver, is when both chips are connected to the same bus
> > (e.g. QSPIA) using separate chip selects.
> 
> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
> QSPI0_B lines.
> 
> > 
> > Does your board use this kind of setup, or are the two chips
> > connected two different buses (QSPIA and QSPIB)?
> > 
> > Have you tested the new driver? It would be great to receive some
> > more feedback.
> 
> I will check (test) this new driver. No problem.
> 
> > 
> > > I do have a setup with qspi0 having two SPI memories connected (2x16
> > > MiB), and I'm wondering if anybody has some more info regarding:
> > > 
> > > (What's more is that there is a bug in
> > >   * the "IP Command Read" in the Vybrid.) found here:
> > > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> > > 
> > > I've googled for some errata or known issues for vybryd's QSPI IP
> > > block (vf610) but without luck so far ...  
> > 
> > Unfortunately I don't know the background for this comment.
> 
> The comment was added by some Freescale employee when the driver was
> added to Linux (by Huang - CC'ed).

I was told that there was a hardware bug in the vybryd when we use the "IP Command Read":
    If you use the "IP Command Read", you will not get the correct data.

So I added that comment.

I suggest that do not use the "IP Command Read" for vybryd.

Thanks
Huang Shijie

> 
> > Is your 
> > board using VF610?
> 
> Yes, it uses vf610 (A5 + M4 cores).
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Huang Shijie]

On Wed, Sep 19, 2018 at 01:02:11PM +0200, Lukasz Majewski wrote:
> Hi Frieder,
> 
> > Hi Lukasz,
> > 
> > On 19.09.2018 00:42, Lukasz Majewski wrote:
> > > Dear All,
> > > 
> > > Maybe I do jump a bit off topic here, but...
> > > 
> > > I've read through the following thread:
> > > https://patchwork.ozlabs.org/patch/939885/
> > > 
> > > And it mentions some issues with reading AHB content (buffers) in
> > > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > > developed.  
> > 
> > The only setup with two chips that is known to be problematic with
> > the new driver, is when both chips are connected to the same bus
> > (e.g. QSPIA) using separate chip selects.
> 
> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
> QSPI0_B lines.
> 
> > 
> > Does your board use this kind of setup, or are the two chips
> > connected two different buses (QSPIA and QSPIB)?
> > 
> > Have you tested the new driver? It would be great to receive some
> > more feedback.
> 
> I will check (test) this new driver. No problem.
> 
> > 
> > > I do have a setup with qspi0 having two SPI memories connected (2x16
> > > MiB), and I'm wondering if anybody has some more info regarding:
> > > 
> > > (What's more is that there is a bug in
> > >   * the "IP Command Read" in the Vybrid.) found here:
> > > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
> > > 
> > > I've googled for some errata or known issues for vybryd's QSPI IP
> > > block (vf610) but without luck so far ...  
> > 
> > Unfortunately I don't know the background for this comment.
> 
> The comment was added by some Freescale employee when the driver was
> added to Linux (by Huang - CC'ed).

I was told that there was a hardware bug in the vybryd when we use the "IP Command Read":
    If you use the "IP Command Read", you will not get the correct data.

So I added that comment.

I suggest that do not use the "IP Command Read" for vybryd.

Thanks
Huang Shijie

> 
> > Is your 
> > board using VF610?
> 
> Yes, it uses vf610 (A5 + M4 cores).
> 

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 4775 bytes --]

Hi Frieder, 

> Hi Frieder,
> 
> > Hi Lukasz,
> > 
> > On 19.09.2018 00:42, Lukasz Majewski wrote:  
> > > Dear All,
> > > 
> > > Maybe I do jump a bit off topic here, but...
> > > 
> > > I've read through the following thread:
> > > https://patchwork.ozlabs.org/patch/939885/
> > > 
> > > And it mentions some issues with reading AHB content (buffers) in
> > > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > > developed.    
> > 
> > The only setup with two chips that is known to be problematic with
> > the new driver, is when both chips are connected to the same bus
> > (e.g. QSPIA) using separate chip selects.  
> 
> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
> QSPI0_B lines.
> 
> > 
> > Does your board use this kind of setup, or are the two chips
> > connected two different buses (QSPIA and QSPIB)?
> > 
> > Have you tested the new driver? It would be great to receive some
> > more feedback.  
> 
> I will check (test) this new driver. No problem.

I've ported your patch on v4.19-rc3.

I had to fix the "div0 issue" by adding:
if (op->dummy.buswidth && 
	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))

In fsl_qspi_supports_op() function.


Unfortunately, on Vybrid vf610 when testing I do see corruption of read
data from the mtd device:

~# hexdump aaa.img
0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
0000010 e98e 5265 683c a635 c069 e402 303f d936
0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
0000040 ffff ffff ffff ffff ffff ffff ffff ffff
*
0000100

~# hexdump data_test.img
0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
0000010 e98e 5265 683c a635 c069 e402 303f d936
0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c


Test case:
flash_erase /dev/mtd3 0 1
dd if=data_test.img of=/dev/mtd3
dd if=/dev/mtd3 of=aaa.img bs=1 count=256


From the code I see that the AHB buffer has 1024B. It is accessed in 8
bytes packs.

This seems like some cache or HW issue....

In the old driver, to fix this problem one needed to 
1. Reduce the RX fifo size from 128B to 64B

2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
transfer size is the same as in LUT.

(Original patch: https://patchwork.ozlabs.org/patch/675401/)


> 
> >   
> > > I do have a setup with qspi0 having two SPI memories connected
> > > (2x16 MiB), and I'm wondering if anybody has some more info
> > > regarding:
> > > 
> > > (What's more is that there is a bug in
> > >   * the "IP Command Read" in the Vybrid.) found here:
	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the exact
	explanation of this issue.

> > > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
> > > 
> > > I've googled for some errata or known issues for vybryd's QSPI IP
> > > block (vf610) but without luck so far ...    
> > 
> > Unfortunately I don't know the background for this comment.  
> 
> The comment was added by some Freescale employee when the driver was
> added to Linux (by Huang - CC'ed).
> 
> > Is your 
> > board using VF610?  
> 
> Yes, it uses vf610 (A5 + M4 cores).
> 
> > Do you experience problems?  
> 
> I've already observed following issue:
> 
> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> of the AHB buffer is valid. When I do read the whole one - I do see
> read data corruption (on UBI or raw memory). 
> 
> This was pointed out in the patch:
> https://patchwork.ozlabs.org/patch/675401/
> 
> Unfortunately, I did not found any info regarding this problem (in
> NXP's errata or other doc).
> 
> I will check if this issue shows up on new patches.
> 
> Thanks in advance for your help.
> 
> > 
> > Regards,
> > Frieder
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 4775 bytes --]

Hi Frieder, 

> Hi Frieder,
> 
> > Hi Lukasz,
> > 
> > On 19.09.2018 00:42, Lukasz Majewski wrote:  
> > > Dear All,
> > > 
> > > Maybe I do jump a bit off topic here, but...
> > > 
> > > I've read through the following thread:
> > > https://patchwork.ozlabs.org/patch/939885/
> > > 
> > > And it mentions some issues with reading AHB content (buffers) in
> > > fsl-quadspi.c driver discovered when new QuadSPI driver was
> > > developed.    
> > 
> > The only setup with two chips that is known to be problematic with
> > the new driver, is when both chips are connected to the same bus
> > (e.g. QSPIA) using separate chip selects.  
> 
> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
> QSPI0_B lines.
> 
> > 
> > Does your board use this kind of setup, or are the two chips
> > connected two different buses (QSPIA and QSPIB)?
> > 
> > Have you tested the new driver? It would be great to receive some
> > more feedback.  
> 
> I will check (test) this new driver. No problem.

I've ported your patch on v4.19-rc3.

I had to fix the "div0 issue" by adding:
if (op->dummy.buswidth && 
	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))

In fsl_qspi_supports_op() function.


Unfortunately, on Vybrid vf610 when testing I do see corruption of read
data from the mtd device:

~# hexdump aaa.img
0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
0000010 e98e 5265 683c a635 c069 e402 303f d936
0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
0000040 ffff ffff ffff ffff ffff ffff ffff ffff
*
0000100

~# hexdump data_test.img
0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
0000010 e98e 5265 683c a635 c069 e402 303f d936
0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c


Test case:
flash_erase /dev/mtd3 0 1
dd if=data_test.img of=/dev/mtd3
dd if=/dev/mtd3 of=aaa.img bs=1 count=256


From the code I see that the AHB buffer has 1024B. It is accessed in 8
bytes packs.

This seems like some cache or HW issue....

In the old driver, to fix this problem one needed to 
1. Reduce the RX fifo size from 128B to 64B

2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
transfer size is the same as in LUT.

(Original patch: https://patchwork.ozlabs.org/patch/675401/)


> 
> >   
> > > I do have a setup with qspi0 having two SPI memories connected
> > > (2x16 MiB), and I'm wondering if anybody has some more info
> > > regarding:
> > > 
> > > (What's more is that there is a bug in
> > >   * the "IP Command Read" in the Vybrid.) found here:
	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the exact
	explanation of this issue.

> > > https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
> > > 
> > > I've googled for some errata or known issues for vybryd's QSPI IP
> > > block (vf610) but without luck so far ...    
> > 
> > Unfortunately I don't know the background for this comment.  
> 
> The comment was added by some Freescale employee when the driver was
> added to Linux (by Huang - CC'ed).
> 
> > Is your 
> > board using VF610?  
> 
> Yes, it uses vf610 (A5 + M4 cores).
> 
> > Do you experience problems?  
> 
> I've already observed following issue:
> 
> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> of the AHB buffer is valid. When I do read the whole one - I do see
> read data corruption (on UBI or raw memory). 
> 
> This was pointed out in the patch:
> https://patchwork.ozlabs.org/patch/675401/
> 
> Unfortunately, I did not found any info regarding this problem (in
> NXP's errata or other doc).
> 
> I will check if this issue shows up on new patches.
> 
> Thanks in advance for your help.
> 
> > 
> > Regards,
> > Frieder
> > 
> > ______________________________________________________
> > Linux MTD discussion mailing list
> > http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 20.09.2018 17:00, Lukasz Majewski wrote:
> Hi Frieder,
> 
>> Hi Frieder,
>>
>>> Hi Lukasz,
>>>
>>> On 19.09.2018 00:42, Lukasz Majewski wrote:
>>>> Dear All,
>>>>
>>>> Maybe I do jump a bit off topic here, but...
>>>>
>>>> I've read through the following thread:
>>>> https://patchwork.ozlabs.org/patch/939885/
>>>>
>>>> And it mentions some issues with reading AHB content (buffers) in
>>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
>>>> developed.
>>>
>>> The only setup with two chips that is known to be problematic with
>>> the new driver, is when both chips are connected to the same bus
>>> (e.g. QSPIA) using separate chip selects.
>>
>> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
>> QSPI0_B lines.
>>
>>>
>>> Does your board use this kind of setup, or are the two chips
>>> connected two different buses (QSPIA and QSPIB)?
>>>
>>> Have you tested the new driver? It would be great to receive some
>>> more feedback.
>>
>> I will check (test) this new driver. No problem.
> 
> I've ported your patch on v4.19-rc3.
> 
> I had to fix the "div0 issue" by adding:
> if (op->dummy.buswidth &&
> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> 
> In fsl_qspi_supports_op() function.
> 
> 
> Unfortunately, on Vybrid vf610 when testing I do see corruption of read
> data from the mtd device:
> 
> ~# hexdump aaa.img
> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0000100
> 
> ~# hexdump data_test.img
> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> 
> 
> Test case:
> flash_erase /dev/mtd3 0 1
> dd if=data_test.img of=/dev/mtd3
> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> 
> 
>  From the code I see that the AHB buffer has 1024B. It is accessed in 8
> bytes packs.
> 
> This seems like some cache or HW issue....
> 
> In the old driver, to fix this problem one needed to
> 1. Reduce the RX fifo size from 128B to 64B
> 
> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> transfer size is the same as in LUT.
> 
> (Original patch: https://patchwork.ozlabs.org/patch/675401/)

Thanks a lot for doing the test. It seems like Vybrid needs some special 
handling to work around this problem.
So this means the current driver has never worked for Vybrid, as the 
mentioned patch was never merged!?

As these issues seem to be specific to Vybrid and as they seem to exist 
in the current driver too, I would like to fix them after we have a 
first version of the new driver that works for the other platforms.

I hope we can figure out the other issues soon.

Thanks,
Frieder

> 
> 
>>
>>>    
>>>> I do have a setup with qspi0 having two SPI memories connected
>>>> (2x16 MiB), and I'm wondering if anybody has some more info
>>>> regarding:
>>>>
>>>> (What's more is that there is a bug in
>>>>    * the "IP Command Read" in the Vybrid.) found here:
> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the exact
> 	explanation of this issue.
> 
>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
>>>>
>>>> I've googled for some errata or known issues for vybryd's QSPI IP
>>>> block (vf610) but without luck so far ...
>>>
>>> Unfortunately I don't know the background for this comment.
>>
>> The comment was added by some Freescale employee when the driver was
>> added to Linux (by Huang - CC'ed).
>>
>>> Is your
>>> board using VF610?
>>
>> Yes, it uses vf610 (A5 + M4 cores).
>>
>>> Do you experience problems?
>>
>> I've already observed following issue:
>>
>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
>> of the AHB buffer is valid. When I do read the whole one - I do see
>> read data corruption (on UBI or raw memory).
>>
>> This was pointed out in the patch:
>> https://patchwork.ozlabs.org/patch/675401/
>>
>> Unfortunately, I did not found any info regarding this problem (in
>> NXP's errata or other doc).
>>
>> I will check if this issue shows up on new patches.
>>
>> Thanks in advance for your help.
>>
>>>
>>> Regards,
>>> Frieder
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>> Best regards,
>>
>> Lukasz Majewski
>>
>> --
>>
>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 20.09.2018 17:00, Lukasz Majewski wrote:
> Hi Frieder,
> 
>> Hi Frieder,
>>
>>> Hi Lukasz,
>>>
>>> On 19.09.2018 00:42, Lukasz Majewski wrote:
>>>> Dear All,
>>>>
>>>> Maybe I do jump a bit off topic here, but...
>>>>
>>>> I've read through the following thread:
>>>> https://patchwork.ozlabs.org/patch/939885/
>>>>
>>>> And it mentions some issues with reading AHB content (buffers) in
>>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
>>>> developed.
>>>
>>> The only setup with two chips that is known to be problematic with
>>> the new driver, is when both chips are connected to the same bus
>>> (e.g. QSPIA) using separate chip selects.
>>
>> I'm using QSPI0 controller, with two memories connected to QSPI0_A and
>> QSPI0_B lines.
>>
>>>
>>> Does your board use this kind of setup, or are the two chips
>>> connected two different buses (QSPIA and QSPIB)?
>>>
>>> Have you tested the new driver? It would be great to receive some
>>> more feedback.
>>
>> I will check (test) this new driver. No problem.
> 
> I've ported your patch on v4.19-rc3.
> 
> I had to fix the "div0 issue" by adding:
> if (op->dummy.buswidth &&
> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> 
> In fsl_qspi_supports_op() function.
> 
> 
> Unfortunately, on Vybrid vf610 when testing I do see corruption of read
> data from the mtd device:
> 
> ~# hexdump aaa.img
> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0000100
> 
> ~# hexdump data_test.img
> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> 
> 
> Test case:
> flash_erase /dev/mtd3 0 1
> dd if=data_test.img of=/dev/mtd3
> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> 
> 
>  From the code I see that the AHB buffer has 1024B. It is accessed in 8
> bytes packs.
> 
> This seems like some cache or HW issue....
> 
> In the old driver, to fix this problem one needed to
> 1. Reduce the RX fifo size from 128B to 64B
> 
> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> transfer size is the same as in LUT.
> 
> (Original patch: https://patchwork.ozlabs.org/patch/675401/)

Thanks a lot for doing the test. It seems like Vybrid needs some special 
handling to work around this problem.
So this means the current driver has never worked for Vybrid, as the 
mentioned patch was never merged!?

As these issues seem to be specific to Vybrid and as they seem to exist 
in the current driver too, I would like to fix them after we have a 
first version of the new driver that works for the other platforms.

I hope we can figure out the other issues soon.

Thanks,
Frieder

> 
> 
>>
>>>    
>>>> I do have a setup with qspi0 having two SPI memories connected
>>>> (2x16 MiB), and I'm wondering if anybody has some more info
>>>> regarding:
>>>>
>>>> (What's more is that there is a bug in
>>>>    * the "IP Command Read" in the Vybrid.) found here:
> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the exact
> 	explanation of this issue.
> 
>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
>>>>
>>>> I've googled for some errata or known issues for vybryd's QSPI IP
>>>> block (vf610) but without luck so far ...
>>>
>>> Unfortunately I don't know the background for this comment.
>>
>> The comment was added by some Freescale employee when the driver was
>> added to Linux (by Huang - CC'ed).
>>
>>> Is your
>>> board using VF610?
>>
>> Yes, it uses vf610 (A5 + M4 cores).
>>
>>> Do you experience problems?
>>
>> I've already observed following issue:
>>
>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
>> of the AHB buffer is valid. When I do read the whole one - I do see
>> read data corruption (on UBI or raw memory).
>>
>> This was pointed out in the patch:
>> https://patchwork.ozlabs.org/patch/675401/
>>
>> Unfortunately, I did not found any info regarding this problem (in
>> NXP's errata or other doc).
>>
>> I will check if this issue shows up on new patches.
>>
>> Thanks in advance for your help.
>>
>>>
>>> Regards,
>>> Frieder
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
>> Best regards,
>>
>> Lukasz Majewski
>>
>> --
>>
>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 6949 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 20.09.2018 17:00, Lukasz Majewski wrote:
> > Hi Frieder,
> >   
> >> Hi Frieder,
> >>  
> >>> Hi Lukasz,
> >>>
> >>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>> Dear All,
> >>>>
> >>>> Maybe I do jump a bit off topic here, but...
> >>>>
> >>>> I've read through the following thread:
> >>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>
> >>>> And it mentions some issues with reading AHB content (buffers) in
> >>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>> developed.  
> >>>
> >>> The only setup with two chips that is known to be problematic with
> >>> the new driver, is when both chips are connected to the same bus
> >>> (e.g. QSPIA) using separate chip selects.  
> >>
> >> I'm using QSPI0 controller, with two memories connected to QSPI0_A
> >> and QSPI0_B lines.
> >>  
> >>>
> >>> Does your board use this kind of setup, or are the two chips
> >>> connected two different buses (QSPIA and QSPIB)?
> >>>
> >>> Have you tested the new driver? It would be great to receive some
> >>> more feedback.  
> >>
> >> I will check (test) this new driver. No problem.  
> > 
> > I've ported your patch on v4.19-rc3.
> > 
> > I had to fix the "div0 issue" by adding:
> > if (op->dummy.buswidth &&
> > 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> > 
> > In fsl_qspi_supports_op() function.
> > 
> > 
> > Unfortunately, on Vybrid vf610 when testing I do see corruption of
> > read data from the mtd device:
> > 
> > ~# hexdump aaa.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0000100
> > 
> > ~# hexdump data_test.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> > 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> > 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> > 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> > 
> > 
> > Test case:
> > flash_erase /dev/mtd3 0 1
> > dd if=data_test.img of=/dev/mtd3
> > dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> > 
> > 
> >  From the code I see that the AHB buffer has 1024B. It is accessed
> > in 8 bytes packs.
> > 
> > This seems like some cache or HW issue....
> > 
> > In the old driver, to fix this problem one needed to
> > 1. Reduce the RX fifo size from 128B to 64B
> > 
> > 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> > transfer size is the same as in LUT.
> > 
> > (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> 
> Thanks a lot for doing the test. It seems like Vybrid needs some
> special handling to work around this problem.

I'm not sure if it is special - it looks like there may be some HW
issue with Vybrid.

> So this means the current driver has never worked for Vybrid, as the 
> mentioned patch was never merged!?

At least on my setup. You cannot use MTD memory for anything as you
cannot read correctly data from it.

I'm wondering if any other vybrid users (with QSPI) also experience
such problems.

> 
> As these issues seem to be specific to Vybrid and as they seem to
> exist in the current driver too, I would like to fix them after we
> have a first version of the new driver that works for the other
> platforms.

It is fine for me - I hope that I will find solution soon (and rebase
it on top of your patch).

> 
> I hope we can figure out the other issues soon.

I would be very happy if anybody from NXP could look on this issue and
forward it to HW engineers for some insight.

(Vybryd has some old "chip errata document":
https://community.nxp.com/message/1059701 , but it mentions other issue
with QSPI).

> 
> Thanks,
> Frieder
> 
> > 
> >   
> >>  
> >>>      
> >>>> I do have a setup with qspi0 having two SPI memories connected
> >>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>> regarding:
> >>>>
> >>>> (What's more is that there is a bug in
> >>>>    * the "IP Command Read" in the Vybrid.) found here:  
> > 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> > exact explanation of this issue.
> >   
> >>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
> >>>>
> >>>> I've googled for some errata or known issues for vybryd's QSPI IP
> >>>> block (vf610) but without luck so far ...  
> >>>
> >>> Unfortunately I don't know the background for this comment.  
> >>
> >> The comment was added by some Freescale employee when the driver
> >> was added to Linux (by Huang - CC'ed).
> >>  
> >>> Is your
> >>> board using VF610?  
> >>
> >> Yes, it uses vf610 (A5 + M4 cores).
> >>  
> >>> Do you experience problems?  
> >>
> >> I've already observed following issue:
> >>
> >> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> >> of the AHB buffer is valid. When I do read the whole one - I do see
> >> read data corruption (on UBI or raw memory).
> >>
> >> This was pointed out in the patch:
> >> https://patchwork.ozlabs.org/patch/675401/
> >>
> >> Unfortunately, I did not found any info regarding this problem (in
> >> NXP's errata or other doc).
> >>
> >> I will check if this issue shows up on new patches.
> >>
> >> Thanks in advance for your help.
> >>  
> >>>
> >>> Regards,
> >>> Frieder
> >>>
> >>> ______________________________________________________
> >>> Linux MTD discussion mailing list
> >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> --
> >>
> >> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >> wd@denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 6949 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 20.09.2018 17:00, Lukasz Majewski wrote:
> > Hi Frieder,
> >   
> >> Hi Frieder,
> >>  
> >>> Hi Lukasz,
> >>>
> >>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>> Dear All,
> >>>>
> >>>> Maybe I do jump a bit off topic here, but...
> >>>>
> >>>> I've read through the following thread:
> >>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>
> >>>> And it mentions some issues with reading AHB content (buffers) in
> >>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>> developed.  
> >>>
> >>> The only setup with two chips that is known to be problematic with
> >>> the new driver, is when both chips are connected to the same bus
> >>> (e.g. QSPIA) using separate chip selects.  
> >>
> >> I'm using QSPI0 controller, with two memories connected to QSPI0_A
> >> and QSPI0_B lines.
> >>  
> >>>
> >>> Does your board use this kind of setup, or are the two chips
> >>> connected two different buses (QSPIA and QSPIB)?
> >>>
> >>> Have you tested the new driver? It would be great to receive some
> >>> more feedback.  
> >>
> >> I will check (test) this new driver. No problem.  
> > 
> > I've ported your patch on v4.19-rc3.
> > 
> > I had to fix the "div0 issue" by adding:
> > if (op->dummy.buswidth &&
> > 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> > 
> > In fsl_qspi_supports_op() function.
> > 
> > 
> > Unfortunately, on Vybrid vf610 when testing I do see corruption of
> > read data from the mtd device:
> > 
> > ~# hexdump aaa.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0000100
> > 
> > ~# hexdump data_test.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> > 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> > 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> > 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> > 
> > 
> > Test case:
> > flash_erase /dev/mtd3 0 1
> > dd if=data_test.img of=/dev/mtd3
> > dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> > 
> > 
> >  From the code I see that the AHB buffer has 1024B. It is accessed
> > in 8 bytes packs.
> > 
> > This seems like some cache or HW issue....
> > 
> > In the old driver, to fix this problem one needed to
> > 1. Reduce the RX fifo size from 128B to 64B
> > 
> > 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> > transfer size is the same as in LUT.
> > 
> > (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> 
> Thanks a lot for doing the test. It seems like Vybrid needs some
> special handling to work around this problem.

I'm not sure if it is special - it looks like there may be some HW
issue with Vybrid.

> So this means the current driver has never worked for Vybrid, as the 
> mentioned patch was never merged!?

At least on my setup. You cannot use MTD memory for anything as you
cannot read correctly data from it.

I'm wondering if any other vybrid users (with QSPI) also experience
such problems.

> 
> As these issues seem to be specific to Vybrid and as they seem to
> exist in the current driver too, I would like to fix them after we
> have a first version of the new driver that works for the other
> platforms.

It is fine for me - I hope that I will find solution soon (and rebase
it on top of your patch).

> 
> I hope we can figure out the other issues soon.

I would be very happy if anybody from NXP could look on this issue and
forward it to HW engineers for some insight.

(Vybryd has some old "chip errata document":
https://community.nxp.com/message/1059701 , but it mentions other issue
with QSPI).

> 
> Thanks,
> Frieder
> 
> > 
> >   
> >>  
> >>>      
> >>>> I do have a setup with qspi0 having two SPI memories connected
> >>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>> regarding:
> >>>>
> >>>> (What's more is that there is a bug in
> >>>>    * the "IP Command Read" in the Vybrid.) found here:  
> > 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> > exact explanation of this issue.
> >   
> >>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L67
> >>>>
> >>>> I've googled for some errata or known issues for vybryd's QSPI IP
> >>>> block (vf610) but without luck so far ...  
> >>>
> >>> Unfortunately I don't know the background for this comment.  
> >>
> >> The comment was added by some Freescale employee when the driver
> >> was added to Linux (by Huang - CC'ed).
> >>  
> >>> Is your
> >>> board using VF610?  
> >>
> >> Yes, it uses vf610 (A5 + M4 cores).
> >>  
> >>> Do you experience problems?  
> >>
> >> I've already observed following issue:
> >>
> >> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> >> of the AHB buffer is valid. When I do read the whole one - I do see
> >> read data corruption (on UBI or raw memory).
> >>
> >> This was pointed out in the patch:
> >> https://patchwork.ozlabs.org/patch/675401/
> >>
> >> Unfortunately, I did not found any info regarding this problem (in
> >> NXP's errata or other doc).
> >>
> >> I will check if this issue shows up on new patches.
> >>
> >> Thanks in advance for your help.
> >>  
> >>>
> >>> Regards,
> >>> Frieder
> >>>
> >>> ______________________________________________________
> >>> Linux MTD discussion mailing list
> >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> --
> >>
> >> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >> wd@denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 7094 bytes --]

Hi Frieder,

Please find some more comments regarding the new spi-fsl-qspi.c driver.

> Hi Lukasz,
> 
> On 20.09.2018 17:00, Lukasz Majewski wrote:
> > Hi Frieder,
> >   
> >> Hi Frieder,
> >>  
> >>> Hi Lukasz,
> >>>
> >>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>> Dear All,
> >>>>
> >>>> Maybe I do jump a bit off topic here, but...
> >>>>
> >>>> I've read through the following thread:
> >>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>
> >>>> And it mentions some issues with reading AHB content (buffers) in
> >>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>> developed.  
> >>>
> >>> The only setup with two chips that is known to be problematic with
> >>> the new driver, is when both chips are connected to the same bus
> >>> (e.g. QSPIA) using separate chip selects.  
> >>
> >> I'm using QSPI0 controller, with two memories connected to QSPI0_A
> >> and QSPI0_B lines.
> >>  
> >>>
> >>> Does your board use this kind of setup, or are the two chips
> >>> connected two different buses (QSPIA and QSPIB)?
> >>>
> >>> Have you tested the new driver? It would be great to receive some
> >>> more feedback.  
> >>
> >> I will check (test) this new driver. No problem.  
> > 
> > I've ported your patch on v4.19-rc3.
> > 
> > I had to fix the "div0 issue" by adding:
> > if (op->dummy.buswidth &&
> > 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> > 
> > In fsl_qspi_supports_op() function.
> > 
> > 
> > Unfortunately, on Vybrid vf610 when testing I do see corruption of
> > read data from the mtd device:
> > 
> > ~# hexdump aaa.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0000100
> > 
> > ~# hexdump data_test.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> > 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> > 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> > 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> > 
> > 
> > Test case:
> > flash_erase /dev/mtd3 0 1
> > dd if=data_test.img of=/dev/mtd3
> > dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> > 
> > 
> >  From the code I see that the AHB buffer has 1024B. It is accessed
> > in 8 bytes packs.
> > 
> > This seems like some cache or HW issue....
> > 
> > In the old driver, to fix this problem one needed to
> > 1. Reduce the RX fifo size from 128B to 64B
> > 
> > 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> > transfer size is the same as in LUT.
> > 
> > (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> 
> Thanks a lot for doing the test. It seems like Vybrid needs some
> special handling to work around this problem.
> So this means the current driver has never worked for Vybrid, as the 
> mentioned patch was never merged!?
> 
> As these issues seem to be specific to Vybrid and as they seem to
> exist in the current driver too, I would like to fix them after we
> have a first version of the new driver that works for the other
> platforms.
> 
> I hope we can figure out the other issues soon.
> 
> Thanks,
> Frieder
> 
> > 
> >   
> >>  
> >>>      
> >>>> I do have a setup with qspi0 having two SPI memories connected
> >>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>> regarding:
> >>>>
> >>>> (What's more is that there is a bug in
> >>>>    * the "IP Command Read" in the Vybrid.) found here:  
> > 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> > exact explanation of this issue.
> >   
> >>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
       ^^^^^^^^^^^^ - [1]


I've looked a bit closer to the new spi-fsl-qspi.c driver and it looks
like it uses fsl_qspi_exec_op() and then calls fsl_qspi_do_op().

In the last function we setup the QUADSPI_IPCR register to initiate the
transfer between SPI-NOR and the internal RX buffer.

Please correct me if I'm wrong but it seems to me like we are using "IP
Command Read" approach here.

If this is true - what was the rationale to use it in the new driver, as
in the old one the "AHB Command Read" approach was recommended (i.e.
faster) [1]?

To be even more problematic the info in link [1] states that on vybrid
there is a bug on the "IP Command Read" HW block and it should be
avoided.

> >>>>
> >>>> I've googled for some errata or known issues for vybryd's QSPI IP
> >>>> block (vf610) but without luck so far ...  
> >>>
> >>> Unfortunately I don't know the background for this comment.  
> >>
> >> The comment was added by some Freescale employee when the driver
> >> was added to Linux (by Huang - CC'ed).
> >>  
> >>> Is your
> >>> board using VF610?  
> >>
> >> Yes, it uses vf610 (A5 + M4 cores).
> >>  
> >>> Do you experience problems?  
> >>
> >> I've already observed following issue:
> >>
> >> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> >> of the AHB buffer is valid. When I do read the whole one - I do see
> >> read data corruption (on UBI or raw memory).
> >>
> >> This was pointed out in the patch:
> >> https://patchwork.ozlabs.org/patch/675401/
> >>
> >> Unfortunately, I did not found any info regarding this problem (in
> >> NXP's errata or other doc).
> >>
> >> I will check if this issue shows up on new patches.
> >>
> >> Thanks in advance for your help.
> >>  
> >>>
> >>> Regards,
> >>> Frieder
> >>>
> >>> ______________________________________________________
> >>> Linux MTD discussion mailing list
> >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> --
> >>
> >> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >> wd@denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 7094 bytes --]

Hi Frieder,

Please find some more comments regarding the new spi-fsl-qspi.c driver.

> Hi Lukasz,
> 
> On 20.09.2018 17:00, Lukasz Majewski wrote:
> > Hi Frieder,
> >   
> >> Hi Frieder,
> >>  
> >>> Hi Lukasz,
> >>>
> >>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>> Dear All,
> >>>>
> >>>> Maybe I do jump a bit off topic here, but...
> >>>>
> >>>> I've read through the following thread:
> >>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>
> >>>> And it mentions some issues with reading AHB content (buffers) in
> >>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>> developed.  
> >>>
> >>> The only setup with two chips that is known to be problematic with
> >>> the new driver, is when both chips are connected to the same bus
> >>> (e.g. QSPIA) using separate chip selects.  
> >>
> >> I'm using QSPI0 controller, with two memories connected to QSPI0_A
> >> and QSPI0_B lines.
> >>  
> >>>
> >>> Does your board use this kind of setup, or are the two chips
> >>> connected two different buses (QSPIA and QSPIB)?
> >>>
> >>> Have you tested the new driver? It would be great to receive some
> >>> more feedback.  
> >>
> >> I will check (test) this new driver. No problem.  
> > 
> > I've ported your patch on v4.19-rc3.
> > 
> > I had to fix the "div0 issue" by adding:
> > if (op->dummy.buswidth &&
> > 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> > 
> > In fsl_qspi_supports_op() function.
> > 
> > 
> > Unfortunately, on Vybrid vf610 when testing I do see corruption of
> > read data from the mtd device:
> > 
> > ~# hexdump aaa.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0000100
> > 
> > ~# hexdump data_test.img
> > 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> > 0000010 e98e 5265 683c a635 c069 e402 303f d936
> > 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> > 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> > 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> > 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> > 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> > 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> > 
> > 
> > Test case:
> > flash_erase /dev/mtd3 0 1
> > dd if=data_test.img of=/dev/mtd3
> > dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> > 
> > 
> >  From the code I see that the AHB buffer has 1024B. It is accessed
> > in 8 bytes packs.
> > 
> > This seems like some cache or HW issue....
> > 
> > In the old driver, to fix this problem one needed to
> > 1. Reduce the RX fifo size from 128B to 64B
> > 
> > 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> > transfer size is the same as in LUT.
> > 
> > (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> 
> Thanks a lot for doing the test. It seems like Vybrid needs some
> special handling to work around this problem.
> So this means the current driver has never worked for Vybrid, as the 
> mentioned patch was never merged!?
> 
> As these issues seem to be specific to Vybrid and as they seem to
> exist in the current driver too, I would like to fix them after we
> have a first version of the new driver that works for the other
> platforms.
> 
> I hope we can figure out the other issues soon.
> 
> Thanks,
> Frieder
> 
> > 
> >   
> >>  
> >>>      
> >>>> I do have a setup with qspi0 having two SPI memories connected
> >>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>> regarding:
> >>>>
> >>>> (What's more is that there is a bug in
> >>>>    * the "IP Command Read" in the Vybrid.) found here:  
> > 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> > exact explanation of this issue.
> >   
> >>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
       ^^^^^^^^^^^^ - [1]


I've looked a bit closer to the new spi-fsl-qspi.c driver and it looks
like it uses fsl_qspi_exec_op() and then calls fsl_qspi_do_op().

In the last function we setup the QUADSPI_IPCR register to initiate the
transfer between SPI-NOR and the internal RX buffer.

Please correct me if I'm wrong but it seems to me like we are using "IP
Command Read" approach here.

If this is true - what was the rationale to use it in the new driver, as
in the old one the "AHB Command Read" approach was recommended (i.e.
faster) [1]?

To be even more problematic the info in link [1] states that on vybrid
there is a bug on the "IP Command Read" HW block and it should be
avoided.

> >>>>
> >>>> I've googled for some errata or known issues for vybryd's QSPI IP
> >>>> block (vf610) but without luck so far ...  
> >>>
> >>> Unfortunately I don't know the background for this comment.  
> >>
> >> The comment was added by some Freescale employee when the driver
> >> was added to Linux (by Huang - CC'ed).
> >>  
> >>> Is your
> >>> board using VF610?  
> >>
> >> Yes, it uses vf610 (A5 + M4 cores).
> >>  
> >>> Do you experience problems?  
> >>
> >> I've already observed following issue:
> >>
> >> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
> >> of the AHB buffer is valid. When I do read the whole one - I do see
> >> read data corruption (on UBI or raw memory).
> >>
> >> This was pointed out in the patch:
> >> https://patchwork.ozlabs.org/patch/675401/
> >>
> >> Unfortunately, I did not found any info regarding this problem (in
> >> NXP's errata or other doc).
> >>
> >> I will check if this issue shows up on new patches.
> >>
> >> Thanks in advance for your help.
> >>  
> >>>
> >>> Regards,
> >>> Frieder
> >>>
> >>> ______________________________________________________
> >>> Linux MTD discussion mailing list
> >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>
> >> Best regards,
> >>
> >> Lukasz Majewski
> >>
> >> --
> >>
> >> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >> wd@denx.de  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 21.09.2018 00:13, Lukasz Majewski wrote:
> Hi Frieder,
> 
> Please find some more comments regarding the new spi-fsl-qspi.c driver.
> 
>> Hi Lukasz,
>>
>> On 20.09.2018 17:00, Lukasz Majewski wrote:
>>> Hi Frieder,
>>>    
>>>> Hi Frieder,
>>>>   
>>>>> Hi Lukasz,
>>>>>
>>>>> On 19.09.2018 00:42, Lukasz Majewski wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> Maybe I do jump a bit off topic here, but...
>>>>>>
>>>>>> I've read through the following thread:
>>>>>> https://patchwork.ozlabs.org/patch/939885/
>>>>>>
>>>>>> And it mentions some issues with reading AHB content (buffers) in
>>>>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
>>>>>> developed.
>>>>>
>>>>> The only setup with two chips that is known to be problematic with
>>>>> the new driver, is when both chips are connected to the same bus
>>>>> (e.g. QSPIA) using separate chip selects.
>>>>
>>>> I'm using QSPI0 controller, with two memories connected to QSPI0_A
>>>> and QSPI0_B lines.
>>>>   
>>>>>
>>>>> Does your board use this kind of setup, or are the two chips
>>>>> connected two different buses (QSPIA and QSPIB)?
>>>>>
>>>>> Have you tested the new driver? It would be great to receive some
>>>>> more feedback.
>>>>
>>>> I will check (test) this new driver. No problem.
>>>
>>> I've ported your patch on v4.19-rc3.
>>>
>>> I had to fix the "div0 issue" by adding:
>>> if (op->dummy.buswidth &&
>>> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
>>>
>>> In fsl_qspi_supports_op() function.
>>>
>>>
>>> Unfortunately, on Vybrid vf610 when testing I do see corruption of
>>> read data from the mtd device:
>>>
>>> ~# hexdump aaa.img
>>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
>>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
>>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
>>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
>>> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
>>> *
>>> 0000100
>>>
>>> ~# hexdump data_test.img
>>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
>>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
>>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
>>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
>>> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
>>> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
>>> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
>>> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
>>>
>>>
>>> Test case:
>>> flash_erase /dev/mtd3 0 1
>>> dd if=data_test.img of=/dev/mtd3
>>> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
>>>
>>>
>>>   From the code I see that the AHB buffer has 1024B. It is accessed
>>> in 8 bytes packs.
>>>
>>> This seems like some cache or HW issue....
>>>
>>> In the old driver, to fix this problem one needed to
>>> 1. Reduce the RX fifo size from 128B to 64B
>>>
>>> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
>>> transfer size is the same as in LUT.
>>>
>>> (Original patch: https://patchwork.ozlabs.org/patch/675401/)
>>
>> Thanks a lot for doing the test. It seems like Vybrid needs some
>> special handling to work around this problem.
>> So this means the current driver has never worked for Vybrid, as the
>> mentioned patch was never merged!?
>>
>> As these issues seem to be specific to Vybrid and as they seem to
>> exist in the current driver too, I would like to fix them after we
>> have a first version of the new driver that works for the other
>> platforms.
>>
>> I hope we can figure out the other issues soon.
>>
>> Thanks,
>> Frieder
>>
>>>
>>>    
>>>>   
>>>>>       
>>>>>> I do have a setup with qspi0 having two SPI memories connected
>>>>>> (2x16 MiB), and I'm wondering if anybody has some more info
>>>>>> regarding:
>>>>>>
>>>>>> (What's more is that there is a bug in
>>>>>>     * the "IP Command Read" in the Vybrid.) found here:
>>> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
>>> exact explanation of this issue.
>>>    
>>>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
>         ^^^^^^^^^^^^ - [1]
> 
> 
> I've looked a bit closer to the new spi-fsl-qspi.c driver and it looks
> like it uses fsl_qspi_exec_op() and then calls fsl_qspi_do_op().
> 
> In the last function we setup the QUADSPI_IPCR register to initiate the
> transfer between SPI-NOR and the internal RX buffer.
> 
> Please correct me if I'm wrong but it seems to me like we are using "IP
> Command Read" approach here.

"IP Read" is only used if data size is smaller then RX FIFO size (128 
bytes for Vybrid). For bigger chunks of data "AHB Read" is used.

> 
> If this is true - what was the rationale to use it in the new driver, as
> in the old one the "AHB Command Read" approach was recommended (i.e.
> faster) [1]?

As explained above we only use "IP Read" for small chunks of data. To 
speed up the tranfer for bigger chunks we do use "AHB Read".
And in the future we plan to add an interface for mapping memory, so we 
can use the "AHB Read" even more efficiently.

> 
> To be even more problematic the info in link [1] states that on vybrid
> there is a bug on the "IP Command Read" HW block and it should be
> avoided.

If "IP Read" should be avoided completely for Vybrid, we have to add 
some kind of quirk.

Thanks for you comments,
Frieder

> 
>>>>>>
>>>>>> I've googled for some errata or known issues for vybryd's QSPI IP
>>>>>> block (vf610) but without luck so far ...
>>>>>
>>>>> Unfortunately I don't know the background for this comment.
>>>>
>>>> The comment was added by some Freescale employee when the driver
>>>> was added to Linux (by Huang - CC'ed).
>>>>   
>>>>> Is your
>>>>> board using VF610?
>>>>
>>>> Yes, it uses vf610 (A5 + M4 cores).
>>>>   
>>>>> Do you experience problems?
>>>>
>>>> I've already observed following issue:
>>>>
>>>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
>>>> of the AHB buffer is valid. When I do read the whole one - I do see
>>>> read data corruption (on UBI or raw memory).
>>>>
>>>> This was pointed out in the patch:
>>>> https://patchwork.ozlabs.org/patch/675401/
>>>>
>>>> Unfortunately, I did not found any info regarding this problem (in
>>>> NXP's errata or other doc).
>>>>
>>>> I will check if this issue shows up on new patches.
>>>>
>>>> Thanks in advance for your help.
>>>>   
>>>>>
>>>>> Regards,
>>>>> Frieder
>>>>>
>>>>> ______________________________________________________
>>>>> Linux MTD discussion mailing list
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>
>>>> Best regards,
>>>>
>>>> Lukasz Majewski
>>>>
>>>> --
>>>>
>>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
>>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
>>>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
>>>> wd@denx.de
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Lukasz Majewski
>>>
>>> --
>>>
>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
>>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
>>> wd@denx.de
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Frieder Schrempf]

Hi Lukasz,

On 21.09.2018 00:13, Lukasz Majewski wrote:
> Hi Frieder,
> 
> Please find some more comments regarding the new spi-fsl-qspi.c driver.
> 
>> Hi Lukasz,
>>
>> On 20.09.2018 17:00, Lukasz Majewski wrote:
>>> Hi Frieder,
>>>    
>>>> Hi Frieder,
>>>>   
>>>>> Hi Lukasz,
>>>>>
>>>>> On 19.09.2018 00:42, Lukasz Majewski wrote:
>>>>>> Dear All,
>>>>>>
>>>>>> Maybe I do jump a bit off topic here, but...
>>>>>>
>>>>>> I've read through the following thread:
>>>>>> https://patchwork.ozlabs.org/patch/939885/
>>>>>>
>>>>>> And it mentions some issues with reading AHB content (buffers) in
>>>>>> fsl-quadspi.c driver discovered when new QuadSPI driver was
>>>>>> developed.
>>>>>
>>>>> The only setup with two chips that is known to be problematic with
>>>>> the new driver, is when both chips are connected to the same bus
>>>>> (e.g. QSPIA) using separate chip selects.
>>>>
>>>> I'm using QSPI0 controller, with two memories connected to QSPI0_A
>>>> and QSPI0_B lines.
>>>>   
>>>>>
>>>>> Does your board use this kind of setup, or are the two chips
>>>>> connected two different buses (QSPIA and QSPIB)?
>>>>>
>>>>> Have you tested the new driver? It would be great to receive some
>>>>> more feedback.
>>>>
>>>> I will check (test) this new driver. No problem.
>>>
>>> I've ported your patch on v4.19-rc3.
>>>
>>> I had to fix the "div0 issue" by adding:
>>> if (op->dummy.buswidth &&
>>> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
>>>
>>> In fsl_qspi_supports_op() function.
>>>
>>>
>>> Unfortunately, on Vybrid vf610 when testing I do see corruption of
>>> read data from the mtd device:
>>>
>>> ~# hexdump aaa.img
>>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
>>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
>>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
>>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
>>> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
>>> *
>>> 0000100
>>>
>>> ~# hexdump data_test.img
>>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
>>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
>>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
>>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
>>> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
>>> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
>>> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
>>> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
>>>
>>>
>>> Test case:
>>> flash_erase /dev/mtd3 0 1
>>> dd if=data_test.img of=/dev/mtd3
>>> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
>>>
>>>
>>>   From the code I see that the AHB buffer has 1024B. It is accessed
>>> in 8 bytes packs.
>>>
>>> This seems like some cache or HW issue....
>>>
>>> In the old driver, to fix this problem one needed to
>>> 1. Reduce the RX fifo size from 128B to 64B
>>>
>>> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
>>> transfer size is the same as in LUT.
>>>
>>> (Original patch: https://patchwork.ozlabs.org/patch/675401/)
>>
>> Thanks a lot for doing the test. It seems like Vybrid needs some
>> special handling to work around this problem.
>> So this means the current driver has never worked for Vybrid, as the
>> mentioned patch was never merged!?
>>
>> As these issues seem to be specific to Vybrid and as they seem to
>> exist in the current driver too, I would like to fix them after we
>> have a first version of the new driver that works for the other
>> platforms.
>>
>> I hope we can figure out the other issues soon.
>>
>> Thanks,
>> Frieder
>>
>>>
>>>    
>>>>   
>>>>>       
>>>>>> I do have a setup with qspi0 having two SPI memories connected
>>>>>> (2x16 MiB), and I'm wondering if anybody has some more info
>>>>>> regarding:
>>>>>>
>>>>>> (What's more is that there is a bug in
>>>>>>     * the "IP Command Read" in the Vybrid.) found here:
>>> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
>>> exact explanation of this issue.
>>>    
>>>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671
>         ^^^^^^^^^^^^ - [1]
> 
> 
> I've looked a bit closer to the new spi-fsl-qspi.c driver and it looks
> like it uses fsl_qspi_exec_op() and then calls fsl_qspi_do_op().
> 
> In the last function we setup the QUADSPI_IPCR register to initiate the
> transfer between SPI-NOR and the internal RX buffer.
> 
> Please correct me if I'm wrong but it seems to me like we are using "IP
> Command Read" approach here.

"IP Read" is only used if data size is smaller then RX FIFO size (128 
bytes for Vybrid). For bigger chunks of data "AHB Read" is used.

> 
> If this is true - what was the rationale to use it in the new driver, as
> in the old one the "AHB Command Read" approach was recommended (i.e.
> faster) [1]?

As explained above we only use "IP Read" for small chunks of data. To 
speed up the tranfer for bigger chunks we do use "AHB Read".
And in the future we plan to add an interface for mapping memory, so we 
can use the "AHB Read" even more efficiently.

> 
> To be even more problematic the info in link [1] states that on vybrid
> there is a bug on the "IP Command Read" HW block and it should be
> avoided.

If "IP Read" should be avoided completely for Vybrid, we have to add 
some kind of quirk.

Thanks for you comments,
Frieder

> 
>>>>>>
>>>>>> I've googled for some errata or known issues for vybryd's QSPI IP
>>>>>> block (vf610) but without luck so far ...
>>>>>
>>>>> Unfortunately I don't know the background for this comment.
>>>>
>>>> The comment was added by some Freescale employee when the driver
>>>> was added to Linux (by Huang - CC'ed).
>>>>   
>>>>> Is your
>>>>> board using VF610?
>>>>
>>>> Yes, it uses vf610 (A5 + M4 cores).
>>>>   
>>>>> Do you experience problems?
>>>>
>>>> I've already observed following issue:
>>>>
>>>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only half
>>>> of the AHB buffer is valid. When I do read the whole one - I do see
>>>> read data corruption (on UBI or raw memory).
>>>>
>>>> This was pointed out in the patch:
>>>> https://patchwork.ozlabs.org/patch/675401/
>>>>
>>>> Unfortunately, I did not found any info regarding this problem (in
>>>> NXP's errata or other doc).
>>>>
>>>> I will check if this issue shows up on new patches.
>>>>
>>>> Thanks in advance for your help.
>>>>   
>>>>>
>>>>> Regards,
>>>>> Frieder
>>>>>
>>>>> ______________________________________________________
>>>>> Linux MTD discussion mailing list
>>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>>
>>>> Best regards,
>>>>
>>>> Lukasz Majewski
>>>>
>>>> --
>>>>
>>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
>>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
>>>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
>>>> wd@denx.de
>>>
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Lukasz Majewski
>>>
>>> --
>>>
>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
>>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
>>> wd@denx.de
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1.1: Type: text/plain, Size: 9065 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 21.09.2018 00:13, Lukasz Majewski wrote:
> > Hi Frieder,
> > 
> > Please find some more comments regarding the new spi-fsl-qspi.c
> > driver. 
> >> Hi Lukasz,
> >>
> >> On 20.09.2018 17:00, Lukasz Majewski wrote:  
> >>> Hi Frieder,
> >>>      
> >>>> Hi Frieder,
> >>>>     
> >>>>> Hi Lukasz,
> >>>>>
> >>>>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>>>> Dear All,
> >>>>>>
> >>>>>> Maybe I do jump a bit off topic here, but...
> >>>>>>
> >>>>>> I've read through the following thread:
> >>>>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>>>
> >>>>>> And it mentions some issues with reading AHB content (buffers)
> >>>>>> in fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>>>> developed.  
> >>>>>
> >>>>> The only setup with two chips that is known to be problematic
> >>>>> with the new driver, is when both chips are connected to the
> >>>>> same bus (e.g. QSPIA) using separate chip selects.  
> >>>>
> >>>> I'm using QSPI0 controller, with two memories connected to
> >>>> QSPI0_A and QSPI0_B lines.
> >>>>     
> >>>>>
> >>>>> Does your board use this kind of setup, or are the two chips
> >>>>> connected two different buses (QSPIA and QSPIB)?
> >>>>>
> >>>>> Have you tested the new driver? It would be great to receive
> >>>>> some more feedback.  
> >>>>
> >>>> I will check (test) this new driver. No problem.  
> >>>
> >>> I've ported your patch on v4.19-rc3.
> >>>
> >>> I had to fix the "div0 issue" by adding:
> >>> if (op->dummy.buswidth &&
> >>> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> >>>
> >>> In fsl_qspi_supports_op() function.
> >>>
> >>>
> >>> Unfortunately, on Vybrid vf610 when testing I do see corruption of
> >>> read data from the mtd device:
> >>>
> >>> ~# hexdump aaa.img
> >>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> >>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> >>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> >>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> >>> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> >>> *
> >>> 0000100
> >>>
> >>> ~# hexdump data_test.img
> >>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> >>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> >>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> >>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> >>> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> >>> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> >>> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> >>> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> >>>
> >>>
> >>> Test case:
> >>> flash_erase /dev/mtd3 0 1
> >>> dd if=data_test.img of=/dev/mtd3
> >>> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> >>>
> >>>
> >>>   From the code I see that the AHB buffer has 1024B. It is
> >>> accessed in 8 bytes packs.
> >>>
> >>> This seems like some cache or HW issue....
> >>>
> >>> In the old driver, to fix this problem one needed to
> >>> 1. Reduce the RX fifo size from 128B to 64B
> >>>
> >>> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> >>> transfer size is the same as in LUT.
> >>>
> >>> (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> >>
> >> Thanks a lot for doing the test. It seems like Vybrid needs some
> >> special handling to work around this problem.
> >> So this means the current driver has never worked for Vybrid, as
> >> the mentioned patch was never merged!?
> >>
> >> As these issues seem to be specific to Vybrid and as they seem to
> >> exist in the current driver too, I would like to fix them after we
> >> have a first version of the new driver that works for the other
> >> platforms.
> >>
> >> I hope we can figure out the other issues soon.
> >>
> >> Thanks,
> >> Frieder
> >>  
> >>>
> >>>      
> >>>>     
> >>>>>         
> >>>>>> I do have a setup with qspi0 having two SPI memories connected
> >>>>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>>>> regarding:
> >>>>>>
> >>>>>> (What's more is that there is a bug in
> >>>>>>     * the "IP Command Read" in the Vybrid.) found here:  
> >>> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> >>> exact explanation of this issue.
> >>>      
> >>>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671  
> >         ^^^^^^^^^^^^ - [1]
> > 
> > 
> > I've looked a bit closer to the new spi-fsl-qspi.c driver and it
> > looks like it uses fsl_qspi_exec_op() and then calls
> > fsl_qspi_do_op().
> > 
> > In the last function we setup the QUADSPI_IPCR register to initiate
> > the transfer between SPI-NOR and the internal RX buffer.
> > 
> > Please correct me if I'm wrong but it seems to me like we are using
> > "IP Command Read" approach here.  
> 
> "IP Read" is only used if data size is smaller then RX FIFO size (128 
> bytes for Vybrid).

I would like to just point out that the "legacy" (in-kernel) driver
(fsl_quadspi.c) is using AHB transfers for even small chunks of data
(even RX FIFO size).

> For bigger chunks of data "AHB Read" is used.
> 
> > 
> > If this is true - what was the rationale to use it in the new
> > driver, as in the old one the "AHB Command Read" approach was
> > recommended (i.e. faster) [1]?  
> 
> As explained above we only use "IP Read" for small chunks of data. To 
> speed up the tranfer for bigger chunks we do use "AHB Read".
> And in the future we plan to add an interface for mapping memory, so
> we can use the "AHB Read" even more efficiently.

It looks like I do read the AHB internal QUADSPI buffer before it is
filled up completely.
(I've asked the NXP community support about it,
but no reply so far https://community.nxp.com/thread/485139).

> 
> > 
> > To be even more problematic the info in link [1] states that on
> > vybrid there is a bug on the "IP Command Read" HW block and it
> > should be avoided.  
> 
> If "IP Read" should be avoided completely for Vybrid, we have to add 
> some kind of quirk.

Yes, I think so. According to the in-code comment the "IP Read" mode
shall be avoided as it has some bugs.

> 
> Thanks for you comments,
> Frieder
> 
> >   
> >>>>>>
> >>>>>> I've googled for some errata or known issues for vybryd's QSPI
> >>>>>> IP block (vf610) but without luck so far ...  
> >>>>>
> >>>>> Unfortunately I don't know the background for this comment.  
> >>>>
> >>>> The comment was added by some Freescale employee when the driver
> >>>> was added to Linux (by Huang - CC'ed).
> >>>>     
> >>>>> Is your
> >>>>> board using VF610?  
> >>>>
> >>>> Yes, it uses vf610 (A5 + M4 cores).
> >>>>     
> >>>>> Do you experience problems?  
> >>>>
> >>>> I've already observed following issue:
> >>>>
> >>>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only
> >>>> half of the AHB buffer is valid. When I do read the whole one -
> >>>> I do see read data corruption (on UBI or raw memory).
> >>>>
> >>>> This was pointed out in the patch:
> >>>> https://patchwork.ozlabs.org/patch/675401/
> >>>>
> >>>> Unfortunately, I did not found any info regarding this problem
> >>>> (in NXP's errata or other doc).
> >>>>
> >>>> I will check if this issue shows up on new patches.
> >>>>
> >>>> Thanks in advance for your help.
> >>>>     
> >>>>>
> >>>>> Regards,
> >>>>> Frieder
> >>>>>
> >>>>> ______________________________________________________
> >>>>> Linux MTD discussion mailing list
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Lukasz Majewski
> >>>>
> >>>> --
> >>>>
> >>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> >>>> Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax:
> >>>> (+49)-8142-66989-80 Email: wd@denx.de  
> >>>
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Lukasz Majewski
> >>>
> >>> --
> >>>
> >>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >>> wd@denx.de  
> >>
> >> ______________________________________________________
> >> Linux MTD discussion mailing list
> >> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 9065 bytes --]

Hi Frieder,

> Hi Lukasz,
> 
> On 21.09.2018 00:13, Lukasz Majewski wrote:
> > Hi Frieder,
> > 
> > Please find some more comments regarding the new spi-fsl-qspi.c
> > driver. 
> >> Hi Lukasz,
> >>
> >> On 20.09.2018 17:00, Lukasz Majewski wrote:  
> >>> Hi Frieder,
> >>>      
> >>>> Hi Frieder,
> >>>>     
> >>>>> Hi Lukasz,
> >>>>>
> >>>>> On 19.09.2018 00:42, Lukasz Majewski wrote:  
> >>>>>> Dear All,
> >>>>>>
> >>>>>> Maybe I do jump a bit off topic here, but...
> >>>>>>
> >>>>>> I've read through the following thread:
> >>>>>> https://patchwork.ozlabs.org/patch/939885/
> >>>>>>
> >>>>>> And it mentions some issues with reading AHB content (buffers)
> >>>>>> in fsl-quadspi.c driver discovered when new QuadSPI driver was
> >>>>>> developed.  
> >>>>>
> >>>>> The only setup with two chips that is known to be problematic
> >>>>> with the new driver, is when both chips are connected to the
> >>>>> same bus (e.g. QSPIA) using separate chip selects.  
> >>>>
> >>>> I'm using QSPI0 controller, with two memories connected to
> >>>> QSPI0_A and QSPI0_B lines.
> >>>>     
> >>>>>
> >>>>> Does your board use this kind of setup, or are the two chips
> >>>>> connected two different buses (QSPIA and QSPIB)?
> >>>>>
> >>>>> Have you tested the new driver? It would be great to receive
> >>>>> some more feedback.  
> >>>>
> >>>> I will check (test) this new driver. No problem.  
> >>>
> >>> I've ported your patch on v4.19-rc3.
> >>>
> >>> I had to fix the "div0 issue" by adding:
> >>> if (op->dummy.buswidth &&
> >>> 	(op->dummy.nbytes * 8 / op->dummy.buswidth > 64))
> >>>
> >>> In fsl_qspi_supports_op() function.
> >>>
> >>>
> >>> Unfortunately, on Vybrid vf610 when testing I do see corruption of
> >>> read data from the mtd device:
> >>>
> >>> ~# hexdump aaa.img
> >>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> >>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> >>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> >>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> >>> 0000040 ffff ffff ffff ffff ffff ffff ffff ffff
> >>> *
> >>> 0000100
> >>>
> >>> ~# hexdump data_test.img
> >>> 0000000 464c eec0 baa5 c5ff 7b99 4dfb e0b6 8a2e
> >>> 0000010 e98e 5265 683c a635 c069 e402 303f d936
> >>> 0000020 c243 01a7 7064 fce8 e3a9 200a 7e85 28bc
> >>> 0000030 4296 a30e 1bb4 88d4 b456 b4a6 f3aa 8cff
> >>> 0000040 01c9 462d 0a43 f893 0e42 67f1 57f0 787c
> >>> 0000050 49c0 fb2a e514 e954 1d21 affa bac4 38f1
> >>> 0000060 1ca5 ec46 77eb a854 285b 8e21 12d7 f377
> >>> 0000070 b441 2baf ee33 596c 98b6 e71a c1cb 876c
> >>>
> >>>
> >>> Test case:
> >>> flash_erase /dev/mtd3 0 1
> >>> dd if=data_test.img of=/dev/mtd3
> >>> dd if=/dev/mtd3 of=aaa.img bs=1 count=256
> >>>
> >>>
> >>>   From the code I see that the AHB buffer has 1024B. It is
> >>> accessed in 8 bytes packs.
> >>>
> >>> This seems like some cache or HW issue....
> >>>
> >>> In the old driver, to fix this problem one needed to
> >>> 1. Reduce the RX fifo size from 128B to 64B
> >>>
> >>> 2. Disable (set to 0) the AHB transfer's BUF3CR ADATSZ field - the
> >>> transfer size is the same as in LUT.
> >>>
> >>> (Original patch: https://patchwork.ozlabs.org/patch/675401/)  
> >>
> >> Thanks a lot for doing the test. It seems like Vybrid needs some
> >> special handling to work around this problem.
> >> So this means the current driver has never worked for Vybrid, as
> >> the mentioned patch was never merged!?
> >>
> >> As these issues seem to be specific to Vybrid and as they seem to
> >> exist in the current driver too, I would like to fix them after we
> >> have a first version of the new driver that works for the other
> >> platforms.
> >>
> >> I hope we can figure out the other issues soon.
> >>
> >> Thanks,
> >> Frieder
> >>  
> >>>
> >>>      
> >>>>     
> >>>>>         
> >>>>>> I do have a setup with qspi0 having two SPI memories connected
> >>>>>> (2x16 MiB), and I'm wondering if anybody has some more info
> >>>>>> regarding:
> >>>>>>
> >>>>>> (What's more is that there is a bug in
> >>>>>>     * the "IP Command Read" in the Vybrid.) found here:  
> >>> 	^^^^^^^^^^^^^^^^^^^^^^^^ - It would be handy to have the
> >>> exact explanation of this issue.
> >>>      
> >>>>>> https://elixir.bootlin.com/linux/v4.19-rc4/source/drivers/mtd/spi-nor/fsl-quadspi.c#L671  
> >         ^^^^^^^^^^^^ - [1]
> > 
> > 
> > I've looked a bit closer to the new spi-fsl-qspi.c driver and it
> > looks like it uses fsl_qspi_exec_op() and then calls
> > fsl_qspi_do_op().
> > 
> > In the last function we setup the QUADSPI_IPCR register to initiate
> > the transfer between SPI-NOR and the internal RX buffer.
> > 
> > Please correct me if I'm wrong but it seems to me like we are using
> > "IP Command Read" approach here.  
> 
> "IP Read" is only used if data size is smaller then RX FIFO size (128 
> bytes for Vybrid).

I would like to just point out that the "legacy" (in-kernel) driver
(fsl_quadspi.c) is using AHB transfers for even small chunks of data
(even RX FIFO size).

> For bigger chunks of data "AHB Read" is used.
> 
> > 
> > If this is true - what was the rationale to use it in the new
> > driver, as in the old one the "AHB Command Read" approach was
> > recommended (i.e. faster) [1]?  
> 
> As explained above we only use "IP Read" for small chunks of data. To 
> speed up the tranfer for bigger chunks we do use "AHB Read".
> And in the future we plan to add an interface for mapping memory, so
> we can use the "AHB Read" even more efficiently.

It looks like I do read the AHB internal QUADSPI buffer before it is
filled up completely.
(I've asked the NXP community support about it,
but no reply so far https://community.nxp.com/thread/485139).

> 
> > 
> > To be even more problematic the info in link [1] states that on
> > vybrid there is a bug on the "IP Command Read" HW block and it
> > should be avoided.  
> 
> If "IP Read" should be avoided completely for Vybrid, we have to add 
> some kind of quirk.

Yes, I think so. According to the in-code comment the "IP Read" mode
shall be avoided as it has some bugs.

> 
> Thanks for you comments,
> Frieder
> 
> >   
> >>>>>>
> >>>>>> I've googled for some errata or known issues for vybryd's QSPI
> >>>>>> IP block (vf610) but without luck so far ...  
> >>>>>
> >>>>> Unfortunately I don't know the background for this comment.  
> >>>>
> >>>> The comment was added by some Freescale employee when the driver
> >>>> was added to Linux (by Huang - CC'ed).
> >>>>     
> >>>>> Is your
> >>>>> board using VF610?  
> >>>>
> >>>> Yes, it uses vf610 (A5 + M4 cores).
> >>>>     
> >>>>> Do you experience problems?  
> >>>>
> >>>> I've already observed following issue:
> >>>>
> >>>> For the current QSPI ML driver (fsl-quadspi.c - 4.19-rc3) only
> >>>> half of the AHB buffer is valid. When I do read the whole one -
> >>>> I do see read data corruption (on UBI or raw memory).
> >>>>
> >>>> This was pointed out in the patch:
> >>>> https://patchwork.ozlabs.org/patch/675401/
> >>>>
> >>>> Unfortunately, I did not found any info regarding this problem
> >>>> (in NXP's errata or other doc).
> >>>>
> >>>> I will check if this issue shows up on new patches.
> >>>>
> >>>> Thanks in advance for your help.
> >>>>     
> >>>>>
> >>>>> Regards,
> >>>>> Frieder
> >>>>>
> >>>>> ______________________________________________________
> >>>>> Linux MTD discussion mailing list
> >>>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Lukasz Majewski
> >>>>
> >>>> --
> >>>>
> >>>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >>>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194
> >>>> Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax:
> >>>> (+49)-8142-66989-80 Email: wd@denx.de  
> >>>
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Lukasz Majewski
> >>>
> >>> --
> >>>
> >>> DENX Software Engineering GmbH,      Managing Director: Wolfgang
> >>> Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> >>> Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> >>> wd@denx.de  
> >>
> >> ______________________________________________________
> >> Linux MTD discussion mailing list
> >> http://lists.infradead.org/mailman/listinfo/linux-mtd/  
> > 
> > 
> > 
> > 
> > Best regards,
> > 
> > Lukasz Majewski
> > 
> > --
> > 
> > DENX Software Engineering GmbH,      Managing Director: Wolfgang
> > Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> > Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> > wd@denx.de 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: Questions about the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Saturday, August 4, 2018 7:07 PM
> To: Han Xu <han.xu@nxp.com>
> Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>; Prabhakar
> Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On Thu, 2 Aug 2018 21:58:48 +0000
> Han Xu <han.xu@nxp.com> wrote:
> 
> > > -----Original Message-----
> > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > Sent: Thursday, August 2, 2018 8:09 AM
> > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > shawnguo@kernel.org
> > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> > > miquel.raynal@bootlin.com; broonie@kernel.org
> > > Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> > >
> > > Ping.
> > >
> > > I'm not sure if my message below went out to you at all. At least I
> > > can't find it in the ML archive.
> > >
> > > I still hope someone can help with the questions below.
> > >
> > > Meanwhile for the second point I did some tests myself with one chip
> > > on each of the two buses and it worked fine with my latest v2 patches.
> > > So I'm not sure at all why Yogesh has problems with his setup (two
> > > chips on the first bus).
> >
> > Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map
> failure.
> >
> > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
> 0x70000000-0x7fffffff]
> > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> > [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >
> > This is the reason why dynamic ioremap added in previous driver,
> > please refer to
> >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> ayan
> > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc2
> b4c6fa
> >
> 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> 2BOp8yY
> > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0
> 
> We can reduce the size of the iomap to 2k * 4, since this is all we use currently.
> Can you try to change the size of the ioremap call to 16k and tell us if it works.
> 
> Unrelated to this issue, we still have 2 questions left unanswered:
> 
> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>    something that implies a full reset + several milliseconds of delay
>    after the reset. Right now we trick the caching logic by mapping a
>    portion that is twice the size of the buffer and switching from one
>    sub-portion to this other to trigger a real read on each read
>    access, but that's hack-ish, and I'd be surprised if HW
>    engineers hadn't planned for this "manual AHB buffer flush" case.
> 

I had a discussion with the HW IP owner, they said that IP command and AHB command are two separate sets of accessing method to flash. 
Memory coherency between IP and AHB command can't be maintained by the hardware.
So after every IP data write command (write, erase, write reg) AHB RX buffer needs to be flushed.

Software Reset is the safest way to achieve this. 
Adding of the delay in several millisecond after setting of the Reset Bits is too conservative, can be tried with the reduced value.

> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>    of data while the TX request is not finished yet. In PIO mode, it
>    seems the engine sends garbage on the bus when that happens, and we
>    definitely don't want that.

For this query, they have said TX FIFO is the max limit, if data send more than TX FIFO size then it would results in un-defined behavior and there would be data corruption.

--
Regards
Yogesh Gaur.

> 
> While #1 is not blocking us, #2 is if we don't have those patches [1][2] applied,
> and Marek wanted to be sure there was no other ways to solve the "TX FIFO
> starvation" issue before considering these changes. So that'd be great if
> someone from NXP could have a look/ask around and give us answers to those 2
> questions.
> 
> Thanks,
> 
> Boris
> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=Iw
> nETfWcL%2BmDkgFPgAjn73C33a877%2BsZz37qhUdLG0I%3D&amp;reserved=0
> [2]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928678%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=thf
> I9yDC2epen9Zp18ekku%2FVLsjUIdX6EIPENBbY8xE%3D&amp;reserved=0

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: Questions about the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Saturday, August 4, 2018 7:07 PM
> To: Han Xu <han.xu@nxp.com>
> Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>; Prabhakar
> Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> miquel.raynal@bootlin.com; broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> Hi Han,
> 
> On Thu, 2 Aug 2018 21:58:48 +0000
> Han Xu <han.xu@nxp.com> wrote:
> 
> > > -----Original Message-----
> > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > Sent: Thursday, August 2, 2018 8:09 AM
> > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > shawnguo@kernel.org
> > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > computersforpeace@gmail.com; marek.vasut@gmail.com; richard@nod.at;
> > > miquel.raynal@bootlin.com; broonie@kernel.org
> > > Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> > >
> > > Ping.
> > >
> > > I'm not sure if my message below went out to you at all. At least I
> > > can't find it in the ML archive.
> > >
> > > I still hope someone can help with the questions below.
> > >
> > > Meanwhile for the second point I did some tests myself with one chip
> > > on each of the two buses and it worked fine with my latest v2 patches.
> > > So I'm not sure at all why Yogesh has problems with his setup (two
> > > chips on the first bus).
> >
> > Tried to test the v2 patch set on i.MX6SX SDB board but get the memory map
> failure.
> >
> > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for resource [mem
> 0x70000000-0x7fffffff]
> > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe failed
> > [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed with error -12
> >
> > This is the reason why dynamic ioremap added in previous driver,
> > please refer to
> >
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> >
> chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> ayan
> > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc2
> b4c6fa
> >
> 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> 2BOp8yY
> > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0
> 
> We can reduce the size of the iomap to 2k * 4, since this is all we use currently.
> Can you try to change the size of the ioremap call to 16k and tell us if it works.
> 
> Unrelated to this issue, we still have 2 questions left unanswered:
> 
> 1/ is there an easy way to invalidate AHB buffers? I mean, not
>    something that implies a full reset + several milliseconds of delay
>    after the reset. Right now we trick the caching logic by mapping a
>    portion that is twice the size of the buffer and switching from one
>    sub-portion to this other to trigger a real read on each read
>    access, but that's hack-ish, and I'd be surprised if HW
>    engineers hadn't planned for this "manual AHB buffer flush" case.
> 

I had a discussion with the HW IP owner, they said that IP command and AHB command are two separate sets of accessing method to flash. 
Memory coherency between IP and AHB command can't be maintained by the hardware.
So after every IP data write command (write, erase, write reg) AHB RX buffer needs to be flushed.

Software Reset is the safest way to achieve this. 
Adding of the delay in several millisecond after setting of the Reset Bits is too conservative, can be tried with the reduced value.

> 2/ if we use DMA, do you know what happens when the TX FIFO runs out
>    of data while the TX request is not finished yet. In PIO mode, it
>    seems the engine sends garbage on the bus when that happens, and we
>    definitely don't want that.

For this query, they have said TX FIFO is the max limit, if data send more than TX FIFO size then it would results in un-defined behavior and there would be data corruption.

--
Regards
Yogesh Gaur.

> 
> While #1 is not blocking us, #2 is if we don't have those patches [1][2] applied,
> and Marek wanted to be sure there was no other ways to solve the "TX FIFO
> starvation" issue before considering these changes. So that'd be great if
> someone from NXP could have a look/ask around and give us answers to those 2
> questions.
> 
> Thanks,
> 
> Boris
> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=Iw
> nETfWcL%2BmDkgFPgAjn73C33a877%2BsZz37qhUdLG0I%3D&amp;reserved=0
> [2]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928678%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=thf
> I9yDC2epen9Zp18ekku%2FVLsjUIdX6EIPENBbY8xE%3D&amp;reserved=0

Re: Questions about the Freescale/NXP QuadSPI controller

[Boris Brezillon]

On Thu, 6 Sep 2018 11:11:57 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:

> Hi Boris,
> 
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > Sent: Saturday, August 4, 2018 7:07 PM
> > To: Han Xu <han.xu@nxp.com>
> > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> > <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> > mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> > dwmw2@infradead.org; computersforpeace@gmail.com;
> > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> > broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> > QuadSPI controller
> > 
> > Hi Han,
> > 
> > On Thu, 2 Aug 2018 21:58:48 +0000
> > Han Xu <han.xu@nxp.com> wrote:
> >   
> > > > -----Original Message-----
> > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > > Sent: Thursday, August 2, 2018 8:09 AM
> > > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > > shawnguo@kernel.org
> > > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > > computersforpeace@gmail.com; marek.vasut@gmail.com;
> > > > richard@nod.at; miquel.raynal@bootlin.com; broonie@kernel.org
> > > > Subject: Re: Questions about the Freescale/NXP QuadSPI
> > > > controller
> > > >
> > > > Ping.
> > > >
> > > > I'm not sure if my message below went out to you at all. At
> > > > least I can't find it in the ML archive.
> > > >
> > > > I still hope someone can help with the questions below.
> > > >
> > > > Meanwhile for the second point I did some tests myself with one
> > > > chip on each of the two buses and it worked fine with my latest
> > > > v2 patches. So I'm not sure at all why Yogesh has problems with
> > > > his setup (two chips on the first bus).  
> > >
> > > Tried to test the v2 patch set on i.MX6SX SDB board but get the
> > > memory map  
> > failure.  
> > >
> > > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> > > resource [mem  
> > 0x70000000-0x7fffffff]  
> > > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe
> > > failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed
> > > with error -12
> > >
> > > This is the reason why dynamic ioremap added in previous driver,
> > > please refer to
> > >
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >  
> > chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> > ayan  
> > > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc2  
> > b4c6fa  
> > >  
> > 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> > 2BOp8yY  
> > > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0  
> > 
> > We can reduce the size of the iomap to 2k * 4, since this is all we
> > use currently. Can you try to change the size of the ioremap call
> > to 16k and tell us if it works.
> > 
> > Unrelated to this issue, we still have 2 questions left unanswered:
> > 
> > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >    something that implies a full reset + several milliseconds of
> > delay after the reset. Right now we trick the caching logic by
> > mapping a portion that is twice the size of the buffer and
> > switching from one sub-portion to this other to trigger a real read
> > on each read access, but that's hack-ish, and I'd be surprised if HW
> >    engineers hadn't planned for this "manual AHB buffer flush" case.
> >   
> 
> I had a discussion with the HW IP owner, they said that IP command
> and AHB command are two separate sets of accessing method to flash.
> Memory coherency between IP and AHB command can't be maintained by
> the hardware. So after every IP data write command (write, erase,
> write reg) AHB RX buffer needs to be flushed.
> 
> Software Reset is the safest way to achieve this. 
> Adding of the delay in several millisecond after setting of the Reset
> Bits is too conservative, can be tried with the reduced value.

Do you know exactly how many cycles/nanoseconds we should wait? Is
there a status reg that says when the block is ready to be used again?

> 
> > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> >    of data while the TX request is not finished yet. In PIO mode, it
> >    seems the engine sends garbage on the bus when that happens, and
> > we definitely don't want that.  
> 
> For this query, they have said TX FIFO is the max limit, if data send
> more than TX FIFO size then it would results in un-defined behavior
> and there would be data corruption.

Okay.
Marek, I guess we have a good reason to accept patch [1] now.

[1]http://patchwork.ozlabs.org/patch/928677/

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Questions about the Freescale/NXP QuadSPI controller

[Boris Brezillon]

On Thu, 6 Sep 2018 11:11:57 +0000
Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:

> Hi Boris,
> 
> > -----Original Message-----
> > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > Sent: Saturday, August 4, 2018 7:07 PM
> > To: Han Xu <han.xu@nxp.com>
> > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> > <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> > mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> > dwmw2@infradead.org; computersforpeace@gmail.com;
> > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> > broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> > QuadSPI controller
> > 
> > Hi Han,
> > 
> > On Thu, 2 Aug 2018 21:58:48 +0000
> > Han Xu <han.xu@nxp.com> wrote:
> >   
> > > > -----Original Message-----
> > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > > Sent: Thursday, August 2, 2018 8:09 AM
> > > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > > shawnguo@kernel.org
> > > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > > computersforpeace@gmail.com; marek.vasut@gmail.com;
> > > > richard@nod.at; miquel.raynal@bootlin.com; broonie@kernel.org
> > > > Subject: Re: Questions about the Freescale/NXP QuadSPI
> > > > controller
> > > >
> > > > Ping.
> > > >
> > > > I'm not sure if my message below went out to you at all. At
> > > > least I can't find it in the ML archive.
> > > >
> > > > I still hope someone can help with the questions below.
> > > >
> > > > Meanwhile for the second point I did some tests myself with one
> > > > chip on each of the two buses and it worked fine with my latest
> > > > v2 patches. So I'm not sure at all why Yogesh has problems with
> > > > his setup (two chips on the first bus).  
> > >
> > > Tried to test the v2 patch set on i.MX6SX SDB board but get the
> > > memory map  
> > failure.  
> > >
> > > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> > > resource [mem  
> > 0x70000000-0x7fffffff]  
> > > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe
> > > failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed
> > > with error -12
> > >
> > > This is the reason why dynamic ioremap added in previous driver,
> > > please refer to
> > >
> > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat
> > >  
> > chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> > ayan  
> > > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3bc2  
> > b4c6fa  
> > >  
> > 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> > 2BOp8yY  
> > > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0  
> > 
> > We can reduce the size of the iomap to 2k * 4, since this is all we
> > use currently. Can you try to change the size of the ioremap call
> > to 16k and tell us if it works.
> > 
> > Unrelated to this issue, we still have 2 questions left unanswered:
> > 
> > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> >    something that implies a full reset + several milliseconds of
> > delay after the reset. Right now we trick the caching logic by
> > mapping a portion that is twice the size of the buffer and
> > switching from one sub-portion to this other to trigger a real read
> > on each read access, but that's hack-ish, and I'd be surprised if HW
> >    engineers hadn't planned for this "manual AHB buffer flush" case.
> >   
> 
> I had a discussion with the HW IP owner, they said that IP command
> and AHB command are two separate sets of accessing method to flash.
> Memory coherency between IP and AHB command can't be maintained by
> the hardware. So after every IP data write command (write, erase,
> write reg) AHB RX buffer needs to be flushed.
> 
> Software Reset is the safest way to achieve this. 
> Adding of the delay in several millisecond after setting of the Reset
> Bits is too conservative, can be tried with the reduced value.

Do you know exactly how many cycles/nanoseconds we should wait? Is
there a status reg that says when the block is ready to be used again?

> 
> > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> >    of data while the TX request is not finished yet. In PIO mode, it
> >    seems the engine sends garbage on the bus when that happens, and
> > we definitely don't want that.  
> 
> For this query, they have said TX FIFO is the max limit, if data send
> more than TX FIFO size then it would results in un-defined behavior
> and there would be data corruption.

Okay.
Marek, I guess we have a good reason to accept patch [1] now.

[1]http://patchwork.ozlabs.org/patch/928677/

RE: Questions about the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Thursday, September 6, 2018 5:06 PM
> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>;
> marek.vasut@gmail.com
> Cc: Han Xu <han.xu@nxp.com>; Frieder Schrempf
> <frieder.schrempf@exceet.de>; David Wolfe <david.wolfe@nxp.com>; Fabio
> Estevam <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> On Thu, 6 Sep 2018 11:11:57 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> 
> > Hi Boris,
> >
> > > -----Original Message-----
> > > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > > Sent: Saturday, August 4, 2018 7:07 PM
> > > To: Han Xu <han.xu@nxp.com>
> > > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> > > <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> > > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur
> > > <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> > > mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> > > dwmw2@infradead.org; computersforpeace@gmail.com;
> > > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> > > broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> > > QuadSPI controller
> > >
> > > Hi Han,
> > >
> > > On Thu, 2 Aug 2018 21:58:48 +0000
> > > Han Xu <han.xu@nxp.com> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > > > Sent: Thursday, August 2, 2018 8:09 AM
> > > > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > > > shawnguo@kernel.org
> > > > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > > > computersforpeace@gmail.com; marek.vasut@gmail.com;
> > > > > richard@nod.at; miquel.raynal@bootlin.com; broonie@kernel.org
> > > > > Subject: Re: Questions about the Freescale/NXP QuadSPI
> > > > > controller
> > > > >
> > > > > Ping.
> > > > >
> > > > > I'm not sure if my message below went out to you at all. At
> > > > > least I can't find it in the ML archive.
> > > > >
> > > > > I still hope someone can help with the questions below.
> > > > >
> > > > > Meanwhile for the second point I did some tests myself with one
> > > > > chip on each of the two buses and it worked fine with my latest
> > > > > v2 patches. So I'm not sure at all why Yogesh has problems with
> > > > > his setup (two chips on the first bus).
> > > >
> > > > Tried to test the v2 patch set on i.MX6SX SDB board but get the
> > > > memory map
> > > failure.
> > > >
> > > > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> > > > resource [mem
> > > 0x70000000-0x7fffffff]
> > > > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe
> > > > failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed
> > > > with error -12
> > > >
> > > > This is the reason why dynamic ioremap added in previous driver,
> > > > please refer to
> > > >
> > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fpat
> > > >
> > >
> chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> > > ayan
> > > > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3
> bc2
> > > b4c6fa
> > > >
> > >
> 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> > > 2BOp8yY
> > > > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0
> > >
> > > We can reduce the size of the iomap to 2k * 4, since this is all we
> > > use currently. Can you try to change the size of the ioremap call to
> > > 16k and tell us if it works.
> > >
> > > Unrelated to this issue, we still have 2 questions left unanswered:
> > >
> > > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> > >    something that implies a full reset + several milliseconds of
> > > delay after the reset. Right now we trick the caching logic by
> > > mapping a portion that is twice the size of the buffer and switching
> > > from one sub-portion to this other to trigger a real read on each
> > > read access, but that's hack-ish, and I'd be surprised if HW
> > >    engineers hadn't planned for this "manual AHB buffer flush" case.
> > >
> >
> > I had a discussion with the HW IP owner, they said that IP command and
> > AHB command are two separate sets of accessing method to flash.
> > Memory coherency between IP and AHB command can't be maintained by the
> > hardware. So after every IP data write command (write, erase, write
> > reg) AHB RX buffer needs to be flushed.
> >
> > Software Reset is the safest way to achieve this.
> > Adding of the delay in several millisecond after setting of the Reset
> > Bits is too conservative, can be tried with the reduced value.
> 
> Do you know exactly how many cycles/nanoseconds we should wait? Is there a
> status reg that says when the block is ready to be used again?
> 

There is no specific cycles being mentioned in document and this was the design issue to not having these bits as w1c or any reg which provides the status.
Needs to explicitly set the RESET bits, wait for some time and then reset the RESET bit with 0.
We need to come-out with nanosecond number with the experiment.

> >
> > > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> > >    of data while the TX request is not finished yet. In PIO mode, it
> > >    seems the engine sends garbage on the bus when that happens, and
> > > we definitely don't want that.
> >
> > For this query, they have said TX FIFO is the max limit, if data send
> > more than TX FIFO size then it would results in un-defined behavior
> > and there would be data corruption.
> 
> Okay.
> Marek, I guess we have a good reason to accept patch [1] now.

Thanks

Regards
Yogesh Gaur

> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Cf8c6c7f0083c4ddf0e0708d613ecec3c%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636718305631257433&amp;sdata=3sI
> wpOn4pXDNsqfPSpJqLXKerll%2BoJ1i%2FV3WMY9cx5s%3D&amp;reserved=0

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: Questions about the Freescale/NXP QuadSPI controller

[Yogesh Narayan Gaur]

Hi Boris,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Thursday, September 6, 2018 5:06 PM
> To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com>;
> marek.vasut@gmail.com
> Cc: Han Xu <han.xu@nxp.com>; Frieder Schrempf
> <frieder.schrempf@exceet.de>; David Wolfe <david.wolfe@nxp.com>; Fabio
> Estevam <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; shawnguo@kernel.org; linux-
> mtd@lists.infradead.org; linux-spi@vger.kernel.org; dwmw2@infradead.org;
> computersforpeace@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org
> Subject: Re: Questions about the Freescale/NXP QuadSPI controller
> 
> On Thu, 6 Sep 2018 11:11:57 +0000
> Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote:
> 
> > Hi Boris,
> >
> > > -----Original Message-----
> > > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> > > Sent: Saturday, August 4, 2018 7:07 PM
> > > To: Han Xu <han.xu@nxp.com>
> > > Cc: Frieder Schrempf <frieder.schrempf@exceet.de>; David Wolfe
> > > <david.wolfe@nxp.com>; Fabio Estevam <fabio.estevam@nxp.com>;
> > > Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>; Yogesh Narayan
> Gaur
> > > <yogeshnarayan.gaur@nxp.com>; shawnguo@kernel.org; linux-
> > > mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> > > dwmw2@infradead.org; computersforpeace@gmail.com;
> > > marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> > > broonie@kernel.org Subject: Re: Questions about the Freescale/NXP
> > > QuadSPI controller
> > >
> > > Hi Han,
> > >
> > > On Thu, 2 Aug 2018 21:58:48 +0000
> > > Han Xu <han.xu@nxp.com> wrote:
> > >
> > > > > -----Original Message-----
> > > > > From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> > > > > Sent: Thursday, August 2, 2018 8:09 AM
> > > > > To: David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> > > > > <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> > > > > <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> > > > > <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> > > > > shawnguo@kernel.org
> > > > > Cc: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com;
> > > > > linux- spi@vger.kernel.org; dwmw2@infradead.org;
> > > > > computersforpeace@gmail.com; marek.vasut@gmail.com;
> > > > > richard@nod.at; miquel.raynal@bootlin.com; broonie@kernel.org
> > > > > Subject: Re: Questions about the Freescale/NXP QuadSPI
> > > > > controller
> > > > >
> > > > > Ping.
> > > > >
> > > > > I'm not sure if my message below went out to you at all. At
> > > > > least I can't find it in the ML archive.
> > > > >
> > > > > I still hope someone can help with the questions below.
> > > > >
> > > > > Meanwhile for the second point I did some tests myself with one
> > > > > chip on each of the two buses and it worked fine with my latest
> > > > > v2 patches. So I'm not sure at all why Yogesh has problems with
> > > > > his setup (two chips on the first bus).
> > > >
> > > > Tried to test the v2 patch set on i.MX6SX SDB board but get the
> > > > memory map
> > > failure.
> > > >
> > > > [    1.298633] fsl-quadspi 21e4000.qspi: ioremap failed for
> > > > resource [mem
> > > 0x70000000-0x7fffffff]
> > > > [    1.307330] fsl-quadspi 21e4000.qspi: Freescale QuadSPI probe
> > > > failed [    1.313922] fsl-quadspi: probe of 21e4000.qspi failed
> > > > with error -12
> > > >
> > > > This is the reason why dynamic ioremap added in previous driver,
> > > > please refer to
> > > >
> > > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Fpat
> > > >
> > >
> chwork.ozlabs.org%2Fpatch%2F503655%2F&amp;data=02%7C01%7Cyogeshnar
> > > ayan
> > > > .gaur%40nxp.com%7Caed89ff1b0ac4936acd408d5fa0f7303%7C686ea1d3
> bc2
> > > b4c6fa
> > > >
> > >
> 92cd99c5c301635%7C0%7C0%7C636689866643724038&amp;sdata=lZnBc0m%
> > > 2BOp8yY
> > > > JBFcNBEa2HSoNMhmJjeM9cIoGeVs0E%3D&amp;reserved=0
> > >
> > > We can reduce the size of the iomap to 2k * 4, since this is all we
> > > use currently. Can you try to change the size of the ioremap call to
> > > 16k and tell us if it works.
> > >
> > > Unrelated to this issue, we still have 2 questions left unanswered:
> > >
> > > 1/ is there an easy way to invalidate AHB buffers? I mean, not
> > >    something that implies a full reset + several milliseconds of
> > > delay after the reset. Right now we trick the caching logic by
> > > mapping a portion that is twice the size of the buffer and switching
> > > from one sub-portion to this other to trigger a real read on each
> > > read access, but that's hack-ish, and I'd be surprised if HW
> > >    engineers hadn't planned for this "manual AHB buffer flush" case.
> > >
> >
> > I had a discussion with the HW IP owner, they said that IP command and
> > AHB command are two separate sets of accessing method to flash.
> > Memory coherency between IP and AHB command can't be maintained by the
> > hardware. So after every IP data write command (write, erase, write
> > reg) AHB RX buffer needs to be flushed.
> >
> > Software Reset is the safest way to achieve this.
> > Adding of the delay in several millisecond after setting of the Reset
> > Bits is too conservative, can be tried with the reduced value.
> 
> Do you know exactly how many cycles/nanoseconds we should wait? Is there a
> status reg that says when the block is ready to be used again?
> 

There is no specific cycles being mentioned in document and this was the design issue to not having these bits as w1c or any reg which provides the status.
Needs to explicitly set the RESET bits, wait for some time and then reset the RESET bit with 0.
We need to come-out with nanosecond number with the experiment.

> >
> > > 2/ if we use DMA, do you know what happens when the TX FIFO runs out
> > >    of data while the TX request is not finished yet. In PIO mode, it
> > >    seems the engine sends garbage on the bus when that happens, and
> > > we definitely don't want that.
> >
> > For this query, they have said TX FIFO is the max limit, if data send
> > more than TX FIFO size then it would results in un-defined behavior
> > and there would be data corruption.
> 
> Okay.
> Marek, I guess we have a good reason to accept patch [1] now.

Thanks

Regards
Yogesh Gaur

> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatc
> hwork.ozlabs.org%2Fpatch%2F928677%2F&amp;data=02%7C01%7Cyogeshnara
> yan.gaur%40nxp.com%7Cf8c6c7f0083c4ddf0e0708d613ecec3c%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636718305631257433&amp;sdata=3sI
> wpOn4pXDNsqfPSpJqLXKerll%2BoJ1i%2FV3WMY9cx5s%3D&amp;reserved=0

[PATCH v2 04/12] dt-bindings: spi: Move the bindings for the FSL QSPI driver

[Frieder Schrempf]

Move the documentation of the old SPI NOR driver to the place of the new
SPI memory interface based driver.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
Changes in v2:
==============
* Split the moving and editing of the dt-bindings in two patches

 .../devicetree/bindings/mtd/fsl-quadspi.txt     | 65 --------------------
 .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 65 ++++++++++++++++++++
 2 files changed, 65 insertions(+), 65 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
deleted file mode 100644
index 483e9cf..0000000
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-* Freescale Quad Serial Peripheral Interface(QuadSPI)
-
-Required properties:
-  - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
-		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
-		 "fsl,ls1021a-qspi"
-		 or
-		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
-		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
-  - reg : the first contains the register location and length,
-          the second contains the memory mapping address and length
-  - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
-  - interrupts : Should contain the interrupt for the device
-  - clocks : The clocks needed by the QuadSPI controller
-  - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
-
-Optional properties:
-  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
-                              Each bus can be connected with two NOR flashes.
-			      Most of the time, each bus only has one NOR flash
-			      connected, this is the default case.
-			      But if there are two NOR flashes connected to the
-			      bus, you should enable this property.
-			      (Please check the board's schematic.)
-  - big-endian : That means the IP register is big endian
-
-Example:
-
-qspi0: quadspi@40044000 {
-	compatible = "fsl,vf610-qspi";
-	reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
-	reg-names = "QuadSPI", "QuadSPI-memory";
-	interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
-	clocks = <&clks VF610_CLK_QSPI0_EN>,
-		<&clks VF610_CLK_QSPI0>;
-	clock-names = "qspi_en", "qspi";
-
-	flash0: s25fl128s@0 {
-		....
-	};
-};
-
-Example showing the usage of two SPI NOR devices:
-
-&qspi2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&pinctrl_qspi2>;
-	status = "okay";
-
-	flash0: n25q256a@0 {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		compatible = "micron,n25q256a", "jedec,spi-nor";
-		spi-max-frequency = <29000000>;
-		reg = <0>;
-	};
-
-	flash1: n25q256a@1 {
-		#address-cells = <1>;
-		#size-cells = <1>;
-		compatible = "micron,n25q256a", "jedec,spi-nor";
-		spi-max-frequency = <29000000>;
-		reg = <1>;
-	};
-};
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
new file mode 100644
index 0000000..483e9cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
@@ -0,0 +1,65 @@
+* Freescale Quad Serial Peripheral Interface(QuadSPI)
+
+Required properties:
+  - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
+		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
+		 "fsl,ls1021a-qspi"
+		 or
+		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
+		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
+  - reg : the first contains the register location and length,
+          the second contains the memory mapping address and length
+  - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
+  - interrupts : Should contain the interrupt for the device
+  - clocks : The clocks needed by the QuadSPI controller
+  - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
+
+Optional properties:
+  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
+                              Each bus can be connected with two NOR flashes.
+			      Most of the time, each bus only has one NOR flash
+			      connected, this is the default case.
+			      But if there are two NOR flashes connected to the
+			      bus, you should enable this property.
+			      (Please check the board's schematic.)
+  - big-endian : That means the IP register is big endian
+
+Example:
+
+qspi0: quadspi@40044000 {
+	compatible = "fsl,vf610-qspi";
+	reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
+	reg-names = "QuadSPI", "QuadSPI-memory";
+	interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+	clocks = <&clks VF610_CLK_QSPI0_EN>,
+		<&clks VF610_CLK_QSPI0>;
+	clock-names = "qspi_en", "qspi";
+
+	flash0: s25fl128s@0 {
+		....
+	};
+};
+
+Example showing the usage of two SPI NOR devices:
+
+&qspi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_qspi2>;
+	status = "okay";
+
+	flash0: n25q256a@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "micron,n25q256a", "jedec,spi-nor";
+		spi-max-frequency = <29000000>;
+		reg = <0>;
+	};
+
+	flash1: n25q256a@1 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "micron,n25q256a", "jedec,spi-nor";
+		spi-max-frequency = <29000000>;
+		reg = <1>;
+	};
+};
-- 
2.7.4

Re: [PATCH v2 04/12] dt-bindings: spi: Move the bindings for the FSL QSPI driver

[Rob Herring]

On Thu, Jul 05, 2018 at 01:15:00PM +0200, Frieder Schrempf wrote:
> Move the documentation of the old SPI NOR driver to the place of the new
> SPI memory interface based driver.
> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
> Changes in v2:
> ==============
> * Split the moving and editing of the dt-bindings in two patches
> 
>  .../devicetree/bindings/mtd/fsl-quadspi.txt     | 65 --------------------
>  .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 65 ++++++++++++++++++++
>  2 files changed, 65 insertions(+), 65 deletions(-)

Next time, use the -M option so the move shows any real diffs.

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v2 04/12] dt-bindings: spi: Move the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 11.07.2018 17:54, Rob Herring wrote:
> On Thu, Jul 05, 2018 at 01:15:00PM +0200, Frieder Schrempf wrote:
>> Move the documentation of the old SPI NOR driver to the place of the new
>> SPI memory interface based driver.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Split the moving and editing of the dt-bindings in two patches
>>
>>   .../devicetree/bindings/mtd/fsl-quadspi.txt     | 65 --------------------
>>   .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 65 ++++++++++++++++++++
>>   2 files changed, 65 insertions(+), 65 deletions(-)
> 
> Next time, use the -M option so the move shows any real diffs.

Ok, I'll keep that in mind.

Thanks,
Frieder

> 
> Acked-by: Rob Herring <robh@kernel.org>
> 

Re: [PATCH v2 04/12] dt-bindings: spi: Move the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 11.07.2018 17:54, Rob Herring wrote:
> On Thu, Jul 05, 2018 at 01:15:00PM +0200, Frieder Schrempf wrote:
>> Move the documentation of the old SPI NOR driver to the place of the new
>> SPI memory interface based driver.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Split the moving and editing of the dt-bindings in two patches
>>
>>   .../devicetree/bindings/mtd/fsl-quadspi.txt     | 65 --------------------
>>   .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 65 ++++++++++++++++++++
>>   2 files changed, 65 insertions(+), 65 deletions(-)
> 
> Next time, use the -M option so the move shows any real diffs.

Ok, I'll keep that in mind.

Thanks,
Frieder

> 
> Acked-by: Rob Herring <robh@kernel.org>
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Frieder Schrempf]

Adjust the documentation of the new SPI memory interface based
driver to reflect the new drivers settings.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
Changes in v2:
==============
* Split the moving and editing of the dt-bindings in two patches

 .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
index 483e9cf..8b4eed7 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
@@ -3,9 +3,8 @@
 Required properties:
   - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
 		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
-		 "fsl,ls1021a-qspi"
+		 "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
 		 or
-		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
 		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
   - reg : the first contains the register location and length,
           the second contains the memory mapping address and length
@@ -15,14 +14,15 @@ Required properties:
   - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
 
 Optional properties:
-  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
-                              Each bus can be connected with two NOR flashes.
-			      Most of the time, each bus only has one NOR flash
-			      connected, this is the default case.
-			      But if there are two NOR flashes connected to the
-			      bus, you should enable this property.
-			      (Please check the board's schematic.)
-  - big-endian : That means the IP register is big endian
+  - big-endian : That means the IP registers format is big endian
+
+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:
 
@@ -40,7 +40,7 @@ qspi0: quadspi@40044000 {
 	};
 };
 
-Example showing the usage of two SPI NOR devices:
+Example showing the usage of two SPI NOR devices on bus A:
 
 &qspi2 {
 	pinctrl-names = "default";
-- 
2.7.4

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Rob Herring]

On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
> Adjust the documentation of the new SPI memory interface based
> driver to reflect the new drivers settings.

Bindings shouldn't change (other than new properties) due to driver 
changes.

> 
> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> ---
> Changes in v2:
> ==============
> * Split the moving and editing of the dt-bindings in two patches
> 
>  .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> index 483e9cf..8b4eed7 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> @@ -3,9 +3,8 @@
>  Required properties:
>    - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>  		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
> -		 "fsl,ls1021a-qspi"
> +		 "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
>  		 or
> -		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
>  		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"

So the 2080a h/w was compatible with the 1021a h/w, but now it is not? 
How did the h/w change?

>    - reg : the first contains the register location and length,
>            the second contains the memory mapping address and length
> @@ -15,14 +14,15 @@ Required properties:
>    - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
>  
>  Optional properties:
> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
> -                              Each bus can be connected with two NOR flashes.
> -			      Most of the time, each bus only has one NOR flash
> -			      connected, this is the default case.
> -			      But if there are two NOR flashes connected to the
> -			      bus, you should enable this property.
> -			      (Please check the board's schematic.)

You can't just remove properties without explanation. Why is this no 
longer needed? What about backwards compatibility with existing dtbs?

> -  - big-endian : That means the IP register is big endian
> +  - big-endian : That means the IP registers format is big endian

This is a standard property so it doesn't really need to be redefined 
here, but just reference the definition.

> +
> +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:
>  
> @@ -40,7 +40,7 @@ qspi0: quadspi@40044000 {
>  	};
>  };
>  
> -Example showing the usage of two SPI NOR devices:
> +Example showing the usage of two SPI NOR devices on bus A:
>  
>  &qspi2 {
>  	pinctrl-names = "default";
> -- 
> 2.7.4
> 

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 11.07.2018 18:05, Rob Herring wrote:
> On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
>> Adjust the documentation of the new SPI memory interface based
>> driver to reflect the new drivers settings.
> 
> Bindings shouldn't change (other than new properties) due to driver
> changes.

Right, I added an explanation below, why I think the changes are necessary.

> 
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Split the moving and editing of the dt-bindings in two patches
>>
>>   .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
>>   1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> index 483e9cf..8b4eed7 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> @@ -3,9 +3,8 @@
>>   Required properties:
>>     - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>>   		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
>> -		 "fsl,ls1021a-qspi"
>> +		 "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
>>   		 or
>> -		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
>>   		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
> 
> So the 2080a h/w was compatible with the 1021a h/w, but now it is not?
> How did the h/w change?

I guess this should be posted as a separate fix. Formerly there was only 
"fsl,ls1021a-qspi" handled in the driver and the bindings here claimed 
that "fsl,ls2080a-qspi" is compatible.

Some time ago a separate entry for "fsl,ls2080a-qspi" was added to the 
driver [1] and it adds a quirk, that is not set for "fsl,ls1021a-qspi". 
That's why I concluded, that these two are actually not compatible.

> 
>>     - reg : the first contains the register location and length,
>>             the second contains the memory mapping address and length
>> @@ -15,14 +14,15 @@ Required properties:
>>     - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
>>   
>>   Optional properties:
>> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
>> -                              Each bus can be connected with two NOR flashes.
>> -			      Most of the time, each bus only has one NOR flash
>> -			      connected, this is the default case.
>> -			      But if there are two NOR flashes connected to the
>> -			      bus, you should enable this property.
>> -			      (Please check the board's schematic.)
> 
> You can't just remove properties without explanation. Why is this no
> longer needed? What about backwards compatibility with existing dtbs?

You're right, the explanation is missing here.

The "old" driver was using this property to select one of two dual chip 
setups (two chips on one bus or two chips on separate buses). And it 
used the order in which the subnodes are defined in the dt to select the 
CS, the chip is connected to.

Both methods are wrong and in fact the "reg" property should be used to 
determine which bus and CS a chip is connected to. This also enables us 
to use different setups than just single chip, or symmetric dual chip.

So the porting of the driver from the MTD to the SPI framework actually 
enforces the use of the "reg" properties and makes 
"fsl,qspi-has-second-chip" superfluous.

As all boards that have "fsl,qspi-has-second-chip" set, also have 
correct "reg" properties, the removal of this property shouldn't lead to 
any incompatibilities.

The only compatibility issues I can see are with imx6sx-sdb.dts and 
imx6sx-sdb-reva.dts, which have their reg properties set incorrectly 
(see explanation here: [2]), all other boards should stay compatible.

> 
>> -  - big-endian : That means the IP register is big endian
>> +  - big-endian : That means the IP registers format is big endian
> 
> This is a standard property so it doesn't really need to be redefined
> here, but just reference the definition.

So I will change that to:

	big-endian : See common-properties.txt for a definition

Thanks,
Frieder

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4&id=d728a7ea9037c2df085bf9494d56e90d0ff69d7d
[2] https://patchwork.ozlabs.org/patch/922817/#1925445

> 
>> +
>> +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:
>>   
>> @@ -40,7 +40,7 @@ qspi0: quadspi@40044000 {
>>   	};
>>   };
>>   
>> -Example showing the usage of two SPI NOR devices:
>> +Example showing the usage of two SPI NOR devices on bus A:
>>   
>>   &qspi2 {
>>   	pinctrl-names = "default";
>> -- 
>> 2.7.4
>>

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 11.07.2018 18:05, Rob Herring wrote:
> On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
>> Adjust the documentation of the new SPI memory interface based
>> driver to reflect the new drivers settings.
> 
> Bindings shouldn't change (other than new properties) due to driver
> changes.

Right, I added an explanation below, why I think the changes are necessary.

> 
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>> ---
>> Changes in v2:
>> ==============
>> * Split the moving and editing of the dt-bindings in two patches
>>
>>   .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
>>   1 file changed, 11 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> index 483e9cf..8b4eed7 100644
>> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>> @@ -3,9 +3,8 @@
>>   Required properties:
>>     - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>>   		 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
>> -		 "fsl,ls1021a-qspi"
>> +		 "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
>>   		 or
>> -		 "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
>>   		 "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
> 
> So the 2080a h/w was compatible with the 1021a h/w, but now it is not?
> How did the h/w change?

I guess this should be posted as a separate fix. Formerly there was only 
"fsl,ls1021a-qspi" handled in the driver and the bindings here claimed 
that "fsl,ls2080a-qspi" is compatible.

Some time ago a separate entry for "fsl,ls2080a-qspi" was added to the 
driver [1] and it adds a quirk, that is not set for "fsl,ls1021a-qspi". 
That's why I concluded, that these two are actually not compatible.

> 
>>     - reg : the first contains the register location and length,
>>             the second contains the memory mapping address and length
>> @@ -15,14 +14,15 @@ Required properties:
>>     - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
>>   
>>   Optional properties:
>> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
>> -                              Each bus can be connected with two NOR flashes.
>> -			      Most of the time, each bus only has one NOR flash
>> -			      connected, this is the default case.
>> -			      But if there are two NOR flashes connected to the
>> -			      bus, you should enable this property.
>> -			      (Please check the board's schematic.)
> 
> You can't just remove properties without explanation. Why is this no
> longer needed? What about backwards compatibility with existing dtbs?

You're right, the explanation is missing here.

The "old" driver was using this property to select one of two dual chip 
setups (two chips on one bus or two chips on separate buses). And it 
used the order in which the subnodes are defined in the dt to select the 
CS, the chip is connected to.

Both methods are wrong and in fact the "reg" property should be used to 
determine which bus and CS a chip is connected to. This also enables us 
to use different setups than just single chip, or symmetric dual chip.

So the porting of the driver from the MTD to the SPI framework actually 
enforces the use of the "reg" properties and makes 
"fsl,qspi-has-second-chip" superfluous.

As all boards that have "fsl,qspi-has-second-chip" set, also have 
correct "reg" properties, the removal of this property shouldn't lead to 
any incompatibilities.

The only compatibility issues I can see are with imx6sx-sdb.dts and 
imx6sx-sdb-reva.dts, which have their reg properties set incorrectly 
(see explanation here: [2]), all other boards should stay compatible.

> 
>> -  - big-endian : That means the IP register is big endian
>> +  - big-endian : That means the IP registers format is big endian
> 
> This is a standard property so it doesn't really need to be redefined
> here, but just reference the definition.

So I will change that to:

	big-endian : See common-properties.txt for a definition

Thanks,
Frieder

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/spi-nor/fsl-quadspi.c?h=v4.18-rc4&id=d728a7ea9037c2df085bf9494d56e90d0ff69d7d
[2] https://patchwork.ozlabs.org/patch/922817/#1925445

> 
>> +
>> +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:
>>   
>> @@ -40,7 +40,7 @@ qspi0: quadspi@40044000 {
>>   	};
>>   };
>>   
>> -Example showing the usage of two SPI NOR devices:
>> +Example showing the usage of two SPI NOR devices on bus A:
>>   
>>   &qspi2 {
>>   	pinctrl-names = "default";
>> -- 
>> 2.7.4
>>

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Rob Herring]

On Thu, Jul 12, 2018 at 2:14 AM Frieder Schrempf
<frieder.schrempf@exceet.de> wrote:
>
> Hi Rob,
>
> On 11.07.2018 18:05, Rob Herring wrote:
> > On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
> >> Adjust the documentation of the new SPI memory interface based
> >> driver to reflect the new drivers settings.
> >
> > Bindings shouldn't change (other than new properties) due to driver
> > changes.
>
> Right, I added an explanation below, why I think the changes are necessary.
>
> >
> >>
> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
> >> ---
> >> Changes in v2:
> >> ==============
> >> * Split the moving and editing of the dt-bindings in two patches
> >>
> >>   .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
> >>   1 file changed, 11 insertions(+), 11 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> >> index 483e9cf..8b4eed7 100644
> >> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> >> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
> >> @@ -3,9 +3,8 @@
> >>   Required properties:
> >>     - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
> >>               "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
> >> -             "fsl,ls1021a-qspi"
> >> +             "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
> >>               or
> >> -             "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
> >>               "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
> >
> > So the 2080a h/w was compatible with the 1021a h/w, but now it is not?
> > How did the h/w change?
>
> I guess this should be posted as a separate fix. Formerly there was only
> "fsl,ls1021a-qspi" handled in the driver and the bindings here claimed
> that "fsl,ls2080a-qspi" is compatible.
>
> Some time ago a separate entry for "fsl,ls2080a-qspi" was added to the
> driver [1] and it adds a quirk, that is not set for "fsl,ls1021a-qspi".
> That's why I concluded, that these two are actually not compatible.

So before the driver change, the driver didn't work at all on the
ls2080a? If so, then removing is appropriate. If not, then removing
breaks all kernel versions before the change if you use a newer DT.


> >>     - reg : the first contains the register location and length,
> >>             the second contains the memory mapping address and length
> >> @@ -15,14 +14,15 @@ Required properties:
> >>     - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
> >>
> >>   Optional properties:
> >> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
> >> -                              Each bus can be connected with two NOR flashes.
> >> -                          Most of the time, each bus only has one NOR flash
> >> -                          connected, this is the default case.
> >> -                          But if there are two NOR flashes connected to the
> >> -                          bus, you should enable this property.
> >> -                          (Please check the board's schematic.)
> >
> > You can't just remove properties without explanation. Why is this no
> > longer needed? What about backwards compatibility with existing dtbs?
>
> You're right, the explanation is missing here.
>
> The "old" driver was using this property to select one of two dual chip
> setups (two chips on one bus or two chips on separate buses). And it
> used the order in which the subnodes are defined in the dt to select the
> CS, the chip is connected to.
>
> Both methods are wrong and in fact the "reg" property should be used to
> determine which bus and CS a chip is connected to. This also enables us
> to use different setups than just single chip, or symmetric dual chip.
>
> So the porting of the driver from the MTD to the SPI framework actually
> enforces the use of the "reg" properties and makes
> "fsl,qspi-has-second-chip" superfluous.
>
> As all boards that have "fsl,qspi-has-second-chip" set, also have
> correct "reg" properties, the removal of this property shouldn't lead to
> any incompatibilities.
>
> The only compatibility issues I can see are with imx6sx-sdb.dts and
> imx6sx-sdb-reva.dts, which have their reg properties set incorrectly
> (see explanation here: [2]), all other boards should stay compatible.

Add this to the commit msg.

> >> -  - big-endian : That means the IP register is big endian
> >> +  - big-endian : That means the IP registers format is big endian
> >
> > This is a standard property so it doesn't really need to be redefined
> > here, but just reference the definition.
>
> So I will change that to:
>
>         big-endian : See common-properties.txt for a definition

You can drop "for a definition"

Rob

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 12.07.2018 17:20, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 2:14 AM Frieder Schrempf
> <frieder.schrempf@exceet.de> wrote:
>>
>> Hi Rob,
>>
>> On 11.07.2018 18:05, Rob Herring wrote:
>>> On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
>>>> Adjust the documentation of the new SPI memory interface based
>>>> driver to reflect the new drivers settings.
>>>
>>> Bindings shouldn't change (other than new properties) due to driver
>>> changes.
>>
>> Right, I added an explanation below, why I think the changes are necessary.
>>
>>>
>>>>
>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>>>> ---
>>>> Changes in v2:
>>>> ==============
>>>> * Split the moving and editing of the dt-bindings in two patches
>>>>
>>>>    .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
>>>>    1 file changed, 11 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> index 483e9cf..8b4eed7 100644
>>>> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> @@ -3,9 +3,8 @@
>>>>    Required properties:
>>>>      - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>>>>                "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
>>>> -             "fsl,ls1021a-qspi"
>>>> +             "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
>>>>                or
>>>> -             "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
>>>>                "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
>>>
>>> So the 2080a h/w was compatible with the 1021a h/w, but now it is not?
>>> How did the h/w change?
>>
>> I guess this should be posted as a separate fix. Formerly there was only
>> "fsl,ls1021a-qspi" handled in the driver and the bindings here claimed
>> that "fsl,ls2080a-qspi" is compatible.
>>
>> Some time ago a separate entry for "fsl,ls2080a-qspi" was added to the
>> driver [1] and it adds a quirk, that is not set for "fsl,ls1021a-qspi".
>> That's why I concluded, that these two are actually not compatible.
> 
> So before the driver change, the driver didn't work at all on the
> ls2080a? If so, then removing is appropriate. If not, then removing
> breaks all kernel versions before the change if you use a newer DT.

Before the driver change it couldn't work fully on the ls2080a, as the 
quirk was missing. At least that's what I deduce from the driver.

> 
> 
>>>>      - reg : the first contains the register location and length,
>>>>              the second contains the memory mapping address and length
>>>> @@ -15,14 +14,15 @@ Required properties:
>>>>      - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
>>>>
>>>>    Optional properties:
>>>> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
>>>> -                              Each bus can be connected with two NOR flashes.
>>>> -                          Most of the time, each bus only has one NOR flash
>>>> -                          connected, this is the default case.
>>>> -                          But if there are two NOR flashes connected to the
>>>> -                          bus, you should enable this property.
>>>> -                          (Please check the board's schematic.)
>>>
>>> You can't just remove properties without explanation. Why is this no
>>> longer needed? What about backwards compatibility with existing dtbs?
>>
>> You're right, the explanation is missing here.
>>
>> The "old" driver was using this property to select one of two dual chip
>> setups (two chips on one bus or two chips on separate buses). And it
>> used the order in which the subnodes are defined in the dt to select the
>> CS, the chip is connected to.
>>
>> Both methods are wrong and in fact the "reg" property should be used to
>> determine which bus and CS a chip is connected to. This also enables us
>> to use different setups than just single chip, or symmetric dual chip.
>>
>> So the porting of the driver from the MTD to the SPI framework actually
>> enforces the use of the "reg" properties and makes
>> "fsl,qspi-has-second-chip" superfluous.
>>
>> As all boards that have "fsl,qspi-has-second-chip" set, also have
>> correct "reg" properties, the removal of this property shouldn't lead to
>> any incompatibilities.
>>
>> The only compatibility issues I can see are with imx6sx-sdb.dts and
>> imx6sx-sdb-reva.dts, which have their reg properties set incorrectly
>> (see explanation here: [2]), all other boards should stay compatible.
> 
> Add this to the commit msg.

Ok.

> 
>>>> -  - big-endian : That means the IP register is big endian
>>>> +  - big-endian : That means the IP registers format is big endian
>>>
>>> This is a standard property so it doesn't really need to be redefined
>>> here, but just reference the definition.
>>
>> So I will change that to:
>>
>>          big-endian : See common-properties.txt for a definition
> 
> You can drop "for a definition"

Ok.

Thanks,
Frieder

Re: [PATCH v2 05/12] dt-bindings: spi: Adjust the bindings for the FSL QSPI driver

[Frieder Schrempf]

Hi Rob,

On 12.07.2018 17:20, Rob Herring wrote:
> On Thu, Jul 12, 2018 at 2:14 AM Frieder Schrempf
> <frieder.schrempf@exceet.de> wrote:
>>
>> Hi Rob,
>>
>> On 11.07.2018 18:05, Rob Herring wrote:
>>> On Thu, Jul 05, 2018 at 01:15:01PM +0200, Frieder Schrempf wrote:
>>>> Adjust the documentation of the new SPI memory interface based
>>>> driver to reflect the new drivers settings.
>>>
>>> Bindings shouldn't change (other than new properties) due to driver
>>> changes.
>>
>> Right, I added an explanation below, why I think the changes are necessary.
>>
>>>
>>>>
>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
>>>> ---
>>>> Changes in v2:
>>>> ==============
>>>> * Split the moving and editing of the dt-bindings in two patches
>>>>
>>>>    .../devicetree/bindings/spi/spi-fsl-qspi.txt    | 22 ++++++++++----------
>>>>    1 file changed, 11 insertions(+), 11 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> index 483e9cf..8b4eed7 100644
>>>> --- a/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>>>> @@ -3,9 +3,8 @@
>>>>    Required properties:
>>>>      - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
>>>>                "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
>>>> -             "fsl,ls1021a-qspi"
>>>> +             "fsl,ls1021a-qspi", "fsl,ls2080a-qspi"
>>>>                or
>>>> -             "fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi",
>>>>                "fsl,ls1043a-qspi" followed by "fsl,ls1021a-qspi"
>>>
>>> So the 2080a h/w was compatible with the 1021a h/w, but now it is not?
>>> How did the h/w change?
>>
>> I guess this should be posted as a separate fix. Formerly there was only
>> "fsl,ls1021a-qspi" handled in the driver and the bindings here claimed
>> that "fsl,ls2080a-qspi" is compatible.
>>
>> Some time ago a separate entry for "fsl,ls2080a-qspi" was added to the
>> driver [1] and it adds a quirk, that is not set for "fsl,ls1021a-qspi".
>> That's why I concluded, that these two are actually not compatible.
> 
> So before the driver change, the driver didn't work at all on the
> ls2080a? If so, then removing is appropriate. If not, then removing
> breaks all kernel versions before the change if you use a newer DT.

Before the driver change it couldn't work fully on the ls2080a, as the 
quirk was missing. At least that's what I deduce from the driver.

> 
> 
>>>>      - reg : the first contains the register location and length,
>>>>              the second contains the memory mapping address and length
>>>> @@ -15,14 +14,15 @@ Required properties:
>>>>      - clock-names : Should contain the name of the clocks: "qspi_en" and "qspi".
>>>>
>>>>    Optional properties:
>>>> -  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
>>>> -                              Each bus can be connected with two NOR flashes.
>>>> -                          Most of the time, each bus only has one NOR flash
>>>> -                          connected, this is the default case.
>>>> -                          But if there are two NOR flashes connected to the
>>>> -                          bus, you should enable this property.
>>>> -                          (Please check the board's schematic.)
>>>
>>> You can't just remove properties without explanation. Why is this no
>>> longer needed? What about backwards compatibility with existing dtbs?
>>
>> You're right, the explanation is missing here.
>>
>> The "old" driver was using this property to select one of two dual chip
>> setups (two chips on one bus or two chips on separate buses). And it
>> used the order in which the subnodes are defined in the dt to select the
>> CS, the chip is connected to.
>>
>> Both methods are wrong and in fact the "reg" property should be used to
>> determine which bus and CS a chip is connected to. This also enables us
>> to use different setups than just single chip, or symmetric dual chip.
>>
>> So the porting of the driver from the MTD to the SPI framework actually
>> enforces the use of the "reg" properties and makes
>> "fsl,qspi-has-second-chip" superfluous.
>>
>> As all boards that have "fsl,qspi-has-second-chip" set, also have
>> correct "reg" properties, the removal of this property shouldn't lead to
>> any incompatibilities.
>>
>> The only compatibility issues I can see are with imx6sx-sdb.dts and
>> imx6sx-sdb-reva.dts, which have their reg properties set incorrectly
>> (see explanation here: [2]), all other boards should stay compatible.
> 
> Add this to the commit msg.

Ok.

> 
>>>> -  - big-endian : That means the IP register is big endian
>>>> +  - big-endian : That means the IP registers format is big endian
>>>
>>> This is a standard property so it doesn't really need to be redefined
>>> here, but just reference the definition.
>>
>> So I will change that to:
>>
>>          big-endian : See common-properties.txt for a definition
> 
> You can drop "for a definition"

Ok.

Thanks,
Frieder

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 06/12] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties

[Frieder Schrempf]

The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.

Also the properties 'bus-num', 'fsl,spi-num-chipselects' and
'fsl,spi-flash-chipselects' were never read by the driver and
can be removed.

The 'reg' properties are adjusted to reflect the what bus and
chipselect the flash is connected to, as the new driver needs
this information.

The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking ls1021a-moxa-uc-8410a.dts.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/boot/dts/imx6sx-sdb-reva.dts       | 8 ++++++--
 arch/arm/boot/dts/imx6sx-sdb.dts            | 8 ++++++--
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi     | 2 ++
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index e3533e7..1a6f680 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -131,13 +131,17 @@
 		#size-cells = <1>;
 		compatible = "spansion,s25fl128s", "jedec,spi-nor";
 		spi-max-frequency = <66000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 	};
 
-	flash1: s25fl128s@1 {
-		reg = <1>;
+	flash1: s25fl128s@2 {
+		reg = <2>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "spansion,s25fl128s", "jedec,spi-nor";
 		spi-max-frequency = <66000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 6dd9beb..9acfda8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -117,15 +117,19 @@
 		#size-cells = <1>;
 		compatible = "micron,n25q256a", "jedec,spi-nor";
 		spi-max-frequency = <29000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 
-	flash1: n25q256a@1 {
+	flash1: n25q256a@2 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "micron,n25q256a", "jedec,spi-nor";
 		spi-max-frequency = <29000000>;
-		reg = <1>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
+		reg = <2>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 32a0723..c2c9a2a 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -176,6 +176,8 @@
 		#size-cells = <1>;
 		compatible = "micron,n25q256a";
 		spi-max-frequency = <29000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index d01f64b..6a83f30 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,9 +203,6 @@
 };
 
 &qspi {
-	bus-num = <0>;
-	fsl,spi-num-chipselects = <2>;
-	fsl,spi-flash-chipselects = <0>;
 	fsl,qspi-has-second-chip;
 	status = "okay";
 
@@ -214,6 +211,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 
 		partitions@0 {
-- 
2.7.4

[PATCH v2 06/12] ARM: dts: Reflect change of FSL QSPI driver and remove unused properties

[Frieder Schrempf]

The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.

Also the properties 'bus-num', 'fsl,spi-num-chipselects' and
'fsl,spi-flash-chipselects' were never read by the driver and
can be removed.

The 'reg' properties are adjusted to reflect the what bus and
chipselect the flash is connected to, as the new driver needs
this information.

The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking ls1021a-moxa-uc-8410a.dts.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/boot/dts/imx6sx-sdb-reva.dts       | 8 ++++++--
 arch/arm/boot/dts/imx6sx-sdb.dts            | 8 ++++++--
 arch/arm/boot/dts/imx6ul-14x14-evk.dtsi     | 2 ++
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 5 ++---
 4 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/imx6sx-sdb-reva.dts b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
index e3533e7..1a6f680 100644
--- a/arch/arm/boot/dts/imx6sx-sdb-reva.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb-reva.dts
@@ -131,13 +131,17 @@
 		#size-cells = <1>;
 		compatible = "spansion,s25fl128s", "jedec,spi-nor";
 		spi-max-frequency = <66000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 	};
 
-	flash1: s25fl128s at 1 {
-		reg = <1>;
+	flash1: s25fl128s at 2 {
+		reg = <2>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "spansion,s25fl128s", "jedec,spi-nor";
 		spi-max-frequency = <66000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 	};
 };
diff --git a/arch/arm/boot/dts/imx6sx-sdb.dts b/arch/arm/boot/dts/imx6sx-sdb.dts
index 6dd9beb..9acfda8 100644
--- a/arch/arm/boot/dts/imx6sx-sdb.dts
+++ b/arch/arm/boot/dts/imx6sx-sdb.dts
@@ -117,15 +117,19 @@
 		#size-cells = <1>;
 		compatible = "micron,n25q256a", "jedec,spi-nor";
 		spi-max-frequency = <29000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 
-	flash1: n25q256a at 1 {
+	flash1: n25q256a at 2 {
 		#address-cells = <1>;
 		#size-cells = <1>;
 		compatible = "micron,n25q256a", "jedec,spi-nor";
 		spi-max-frequency = <29000000>;
-		reg = <1>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
+		reg = <2>;
 	};
 };
 
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
index 32a0723..c2c9a2a 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dtsi
@@ -176,6 +176,8 @@
 		#size-cells = <1>;
 		compatible = "micron,n25q256a";
 		spi-max-frequency = <29000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index d01f64b..6a83f30 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,9 +203,6 @@
 };
 
 &qspi {
-	bus-num = <0>;
-	fsl,spi-num-chipselects = <2>;
-	fsl,spi-flash-chipselects = <0>;
 	fsl,qspi-has-second-chip;
 	status = "okay";
 
@@ -214,6 +211,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 
 		partitions at 0 {
-- 
2.7.4

[PATCH v2 07/12] arm64: dts: Reflect change of FSL QSPI driver and remove unused properties

[Frieder Schrempf]

The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.

Also the properties 'num-cs' and 'bus-num' were never read by the
driver and can be removed.

The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking fsl-ls1046a-rdb.dts.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  | 3 ++-
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  | 4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  | 6 ++++--
 arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 6341281..31e7b31 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -170,7 +170,6 @@
 };
 
 &qspi {
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fl128s@0 {
@@ -178,6 +177,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 434383b..dc10105 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -198,8 +198,6 @@
 };
 
 &qspi {
-	num-cs = <2>;
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fl128s@0 {
@@ -207,6 +205,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 5dc2782..1848c33 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -136,8 +136,6 @@
 };
 
 &qspi {
-	num-cs = <2>;
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fs512s@0 {
@@ -145,6 +143,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 
@@ -153,6 +153,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <1>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index 1de6188..fc62ed9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -170,6 +170,8 @@
 		#size-cells = <1>;
 		compatible = "st,m25p80";
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 	flash2: s25fl256s1@2 {
@@ -177,6 +179,8 @@
 		#size-cells = <1>;
 		compatible = "st,m25p80";
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <2>;
 	};
 };
-- 
2.7.4

[PATCH v2 07/12] arm64: dts: Reflect change of FSL QSPI driver and remove unused properties

[Frieder Schrempf]

The FSL QSPI driver was moved to the SPI framework and it now
acts as a SPI controller. Therefore the subnodes need to set
spi-[rx/tx]-bus-width = <4>, so quad mode is used just as before.

Also the properties 'num-cs' and 'bus-num' were never read by the
driver and can be removed.

The property 'fsl,qspi-has-second-chip' is not needed anymore
and will be removed after the old driver was disabled to avoid
breaking fsl-ls1046a-rdb.dts.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts  | 3 ++-
 arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts  | 4 ++--
 arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts  | 6 ++++--
 arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi | 4 ++++
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
index 6341281..31e7b31 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a-qds.dts
@@ -170,7 +170,6 @@
 };
 
 &qspi {
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fl128s at 0 {
@@ -178,6 +177,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
index 434383b..dc10105 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-qds.dts
@@ -198,8 +198,6 @@
 };
 
 &qspi {
-	num-cs = <2>;
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fl128s at 0 {
@@ -207,6 +205,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
index 5dc2782..1848c33 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb.dts
@@ -136,8 +136,6 @@
 };
 
 &qspi {
-	num-cs = <2>;
-	bus-num = <0>;
 	status = "okay";
 
 	qflash0: s25fs512s at 0 {
@@ -145,6 +143,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 
@@ -153,6 +153,8 @@
 		#address-cells = <1>;
 		#size-cells = <1>;
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <1>;
 	};
 };
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
index 1de6188..fc62ed9 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa-qds.dtsi
@@ -170,6 +170,8 @@
 		#size-cells = <1>;
 		compatible = "st,m25p80";
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <0>;
 	};
 	flash2: s25fl256s1 at 2 {
@@ -177,6 +179,8 @@
 		#size-cells = <1>;
 		compatible = "st,m25p80";
 		spi-max-frequency = <20000000>;
+		spi-rx-bus-width = <4>;
+		spi-tx-bus-width = <4>;
 		reg = <2>;
 	};
 };
-- 
2.7.4

[PATCH v2 08/12] ARM: defconfig: Use the new FSL QSPI driver under the SPI framework

[Frieder Schrempf]

The new driver at spi/spi-fsl-qspi.c replaces the old SPI NOR driver
at mtd/fsl-quadspi.c. Switch to the new driver in the defconfigs.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 +-
 arch/arm/configs/multi_v7_defconfig  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507a..d07a535 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -111,7 +111,6 @@ CONFIG_MTD_NAND_GPMI_NAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_MXC=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_MTD_UBI_BLOCK=y
@@ -199,6 +198,7 @@ CONFIG_I2C_ALGOPCA=m
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_IMX=y
 CONFIG_SPI=y
+CONFIG_SPI_FSL_QSPI=y
 CONFIG_SPI_GPIO=y
 CONFIG_SPI_IMX=y
 CONFIG_SPI_FSL_DSPI=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8f6be19..da4db3b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -189,7 +189,6 @@ CONFIG_MTD_NAND_BRCMNAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=m
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
@@ -377,6 +376,7 @@ CONFIG_SPI_BCM2835=y
 CONFIG_SPI_BCM2835AUX=y
 CONFIG_SPI_CADENCE=y
 CONFIG_SPI_DAVINCI=y
+CONFIG_SPI_FSL_QSPI=m
 CONFIG_SPI_GPIO=m
 CONFIG_SPI_FSL_DSPI=m
 CONFIG_SPI_OMAP24XX=y
-- 
2.7.4

[PATCH v2 08/12] ARM: defconfig: Use the new FSL QSPI driver under the SPI framework

[Frieder Schrempf]

The new driver at spi/spi-fsl-qspi.c replaces the old SPI NOR driver
at mtd/fsl-quadspi.c. Switch to the new driver in the defconfigs.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 +-
 arch/arm/configs/multi_v7_defconfig  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507a..d07a535 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -111,7 +111,6 @@ CONFIG_MTD_NAND_GPMI_NAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_MXC=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_MTD_UBI_BLOCK=y
@@ -199,6 +198,7 @@ CONFIG_I2C_ALGOPCA=m
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_IMX=y
 CONFIG_SPI=y
+CONFIG_SPI_FSL_QSPI=y
 CONFIG_SPI_GPIO=y
 CONFIG_SPI_IMX=y
 CONFIG_SPI_FSL_DSPI=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8f6be19..da4db3b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -189,7 +189,6 @@ CONFIG_MTD_NAND_BRCMNAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=m
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
@@ -377,6 +376,7 @@ CONFIG_SPI_BCM2835=y
 CONFIG_SPI_BCM2835AUX=y
 CONFIG_SPI_CADENCE=y
 CONFIG_SPI_DAVINCI=y
+CONFIG_SPI_FSL_QSPI=m
 CONFIG_SPI_GPIO=m
 CONFIG_SPI_FSL_DSPI=m
 CONFIG_SPI_OMAP24XX=y
-- 
2.7.4

[PATCH v2 08/12] ARM: defconfig: Use the new FSL QSPI driver under the SPI framework

[Frieder Schrempf]

The new driver at spi/spi-fsl-qspi.c replaces the old SPI NOR driver
at mtd/fsl-quadspi.c. Switch to the new driver in the defconfigs.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 +-
 arch/arm/configs/multi_v7_defconfig  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507a..d07a535 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -111,7 +111,6 @@ CONFIG_MTD_NAND_GPMI_NAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_MXC=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_MTD_UBI_BLOCK=y
@@ -199,6 +198,7 @@ CONFIG_I2C_ALGOPCA=m
 CONFIG_I2C_GPIO=y
 CONFIG_I2C_IMX=y
 CONFIG_SPI=y
+CONFIG_SPI_FSL_QSPI=y
 CONFIG_SPI_GPIO=y
 CONFIG_SPI_IMX=y
 CONFIG_SPI_FSL_DSPI=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 8f6be19..da4db3b 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -189,7 +189,6 @@ CONFIG_MTD_NAND_BRCMNAND=y
 CONFIG_MTD_NAND_VF610_NFC=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
-CONFIG_SPI_FSL_QUADSPI=m
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_RAM=y
@@ -377,6 +376,7 @@ CONFIG_SPI_BCM2835=y
 CONFIG_SPI_BCM2835AUX=y
 CONFIG_SPI_CADENCE=y
 CONFIG_SPI_DAVINCI=y
+CONFIG_SPI_FSL_QSPI=m
 CONFIG_SPI_GPIO=m
 CONFIG_SPI_FSL_DSPI=m
 CONFIG_SPI_OMAP24XX=y
-- 
2.7.4

[PATCH v2 09/12] mtd: fsl-quadspi: Remove the driver as it was replaced by spi-fsl-qspi.c

[Frieder Schrempf]

There's a new driver using the SPI memory interface of the SPI framework
at spi/spi-fsl-qspi.c, which can be used together with m25p80.c to
replace the functionality of this SPI NOR driver.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 drivers/mtd/spi-nor/Kconfig       |    9 -
 drivers/mtd/spi-nor/Makefile      |    1 -
 drivers/mtd/spi-nor/fsl-quadspi.c | 1217 --------------------------------
 3 files changed, 1227 deletions(-)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 6cc9c92..d1ca307 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -59,15 +59,6 @@ config SPI_CADENCE_QUADSPI
 	  device with a Cadence QSPI controller and want to access the
 	  Flash as an MTD device.
 
-config SPI_FSL_QUADSPI
-	tristate "Freescale Quad SPI controller"
-	depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
-	depends on HAS_IOMEM
-	help
-	  This enables support for the Quad SPI controller in master mode.
-	  This controller does not support generic SPI. It only supports
-	  SPI NOR.
-
 config SPI_HISI_SFC
 	tristate "Hisilicon SPI-NOR Flash Controller(SFC)"
 	depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index f4c61d2..3f160c2e3 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -3,7 +3,6 @@ obj-$(CONFIG_MTD_SPI_NOR)	+= spi-nor.o
 obj-$(CONFIG_SPI_ASPEED_SMC)	+= aspeed-smc.o
 obj-$(CONFIG_SPI_ATMEL_QUADSPI)	+= atmel-quadspi.o
 obj-$(CONFIG_SPI_CADENCE_QUADSPI)	+= cadence-quadspi.o
-obj-$(CONFIG_SPI_FSL_QUADSPI)	+= fsl-quadspi.o
 obj-$(CONFIG_SPI_HISI_SFC)	+= hisi-sfc.o
 obj-$(CONFIG_MTD_MT81xx_NOR)    += mtk-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)	+= nxp-spifi.o
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c b/drivers/mtd/spi-nor/fsl-quadspi.c
deleted file mode 100644
index 7d9620c..0000000
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ /dev/null
@@ -1,1217 +0,0 @@
-/*
- * Freescale QuadSPI driver.
- *
- * Copyright (C) 2013 Freescale Semiconductor, Inc.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/interrupt.h>
-#include <linux/errno.h>
-#include <linux/platform_device.h>
-#include <linux/sched.h>
-#include <linux/delay.h>
-#include <linux/io.h>
-#include <linux/clk.h>
-#include <linux/err.h>
-#include <linux/of.h>
-#include <linux/of_device.h>
-#include <linux/timer.h>
-#include <linux/jiffies.h>
-#include <linux/completion.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/partitions.h>
-#include <linux/mtd/spi-nor.h>
-#include <linux/mutex.h>
-#include <linux/pm_qos.h>
-#include <linux/sizes.h>
-
-/* Controller needs driver to swap endian */
-#define QUADSPI_QUIRK_SWAP_ENDIAN	(1 << 0)
-/* Controller needs 4x internal clock */
-#define QUADSPI_QUIRK_4X_INT_CLK	(1 << 1)
-/*
- * TKT253890, Controller needs driver to fill txfifo till 16 byte to
- * trigger data transfer even though extern data will not transferred.
- */
-#define QUADSPI_QUIRK_TKT253890		(1 << 2)
-/* Controller cannot wake up from wait mode, TKT245618 */
-#define QUADSPI_QUIRK_TKT245618         (1 << 3)
-
-/* The registers */
-#define QUADSPI_MCR			0x00
-#define QUADSPI_MCR_RESERVED_SHIFT	16
-#define QUADSPI_MCR_RESERVED_MASK	(0xF << QUADSPI_MCR_RESERVED_SHIFT)
-#define QUADSPI_MCR_MDIS_SHIFT		14
-#define QUADSPI_MCR_MDIS_MASK		(1 << QUADSPI_MCR_MDIS_SHIFT)
-#define QUADSPI_MCR_CLR_TXF_SHIFT	11
-#define QUADSPI_MCR_CLR_TXF_MASK	(1 << QUADSPI_MCR_CLR_TXF_SHIFT)
-#define QUADSPI_MCR_CLR_RXF_SHIFT	10
-#define QUADSPI_MCR_CLR_RXF_MASK	(1 << QUADSPI_MCR_CLR_RXF_SHIFT)
-#define QUADSPI_MCR_DDR_EN_SHIFT	7
-#define QUADSPI_MCR_DDR_EN_MASK		(1 << QUADSPI_MCR_DDR_EN_SHIFT)
-#define QUADSPI_MCR_END_CFG_SHIFT	2
-#define QUADSPI_MCR_END_CFG_MASK	(3 << QUADSPI_MCR_END_CFG_SHIFT)
-#define QUADSPI_MCR_SWRSTHD_SHIFT	1
-#define QUADSPI_MCR_SWRSTHD_MASK	(1 << QUADSPI_MCR_SWRSTHD_SHIFT)
-#define QUADSPI_MCR_SWRSTSD_SHIFT	0
-#define QUADSPI_MCR_SWRSTSD_MASK	(1 << QUADSPI_MCR_SWRSTSD_SHIFT)
-
-#define QUADSPI_IPCR			0x08
-#define QUADSPI_IPCR_SEQID_SHIFT	24
-#define QUADSPI_IPCR_SEQID_MASK		(0xF << QUADSPI_IPCR_SEQID_SHIFT)
-
-#define QUADSPI_BUF0CR			0x10
-#define QUADSPI_BUF1CR			0x14
-#define QUADSPI_BUF2CR			0x18
-#define QUADSPI_BUFXCR_INVALID_MSTRID	0xe
-
-#define QUADSPI_BUF3CR			0x1c
-#define QUADSPI_BUF3CR_ALLMST_SHIFT	31
-#define QUADSPI_BUF3CR_ALLMST_MASK	(1 << QUADSPI_BUF3CR_ALLMST_SHIFT)
-#define QUADSPI_BUF3CR_ADATSZ_SHIFT		8
-#define QUADSPI_BUF3CR_ADATSZ_MASK	(0xFF << QUADSPI_BUF3CR_ADATSZ_SHIFT)
-
-#define QUADSPI_BFGENCR			0x20
-#define QUADSPI_BFGENCR_PAR_EN_SHIFT	16
-#define QUADSPI_BFGENCR_PAR_EN_MASK	(1 << (QUADSPI_BFGENCR_PAR_EN_SHIFT))
-#define QUADSPI_BFGENCR_SEQID_SHIFT	12
-#define QUADSPI_BFGENCR_SEQID_MASK	(0xF << QUADSPI_BFGENCR_SEQID_SHIFT)
-
-#define QUADSPI_BUF0IND			0x30
-#define QUADSPI_BUF1IND			0x34
-#define QUADSPI_BUF2IND			0x38
-#define QUADSPI_SFAR			0x100
-
-#define QUADSPI_SMPR			0x108
-#define QUADSPI_SMPR_DDRSMP_SHIFT	16
-#define QUADSPI_SMPR_DDRSMP_MASK	(7 << QUADSPI_SMPR_DDRSMP_SHIFT)
-#define QUADSPI_SMPR_FSDLY_SHIFT	6
-#define QUADSPI_SMPR_FSDLY_MASK		(1 << QUADSPI_SMPR_FSDLY_SHIFT)
-#define QUADSPI_SMPR_FSPHS_SHIFT	5
-#define QUADSPI_SMPR_FSPHS_MASK		(1 << QUADSPI_SMPR_FSPHS_SHIFT)
-#define QUADSPI_SMPR_HSENA_SHIFT	0
-#define QUADSPI_SMPR_HSENA_MASK		(1 << QUADSPI_SMPR_HSENA_SHIFT)
-
-#define QUADSPI_RBSR			0x10c
-#define QUADSPI_RBSR_RDBFL_SHIFT	8
-#define QUADSPI_RBSR_RDBFL_MASK		(0x3F << QUADSPI_RBSR_RDBFL_SHIFT)
-
-#define QUADSPI_RBCT			0x110
-#define QUADSPI_RBCT_WMRK_MASK		0x1F
-#define QUADSPI_RBCT_RXBRD_SHIFT	8
-#define QUADSPI_RBCT_RXBRD_USEIPS	(0x1 << QUADSPI_RBCT_RXBRD_SHIFT)
-
-#define QUADSPI_TBSR			0x150
-#define QUADSPI_TBDR			0x154
-#define QUADSPI_SR			0x15c
-#define QUADSPI_SR_IP_ACC_SHIFT		1
-#define QUADSPI_SR_IP_ACC_MASK		(0x1 << QUADSPI_SR_IP_ACC_SHIFT)
-#define QUADSPI_SR_AHB_ACC_SHIFT	2
-#define QUADSPI_SR_AHB_ACC_MASK		(0x1 << QUADSPI_SR_AHB_ACC_SHIFT)
-
-#define QUADSPI_FR			0x160
-#define QUADSPI_FR_TFF_MASK		0x1
-
-#define QUADSPI_SFA1AD			0x180
-#define QUADSPI_SFA2AD			0x184
-#define QUADSPI_SFB1AD			0x188
-#define QUADSPI_SFB2AD			0x18c
-#define QUADSPI_RBDR			0x200
-
-#define QUADSPI_LUTKEY			0x300
-#define QUADSPI_LUTKEY_VALUE		0x5AF05AF0
-
-#define QUADSPI_LCKCR			0x304
-#define QUADSPI_LCKER_LOCK		0x1
-#define QUADSPI_LCKER_UNLOCK		0x2
-
-#define QUADSPI_RSER			0x164
-#define QUADSPI_RSER_TFIE		(0x1 << 0)
-
-#define QUADSPI_LUT_BASE		0x310
-
-/*
- * The definition of the LUT register shows below:
- *
- *  ---------------------------------------------------
- *  | INSTR1 | PAD1 | OPRND1 | INSTR0 | PAD0 | OPRND0 |
- *  ---------------------------------------------------
- */
-#define OPRND0_SHIFT		0
-#define PAD0_SHIFT		8
-#define INSTR0_SHIFT		10
-#define OPRND1_SHIFT		16
-
-/* Instruction set for the LUT register. */
-#define LUT_STOP		0
-#define LUT_CMD			1
-#define LUT_ADDR		2
-#define LUT_DUMMY		3
-#define LUT_MODE		4
-#define LUT_MODE2		5
-#define LUT_MODE4		6
-#define LUT_FSL_READ		7
-#define LUT_FSL_WRITE		8
-#define LUT_JMP_ON_CS		9
-#define LUT_ADDR_DDR		10
-#define LUT_MODE_DDR		11
-#define LUT_MODE2_DDR		12
-#define LUT_MODE4_DDR		13
-#define LUT_FSL_READ_DDR		14
-#define LUT_FSL_WRITE_DDR		15
-#define LUT_DATA_LEARN		16
-
-/*
- * The PAD definitions for LUT register.
- *
- * The pad stands for the lines number of IO[0:3].
- * For example, the Quad read need four IO lines, so you should
- * set LUT_PAD4 which means we use four IO lines.
- */
-#define LUT_PAD1		0
-#define LUT_PAD2		1
-#define LUT_PAD4		2
-
-/* Oprands for the LUT register. */
-#define ADDR24BIT		0x18
-#define ADDR32BIT		0x20
-
-/* Macros for constructing the LUT register. */
-#define LUT0(ins, pad, opr)						\
-		(((opr) << OPRND0_SHIFT) | ((LUT_##pad) << PAD0_SHIFT) | \
-		((LUT_##ins) << INSTR0_SHIFT))
-
-#define LUT1(ins, pad, opr)	(LUT0(ins, pad, opr) << OPRND1_SHIFT)
-
-/* other macros for LUT register. */
-#define QUADSPI_LUT(x)          (QUADSPI_LUT_BASE + (x) * 4)
-#define QUADSPI_LUT_NUM		64
-
-/* SEQID -- we can have 16 seqids at most. */
-#define SEQID_READ		0
-#define SEQID_WREN		1
-#define SEQID_WRDI		2
-#define SEQID_RDSR		3
-#define SEQID_SE		4
-#define SEQID_CHIP_ERASE	5
-#define SEQID_PP		6
-#define SEQID_RDID		7
-#define SEQID_WRSR		8
-#define SEQID_RDCR		9
-#define SEQID_EN4B		10
-#define SEQID_BRWR		11
-
-#define QUADSPI_MIN_IOMAP SZ_4M
-
-enum fsl_qspi_devtype {
-	FSL_QUADSPI_VYBRID,
-	FSL_QUADSPI_IMX6SX,
-	FSL_QUADSPI_IMX7D,
-	FSL_QUADSPI_IMX6UL,
-	FSL_QUADSPI_LS1021A,
-	FSL_QUADSPI_LS2080A,
-};
-
-struct fsl_qspi_devtype_data {
-	enum fsl_qspi_devtype devtype;
-	int rxfifo;
-	int txfifo;
-	int ahb_buf_size;
-	int driver_data;
-};
-
-static const struct fsl_qspi_devtype_data vybrid_data = {
-	.devtype = FSL_QUADSPI_VYBRID,
-	.rxfifo = 128,
-	.txfifo = 64,
-	.ahb_buf_size = 1024,
-	.driver_data = QUADSPI_QUIRK_SWAP_ENDIAN,
-};
-
-static const struct fsl_qspi_devtype_data imx6sx_data = {
-	.devtype = FSL_QUADSPI_IMX6SX,
-	.rxfifo = 128,
-	.txfifo = 512,
-	.ahb_buf_size = 1024,
-	.driver_data = QUADSPI_QUIRK_4X_INT_CLK
-		       | QUADSPI_QUIRK_TKT245618,
-};
-
-static const struct fsl_qspi_devtype_data imx7d_data = {
-	.devtype = FSL_QUADSPI_IMX7D,
-	.rxfifo = 512,
-	.txfifo = 512,
-	.ahb_buf_size = 1024,
-	.driver_data = QUADSPI_QUIRK_TKT253890
-		       | QUADSPI_QUIRK_4X_INT_CLK,
-};
-
-static const struct fsl_qspi_devtype_data imx6ul_data = {
-	.devtype = FSL_QUADSPI_IMX6UL,
-	.rxfifo = 128,
-	.txfifo = 512,
-	.ahb_buf_size = 1024,
-	.driver_data = QUADSPI_QUIRK_TKT253890
-		       | QUADSPI_QUIRK_4X_INT_CLK,
-};
-
-static struct fsl_qspi_devtype_data ls1021a_data = {
-	.devtype = FSL_QUADSPI_LS1021A,
-	.rxfifo = 128,
-	.txfifo = 64,
-	.ahb_buf_size = 1024,
-	.driver_data = 0,
-};
-
-static const struct fsl_qspi_devtype_data ls2080a_data = {
-	.devtype = FSL_QUADSPI_LS2080A,
-	.rxfifo = 128,
-	.txfifo = 64,
-	.ahb_buf_size = 1024,
-	.driver_data = QUADSPI_QUIRK_TKT253890,
-};
-
-
-#define FSL_QSPI_MAX_CHIP	4
-struct fsl_qspi {
-	struct spi_nor nor[FSL_QSPI_MAX_CHIP];
-	void __iomem *iobase;
-	void __iomem *ahb_addr;
-	u32 memmap_phy;
-	u32 memmap_offs;
-	u32 memmap_len;
-	struct clk *clk, *clk_en;
-	struct device *dev;
-	struct completion c;
-	const struct fsl_qspi_devtype_data *devtype_data;
-	u32 nor_size;
-	u32 nor_num;
-	u32 clk_rate;
-	unsigned int chip_base_addr; /* We may support two chips. */
-	bool has_second_chip;
-	bool big_endian;
-	struct mutex lock;
-	struct pm_qos_request pm_qos_req;
-};
-
-static inline int needs_swap_endian(struct fsl_qspi *q)
-{
-	return q->devtype_data->driver_data & QUADSPI_QUIRK_SWAP_ENDIAN;
-}
-
-static inline int needs_4x_clock(struct fsl_qspi *q)
-{
-	return q->devtype_data->driver_data & QUADSPI_QUIRK_4X_INT_CLK;
-}
-
-static inline int needs_fill_txfifo(struct fsl_qspi *q)
-{
-	return q->devtype_data->driver_data & QUADSPI_QUIRK_TKT253890;
-}
-
-static inline int needs_wakeup_wait_mode(struct fsl_qspi *q)
-{
-	return q->devtype_data->driver_data & QUADSPI_QUIRK_TKT245618;
-}
-
-/*
- * R/W functions for big- or little-endian registers:
- * The qSPI controller's endian is independent of the CPU core's endian.
- * So far, although the CPU core is little-endian but the qSPI have two
- * versions for big-endian and little-endian.
- */
-static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
-{
-	if (q->big_endian)
-		iowrite32be(val, addr);
-	else
-		iowrite32(val, addr);
-}
-
-static u32 qspi_readl(struct fsl_qspi *q, void __iomem *addr)
-{
-	if (q->big_endian)
-		return ioread32be(addr);
-	else
-		return ioread32(addr);
-}
-
-/*
- * An IC bug makes us to re-arrange the 32-bit data.
- * The following chips, such as IMX6SLX, have fixed this bug.
- */
-static inline u32 fsl_qspi_endian_xchg(struct fsl_qspi *q, u32 a)
-{
-	return needs_swap_endian(q) ? __swab32(a) : a;
-}
-
-static inline void fsl_qspi_unlock_lut(struct fsl_qspi *q)
-{
-	qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-	qspi_writel(q, QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
-}
-
-static inline void fsl_qspi_lock_lut(struct fsl_qspi *q)
-{
-	qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-	qspi_writel(q, QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
-}
-
-static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
-{
-	struct fsl_qspi *q = dev_id;
-	u32 reg;
-
-	/* clear interrupt */
-	reg = qspi_readl(q, q->iobase + QUADSPI_FR);
-	qspi_writel(q, reg, q->iobase + QUADSPI_FR);
-
-	if (reg & QUADSPI_FR_TFF_MASK)
-		complete(&q->c);
-
-	dev_dbg(q->dev, "QUADSPI_FR : 0x%.8x:0x%.8x\n", q->chip_base_addr, reg);
-	return IRQ_HANDLED;
-}
-
-static void fsl_qspi_init_lut(struct fsl_qspi *q)
-{
-	void __iomem *base = q->iobase;
-	int rxfifo = q->devtype_data->rxfifo;
-	u32 lut_base;
-	int i;
-
-	struct spi_nor *nor = &q->nor[0];
-	u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
-	u8 read_op = nor->read_opcode;
-	u8 read_dm = nor->read_dummy;
-
-	fsl_qspi_unlock_lut(q);
-
-	/* Clear all the LUT table */
-	for (i = 0; i < QUADSPI_LUT_NUM; i++)
-		qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
-
-	/* Read */
-	lut_base = SEQID_READ * 4;
-
-	qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
-			base + QUADSPI_LUT(lut_base));
-	qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
-		    LUT1(FSL_READ, PAD4, rxfifo),
-			base + QUADSPI_LUT(lut_base + 1));
-
-	/* Write enable */
-	lut_base = SEQID_WREN * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WREN),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Page Program */
-	lut_base = SEQID_PP * 4;
-
-	qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
-		    LUT1(ADDR, PAD1, addrlen),
-			base + QUADSPI_LUT(lut_base));
-	qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
-			base + QUADSPI_LUT(lut_base + 1));
-
-	/* Read Status */
-	lut_base = SEQID_RDSR * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDSR) |
-			LUT1(FSL_READ, PAD1, 0x1),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Erase a sector */
-	lut_base = SEQID_SE * 4;
-
-	qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
-		    LUT1(ADDR, PAD1, addrlen),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Erase the whole chip */
-	lut_base = SEQID_CHIP_ERASE * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_CHIP_ERASE),
-			base + QUADSPI_LUT(lut_base));
-
-	/* READ ID */
-	lut_base = SEQID_RDID * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDID) |
-			LUT1(FSL_READ, PAD1, 0x8),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Write Register */
-	lut_base = SEQID_WRSR * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WRSR) |
-			LUT1(FSL_WRITE, PAD1, 0x2),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Read Configuration Register */
-	lut_base = SEQID_RDCR * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDCR) |
-			LUT1(FSL_READ, PAD1, 0x1),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Write disable */
-	lut_base = SEQID_WRDI * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WRDI),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Enter 4 Byte Mode (Micron) */
-	lut_base = SEQID_EN4B * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_EN4B),
-			base + QUADSPI_LUT(lut_base));
-
-	/* Enter 4 Byte Mode (Spansion) */
-	lut_base = SEQID_BRWR * 4;
-	qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_BRWR),
-			base + QUADSPI_LUT(lut_base));
-
-	fsl_qspi_lock_lut(q);
-}
-
-/* Get the SEQID for the command */
-static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd)
-{
-	switch (cmd) {
-	case SPINOR_OP_READ_1_1_4:
-		return SEQID_READ;
-	case SPINOR_OP_WREN:
-		return SEQID_WREN;
-	case SPINOR_OP_WRDI:
-		return SEQID_WRDI;
-	case SPINOR_OP_RDSR:
-		return SEQID_RDSR;
-	case SPINOR_OP_SE:
-		return SEQID_SE;
-	case SPINOR_OP_CHIP_ERASE:
-		return SEQID_CHIP_ERASE;
-	case SPINOR_OP_PP:
-		return SEQID_PP;
-	case SPINOR_OP_RDID:
-		return SEQID_RDID;
-	case SPINOR_OP_WRSR:
-		return SEQID_WRSR;
-	case SPINOR_OP_RDCR:
-		return SEQID_RDCR;
-	case SPINOR_OP_EN4B:
-		return SEQID_EN4B;
-	case SPINOR_OP_BRWR:
-		return SEQID_BRWR;
-	default:
-		if (cmd == q->nor[0].erase_opcode)
-			return SEQID_SE;
-		dev_err(q->dev, "Unsupported cmd 0x%.2x\n", cmd);
-		break;
-	}
-	return -EINVAL;
-}
-
-static int
-fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
-{
-	void __iomem *base = q->iobase;
-	int seqid;
-	u32 reg, reg2;
-	int err;
-
-	init_completion(&q->c);
-	dev_dbg(q->dev, "to 0x%.8x:0x%.8x, len:%d, cmd:%.2x\n",
-			q->chip_base_addr, addr, len, cmd);
-
-	/* save the reg */
-	reg = qspi_readl(q, base + QUADSPI_MCR);
-
-	qspi_writel(q, q->memmap_phy + q->chip_base_addr + addr,
-			base + QUADSPI_SFAR);
-	qspi_writel(q, QUADSPI_RBCT_WMRK_MASK | QUADSPI_RBCT_RXBRD_USEIPS,
-			base + QUADSPI_RBCT);
-	qspi_writel(q, reg | QUADSPI_MCR_CLR_RXF_MASK, base + QUADSPI_MCR);
-
-	do {
-		reg2 = qspi_readl(q, base + QUADSPI_SR);
-		if (reg2 & (QUADSPI_SR_IP_ACC_MASK | QUADSPI_SR_AHB_ACC_MASK)) {
-			udelay(1);
-			dev_dbg(q->dev, "The controller is busy, 0x%x\n", reg2);
-			continue;
-		}
-		break;
-	} while (1);
-
-	/* trigger the LUT now */
-	seqid = fsl_qspi_get_seqid(q, cmd);
-	qspi_writel(q, (seqid << QUADSPI_IPCR_SEQID_SHIFT) | len,
-			base + QUADSPI_IPCR);
-
-	/* Wait for the interrupt. */
-	if (!wait_for_completion_timeout(&q->c, msecs_to_jiffies(1000))) {
-		dev_err(q->dev,
-			"cmd 0x%.2x timeout, addr@%.8x, FR:0x%.8x, SR:0x%.8x\n",
-			cmd, addr, qspi_readl(q, base + QUADSPI_FR),
-			qspi_readl(q, base + QUADSPI_SR));
-		err = -ETIMEDOUT;
-	} else {
-		err = 0;
-	}
-
-	/* restore the MCR */
-	qspi_writel(q, reg, base + QUADSPI_MCR);
-
-	return err;
-}
-
-/* Read out the data from the QUADSPI_RBDR buffer registers. */
-static void fsl_qspi_read_data(struct fsl_qspi *q, int len, u8 *rxbuf)
-{
-	u32 tmp;
-	int i = 0;
-
-	while (len > 0) {
-		tmp = qspi_readl(q, q->iobase + QUADSPI_RBDR + i * 4);
-		tmp = fsl_qspi_endian_xchg(q, tmp);
-		dev_dbg(q->dev, "chip addr:0x%.8x, rcv:0x%.8x\n",
-				q->chip_base_addr, tmp);
-
-		if (len >= 4) {
-			*((u32 *)rxbuf) = tmp;
-			rxbuf += 4;
-		} else {
-			memcpy(rxbuf, &tmp, len);
-			break;
-		}
-
-		len -= 4;
-		i++;
-	}
-}
-
-/*
- * If we have changed the content of the flash by writing or erasing,
- * we need to invalidate the AHB buffer. If we do not do so, we may read out
- * the wrong data. The spec tells us reset the AHB domain and Serial Flash
- * domain at the same time.
- */
-static inline void fsl_qspi_invalid(struct fsl_qspi *q)
-{
-	u32 reg;
-
-	reg = qspi_readl(q, q->iobase + QUADSPI_MCR);
-	reg |= QUADSPI_MCR_SWRSTHD_MASK | QUADSPI_MCR_SWRSTSD_MASK;
-	qspi_writel(q, reg, q->iobase + QUADSPI_MCR);
-
-	/*
-	 * The minimum delay : 1 AHB + 2 SFCK clocks.
-	 * Delay 1 us is enough.
-	 */
-	udelay(1);
-
-	reg &= ~(QUADSPI_MCR_SWRSTHD_MASK | QUADSPI_MCR_SWRSTSD_MASK);
-	qspi_writel(q, reg, q->iobase + QUADSPI_MCR);
-}
-
-static ssize_t fsl_qspi_nor_write(struct fsl_qspi *q, struct spi_nor *nor,
-				u8 opcode, unsigned int to, u32 *txbuf,
-				unsigned count)
-{
-	int ret, i, j;
-	u32 tmp;
-
-	dev_dbg(q->dev, "to 0x%.8x:0x%.8x, len : %d\n",
-		q->chip_base_addr, to, count);
-
-	/* clear the TX FIFO. */
-	tmp = qspi_readl(q, q->iobase + QUADSPI_MCR);
-	qspi_writel(q, tmp | QUADSPI_MCR_CLR_TXF_MASK, q->iobase + QUADSPI_MCR);
-
-	/* fill the TX data to the FIFO */
-	for (j = 0, i = ((count + 3) / 4); j < i; j++) {
-		tmp = fsl_qspi_endian_xchg(q, *txbuf);
-		qspi_writel(q, tmp, q->iobase + QUADSPI_TBDR);
-		txbuf++;
-	}
-
-	/* fill the TXFIFO upto 16 bytes for i.MX7d */
-	if (needs_fill_txfifo(q))
-		for (; i < 4; i++)
-			qspi_writel(q, tmp, q->iobase + QUADSPI_TBDR);
-
-	/* Trigger it */
-	ret = fsl_qspi_runcmd(q, opcode, to, count);
-
-	if (ret == 0)
-		return count;
-
-	return ret;
-}
-
-static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
-{
-	int nor_size = q->nor_size;
-	void __iomem *base = q->iobase;
-
-	qspi_writel(q, nor_size + q->memmap_phy, base + QUADSPI_SFA1AD);
-	qspi_writel(q, nor_size * 2 + q->memmap_phy, base + QUADSPI_SFA2AD);
-	qspi_writel(q, nor_size * 3 + q->memmap_phy, base + QUADSPI_SFB1AD);
-	qspi_writel(q, nor_size * 4 + q->memmap_phy, base + QUADSPI_SFB2AD);
-}
-
-/*
- * There are two different ways to read out the data from the flash:
- *  the "IP Command Read" and the "AHB Command Read".
- *
- * The IC guy suggests we use the "AHB Command Read" which is faster
- * then the "IP Command Read". (What's more is that there is a bug in
- * the "IP Command Read" in the Vybrid.)
- *
- * After we set up the registers for the "AHB Command Read", we can use
- * the memcpy to read the data directly. A "missed" access to the buffer
- * causes the controller to clear the buffer, and use the sequence pointed
- * by the QUADSPI_BFGENCR[SEQID] to initiate a read from the flash.
- */
-static void fsl_qspi_init_ahb_read(struct fsl_qspi *q)
-{
-	void __iomem *base = q->iobase;
-	int seqid;
-
-	/* AHB configuration for access buffer 0/1/2 .*/
-	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF0CR);
-	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF1CR);
-	qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base + QUADSPI_BUF2CR);
-	/*
-	 * Set ADATSZ with the maximum AHB buffer size to improve the
-	 * read performance.
-	 */
-	qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
-			((q->devtype_data->ahb_buf_size / 8)
-			<< QUADSPI_BUF3CR_ADATSZ_SHIFT),
-			base + QUADSPI_BUF3CR);
-
-	/* We only use the buffer3 */
-	qspi_writel(q, 0, base + QUADSPI_BUF0IND);
-	qspi_writel(q, 0, base + QUADSPI_BUF1IND);
-	qspi_writel(q, 0, base + QUADSPI_BUF2IND);
-
-	/* Set the default lut sequence for AHB Read. */
-	seqid = fsl_qspi_get_seqid(q, q->nor[0].read_opcode);
-	qspi_writel(q, seqid << QUADSPI_BFGENCR_SEQID_SHIFT,
-		q->iobase + QUADSPI_BFGENCR);
-}
-
-/* This function was used to prepare and enable QSPI clock */
-static int fsl_qspi_clk_prep_enable(struct fsl_qspi *q)
-{
-	int ret;
-
-	ret = clk_prepare_enable(q->clk_en);
-	if (ret)
-		return ret;
-
-	ret = clk_prepare_enable(q->clk);
-	if (ret) {
-		clk_disable_unprepare(q->clk_en);
-		return ret;
-	}
-
-	if (needs_wakeup_wait_mode(q))
-		pm_qos_add_request(&q->pm_qos_req, PM_QOS_CPU_DMA_LATENCY, 0);
-
-	return 0;
-}
-
-/* This function was used to disable and unprepare QSPI clock */
-static void fsl_qspi_clk_disable_unprep(struct fsl_qspi *q)
-{
-	if (needs_wakeup_wait_mode(q))
-		pm_qos_remove_request(&q->pm_qos_req);
-
-	clk_disable_unprepare(q->clk);
-	clk_disable_unprepare(q->clk_en);
-
-}
-
-/* We use this function to do some basic init for spi_nor_scan(). */
-static int fsl_qspi_nor_setup(struct fsl_qspi *q)
-{
-	void __iomem *base = q->iobase;
-	u32 reg;
-	int ret;
-
-	/* disable and unprepare clock to avoid glitch pass to controller */
-	fsl_qspi_clk_disable_unprep(q);
-
-	/* the default frequency, we will change it in the future. */
-	ret = clk_set_rate(q->clk, 66000000);
-	if (ret)
-		return ret;
-
-	ret = fsl_qspi_clk_prep_enable(q);
-	if (ret)
-		return ret;
-
-	/* Reset the module */
-	qspi_writel(q, QUADSPI_MCR_SWRSTSD_MASK | QUADSPI_MCR_SWRSTHD_MASK,
-		base + QUADSPI_MCR);
-	udelay(1);
-
-	/* Init the LUT table. */
-	fsl_qspi_init_lut(q);
-
-	/* Disable the module */
-	qspi_writel(q, QUADSPI_MCR_MDIS_MASK | QUADSPI_MCR_RESERVED_MASK,
-			base + QUADSPI_MCR);
-
-	reg = qspi_readl(q, base + QUADSPI_SMPR);
-	qspi_writel(q, reg & ~(QUADSPI_SMPR_FSDLY_MASK
-			| QUADSPI_SMPR_FSPHS_MASK
-			| QUADSPI_SMPR_HSENA_MASK
-			| QUADSPI_SMPR_DDRSMP_MASK), base + QUADSPI_SMPR);
-
-	/* Enable the module */
-	qspi_writel(q, QUADSPI_MCR_RESERVED_MASK | QUADSPI_MCR_END_CFG_MASK,
-			base + QUADSPI_MCR);
-
-	/* clear all interrupt status */
-	qspi_writel(q, 0xffffffff, q->iobase + QUADSPI_FR);
-
-	/* enable the interrupt */
-	qspi_writel(q, QUADSPI_RSER_TFIE, q->iobase + QUADSPI_RSER);
-
-	return 0;
-}
-
-static int fsl_qspi_nor_setup_last(struct fsl_qspi *q)
-{
-	unsigned long rate = q->clk_rate;
-	int ret;
-
-	if (needs_4x_clock(q))
-		rate *= 4;
-
-	/* disable and unprepare clock to avoid glitch pass to controller */
-	fsl_qspi_clk_disable_unprep(q);
-
-	ret = clk_set_rate(q->clk, rate);
-	if (ret)
-		return ret;
-
-	ret = fsl_qspi_clk_prep_enable(q);
-	if (ret)
-		return ret;
-
-	/* Init the LUT table again. */
-	fsl_qspi_init_lut(q);
-
-	/* Init for AHB read */
-	fsl_qspi_init_ahb_read(q);
-
-	return 0;
-}
-
-static const struct of_device_id fsl_qspi_dt_ids[] = {
-	{ .compatible = "fsl,vf610-qspi", .data = &vybrid_data, },
-	{ .compatible = "fsl,imx6sx-qspi", .data = &imx6sx_data, },
-	{ .compatible = "fsl,imx7d-qspi", .data = &imx7d_data, },
-	{ .compatible = "fsl,imx6ul-qspi", .data = &imx6ul_data, },
-	{ .compatible = "fsl,ls1021a-qspi", .data = (void *)&ls1021a_data, },
-	{ .compatible = "fsl,ls2080a-qspi", .data = &ls2080a_data, },
-	{ /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
-
-static void fsl_qspi_set_base_addr(struct fsl_qspi *q, struct spi_nor *nor)
-{
-	q->chip_base_addr = q->nor_size * (nor - q->nor);
-}
-
-static int fsl_qspi_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
-{
-	int ret;
-	struct fsl_qspi *q = nor->priv;
-
-	ret = fsl_qspi_runcmd(q, opcode, 0, len);
-	if (ret)
-		return ret;
-
-	fsl_qspi_read_data(q, len, buf);
-	return 0;
-}
-
-static int fsl_qspi_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
-{
-	struct fsl_qspi *q = nor->priv;
-	int ret;
-
-	if (!buf) {
-		ret = fsl_qspi_runcmd(q, opcode, 0, 1);
-		if (ret)
-			return ret;
-
-		if (opcode == SPINOR_OP_CHIP_ERASE)
-			fsl_qspi_invalid(q);
-
-	} else if (len > 0) {
-		ret = fsl_qspi_nor_write(q, nor, opcode, 0,
-					(u32 *)buf, len);
-		if (ret > 0)
-			return 0;
-	} else {
-		dev_err(q->dev, "invalid cmd %d\n", opcode);
-		ret = -EINVAL;
-	}
-
-	return ret;
-}
-
-static ssize_t fsl_qspi_write(struct spi_nor *nor, loff_t to,
-			      size_t len, const u_char *buf)
-{
-	struct fsl_qspi *q = nor->priv;
-	ssize_t ret = fsl_qspi_nor_write(q, nor, nor->program_opcode, to,
-					 (u32 *)buf, len);
-
-	/* invalid the data in the AHB buffer. */
-	fsl_qspi_invalid(q);
-	return ret;
-}
-
-static ssize_t fsl_qspi_read(struct spi_nor *nor, loff_t from,
-			     size_t len, u_char *buf)
-{
-	struct fsl_qspi *q = nor->priv;
-	u8 cmd = nor->read_opcode;
-
-	/* if necessary,ioremap buffer before AHB read, */
-	if (!q->ahb_addr) {
-		q->memmap_offs = q->chip_base_addr + from;
-		q->memmap_len = len > QUADSPI_MIN_IOMAP ? len : QUADSPI_MIN_IOMAP;
-
-		q->ahb_addr = ioremap_nocache(
-				q->memmap_phy + q->memmap_offs,
-				q->memmap_len);
-		if (!q->ahb_addr) {
-			dev_err(q->dev, "ioremap failed\n");
-			return -ENOMEM;
-		}
-	/* ioremap if the data requested is out of range */
-	} else if (q->chip_base_addr + from < q->memmap_offs
-			|| q->chip_base_addr + from + len >
-			q->memmap_offs + q->memmap_len) {
-		iounmap(q->ahb_addr);
-
-		q->memmap_offs = q->chip_base_addr + from;
-		q->memmap_len = len > QUADSPI_MIN_IOMAP ? len : QUADSPI_MIN_IOMAP;
-		q->ahb_addr = ioremap_nocache(
-				q->memmap_phy + q->memmap_offs,
-				q->memmap_len);
-		if (!q->ahb_addr) {
-			dev_err(q->dev, "ioremap failed\n");
-			return -ENOMEM;
-		}
-	}
-
-	dev_dbg(q->dev, "cmd [%x],read from %p, len:%zd\n",
-		cmd, q->ahb_addr + q->chip_base_addr + from - q->memmap_offs,
-		len);
-
-	/* Read out the data directly from the AHB buffer.*/
-	memcpy(buf, q->ahb_addr + q->chip_base_addr + from - q->memmap_offs,
-		len);
-
-	return len;
-}
-
-static int fsl_qspi_erase(struct spi_nor *nor, loff_t offs)
-{
-	struct fsl_qspi *q = nor->priv;
-	int ret;
-
-	dev_dbg(nor->dev, "%dKiB at 0x%08x:0x%08x\n",
-		nor->mtd.erasesize / 1024, q->chip_base_addr, (u32)offs);
-
-	ret = fsl_qspi_runcmd(q, nor->erase_opcode, offs, 0);
-	if (ret)
-		return ret;
-
-	fsl_qspi_invalid(q);
-	return 0;
-}
-
-static int fsl_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
-{
-	struct fsl_qspi *q = nor->priv;
-	int ret;
-
-	mutex_lock(&q->lock);
-
-	ret = fsl_qspi_clk_prep_enable(q);
-	if (ret)
-		goto err_mutex;
-
-	fsl_qspi_set_base_addr(q, nor);
-	return 0;
-
-err_mutex:
-	mutex_unlock(&q->lock);
-	return ret;
-}
-
-static void fsl_qspi_unprep(struct spi_nor *nor, enum spi_nor_ops ops)
-{
-	struct fsl_qspi *q = nor->priv;
-
-	fsl_qspi_clk_disable_unprep(q);
-	mutex_unlock(&q->lock);
-}
-
-static int fsl_qspi_probe(struct platform_device *pdev)
-{
-	const struct spi_nor_hwcaps hwcaps = {
-		.mask = SNOR_HWCAPS_READ_1_1_4 |
-			SNOR_HWCAPS_PP,
-	};
-	struct device_node *np = pdev->dev.of_node;
-	struct device *dev = &pdev->dev;
-	struct fsl_qspi *q;
-	struct resource *res;
-	struct spi_nor *nor;
-	struct mtd_info *mtd;
-	int ret, i = 0;
-
-	q = devm_kzalloc(dev, sizeof(*q), GFP_KERNEL);
-	if (!q)
-		return -ENOMEM;
-
-	q->nor_num = of_get_child_count(dev->of_node);
-	if (!q->nor_num || q->nor_num > FSL_QSPI_MAX_CHIP)
-		return -ENODEV;
-
-	q->dev = dev;
-	q->devtype_data = of_device_get_match_data(dev);
-	if (!q->devtype_data)
-		return -ENODEV;
-	platform_set_drvdata(pdev, q);
-
-	/* find the resources */
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "QuadSPI");
-	q->iobase = devm_ioremap_resource(dev, res);
-	if (IS_ERR(q->iobase))
-		return PTR_ERR(q->iobase);
-
-	q->big_endian = of_property_read_bool(np, "big-endian");
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
-					"QuadSPI-memory");
-	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);
-		return -EBUSY;
-	}
-
-	q->memmap_phy = res->start;
-
-	/* find the clocks */
-	q->clk_en = devm_clk_get(dev, "qspi_en");
-	if (IS_ERR(q->clk_en))
-		return PTR_ERR(q->clk_en);
-
-	q->clk = devm_clk_get(dev, "qspi");
-	if (IS_ERR(q->clk))
-		return PTR_ERR(q->clk);
-
-	ret = fsl_qspi_clk_prep_enable(q);
-	if (ret) {
-		dev_err(dev, "can not enable the clock\n");
-		goto clk_failed;
-	}
-
-	/* find the irq */
-	ret = platform_get_irq(pdev, 0);
-	if (ret < 0) {
-		dev_err(dev, "failed to get the irq: %d\n", ret);
-		goto irq_failed;
-	}
-
-	ret = devm_request_irq(dev, ret,
-			fsl_qspi_irq_handler, 0, pdev->name, q);
-	if (ret) {
-		dev_err(dev, "failed to request irq: %d\n", ret);
-		goto irq_failed;
-	}
-
-	ret = fsl_qspi_nor_setup(q);
-	if (ret)
-		goto irq_failed;
-
-	if (of_get_property(np, "fsl,qspi-has-second-chip", NULL))
-		q->has_second_chip = true;
-
-	mutex_init(&q->lock);
-
-	/* iterate the subnodes. */
-	for_each_available_child_of_node(dev->of_node, np) {
-		/* skip the holes */
-		if (!q->has_second_chip)
-			i *= 2;
-
-		nor = &q->nor[i];
-		mtd = &nor->mtd;
-
-		nor->dev = dev;
-		spi_nor_set_flash_node(nor, np);
-		nor->priv = q;
-
-		if (q->nor_num > 1 && !mtd->name) {
-			int spiflash_idx;
-
-			ret = of_property_read_u32(np, "reg", &spiflash_idx);
-			if (!ret) {
-				mtd->name = devm_kasprintf(dev, GFP_KERNEL,
-							   "%s-%d",
-							   dev_name(dev),
-							   spiflash_idx);
-				if (!mtd->name) {
-					ret = -ENOMEM;
-					goto mutex_failed;
-				}
-			} else {
-				dev_warn(dev, "reg property is missing\n");
-			}
-		}
-
-		/* fill the hooks */
-		nor->read_reg = fsl_qspi_read_reg;
-		nor->write_reg = fsl_qspi_write_reg;
-		nor->read = fsl_qspi_read;
-		nor->write = fsl_qspi_write;
-		nor->erase = fsl_qspi_erase;
-
-		nor->prepare = fsl_qspi_prep;
-		nor->unprepare = fsl_qspi_unprep;
-
-		ret = of_property_read_u32(np, "spi-max-frequency",
-				&q->clk_rate);
-		if (ret < 0)
-			goto mutex_failed;
-
-		/* set the chip address for READID */
-		fsl_qspi_set_base_addr(q, nor);
-
-		ret = spi_nor_scan(nor, NULL, &hwcaps);
-		if (ret)
-			goto mutex_failed;
-
-		ret = mtd_device_register(mtd, NULL, 0);
-		if (ret)
-			goto mutex_failed;
-
-		/* Set the correct NOR size now. */
-		if (q->nor_size == 0) {
-			q->nor_size = mtd->size;
-
-			/* Map the SPI NOR to accessiable address */
-			fsl_qspi_set_map_addr(q);
-		}
-
-		/*
-		 * The TX FIFO is 64 bytes in the Vybrid, but the Page Program
-		 * may writes 265 bytes per time. The write is working in the
-		 * unit of the TX FIFO, not in the unit of the SPI NOR's page
-		 * size.
-		 *
-		 * So shrink the spi_nor->page_size if it is larger then the
-		 * TX FIFO.
-		 */
-		if (nor->page_size > q->devtype_data->txfifo)
-			nor->page_size = q->devtype_data->txfifo;
-
-		i++;
-	}
-
-	/* finish the rest init. */
-	ret = fsl_qspi_nor_setup_last(q);
-	if (ret)
-		goto last_init_failed;
-
-	fsl_qspi_clk_disable_unprep(q);
-	return 0;
-
-last_init_failed:
-	for (i = 0; i < q->nor_num; i++) {
-		/* skip the holes */
-		if (!q->has_second_chip)
-			i *= 2;
-		mtd_device_unregister(&q->nor[i].mtd);
-	}
-mutex_failed:
-	mutex_destroy(&q->lock);
-irq_failed:
-	fsl_qspi_clk_disable_unprep(q);
-clk_failed:
-	dev_err(dev, "Freescale QuadSPI probe failed\n");
-	return ret;
-}
-
-static int fsl_qspi_remove(struct platform_device *pdev)
-{
-	struct fsl_qspi *q = platform_get_drvdata(pdev);
-	int i;
-
-	for (i = 0; i < q->nor_num; i++) {
-		/* skip the holes */
-		if (!q->has_second_chip)
-			i *= 2;
-		mtd_device_unregister(&q->nor[i].mtd);
-	}
-
-	/* disable the hardware */
-	qspi_writel(q, QUADSPI_MCR_MDIS_MASK, q->iobase + QUADSPI_MCR);
-	qspi_writel(q, 0x0, q->iobase + QUADSPI_RSER);
-
-	mutex_destroy(&q->lock);
-
-	if (q->ahb_addr)
-		iounmap(q->ahb_addr);
-
-	return 0;
-}
-
-static int fsl_qspi_suspend(struct platform_device *pdev, pm_message_t state)
-{
-	return 0;
-}
-
-static int fsl_qspi_resume(struct platform_device *pdev)
-{
-	int ret;
-	struct fsl_qspi *q = platform_get_drvdata(pdev);
-
-	ret = fsl_qspi_clk_prep_enable(q);
-	if (ret)
-		return ret;
-
-	fsl_qspi_nor_setup(q);
-	fsl_qspi_set_map_addr(q);
-	fsl_qspi_nor_setup_last(q);
-
-	fsl_qspi_clk_disable_unprep(q);
-
-	return 0;
-}
-
-static struct platform_driver fsl_qspi_driver = {
-	.driver = {
-		.name	= "fsl-quadspi",
-		.of_match_table = fsl_qspi_dt_ids,
-	},
-	.probe          = fsl_qspi_probe,
-	.remove		= fsl_qspi_remove,
-	.suspend	= fsl_qspi_suspend,
-	.resume		= fsl_qspi_resume,
-};
-module_platform_driver(fsl_qspi_driver);
-
-MODULE_DESCRIPTION("Freescale QuadSPI Controller Driver");
-MODULE_AUTHOR("Freescale Semiconductor Inc.");
-MODULE_LICENSE("GPL v2");
-- 
2.7.4

[PATCH v2 10/12] ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index 6a83f30..d3a1a73 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,7 +203,6 @@
 };
 
 &qspi {
-	fsl,qspi-has-second-chip;
 	status = "okay";
 
 	flash: flash@0 {
-- 
2.7.4

[PATCH v2 10/12] ARM: dts: ls1021a: Remove fsl, qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
index 6a83f30..d3a1a73 100644
--- a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -203,7 +203,6 @@
 };
 
 &qspi {
-	fsl,qspi-has-second-chip;
 	status = "okay";
 
 	flash: flash@0 {
-- 
2.7.4

[PATCH v2 11/12] ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa..871189e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -247,7 +247,6 @@
 			clock-names = "qspi_en", "qspi";
 			clocks = <&clockgen 4 1>, <&clockgen 4 1>;
 			big-endian;
-			fsl,qspi-has-second-chip;
 			status = "disabled";
 		};
 
-- 
2.7.4

[PATCH v2 11/12] ARM64: dts: ls1046a: Remove fsl, qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa..871189e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -247,7 +247,6 @@
 			clock-names = "qspi_en", "qspi";
 			clocks = <&clockgen 4 1>, <&clockgen 4 1>;
 			big-endian;
-			fsl,qspi-has-second-chip;
 			status = "disabled";
 		};
 
-- 
2.7.4

[PATCH v2 11/12] ARM64: dts: ls1046a: Remove fsl, qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa..871189e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -247,7 +247,6 @@
 			clock-names = "qspi_en", "qspi";
 			clocks = <&clockgen 4 1>, <&clockgen 4 1>;
 			big-endian;
-			fsl,qspi-has-second-chip;
 			status = "disabled";
 		};
 
-- 
2.7.4

[PATCH v2 11/12] ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used

[Frieder Schrempf]

After switching to the new FSL QSPI driver the property
'fsl,qspi-has-second-chip' is not needed anymore.

The driver now uses the 'reg' property to determine the bus and
the chipselect.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
index 136ebfa..871189e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi
@@ -247,7 +247,6 @@
 			clock-names = "qspi_en", "qspi";
 			clocks = <&clockgen 4 1>, <&clockgen 4 1>;
 			big-endian;
-			fsl,qspi-has-second-chip;
 			status = "disabled";
 		};
 
-- 
2.7.4

[PATCH v2 12/12] MAINTAINERS: Move the Freescale QSPI driver to the SPI framework

[Frieder Schrempf]

The driver was ported to the SPI framework so it can be used as
a generic SPI memory driver and not only for SPI NOR.
Reflect this transition in the MAINTAINERS file.

Signed-off-by: Frieder Schrempf <frieder.schrempf@exceet.de>
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 63700ce..14039e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5746,9 +5746,9 @@ F:	Documentation/devicetree/bindings/ptp/ptp-qoriq.txt
 
 FREESCALE QUAD SPI DRIVER
 M:	Han Xu <han.xu@nxp.com>
-L:	linux-mtd@lists.infradead.org
+L:	linux-spi@vger.kernel.org
 S:	Maintained
-F:	drivers/mtd/spi-nor/fsl-quadspi.c
+F:	drivers/spi/spi-fsl-qspi.c
 
 FREESCALE QUICC ENGINE LIBRARY
 M:	Qiang Zhao <qiang.zhao@nxp.com>
-- 
2.7.4

RE: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Yogesh Narayan Gaur]

Hi Frieder,

These patch series also depends on the patches [1][2] for the controller which can't write nor->page_size bytes in single write command step.
Thus, have to invoke Write sequence again and before sending WRITE command, need to send WREN command.

[1] https://patchwork.ozlabs.org/patch/928677/
[2] https://patchwork.ozlabs.org/patch/928678/

--
Regards
Yogesh Gaur.

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Thursday, July 5, 2018 4:45 PM
> To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> spi@vger.kernel.org
> Cc: dwmw2@infradead.org; computersforpeace@gmail.com;
> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org; Frieder Schrempf <frieder.schrempf@exceet.de>
> Subject: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
> 
> Now that the SPI memory interface was introduced by Boris [1], it is possible to
> move drivers from mtd/spi-nor to the SPI framework in order to use them for
> different type of SPI memory chips.
> 
> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface and a
> ->name field to struct spi_mem.
> Patch 2 uses it in m25p80.c to make it possible for SPI controller drivers to
> provide a custom naming scheme for the flash chip.
> This is needed to avoid breaking compatibility of mtdparts when switching from
> the old to the new driver.
> 
> Patch 3 adds a driver for the Freescale QSPI controller to the SPI framework.
> Together with m25p80.c it can be used to interface SPI NOR flashes just as the
> old driver did. For this to work properly a few minor changes to the devicetrees
> are necessary (see patches 5 to 7).
> 
> Patch 8 changes the defconfigs to use the new driver and patch 9 removes the
> old driver.
> 
> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> Patch 12 adjusts the MAINTAINERS file.
> 
> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> The read performance of the new driver is almost the same or even better than
> the old driver, depending on the block size.
> The write performance is a bit slower on average (~10-15%).
> 
> The new driver was also tested with the SPI NAND framework [2] and a Winbond
> W25M02GV flash.
> 
> If someone has a board that uses both chips selects and/or both busses, it would
> be really nice to have the driver be tested on such a setup.
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fbroonie%2Fspi.git%2Fcom
> mit%2F%3Fh%3Dfor-
> 4.18%26id%3Dc36ff266dc82f4ae797a6f3513c6ffa344f7f1c7&data=02%7C01%7
> Cyogeshnarayan.gaur%40nxp.com%7C77846565197d44d7413008d5e268ccb2%
> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439&
> sdata=Y8dyVYysfK3Q6vDXUMEBs%2BBygMxh9qM%2ByWdtk9hGyQU%3D&rese
> rved=0
> [2]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fcover%2F913728%2F&data=02%7C01%7Cyogeshnarayan.g
> aur%40nxp.com%7C77846565197d44d7413008d5e268ccb2%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439&sdata=VUE5kVY7V
> DW0a3PKmQvsUC9TyHZUhhntgM1SJC3EUWU%3D&reserved=0
> 
> Changes in v2:
> ==============
> * Rebase on top of nand/next
> * Add a name field to struct spi_mem and fill it while probing
> * Add Yogesh Gaur and Suresh Gupta as authors
> * Use GENMASK() for generating bitmasks
> * Use callback functions for read/write of registers
> * Attach the seq variable to the selected CS
> * Avoid using conditional in read/write loop
> * Avoid infinite loop and use a timeout instead
> * Return error pointer when allocation in fsl_qspi_get_name() fails
> * Remove redundant iounmap()
> * Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver
> * Split the moving and editing of the dt-bindings in two patches
> 
> Frieder Schrempf (12):
>   spi: spi-mem: Extend the SPI mem interface to set a custom memory name
>   mtd: m25p80: Call spi_mem_get_name() to let controller set a custom
>     name
>   spi: Add a driver for the Freescale/NXP QuadSPI controller
>   dt-bindings: spi: Move the bindings for the FSL QSPI driver
>   dt-bindings: spi: Adjust the bindings for the FSL QSPI driver
>   ARM: dts: Reflect change of FSL QSPI driver and remove unused
>     properties
>   arm64: dts: Reflect change of FSL QSPI driver and remove unused
>     properties
>   ARM: defconfig: Use the new FSL QSPI driver under the SPI framework
>   mtd: fsl-quadspi: Remove the driver as it was replaced by
>     spi-fsl-qspi.c
>   ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used
>   ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used
>   MAINTAINERS: Move the Freescale QSPI driver to the SPI framework
> 
>  .../devicetree/bindings/mtd/fsl-quadspi.txt     |   65 -
>  .../devicetree/bindings/spi/spi-fsl-qspi.txt    |   65 +
>  MAINTAINERS                                     |    4 +-
>  arch/arm/boot/dts/imx6sx-sdb-reva.dts           |    8 +-
>  arch/arm/boot/dts/imx6sx-sdb.dts                |    8 +-
>  arch/arm/boot/dts/imx6ul-14x14-evk.dtsi         |    2 +
>  arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts     |    6 +-
>  arch/arm/configs/imx_v6_v7_defconfig            |    2 +-
>  arch/arm/configs/multi_v7_defconfig             |    2 +-
>  .../boot/dts/freescale/fsl-ls1043a-qds.dts      |    3 +-
>  .../boot/dts/freescale/fsl-ls1046a-qds.dts      |    4 +-
>  .../boot/dts/freescale/fsl-ls1046a-rdb.dts      |    6 +-
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi  |    1 -
>  .../boot/dts/freescale/fsl-ls208xa-qds.dtsi     |    4 +
>  drivers/mtd/devices/m25p80.c                    |    3 +-
>  drivers/mtd/spi-nor/Kconfig                     |    9 -
>  drivers/mtd/spi-nor/Makefile                    |    1 -
>  drivers/mtd/spi-nor/fsl-quadspi.c               | 1217 ------------------
>  drivers/spi/Kconfig                             |   11 +
>  drivers/spi/Makefile                            |    1 +
>  drivers/spi/spi-fsl-qspi.c                      |  954 ++++++++++++++
>  drivers/spi/spi-mem.c                           |   30 +
>  include/linux/spi/spi-mem.h                     |    7 +-
>  23 files changed, 1100 insertions(+), 1313 deletions(-)  delete mode 100644
> Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>  delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c  create mode 100644
> drivers/spi/spi-fsl-qspi.c
> 
> --
> 2.7.4


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Yogesh Narayan Gaur]

Hi Frieder,

These patch series also depends on the patches [1][2] for the controller which can't write nor->page_size bytes in single write command step.
Thus, have to invoke Write sequence again and before sending WRITE command, need to send WREN command.

[1] https://patchwork.ozlabs.org/patch/928677/
[2] https://patchwork.ozlabs.org/patch/928678/

--
Regards
Yogesh Gaur.

> -----Original Message-----
> From: Frieder Schrempf [mailto:frieder.schrempf@exceet.de]
> Sent: Thursday, July 5, 2018 4:45 PM
> To: linux-mtd@lists.infradead.org; boris.brezillon@bootlin.com; linux-
> spi@vger.kernel.org
> Cc: dwmw2@infradead.org; computersforpeace@gmail.com;
> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org; Frieder Schrempf <frieder.schrempf@exceet.de>
> Subject: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
> 
> Now that the SPI memory interface was introduced by Boris [1], it is possible to
> move drivers from mtd/spi-nor to the SPI framework in order to use them for
> different type of SPI memory chips.
> 
> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface and a
> ->name field to struct spi_mem.
> Patch 2 uses it in m25p80.c to make it possible for SPI controller drivers to
> provide a custom naming scheme for the flash chip.
> This is needed to avoid breaking compatibility of mtdparts when switching from
> the old to the new driver.
> 
> Patch 3 adds a driver for the Freescale QSPI controller to the SPI framework.
> Together with m25p80.c it can be used to interface SPI NOR flashes just as the
> old driver did. For this to work properly a few minor changes to the devicetrees
> are necessary (see patches 5 to 7).
> 
> Patch 8 changes the defconfigs to use the new driver and patch 9 removes the
> old driver.
> 
> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> Patch 12 adjusts the MAINTAINERS file.
> 
> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> The read performance of the new driver is almost the same or even better than
> the old driver, depending on the block size.
> The write performance is a bit slower on average (~10-15%).
> 
> The new driver was also tested with the SPI NAND framework [2] and a Winbond
> W25M02GV flash.
> 
> If someone has a board that uses both chips selects and/or both busses, it would
> be really nice to have the driver be tested on such a setup.
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker
> nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fbroonie%2Fspi.git%2Fcom
> mit%2F%3Fh%3Dfor-
> 4.18%26id%3Dc36ff266dc82f4ae797a6f3513c6ffa344f7f1c7&data=02%7C01%7
> Cyogeshnarayan.gaur%40nxp.com%7C77846565197d44d7413008d5e268ccb2%
> 7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439&
> sdata=Y8dyVYysfK3Q6vDXUMEBs%2BBygMxh9qM%2ByWdtk9hGyQU%3D&rese
> rved=0
> [2]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.ozlabs.org%2Fcover%2F913728%2F&data=02%7C01%7Cyogeshnarayan.g
> aur%40nxp.com%7C77846565197d44d7413008d5e268ccb2%7C686ea1d3bc2b4
> c6fa92cd99c5c301635%7C0%7C0%7C636663862101876439&sdata=VUE5kVY7V
> DW0a3PKmQvsUC9TyHZUhhntgM1SJC3EUWU%3D&reserved=0
> 
> Changes in v2:
> ==============
> * Rebase on top of nand/next
> * Add a name field to struct spi_mem and fill it while probing
> * Add Yogesh Gaur and Suresh Gupta as authors
> * Use GENMASK() for generating bitmasks
> * Use callback functions for read/write of registers
> * Attach the seq variable to the selected CS
> * Avoid using conditional in read/write loop
> * Avoid infinite loop and use a timeout instead
> * Return error pointer when allocation in fsl_qspi_get_name() fails
> * Remove redundant iounmap()
> * Put suspend()/resume() in struct dev_pm_ops instead of struct platform_driver
> * Split the moving and editing of the dt-bindings in two patches
> 
> Frieder Schrempf (12):
>   spi: spi-mem: Extend the SPI mem interface to set a custom memory name
>   mtd: m25p80: Call spi_mem_get_name() to let controller set a custom
>     name
>   spi: Add a driver for the Freescale/NXP QuadSPI controller
>   dt-bindings: spi: Move the bindings for the FSL QSPI driver
>   dt-bindings: spi: Adjust the bindings for the FSL QSPI driver
>   ARM: dts: Reflect change of FSL QSPI driver and remove unused
>     properties
>   arm64: dts: Reflect change of FSL QSPI driver and remove unused
>     properties
>   ARM: defconfig: Use the new FSL QSPI driver under the SPI framework
>   mtd: fsl-quadspi: Remove the driver as it was replaced by
>     spi-fsl-qspi.c
>   ARM: dts: ls1021a: Remove fsl,qspi-has-second-chip as it is not used
>   ARM64: dts: ls1046a: Remove fsl,qspi-has-second-chip as it is not used
>   MAINTAINERS: Move the Freescale QSPI driver to the SPI framework
> 
>  .../devicetree/bindings/mtd/fsl-quadspi.txt     |   65 -
>  .../devicetree/bindings/spi/spi-fsl-qspi.txt    |   65 +
>  MAINTAINERS                                     |    4 +-
>  arch/arm/boot/dts/imx6sx-sdb-reva.dts           |    8 +-
>  arch/arm/boot/dts/imx6sx-sdb.dts                |    8 +-
>  arch/arm/boot/dts/imx6ul-14x14-evk.dtsi         |    2 +
>  arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts     |    6 +-
>  arch/arm/configs/imx_v6_v7_defconfig            |    2 +-
>  arch/arm/configs/multi_v7_defconfig             |    2 +-
>  .../boot/dts/freescale/fsl-ls1043a-qds.dts      |    3 +-
>  .../boot/dts/freescale/fsl-ls1046a-qds.dts      |    4 +-
>  .../boot/dts/freescale/fsl-ls1046a-rdb.dts      |    6 +-
>  arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi  |    1 -
>  .../boot/dts/freescale/fsl-ls208xa-qds.dtsi     |    4 +
>  drivers/mtd/devices/m25p80.c                    |    3 +-
>  drivers/mtd/spi-nor/Kconfig                     |    9 -
>  drivers/mtd/spi-nor/Makefile                    |    1 -
>  drivers/mtd/spi-nor/fsl-quadspi.c               | 1217 ------------------
>  drivers/spi/Kconfig                             |   11 +
>  drivers/spi/Makefile                            |    1 +
>  drivers/spi/spi-fsl-qspi.c                      |  954 ++++++++++++++
>  drivers/spi/spi-mem.c                           |   30 +
>  include/linux/spi/spi-mem.h                     |    7 +-
>  23 files changed, 1100 insertions(+), 1313 deletions(-)  delete mode 100644
> Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
>  create mode 100644 Documentation/devicetree/bindings/spi/spi-fsl-qspi.txt
>  delete mode 100644 drivers/mtd/spi-nor/fsl-quadspi.c  create mode 100644
> drivers/spi/spi-fsl-qspi.c
> 
> --
> 2.7.4

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

Hi Frieder, Yogesh,

On Thu,  5 Jul 2018 13:14:56 +0200
Frieder Schrempf <frieder.schrempf@exceet.de> wrote:

> Now that the SPI memory interface was introduced by Boris [1], it is
> possible to move drivers from mtd/spi-nor to the SPI framework in order
> to use them for different type of SPI memory chips.
> 
> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> and a ->name field to struct spi_mem.
> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> drivers to provide a custom naming scheme for the flash chip.
> This is needed to avoid breaking compatibility of mtdparts when switching
> from the old to the new driver.
> 
> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> framework. Together with m25p80.c it can be used to interface SPI
> NOR flashes just as the old driver did. For this to work properly a few
> minor changes to the devicetrees are necessary (see patches 5 to 7).
> 
> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> the old driver.
> 
> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> Patch 12 adjusts the MAINTAINERS file.
> 
> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> The read performance of the new driver is almost the same or even better
> than the old driver, depending on the block size.
> The write performance is a bit slower on average (~10-15%).
> 
> The new driver was also tested with the SPI NAND framework [2] and a
> Winbond W25M02GV flash.
> 
> If someone has a board that uses both chips selects and/or both busses,
> it would be really nice to have the driver be tested on such a setup.

Any progress on this front? Yogesh, can you please remind us the
remaining issues? I'd really like to make some progress, otherwise the
conversion to spi-mem will take ages.

Regards,

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

Hi Frieder, Yogesh,

On Thu,  5 Jul 2018 13:14:56 +0200
Frieder Schrempf <frieder.schrempf@exceet.de> wrote:

> Now that the SPI memory interface was introduced by Boris [1], it is
> possible to move drivers from mtd/spi-nor to the SPI framework in order
> to use them for different type of SPI memory chips.
> 
> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> and a ->name field to struct spi_mem.
> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> drivers to provide a custom naming scheme for the flash chip.
> This is needed to avoid breaking compatibility of mtdparts when switching
> from the old to the new driver.
> 
> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> framework. Together with m25p80.c it can be used to interface SPI
> NOR flashes just as the old driver did. For this to work properly a few
> minor changes to the devicetrees are necessary (see patches 5 to 7).
> 
> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> the old driver.
> 
> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> Patch 12 adjusts the MAINTAINERS file.
> 
> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> The read performance of the new driver is almost the same or even better
> than the old driver, depending on the block size.
> The write performance is a bit slower on average (~10-15%).
> 
> The new driver was also tested with the SPI NAND framework [2] and a
> Winbond W25M02GV flash.
> 
> If someone has a board that uses both chips selects and/or both busses,
> it would be really nice to have the driver be tested on such a setup.

Any progress on this front? Yogesh, can you please remind us the
remaining issues? I'd really like to make some progress, otherwise the
conversion to spi-mem will take ages.

Regards,

Boris

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Boris,

On 31.10.18 14:40, Boris Brezillon wrote:
> Hi Frieder, Yogesh,
> 
> On Thu,  5 Jul 2018 13:14:56 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> Now that the SPI memory interface was introduced by Boris [1], it is
>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>> to use them for different type of SPI memory chips.
>>
>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>> and a ->name field to struct spi_mem.
>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>> drivers to provide a custom naming scheme for the flash chip.
>> This is needed to avoid breaking compatibility of mtdparts when switching
>> from the old to the new driver.
>>
>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>> framework. Together with m25p80.c it can be used to interface SPI
>> NOR flashes just as the old driver did. For this to work properly a few
>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>
>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>> the old driver.
>>
>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>> Patch 12 adjusts the MAINTAINERS file.
>>
>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>> The read performance of the new driver is almost the same or even better
>> than the old driver, depending on the block size.
>> The write performance is a bit slower on average (~10-15%).
>>
>> The new driver was also tested with the SPI NAND framework [2] and a
>> Winbond W25M02GV flash.
>>
>> If someone has a board that uses both chips selects and/or both busses,
>> it would be really nice to have the driver be tested on such a setup.
> 
> Any progress on this front? Yogesh, can you please remind us the
> remaining issues? I'd really like to make some progress, otherwise the
> conversion to spi-mem will take ages.

I definitely want to continue this. I just did not have the time to work 
on it.

I think the only remaining blocking issues is the one that Yogesh 
reported while testing with two chips on the same bus.

Han and I have both successfully tested with two chips, but on separate 
buses.

Regards,
Frieder
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Boris,

On 31.10.18 14:40, Boris Brezillon wrote:
> Hi Frieder, Yogesh,
> 
> On Thu,  5 Jul 2018 13:14:56 +0200
> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> 
>> Now that the SPI memory interface was introduced by Boris [1], it is
>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>> to use them for different type of SPI memory chips.
>>
>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>> and a ->name field to struct spi_mem.
>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>> drivers to provide a custom naming scheme for the flash chip.
>> This is needed to avoid breaking compatibility of mtdparts when switching
>> from the old to the new driver.
>>
>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>> framework. Together with m25p80.c it can be used to interface SPI
>> NOR flashes just as the old driver did. For this to work properly a few
>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>
>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>> the old driver.
>>
>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>> Patch 12 adjusts the MAINTAINERS file.
>>
>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>> The read performance of the new driver is almost the same or even better
>> than the old driver, depending on the block size.
>> The write performance is a bit slower on average (~10-15%).
>>
>> The new driver was also tested with the SPI NAND framework [2] and a
>> Winbond W25M02GV flash.
>>
>> If someone has a board that uses both chips selects and/or both busses,
>> it would be really nice to have the driver be tested on such a setup.
> 
> Any progress on this front? Yogesh, can you please remind us the
> remaining issues? I'd really like to make some progress, otherwise the
> conversion to spi-mem will take ages.

I definitely want to continue this. I just did not have the time to work 
on it.

I think the only remaining blocking issues is the one that Yogesh 
reported while testing with two chips on the same bus.

Han and I have both successfully tested with two chips, but on separate 
buses.

Regards,
Frieder

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

On Wed, 31 Oct 2018 13:54:29 +0000
Schrempf Frieder <frieder.schrempf@kontron.De> wrote:

> Hi Boris,
> 
> On 31.10.18 14:40, Boris Brezillon wrote:
> > Hi Frieder, Yogesh,
> > 
> > On Thu,  5 Jul 2018 13:14:56 +0200
> > Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> >   
> >> Now that the SPI memory interface was introduced by Boris [1], it is
> >> possible to move drivers from mtd/spi-nor to the SPI framework in order
> >> to use them for different type of SPI memory chips.
> >>
> >> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> >> and a ->name field to struct spi_mem.
> >> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> >> drivers to provide a custom naming scheme for the flash chip.
> >> This is needed to avoid breaking compatibility of mtdparts when switching
> >> from the old to the new driver.
> >>
> >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> >> framework. Together with m25p80.c it can be used to interface SPI
> >> NOR flashes just as the old driver did. For this to work properly a few
> >> minor changes to the devicetrees are necessary (see patches 5 to 7).
> >>
> >> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> >> the old driver.
> >>
> >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> >> Patch 12 adjusts the MAINTAINERS file.
> >>
> >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> >> The read performance of the new driver is almost the same or even better
> >> than the old driver, depending on the block size.
> >> The write performance is a bit slower on average (~10-15%).
> >>
> >> The new driver was also tested with the SPI NAND framework [2] and a
> >> Winbond W25M02GV flash.
> >>
> >> If someone has a board that uses both chips selects and/or both busses,
> >> it would be really nice to have the driver be tested on such a setup.  
> > 
> > Any progress on this front? Yogesh, can you please remind us the
> > remaining issues? I'd really like to make some progress, otherwise the
> > conversion to spi-mem will take ages.  
> 
> I definitely want to continue this. I just did not have the time to work 
> on it.
> 
> I think the only remaining blocking issues is the one that Yogesh 
> reported while testing with two chips on the same bus.

Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
and push it somewhere so that Yogesh can test it (again). Yogesh, can we
please make some progress on this? If you really have a bug, that'd be
great to have a serious investigation on what is causing this bug. The
explanation we had so far were not really helpful in understanding the
problem.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

On Wed, 31 Oct 2018 13:54:29 +0000
Schrempf Frieder <frieder.schrempf@kontron.De> wrote:

> Hi Boris,
> 
> On 31.10.18 14:40, Boris Brezillon wrote:
> > Hi Frieder, Yogesh,
> > 
> > On Thu,  5 Jul 2018 13:14:56 +0200
> > Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> >   
> >> Now that the SPI memory interface was introduced by Boris [1], it is
> >> possible to move drivers from mtd/spi-nor to the SPI framework in order
> >> to use them for different type of SPI memory chips.
> >>
> >> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> >> and a ->name field to struct spi_mem.
> >> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> >> drivers to provide a custom naming scheme for the flash chip.
> >> This is needed to avoid breaking compatibility of mtdparts when switching
> >> from the old to the new driver.
> >>
> >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> >> framework. Together with m25p80.c it can be used to interface SPI
> >> NOR flashes just as the old driver did. For this to work properly a few
> >> minor changes to the devicetrees are necessary (see patches 5 to 7).
> >>
> >> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> >> the old driver.
> >>
> >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> >> Patch 12 adjusts the MAINTAINERS file.
> >>
> >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> >> The read performance of the new driver is almost the same or even better
> >> than the old driver, depending on the block size.
> >> The write performance is a bit slower on average (~10-15%).
> >>
> >> The new driver was also tested with the SPI NAND framework [2] and a
> >> Winbond W25M02GV flash.
> >>
> >> If someone has a board that uses both chips selects and/or both busses,
> >> it would be really nice to have the driver be tested on such a setup.  
> > 
> > Any progress on this front? Yogesh, can you please remind us the
> > remaining issues? I'd really like to make some progress, otherwise the
> > conversion to spi-mem will take ages.  
> 
> I definitely want to continue this. I just did not have the time to work 
> on it.
> 
> I think the only remaining blocking issues is the one that Yogesh 
> reported while testing with two chips on the same bus.

Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
and push it somewhere so that Yogesh can test it (again). Yogesh, can we
please make some progress on this? If you really have a bug, that'd be
great to have a serious investigation on what is causing this bug. The
explanation we had so far were not really helpful in understanding the
problem.

RE: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Yogesh Narayan Gaur]

Hi Frieder,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Wednesday, October 31, 2018 8:01 PM
> To: Schrempf Frieder <frieder.schrempf@kontron.De>
> Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> dwmw2@infradead.org; computersforpeace@gmail.com;
> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org
> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
> 
> On Wed, 31 Oct 2018 13:54:29 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
> > Hi Boris,
> >
> > On 31.10.18 14:40, Boris Brezillon wrote:
> > > Hi Frieder, Yogesh,
> > >
> > > On Thu,  5 Jul 2018 13:14:56 +0200
> > > Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> > >
> > >> Now that the SPI memory interface was introduced by Boris [1], it
> > >> is possible to move drivers from mtd/spi-nor to the SPI framework
> > >> in order to use them for different type of SPI memory chips.
> > >>
> > >> Patch 1 adds a function spi_mem_get_name() to the SPI memory
> > >> interface and a ->name field to struct spi_mem.
> > >> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> > >> drivers to provide a custom naming scheme for the flash chip.
> > >> This is needed to avoid breaking compatibility of mtdparts when
> > >> switching from the old to the new driver.
> > >>
> > >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> > >> framework. Together with m25p80.c it can be used to interface SPI
> > >> NOR flashes just as the old driver did. For this to work properly a
> > >> few minor changes to the devicetrees are necessary (see patches 5 to 7).
> > >>
> > >> Patch 8 changes the defconfigs to use the new driver and patch 9
> > >> removes the old driver.
> > >>
> > >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> > >> Patch 12 adjusts the MAINTAINERS file.
> > >>
> > >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> > >> The read performance of the new driver is almost the same or even
> > >> better than the old driver, depending on the block size.
> > >> The write performance is a bit slower on average (~10-15%).
> > >>
> > >> The new driver was also tested with the SPI NAND framework [2] and
> > >> a Winbond W25M02GV flash.
> > >>
> > >> If someone has a board that uses both chips selects and/or both
> > >> busses, it would be really nice to have the driver be tested on such a setup.
> > >
> > > Any progress on this front? Yogesh, can you please remind us the
> > > remaining issues? I'd really like to make some progress, otherwise
> > > the conversion to spi-mem will take ages.
> >
> > I definitely want to continue this. I just did not have the time to
> > work on it.
> >
> > I think the only remaining blocking issues is the one that Yogesh
> > reported while testing with two chips on the same bus.
> 
> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and
> push it somewhere so that Yogesh can test it (again).
In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g. 
1. Redefine all mask fields and use BIT(X) for single bit set/unset.
2. Remove function pointer hooks for ->read/->write function.
3. Remove dependency from 'endianess' property from DTS node.
4. Usage of readl_poll_timeout() instead of busy looping.

--
Regards
Yogesh Gaur

 Yogesh, can we please
> make some progress on this? If you really have a bug, that'd be great to have a
> serious investigation on what is causing this bug. The explanation we had so far
> were not really helpful in understanding the problem.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Yogesh Narayan Gaur]

Hi Frieder,

> -----Original Message-----
> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
> Sent: Wednesday, October 31, 2018 8:01 PM
> To: Schrempf Frieder <frieder.schrempf@kontron.De>
> Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org;
> dwmw2@infradead.org; computersforpeace@gmail.com;
> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
> shawnguo@kernel.org
> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
> 
> On Wed, 31 Oct 2018 13:54:29 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
> > Hi Boris,
> >
> > On 31.10.18 14:40, Boris Brezillon wrote:
> > > Hi Frieder, Yogesh,
> > >
> > > On Thu,  5 Jul 2018 13:14:56 +0200
> > > Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> > >
> > >> Now that the SPI memory interface was introduced by Boris [1], it
> > >> is possible to move drivers from mtd/spi-nor to the SPI framework
> > >> in order to use them for different type of SPI memory chips.
> > >>
> > >> Patch 1 adds a function spi_mem_get_name() to the SPI memory
> > >> interface and a ->name field to struct spi_mem.
> > >> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> > >> drivers to provide a custom naming scheme for the flash chip.
> > >> This is needed to avoid breaking compatibility of mtdparts when
> > >> switching from the old to the new driver.
> > >>
> > >> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> > >> framework. Together with m25p80.c it can be used to interface SPI
> > >> NOR flashes just as the old driver did. For this to work properly a
> > >> few minor changes to the devicetrees are necessary (see patches 5 to 7).
> > >>
> > >> Patch 8 changes the defconfigs to use the new driver and patch 9
> > >> removes the old driver.
> > >>
> > >> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> > >> Patch 12 adjusts the MAINTAINERS file.
> > >>
> > >> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> > >> The read performance of the new driver is almost the same or even
> > >> better than the old driver, depending on the block size.
> > >> The write performance is a bit slower on average (~10-15%).
> > >>
> > >> The new driver was also tested with the SPI NAND framework [2] and
> > >> a Winbond W25M02GV flash.
> > >>
> > >> If someone has a board that uses both chips selects and/or both
> > >> busses, it would be really nice to have the driver be tested on such a setup.
> > >
> > > Any progress on this front? Yogesh, can you please remind us the
> > > remaining issues? I'd really like to make some progress, otherwise
> > > the conversion to spi-mem will take ages.
> >
> > I definitely want to continue this. I just did not have the time to
> > work on it.
> >
> > I think the only remaining blocking issues is the one that Yogesh
> > reported while testing with two chips on the same bus.
> 
> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and
> push it somewhere so that Yogesh can test it (again).
In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g. 
1. Redefine all mask fields and use BIT(X) for single bit set/unset.
2. Remove function pointer hooks for ->read/->write function.
3. Remove dependency from 'endianess' property from DTS node.
4. Usage of readl_poll_timeout() instead of busy looping.

--
Regards
Yogesh Gaur

 Yogesh, can we please
> make some progress on this? If you really have a bug, that'd be great to have a
> serious investigation on what is causing this bug. The explanation we had so far
> were not really helpful in understanding the problem.

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Yogesh,

On 31.10.18 17:03, Yogesh Narayan Gaur wrote:
> Hi Frieder,
> 
>> -----Original Message-----
>> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
>> Sent: Wednesday, October 31, 2018 8:01 PM
>> To: Schrempf Frieder <frieder.schrempf@kontron.De>
>> Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org;
>> dwmw2@infradead.org; computersforpeace@gmail.com;
>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
>> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>> shawnguo@kernel.org
>> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
>>
>> On Wed, 31 Oct 2018 13:54:29 +0000
>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>
>>> Hi Boris,
>>>
>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>> Hi Frieder, Yogesh,
>>>>
>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>
>>>>> Now that the SPI memory interface was introduced by Boris [1], it
>>>>> is possible to move drivers from mtd/spi-nor to the SPI framework
>>>>> in order to use them for different type of SPI memory chips.
>>>>>
>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory
>>>>> interface and a ->name field to struct spi_mem.
>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>> This is needed to avoid breaking compatibility of mtdparts when
>>>>> switching from the old to the new driver.
>>>>>
>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>> NOR flashes just as the old driver did. For this to work properly a
>>>>> few minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>
>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9
>>>>> removes the old driver.
>>>>>
>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>
>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>> The read performance of the new driver is almost the same or even
>>>>> better than the old driver, depending on the block size.
>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>
>>>>> The new driver was also tested with the SPI NAND framework [2] and
>>>>> a Winbond W25M02GV flash.
>>>>>
>>>>> If someone has a board that uses both chips selects and/or both
>>>>> busses, it would be really nice to have the driver be tested on such a setup.
>>>>
>>>> Any progress on this front? Yogesh, can you please remind us the
>>>> remaining issues? I'd really like to make some progress, otherwise
>>>> the conversion to spi-mem will take ages.
>>>
>>> I definitely want to continue this. I just did not have the time to
>>> work on it.
>>>
>>> I think the only remaining blocking issues is the one that Yogesh
>>> reported while testing with two chips on the same bus.
>>
>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and
>> push it somewhere so that Yogesh can test it (again).
> In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g.
> 1. Redefine all mask fields and use BIT(X) for single bit set/unset.
> 2. Remove function pointer hooks for ->read/->write function.
> 3. Remove dependency from 'endianess' property from DTS node.
> 4. Usage of readl_poll_timeout() instead of busy looping.

Thanks for reminding me. I have these on my list.

Thanks,
Frieder

> 
> --
> Regards
> Yogesh Gaur
> 
>   Yogesh, can we please
>> make some progress on this? If you really have a bug, that'd be great to have a
>> serious investigation on what is causing this bug. The explanation we had so far
>> were not really helpful in understanding the problem.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Yogesh,

On 31.10.18 17:03, Yogesh Narayan Gaur wrote:
> Hi Frieder,
> 
>> -----Original Message-----
>> From: Boris Brezillon [mailto:boris.brezillon@bootlin.com]
>> Sent: Wednesday, October 31, 2018 8:01 PM
>> To: Schrempf Frieder <frieder.schrempf@kontron.De>
>> Cc: linux-mtd@lists.infradead.org; linux-spi@vger.kernel.org;
>> dwmw2@infradead.org; computersforpeace@gmail.com;
>> marek.vasut@gmail.com; richard@nod.at; miquel.raynal@bootlin.com;
>> broonie@kernel.org; David Wolfe <david.wolfe@nxp.com>; Fabio Estevam
>> <fabio.estevam@nxp.com>; Prabhakar Kushwaha
>> <prabhakar.kushwaha@nxp.com>; Yogesh Narayan Gaur
>> <yogeshnarayan.gaur@nxp.com>; Han Xu <han.xu@nxp.com>;
>> shawnguo@kernel.org
>> Subject: Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework
>>
>> On Wed, 31 Oct 2018 13:54:29 +0000
>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>
>>> Hi Boris,
>>>
>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>> Hi Frieder, Yogesh,
>>>>
>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>
>>>>> Now that the SPI memory interface was introduced by Boris [1], it
>>>>> is possible to move drivers from mtd/spi-nor to the SPI framework
>>>>> in order to use them for different type of SPI memory chips.
>>>>>
>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory
>>>>> interface and a ->name field to struct spi_mem.
>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>> This is needed to avoid breaking compatibility of mtdparts when
>>>>> switching from the old to the new driver.
>>>>>
>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>> NOR flashes just as the old driver did. For this to work properly a
>>>>> few minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>
>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9
>>>>> removes the old driver.
>>>>>
>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>
>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>> The read performance of the new driver is almost the same or even
>>>>> better than the old driver, depending on the block size.
>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>
>>>>> The new driver was also tested with the SPI NAND framework [2] and
>>>>> a Winbond W25M02GV flash.
>>>>>
>>>>> If someone has a board that uses both chips selects and/or both
>>>>> busses, it would be really nice to have the driver be tested on such a setup.
>>>>
>>>> Any progress on this front? Yogesh, can you please remind us the
>>>> remaining issues? I'd really like to make some progress, otherwise
>>>> the conversion to spi-mem will take ages.
>>>
>>> I definitely want to continue this. I just did not have the time to
>>> work on it.
>>>
>>> I think the only remaining blocking issues is the one that Yogesh
>>> reported while testing with two chips on the same bus.
>>
>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out) and
>> push it somewhere so that Yogesh can test it (again).
> In next version, please take care of the comments being raised by Boris in NXP FlexSPI controller driver patch series. E.g.
> 1. Redefine all mask fields and use BIT(X) for single bit set/unset.
> 2. Remove function pointer hooks for ->read/->write function.
> 3. Remove dependency from 'endianess' property from DTS node.
> 4. Usage of readl_poll_timeout() instead of busy looping.

Thanks for reminding me. I have these on my list.

Thanks,
Frieder

> 
> --
> Regards
> Yogesh Gaur
> 
>   Yogesh, can we please
>> make some progress on this? If you really have a bug, that'd be great to have a
>> serious investigation on what is causing this bug. The explanation we had so far
>> were not really helpful in understanding the problem.

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Boris, hi Yogesh,

On 31.10.18 15:31, Boris Brezillon wrote:
> On Wed, 31 Oct 2018 13:54:29 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris,
>>
>> On 31.10.18 14:40, Boris Brezillon wrote:
>>> Hi Frieder, Yogesh,
>>>
>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>    
>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>> to use them for different type of SPI memory chips.
>>>>
>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>> and a ->name field to struct spi_mem.
>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>> drivers to provide a custom naming scheme for the flash chip.
>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>> from the old to the new driver.
>>>>
>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>
>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>> the old driver.
>>>>
>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>
>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>> The read performance of the new driver is almost the same or even better
>>>> than the old driver, depending on the block size.
>>>> The write performance is a bit slower on average (~10-15%).
>>>>
>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>> Winbond W25M02GV flash.
>>>>
>>>> If someone has a board that uses both chips selects and/or both busses,
>>>> it would be really nice to have the driver be tested on such a setup.
>>>
>>> Any progress on this front? Yogesh, can you please remind us the
>>> remaining issues? I'd really like to make some progress, otherwise the
>>> conversion to spi-mem will take ages.
>>
>> I definitely want to continue this. I just did not have the time to work
>> on it.
>>
>> I think the only remaining blocking issues is the one that Yogesh
>> reported while testing with two chips on the same bus.
> 
> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
> please make some progress on this? If you really have a bug, that'd be
> great to have a serious investigation on what is causing this bug. The
> explanation we had so far were not really helpful in understanding the
> problem.

I have sent a v4 that is based on v4.20-rc1. I only applied small fixes 
and cosmetic changes.

There is still the hack to avoid AHB buffer invalidation delay (not sure 
if we should keep it for now) and we still need to figure out the 
reported problems with two chips on one bus.

As Yogesh is the only one how has a hardware setup for this, maybe you 
can retry and provide some debugging info?

Unfortunately I'll probably do not have time to switch to the dirmap API 
now, so I'd rather do that as a second step, as it probably won't solve 
our problems either.

Thanks,
Frieder
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

Hi Boris, hi Yogesh,

On 31.10.18 15:31, Boris Brezillon wrote:
> On Wed, 31 Oct 2018 13:54:29 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris,
>>
>> On 31.10.18 14:40, Boris Brezillon wrote:
>>> Hi Frieder, Yogesh,
>>>
>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>    
>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>> to use them for different type of SPI memory chips.
>>>>
>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>> and a ->name field to struct spi_mem.
>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>> drivers to provide a custom naming scheme for the flash chip.
>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>> from the old to the new driver.
>>>>
>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>
>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>> the old driver.
>>>>
>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>
>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>> The read performance of the new driver is almost the same or even better
>>>> than the old driver, depending on the block size.
>>>> The write performance is a bit slower on average (~10-15%).
>>>>
>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>> Winbond W25M02GV flash.
>>>>
>>>> If someone has a board that uses both chips selects and/or both busses,
>>>> it would be really nice to have the driver be tested on such a setup.
>>>
>>> Any progress on this front? Yogesh, can you please remind us the
>>> remaining issues? I'd really like to make some progress, otherwise the
>>> conversion to spi-mem will take ages.
>>
>> I definitely want to continue this. I just did not have the time to work
>> on it.
>>
>> I think the only remaining blocking issues is the one that Yogesh
>> reported while testing with two chips on the same bus.
> 
> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
> please make some progress on this? If you really have a bug, that'd be
> great to have a serious investigation on what is causing this bug. The
> explanation we had so far were not really helpful in understanding the
> problem.

I have sent a v4 that is based on v4.20-rc1. I only applied small fixes 
and cosmetic changes.

There is still the hack to avoid AHB buffer invalidation delay (not sure 
if we should keep it for now) and we still need to figure out the 
reported problems with two chips on one bus.

As Yogesh is the only one how has a hardware setup for this, maybe you 
can retry and provide some debugging info?

Unfortunately I'll probably do not have time to switch to the dirmap API 
now, so I'd rather do that as a second step, as it probably won't solve 
our problems either.

Thanks,
Frieder

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

Hi Frieder,

On Thu, 8 Nov 2018 08:15:55 +0000
Schrempf Frieder <frieder.schrempf@kontron.De> wrote:

> Hi Boris, hi Yogesh,
> 
> On 31.10.18 15:31, Boris Brezillon wrote:
> > On Wed, 31 Oct 2018 13:54:29 +0000
> > Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> >   
> >> Hi Boris,
> >>
> >> On 31.10.18 14:40, Boris Brezillon wrote:  
> >>> Hi Frieder, Yogesh,
> >>>
> >>> On Thu,  5 Jul 2018 13:14:56 +0200
> >>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> >>>      
> >>>> Now that the SPI memory interface was introduced by Boris [1], it is
> >>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
> >>>> to use them for different type of SPI memory chips.
> >>>>
> >>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> >>>> and a ->name field to struct spi_mem.
> >>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> >>>> drivers to provide a custom naming scheme for the flash chip.
> >>>> This is needed to avoid breaking compatibility of mtdparts when switching
> >>>> from the old to the new driver.
> >>>>
> >>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> >>>> framework. Together with m25p80.c it can be used to interface SPI
> >>>> NOR flashes just as the old driver did. For this to work properly a few
> >>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
> >>>>
> >>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> >>>> the old driver.
> >>>>
> >>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> >>>> Patch 12 adjusts the MAINTAINERS file.
> >>>>
> >>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> >>>> The read performance of the new driver is almost the same or even better
> >>>> than the old driver, depending on the block size.
> >>>> The write performance is a bit slower on average (~10-15%).
> >>>>
> >>>> The new driver was also tested with the SPI NAND framework [2] and a
> >>>> Winbond W25M02GV flash.
> >>>>
> >>>> If someone has a board that uses both chips selects and/or both busses,
> >>>> it would be really nice to have the driver be tested on such a setup.  
> >>>
> >>> Any progress on this front? Yogesh, can you please remind us the
> >>> remaining issues? I'd really like to make some progress, otherwise the
> >>> conversion to spi-mem will take ages.  
> >>
> >> I definitely want to continue this. I just did not have the time to work
> >> on it.
> >>
> >> I think the only remaining blocking issues is the one that Yogesh
> >> reported while testing with two chips on the same bus.  
> > 
> > Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
> > and push it somewhere so that Yogesh can test it (again). Yogesh, can we
> > please make some progress on this? If you really have a bug, that'd be
> > great to have a serious investigation on what is causing this bug. The
> > explanation we had so far were not really helpful in understanding the
> > problem.  
> 
> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes 
> and cosmetic changes.
> 
> There is still the hack to avoid AHB buffer invalidation delay (not sure 
> if we should keep it for now)

IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
Maybe you can try that.

> and we still need to figure out the 
> reported problems with two chips on one bus.
> 
> As Yogesh is the only one how has a hardware setup for this, maybe you 
> can retry and provide some debugging info?
> 
> Unfortunately I'll probably do not have time to switch to the dirmap API 
> now, so I'd rather do that as a second step, as it probably won't solve 
> our problems either.

Totally agree with that.

Thanks for sending a v4.

Boris

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Boris Brezillon]

Hi Frieder,

On Thu, 8 Nov 2018 08:15:55 +0000
Schrempf Frieder <frieder.schrempf@kontron.De> wrote:

> Hi Boris, hi Yogesh,
> 
> On 31.10.18 15:31, Boris Brezillon wrote:
> > On Wed, 31 Oct 2018 13:54:29 +0000
> > Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> >   
> >> Hi Boris,
> >>
> >> On 31.10.18 14:40, Boris Brezillon wrote:  
> >>> Hi Frieder, Yogesh,
> >>>
> >>> On Thu,  5 Jul 2018 13:14:56 +0200
> >>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
> >>>      
> >>>> Now that the SPI memory interface was introduced by Boris [1], it is
> >>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
> >>>> to use them for different type of SPI memory chips.
> >>>>
> >>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
> >>>> and a ->name field to struct spi_mem.
> >>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
> >>>> drivers to provide a custom naming scheme for the flash chip.
> >>>> This is needed to avoid breaking compatibility of mtdparts when switching
> >>>> from the old to the new driver.
> >>>>
> >>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
> >>>> framework. Together with m25p80.c it can be used to interface SPI
> >>>> NOR flashes just as the old driver did. For this to work properly a few
> >>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
> >>>>
> >>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
> >>>> the old driver.
> >>>>
> >>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
> >>>> Patch 12 adjusts the MAINTAINERS file.
> >>>>
> >>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
> >>>> The read performance of the new driver is almost the same or even better
> >>>> than the old driver, depending on the block size.
> >>>> The write performance is a bit slower on average (~10-15%).
> >>>>
> >>>> The new driver was also tested with the SPI NAND framework [2] and a
> >>>> Winbond W25M02GV flash.
> >>>>
> >>>> If someone has a board that uses both chips selects and/or both busses,
> >>>> it would be really nice to have the driver be tested on such a setup.  
> >>>
> >>> Any progress on this front? Yogesh, can you please remind us the
> >>> remaining issues? I'd really like to make some progress, otherwise the
> >>> conversion to spi-mem will take ages.  
> >>
> >> I definitely want to continue this. I just did not have the time to work
> >> on it.
> >>
> >> I think the only remaining blocking issues is the one that Yogesh
> >> reported while testing with two chips on the same bus.  
> > 
> > Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
> > and push it somewhere so that Yogesh can test it (again). Yogesh, can we
> > please make some progress on this? If you really have a bug, that'd be
> > great to have a serious investigation on what is causing this bug. The
> > explanation we had so far were not really helpful in understanding the
> > problem.  
> 
> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes 
> and cosmetic changes.
> 
> There is still the hack to avoid AHB buffer invalidation delay (not sure 
> if we should keep it for now)

IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
Maybe you can try that.

> and we still need to figure out the 
> reported problems with two chips on one bus.
> 
> As Yogesh is the only one how has a hardware setup for this, maybe you 
> can retry and provide some debugging info?
> 
> Unfortunately I'll probably do not have time to switch to the dirmap API 
> now, so I'd rather do that as a second step, as it probably won't solve 
> our problems either.

Totally agree with that.

Thanks for sending a v4.

Boris

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

On 08.11.18 09:19, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu, 8 Nov 2018 08:15:55 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris, hi Yogesh,
>>
>> On 31.10.18 15:31, Boris Brezillon wrote:
>>> On Wed, 31 Oct 2018 13:54:29 +0000
>>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>>    
>>>> Hi Boris,
>>>>
>>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>>> Hi Frieder, Yogesh,
>>>>>
>>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>>       
>>>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>>>> to use them for different type of SPI memory chips.
>>>>>>
>>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>>>> and a ->name field to struct spi_mem.
>>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>>>> from the old to the new driver.
>>>>>>
>>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>>
>>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>>>> the old driver.
>>>>>>
>>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>>
>>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>>> The read performance of the new driver is almost the same or even better
>>>>>> than the old driver, depending on the block size.
>>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>>
>>>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>>>> Winbond W25M02GV flash.
>>>>>>
>>>>>> If someone has a board that uses both chips selects and/or both busses,
>>>>>> it would be really nice to have the driver be tested on such a setup.
>>>>>
>>>>> Any progress on this front? Yogesh, can you please remind us the
>>>>> remaining issues? I'd really like to make some progress, otherwise the
>>>>> conversion to spi-mem will take ages.
>>>>
>>>> I definitely want to continue this. I just did not have the time to work
>>>> on it.
>>>>
>>>> I think the only remaining blocking issues is the one that Yogesh
>>>> reported while testing with two chips on the same bus.
>>>
>>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
>>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
>>> please make some progress on this? If you really have a bug, that'd be
>>> great to have a serious investigation on what is causing this bug. The
>>> explanation we had so far were not really helpful in understanding the
>>> problem.
>>
>> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes
>> and cosmetic changes.
>>
>> There is still the hack to avoid AHB buffer invalidation delay (not sure
>> if we should keep it for now)
> 
> IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
> Maybe you can try that.

Right, I will do some experiments.

>> and we still need to figure out the
>> reported problems with two chips on one bus.
>>
>> As Yogesh is the only one how has a hardware setup for this, maybe you
>> can retry and provide some debugging info?
>>
>> Unfortunately I'll probably do not have time to switch to the dirmap API
>> now, so I'd rather do that as a second step, as it probably won't solve
>> our problems either.
> 
> Totally agree with that.
> 
> Thanks for sending a v4.
> 
> Boris
> 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

On 08.11.18 09:19, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu, 8 Nov 2018 08:15:55 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris, hi Yogesh,
>>
>> On 31.10.18 15:31, Boris Brezillon wrote:
>>> On Wed, 31 Oct 2018 13:54:29 +0000
>>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>>    
>>>> Hi Boris,
>>>>
>>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>>> Hi Frieder, Yogesh,
>>>>>
>>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>>       
>>>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>>>> to use them for different type of SPI memory chips.
>>>>>>
>>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>>>> and a ->name field to struct spi_mem.
>>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>>>> from the old to the new driver.
>>>>>>
>>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>>
>>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>>>> the old driver.
>>>>>>
>>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>>
>>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>>> The read performance of the new driver is almost the same or even better
>>>>>> than the old driver, depending on the block size.
>>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>>
>>>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>>>> Winbond W25M02GV flash.
>>>>>>
>>>>>> If someone has a board that uses both chips selects and/or both busses,
>>>>>> it would be really nice to have the driver be tested on such a setup.
>>>>>
>>>>> Any progress on this front? Yogesh, can you please remind us the
>>>>> remaining issues? I'd really like to make some progress, otherwise the
>>>>> conversion to spi-mem will take ages.
>>>>
>>>> I definitely want to continue this. I just did not have the time to work
>>>> on it.
>>>>
>>>> I think the only remaining blocking issues is the one that Yogesh
>>>> reported while testing with two chips on the same bus.
>>>
>>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
>>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
>>> please make some progress on this? If you really have a bug, that'd be
>>> great to have a serious investigation on what is causing this bug. The
>>> explanation we had so far were not really helpful in understanding the
>>> problem.
>>
>> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes
>> and cosmetic changes.
>>
>> There is still the hack to avoid AHB buffer invalidation delay (not sure
>> if we should keep it for now)
> 
> IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
> Maybe you can try that.

Right, I will do some experiments.

>> and we still need to figure out the
>> reported problems with two chips on one bus.
>>
>> As Yogesh is the only one how has a hardware setup for this, maybe you
>> can retry and provide some debugging info?
>>
>> Unfortunately I'll probably do not have time to switch to the dirmap API
>> now, so I'd rather do that as a second step, as it probably won't solve
>> our problems either.
> 
> Totally agree with that.
> 
> Thanks for sending a v4.
> 
> Boris
> 

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

On 08.11.18 09:19, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu, 8 Nov 2018 08:15:55 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris, hi Yogesh,
>>
>> On 31.10.18 15:31, Boris Brezillon wrote:
>>> On Wed, 31 Oct 2018 13:54:29 +0000
>>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>>    
>>>> Hi Boris,
>>>>
>>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>>> Hi Frieder, Yogesh,
>>>>>
>>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>>       
>>>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>>>> to use them for different type of SPI memory chips.
>>>>>>
>>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>>>> and a ->name field to struct spi_mem.
>>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>>>> from the old to the new driver.
>>>>>>
>>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>>
>>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>>>> the old driver.
>>>>>>
>>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>>
>>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>>> The read performance of the new driver is almost the same or even better
>>>>>> than the old driver, depending on the block size.
>>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>>
>>>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>>>> Winbond W25M02GV flash.
>>>>>>
>>>>>> If someone has a board that uses both chips selects and/or both busses,
>>>>>> it would be really nice to have the driver be tested on such a setup.
>>>>>
>>>>> Any progress on this front? Yogesh, can you please remind us the
>>>>> remaining issues? I'd really like to make some progress, otherwise the
>>>>> conversion to spi-mem will take ages.
>>>>
>>>> I definitely want to continue this. I just did not have the time to work
>>>> on it.
>>>>
>>>> I think the only remaining blocking issues is the one that Yogesh
>>>> reported while testing with two chips on the same bus.
>>>
>>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
>>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
>>> please make some progress on this? If you really have a bug, that'd be
>>> great to have a serious investigation on what is causing this bug. The
>>> explanation we had so far were not really helpful in understanding the
>>> problem.
>>
>> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes
>> and cosmetic changes.

I forgot to add, that I have pushed the v4 here if someone needs it:

https://github.com/fschrempf/linux/commits/fsl-qspi-next-4

>>
>> There is still the hack to avoid AHB buffer invalidation delay (not sure
>> if we should keep it for now)
> 
> IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
> Maybe you can try that.
> 
>> and we still need to figure out the
>> reported problems with two chips on one bus.
>>
>> As Yogesh is the only one how has a hardware setup for this, maybe you
>> can retry and provide some debugging info?
>>
>> Unfortunately I'll probably do not have time to switch to the dirmap API
>> now, so I'd rather do that as a second step, as it probably won't solve
>> our problems either.
> 
> Totally agree with that.
> 
> Thanks for sending a v4.
> 
> Boris
> 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 00/12] Port the FSL QSPI driver to the SPI framework

[Schrempf Frieder]

On 08.11.18 09:19, Boris Brezillon wrote:
> Hi Frieder,
> 
> On Thu, 8 Nov 2018 08:15:55 +0000
> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
> 
>> Hi Boris, hi Yogesh,
>>
>> On 31.10.18 15:31, Boris Brezillon wrote:
>>> On Wed, 31 Oct 2018 13:54:29 +0000
>>> Schrempf Frieder <frieder.schrempf@kontron.De> wrote:
>>>    
>>>> Hi Boris,
>>>>
>>>> On 31.10.18 14:40, Boris Brezillon wrote:
>>>>> Hi Frieder, Yogesh,
>>>>>
>>>>> On Thu,  5 Jul 2018 13:14:56 +0200
>>>>> Frieder Schrempf <frieder.schrempf@exceet.de> wrote:
>>>>>       
>>>>>> Now that the SPI memory interface was introduced by Boris [1], it is
>>>>>> possible to move drivers from mtd/spi-nor to the SPI framework in order
>>>>>> to use them for different type of SPI memory chips.
>>>>>>
>>>>>> Patch 1 adds a function spi_mem_get_name() to the SPI memory interface
>>>>>> and a ->name field to struct spi_mem.
>>>>>> Patch 2 uses it in m25p80.c to make it possible for SPI controller
>>>>>> drivers to provide a custom naming scheme for the flash chip.
>>>>>> This is needed to avoid breaking compatibility of mtdparts when switching
>>>>>> from the old to the new driver.
>>>>>>
>>>>>> Patch 3 adds a driver for the Freescale QSPI controller to the SPI
>>>>>> framework. Together with m25p80.c it can be used to interface SPI
>>>>>> NOR flashes just as the old driver did. For this to work properly a few
>>>>>> minor changes to the devicetrees are necessary (see patches 5 to 7).
>>>>>>
>>>>>> Patch 8 changes the defconfigs to use the new driver and patch 9 removes
>>>>>> the old driver.
>>>>>>
>>>>>> Patch 10 and 11 remove 'fsl,qspi-has-second-chip' from the devicetrees.
>>>>>> Patch 12 adjusts the MAINTAINERS file.
>>>>>>
>>>>>> The new driver was tested with i.MX6UL and a Micron SPI NOR @ 60MHz.
>>>>>> The read performance of the new driver is almost the same or even better
>>>>>> than the old driver, depending on the block size.
>>>>>> The write performance is a bit slower on average (~10-15%).
>>>>>>
>>>>>> The new driver was also tested with the SPI NAND framework [2] and a
>>>>>> Winbond W25M02GV flash.
>>>>>>
>>>>>> If someone has a board that uses both chips selects and/or both busses,
>>>>>> it would be really nice to have the driver be tested on such a setup.
>>>>>
>>>>> Any progress on this front? Yogesh, can you please remind us the
>>>>> remaining issues? I'd really like to make some progress, otherwise the
>>>>> conversion to spi-mem will take ages.
>>>>
>>>> I definitely want to continue this. I just did not have the time to work
>>>> on it.
>>>>
>>>> I think the only remaining blocking issues is the one that Yogesh
>>>> reported while testing with two chips on the same bus.
>>>
>>> Maybe you can send a new version rebased on v4.20-rc1 (when it's out)
>>> and push it somewhere so that Yogesh can test it (again). Yogesh, can we
>>> please make some progress on this? If you really have a bug, that'd be
>>> great to have a serious investigation on what is causing this bug. The
>>> explanation we had so far were not really helpful in understanding the
>>> problem.
>>
>> I have sent a v4 that is based on v4.20-rc1. I only applied small fixes
>> and cosmetic changes.

I forgot to add, that I have pushed the v4 here if someone needs it:

https://github.com/fschrempf/linux/commits/fsl-qspi-next-4

>>
>> There is still the hack to avoid AHB buffer invalidation delay (not sure
>> if we should keep it for now)
> 
> IIRC, Yogesh proposed to replace this hack by a RESET+smaller-delay.
> Maybe you can try that.
> 
>> and we still need to figure out the
>> reported problems with two chips on one bus.
>>
>> As Yogesh is the only one how has a hardware setup for this, maybe you
>> can retry and provide some debugging info?
>>
>> Unfortunately I'll probably do not have time to switch to the dirmap API
>> now, so I'd rather do that as a second step, as it probably won't solve
>> our problems either.
> 
> Totally agree with that.
> 
> Thanks for sending a v4.
> 
> Boris
>