Re: [U-Boot] [PATCH v2 04/11] mtd: spi: Port SPI NOR framework from Linux

2019-01-28 Thread Vignesh R


On 28/01/19 12:18 AM, Jagan Teki wrote:
> Do you have this whole series in some branch in github? I'm unable to
> apply it on master.
> 

Here is my tentative v3 branch[1] based on top of today's master. I
haven't got to splitting up this patch yet. But have addressed all other
comments by you and Simon on this version.

[1] https://github.com/r-vignesh/u-boot.git branch: spi-nor-mig-patch-v3

Let me know if there are any additional comments. Thanks for the review!

> On Fri, Dec 21, 2018 at 12:15 PM Vignesh R  wrote:
>>
>> Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
>> support 4 byte addressing opcodes, SFDP table parsing and different types of
>> quad mode enable sequences. Many newer flashes no longer support BANK
>> registers used by sf layer to a access >16MB space.
>> Also, many SPI controllers have special MMIO interfaces which provide
>> accelerated read/write access but require knowledge of flash parameters
>> to make use of it. Recent spi-mem layer provides a way to support such
>> flashes but sf layer isn't using that.
>> So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
>> in order to gain 4 byte addressing support, SFDP support and a way to
>> support SPI controllers with MMIO flash interface.
> 
> Understand the usage if direct complete sync, however it's difficult
> for me to review whole stuff. Can you please break into few patches
> like Basic sync, SFDP and other.
> 

Ok, Let me see how that can be done.

>>
>> Signed-off-by: Vignesh R 
>> ---
>>  drivers/mtd/spi/spi-nor-core.c | 2590 
>>  include/linux/mtd/cfi.h|   32 +
>>  include/linux/mtd/spi-nor.h|  410 +
>>  3 files changed, 3032 insertions(+)
>>  create mode 100644 drivers/mtd/spi/spi-nor-core.c
>>  create mode 100644 include/linux/mtd/cfi.h
>>  create mode 100644 include/linux/mtd/spi-nor.h
>>
[...]
>> +static int spi_nor_sr_ready(struct spi_nor *nor)
>> +{
>> +   int sr = read_sr(nor);
>> +
>> +   if (sr < 0)
>> +   return sr;
>> +
>> +#ifndef CONFIG_SPL_BUILD
>> +   if (nor->flags & SNOR_F_USE_CLSR && sr & (SR_E_ERR | SR_P_ERR)) {
>> +   if (sr & SR_E_ERR)
>> +   dev_dbg(nor->dev, "Erase Error occurred\n");
>> +   else
>> +   dev_dbg(nor->dev, "Programming Error occurred\n");
>> +
>> +   nor->write_reg(nor, SPINOR_OP_CLSR, NULL, 0);
>> +   return -EIO;
>> +   }
>> +#endif
> 
> Does it increase SPL size? or do we always assume SPL can't access
> flash that would require CLSR?
> 

Code size increase.. But now that we have SPI_FLASH_TINY, will drop this...

>> +
>> +   return !(sr & SR_WIP);
>> +}
>> +

[...]
>> +enum spi_nor_read_command_index {
>> +   SNOR_CMD_READ,
>> +   SNOR_CMD_READ_FAST,
>> +   SNOR_CMD_READ_1_1_1_DTR,
>> +
>> +   /* Dual SPI */
>> +   SNOR_CMD_READ_1_1_2,
>> +   SNOR_CMD_READ_1_2_2,
>> +   SNOR_CMD_READ_2_2_2,
>> +   SNOR_CMD_READ_1_2_2_DTR,
>> +
>> +   /* Quad SPI */
>> +   SNOR_CMD_READ_1_1_4,
>> +   SNOR_CMD_READ_1_4_4,
>> +   SNOR_CMD_READ_4_4_4,
>> +   SNOR_CMD_READ_1_4_4_DTR,
>> +
>> +   /* Octo SPI */
>> +   SNOR_CMD_READ_1_1_8,
>> +   SNOR_CMD_READ_1_8_8,
>> +   SNOR_CMD_READ_8_8_8,
>> +   SNOR_CMD_READ_1_8_8_DTR,
>> +
>> +   SNOR_CMD_READ_MAX
>> +};
>> +
>> +enum spi_nor_pp_command_index {
>> +   SNOR_CMD_PP,
>> +
>> +   /* Quad SPI */
>> +   SNOR_CMD_PP_1_1_4,
>> +   SNOR_CMD_PP_1_4_4,
>> +   SNOR_CMD_PP_4_4_4,
>> +
>> +   /* Octo SPI */
>> +   SNOR_CMD_PP_1_1_8,
>> +   SNOR_CMD_PP_1_8_8,
>> +   SNOR_CMD_PP_8_8_8,
>> +
>> +   SNOR_CMD_PP_MAX
>> +};
> 
> I'm afraid whether we teatsed all thse combinations? or we doing for
> the sake of Linux sync?
> 

