Hi Brian, I will be on vacation till 2016 January, 4th. I will try to answer your questions as soon as possible. Best regards, Cyrille Le 18/12/2015 02:55, Brian Norris a écrit : > Hi Cyrille, > > On Mon, Dec 07, 2015 at 03:09:10PM +0100, Cyrille Pitchen wrote: >> The quad (or dual) mode of a spi-nor memory may be enabled at boot time by >> non-volatile bits in some setting register. Also such a mode may have >> already been enabled at early stage by some boot loader. >> >> Hence, we should not guess the spi-nor memory is always configured for the >> regular SPI 1-1-1 protocol. >> >> Micron and Macronix memories, once their Quad (or dual for Micron) mode >> enabled, no longer process the regular JEDEC Read ID (0x9f) command but >> instead reply to a new command: JEDEC Read ID Multiple I/O (0xaf). >> Besides, in Quad mode both memory manufacturers expect ALL commands to >> use the SPI 4-4-4 protocol. For Micron memories, enabling their Dual mode >> implies to use the SPI 2-2-2 protocol for ALL commands. >> >> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@xxxxxxxxx> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 52 +++++++++++++++++++++++++++++++++++++++---- >> include/linux/mtd/spi-nor.h | 23 +++++++++++++++++-- >> 2 files changed, 69 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index 3b2460efc019..bf17736750c1 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -73,6 +73,11 @@ struct flash_info { >> >> #define JEDEC_MFR(info) ((info)->id[0]) >> >> +struct read_id_config { >> + enum read_mode mode; >> + enum spi_protocol proto; >> +}; >> + >> static const struct flash_info *spi_nor_match_id(const char *name); >> >> /* >> @@ -867,11 +872,16 @@ static const struct flash_info spi_nor_ids[] = { >> { }, >> }; >> >> -static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) >> +static const struct flash_info *spi_nor_read_id(struct spi_nor *nor, >> + enum read_mode mode) > > It's unclear what you're trying to do with the 'read_mode' enum now. > (Admittedly it may not be clear in the current code either, given the > confusion we already have over Micron support.) > > Would you care to document it better? > >> { >> - int tmp; >> + int i, tmp; >> u8 id[SPI_NOR_MAX_ID_LEN]; >> const struct flash_info *info; >> + static const struct read_id_config configs[] = { >> + {SPI_NOR_QUAD, SPI_PROTO_4_4_4}, >> + {SPI_NOR_DUAL, SPI_PROTO_2_2_2} >> + }; >> >> tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN); >> if (tmp < 0) { >> @@ -879,6 +889,34 @@ static const struct flash_info *spi_nor_read_id(struct spi_nor *nor) >> return ERR_PTR(tmp); >> } >> >> + /* Special case for Micron/Macronix qspi nor. */ >> + if ((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) || >> + (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)) >> + for (i = 0; i < ARRAY_SIZE(configs); ++i) { >> + if (configs[i].mode != mode) >> + continue; >> + >> + /* Set this protocol for all commands. */ >> + nor->reg_proto = configs[i].proto; >> + nor->read_proto = configs[i].proto; >> + nor->write_proto = configs[i].proto; >> + nor->erase_proto = configs[i].proto; > > Are these all fully independent? Do we really need 4 fields for this? > >> + >> + /* >> + * Multiple I/O Read ID only returns the Manufacturer ID >> + * (1 byte) and the Device ID (2 bytes). So we reset the >> + * remaining bytes. >> + */ >> + memset(id, 0, sizeof(id)); >> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID, id, 3); >> + if (tmp < 0) { >> + dev_dbg(nor->dev, >> + "error %d reading JEDEC ID Multi I/O\n", >> + tmp); >> + return ERR_PTR(tmp); >> + } >> + } >> + >> for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) { >> info = &spi_nor_ids[tmp]; >> if (info->id_len) { >> @@ -1178,11 +1216,17 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) >> if (ret) >> return ret; >> >> + /* Reset SPI protocol for all commands */ >> + nor->erase_proto = SPI_PROTO_1_1_1; >> + nor->read_proto = SPI_PROTO_1_1_1; >> + nor->write_proto = SPI_PROTO_1_1_1; >> + nor->reg_proto = SPI_PROTO_1_1_1; >> + >> if (name) >> info = spi_nor_match_id(name); >> /* Try to auto-detect if chip name wasn't specified or not found */ >> if (!info) >> - info = spi_nor_read_id(nor); >> + info = spi_nor_read_id(nor, mode); >> if (IS_ERR_OR_NULL(info)) >> return -ENOENT; >> >> @@ -1193,7 +1237,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, enum read_mode mode) >> if (name && info->id_len) { >> const struct flash_info *jinfo; >> >> - jinfo = spi_nor_read_id(nor); >> + jinfo = spi_nor_read_id(nor, mode); >> if (IS_ERR(jinfo)) { >> return PTR_ERR(jinfo); >> } else if (jinfo != info) { >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h >> index fac3f6f53981..c91986a99caf 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -75,8 +75,9 @@ >> #define SPINOR_OP_BRWR 0x17 /* Bank register write */ >> >> /* Used for Micron flashes only. */ >> -#define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ >> -#define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ >> +#define SPINOR_OP_MIO_RDID 0xaf /* Multiple I/O Read JEDEC ID */ >> +#define SPINOR_OP_RD_EVCR 0x65 /* Read EVCR register */ >> +#define SPINOR_OP_WD_EVCR 0x61 /* Write EVCR register */ >> >> /* Status Register bits. */ >> #define SR_WIP BIT(0) /* Write in progress */ >> @@ -105,6 +106,16 @@ enum read_mode { >> SPI_NOR_QUAD, >> }; >> >> +enum spi_protocol { >> + SPI_PROTO_1_1_1, /* SPI */ >> + SPI_PROTO_1_1_2, /* Dual Output */ >> + SPI_PROTO_1_1_4, /* Quad Output */ >> + SPI_PROTO_1_2_2, /* Dual IO */ >> + SPI_PROTO_1_4_4, /* Quad IO */ >> + SPI_PROTO_2_2_2, /* Dual Command */ >> + SPI_PROTO_4_4_4, /* Quad Command */ > > Would it help at all to make this enum into something more like a > bitfield? So in some cases, rather than a bit switch block, we can just > extract the "number of lines" from the integer value? e.g.: > > #define SNOR_PROTO(command, addr, data) \ > (((command) << 0) | \ > ((addr) << 4) | \ > ((data) << 8)) // or some other kind of macro magic > > enum spi_nor_protocol { > SNOR_PROTO_1_1_1 = SNOR_PROTO(1, 1, 1), > SNOR_PROTO_1_1_2 = SNOR_PROTO(1, 1, 2), > ... > }; > > static inline int spi_nor_io_lines_command(enum spi_nor_protocol proto) > { > return proto & 0xf; > } > > (Similar for addr and data phases. Also, my naming might suck. Feel free > to improve!) > > I don't think we should stomp on the SPI namespace with the > "SPI_PROTO_*" definitions. That's why I chose SNOR_PROTO_ and spi_nor_ > prefixes. > > Brian > >> +}; >> + >> #define SPI_NOR_MAX_CMD_SIZE 8 >> enum spi_nor_ops { >> SPI_NOR_OPS_READ = 0, >> @@ -132,6 +143,10 @@ enum spi_nor_option_flags { >> * @flash_read: the mode of the read >> * @sst_write_second: used by the SST write operation >> * @flags: flag options for the current SPI-NOR (SNOR_F_*) >> + * @erase_proto: the SPI protocol used by erase operations >> + * @read_proto: the SPI protocol used by read operations >> + * @write_proto: the SPI protocol used by write operations >> + * @reg_proto the SPI protocol used by read_reg/write_reg operations >> * @cmd_buf: used by the write_reg >> * @prepare: [OPTIONAL] do some preparations for the >> * read/write/erase/lock/unlock operations >> @@ -160,6 +175,10 @@ struct spi_nor { >> u8 read_opcode; >> u8 read_dummy; >> u8 program_opcode; >> + enum spi_protocol erase_proto; >> + enum spi_protocol read_proto; >> + enum spi_protocol write_proto; >> + enum spi_protocol reg_proto; >> enum read_mode flash_read; >> bool sst_write_second; >> u32 flags; >> -- >> 1.8.2.2 >> -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html