Code exists for 1_1_1, 1_1_2,  1_1_4 and 4_4_4 modes and has been tested
(on par with current U-Boot SF stack). 1-2-2 and 1-4-4 should work with
SFDP(haven't tested it on a real hw though). Other modes are not
implemented (but exists as a result of sync up with Linux) and enums are
dummy definitions with no effect on code (are there for future use). I
can drop unused once if you prefer.

-- 
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 04/11] mtd: spi: Port SPI NOR framework from Linux

2019-01-27 Thread Jagan Teki
Do you have this whole series in some branch in github? I'm unable to
apply it on master.

On Fri, Dec 21, 2018 at 12:15 PM Vignesh R  wrote:
>
> Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
> support 4 byte addressing opcodes, SFDP table parsing and different types of
> quad mode enable sequences. Many newer flashes no longer support BANK
> registers used by sf layer to a access >16MB space.
> Also, many SPI controllers have special MMIO interfaces which provide
> accelerated read/write access but require knowledge of flash parameters
> to make use of it. Recent spi-mem layer provides a way to support such
> flashes but sf layer isn't using that.
> So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
> in order to gain 4 byte addressing support, SFDP support and a way to
> support SPI controllers with MMIO flash interface.

Understand the usage if direct complete sync, however it's difficult
for me to review whole stuff. Can you please break into few patches
like Basic sync, SFDP and other.

>
> Signed-off-by: Vignesh R 
> ---
>  drivers/mtd/spi/spi-nor-core.c | 2590 
>  include/linux/mtd/cfi.h|   32 +
>  include/linux/mtd/spi-nor.h|  410 +
>  3 files changed, 3032 insertions(+)
>  create mode 100644 drivers/mtd/spi/spi-nor-core.c
>  create mode 100644 include/linux/mtd/cfi.h
>  create mode 100644 include/linux/mtd/spi-nor.h
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> new file mode 100644
> index ..597898d3b4af
> --- /dev/null
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -0,0 +1,2590 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Based on m25p80.c, by Mike Lavender (m...@steroidmicros.com), with
> + * influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c
> + *
> + * Copyright (C) 2005, Intec Automation Inc.
> + * Copyright (C) 2014, Freescale Semiconductor, Inc.
> + *
> + * Synced from Linux v4.19
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Define max times to check status register before we give up. */
> +
> +/*
> + * For everything but full-chip erase; probably could be much smaller, but 
> kept
> + * around for safety for now
> + */
> +
> +#define HZ CONFIG_SYS_HZ
> +
> +#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
> +
> +#define SPI_NOR_MAX_ID_LEN 6
> +#define SPI_NOR_MAX_ADDR_WIDTH 4
> +
> +struct flash_info {
> +   char*name;
> +
> +   /*
> +* This array stores the ID bytes.
> +* The first three bytes are the JEDIC ID.
> +* JEDEC ID zero means "no ID" (mostly older chips).
> +*/
> +   u8  id[SPI_NOR_MAX_ID_LEN];
> +   u8  id_len;
> +
> +   /* The size listed here is what works with SPINOR_OP_SE, which isn't
> +* necessarily called a "sector" by the vendor.
> +*/
> +   unsigned intsector_size;
> +   u16 n_sectors;
> +
> +   u16 page_size;
> +   u16 addr_width;
> +
> +   u16 flags;
> +#define SECT_4KBIT(0)  /* SPINOR_OP_BE_4K works 
> uniformly */
> +#define SPI_NOR_NO_ERASE   BIT(1)  /* No erase command needed */
> +#define SST_WRITE  BIT(2)  /* use SST byte programming */
> +#define SPI_NOR_NO_FR  BIT(3)  /* Can't do fastread */
> +#define SECT_4K_PMCBIT(4)  /* SPINOR_OP_BE_4K_PMC works 
> uniformly */
> +#define SPI_NOR_DUAL_READ  BIT(5)  /* Flash supports Dual Read */
> +#define SPI_NOR_QUAD_READ  BIT(6)  /* Flash supports Quad Read */
> +#define USE_FSRBIT(7)  /* use flag status register */
> +#define SPI_NOR_HAS_LOCK   BIT(8)  /* Flash supports lock/unlock via SR 
> */
> +#define SPI_NOR_HAS_TB BIT(9)  /*
> +* Flash SR has Top/Bottom (TB) 
> protect
> +* bit. Must be used with
> +* SPI_NOR_HAS_LOCK.
> +*/
> +#defineSPI_S3ANBIT(10) /*
> +* Xilinx Spartan 3AN In-System Flash
> +* (MFR cannot be used for probing
> +* because it has the same value as
> +* ATMEL flashes)
> +*/
> +#define SPI_NOR_4B_OPCODES BIT(11) /*
> +* Use dedicated 4byte address op 
> codes
> +* to support memory size above 
> 128Mib.
> +*/
> +#define NO_CHIP_ERASE  BIT(12) /* Chip does not support chip erase */
> +#defin

[U-Boot] [PATCH v2 04/11] mtd: spi: Port SPI NOR framework from Linux

2018-12-20 Thread Vignesh R
Current U-Boot SPI NOR support (sf layer) is quite outdated as it does not
support 4 byte addressing opcodes, SFDP table parsing and different types of
quad mode enable sequences. Many newer flashes no longer support BANK
registers used by sf layer to a access >16MB space.
Also, many SPI controllers have special MMIO interfaces which provide
accelerated read/write access but require knowledge of flash parameters
to make use of it. Recent spi-mem layer provides a way to support such
flashes but sf layer isn't using that.
So sync SPI NOR framework from Linux v4.19 and add spi-mem support on top.
in order to gain 4 byte addressing support, SFDP support and a way to
support SPI controllers with MMIO flash interface.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi/spi-nor-core.c | 2590 
 include/linux/mtd/cfi.h|   32 +
 include/linux/mtd/spi-nor.h|  410 +
 3 files changed, 3032 insertions(+)
 create mode 100644 drivers/mtd/spi/spi-nor-core.c
 create mode 100644 include/linux/mtd/cfi.h
 create mode 100644 include/linux/mtd/spi-nor.h

diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
new file mode 100644
index ..597898d3b4af
--- /dev/null
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -0,0 +1,2590 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Based on m25p80.c, by Mike Lavender (m...@steroidmicros.com), with
+ * influence from lart.c (Abraham Van Der Merwe) and mtd_dataflash.c
+ *
+ * Copyright (C) 2005, Intec Automation Inc.
+ * Copyright (C) 2014, Freescale Semiconductor, Inc.
+ *
+ * Synced from Linux v4.19
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Define max times to check status register before we give up. */
+
+/*
+ * For everything but full-chip erase; probably could be much smaller, but kept
+ * around for safety for now
+ */
+
+#define HZ CONFIG_SYS_HZ
+
+#define DEFAULT_READY_WAIT_JIFFIES (40UL * HZ)
+
+#define SPI_NOR_MAX_ID_LEN 6
+#define SPI_NOR_MAX_ADDR_WIDTH 4
+
+struct flash_info {
+   char*name;
+
+   /*
+* This array stores the ID bytes.
+* The first three bytes are the JEDIC ID.
+* JEDEC ID zero means "no ID" (mostly older chips).
+*/
+   u8  id[SPI_NOR_MAX_ID_LEN];
+   u8  id_len;
+
+   /* The size listed here is what works with SPINOR_OP_SE, which isn't
+* necessarily called a "sector" by the vendor.
+*/
+   unsigned intsector_size;
+   u16 n_sectors;
+
+   u16 page_size;
+   u16 addr_width;
+
+   u16 flags;
+#define SECT_4KBIT(0)  /* SPINOR_OP_BE_4K works 
uniformly */
+#define SPI_NOR_NO_ERASE   BIT(1)  /* No erase command needed */
+#define SST_WRITE  BIT(2)  /* use SST byte programming */
+#define SPI_NOR_NO_FR  BIT(3)  /* Can't do fastread */
+#define SECT_4K_PMCBIT(4)  /* SPINOR_OP_BE_4K_PMC works uniformly 
*/
+#define SPI_NOR_DUAL_READ  BIT(5)  /* Flash supports Dual Read */
+#define SPI_NOR_QUAD_READ  BIT(6)  /* Flash supports Quad Read */
+#define USE_FSRBIT(7)  /* use flag status register */
+#define SPI_NOR_HAS_LOCK   BIT(8)  /* Flash supports lock/unlock via SR */
+#define SPI_NOR_HAS_TB BIT(9)  /*
+* Flash SR has Top/Bottom (TB) protect
+* bit. Must be used with
+* SPI_NOR_HAS_LOCK.
+*/
+#defineSPI_S3ANBIT(10) /*
+* Xilinx Spartan 3AN In-System Flash
+* (MFR cannot be used for probing
+* because it has the same value as
+* ATMEL flashes)
+*/
+#define SPI_NOR_4B_OPCODES BIT(11) /*
+* Use dedicated 4byte address op codes
+* to support memory size above 128Mib.
+*/
+#define NO_CHIP_ERASE  BIT(12) /* Chip does not support chip erase */
+#define SPI_NOR_SKIP_SFDP  BIT(13) /* Skip parsing of SFDP tables */
+#define USE_CLSR   BIT(14) /* use CLSR command */
+
+   int (*quad_enable)(struct spi_nor *nor);
+};
+
+#define JEDEC_MFR(info)((info)->id[0])
+
+static int spi_nor_read_write_reg(struct spi_nor *nor, struct spi_mem_op
+   *op, void *buf)
+{
+   if (op->data.dir == SPI_MEM_DATA_IN)
+   op->data.buf.in = buf;
+   else
+   op->data.buf.out = buf;
+   return spi_mem_exec_op(nor->spi, op);
+}
+
+static int spi_nor