* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R This series adds support for octal mode of mt35x flash. Also, adds support for OSPI version of Cadence QSPI controller. Based on top of patches adding basic support for mt35xu512aba here: https://patchwork.ozlabs.org/cover/971437/ Vignesh R (3): mtd: spi-nor: Add Octal mode support for mt35xu512aba dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 4 files changed, 22 insertions(+), 1 deletion(-) -- 2.19.0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: linux-arm-kernel This series adds support for octal mode of mt35x flash. Also, adds support for OSPI version of Cadence QSPI controller. Based on top of patches adding basic support for mt35xu512aba here: https://patchwork.ozlabs.org/cover/971437/ Vignesh R (3): mtd: spi-nor: Add Octal mode support for mt35xu512aba dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 4 files changed, 22 insertions(+), 1 deletion(-) -- 2.19.0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R This series adds support for octal mode of mt35x flash. Also, adds support for OSPI version of Cadence QSPI controller. Based on top of patches adding basic support for mt35xu512aba here: https://patchwork.ozlabs.org/cover/971437/ Vignesh R (3): mtd: spi-nor: Add Octal mode support for mt35xu512aba dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 4 files changed, 22 insertions(+), 1 deletion(-) -- 2.19.0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-03 16:56 ` Vignesh R (?) @ 2018-10-03 16:56 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports read/write over 8 IO lines simulatenously. Add support for Octal read mode for Micron mt35xu512aba. Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem to support newer JESD216C standard that provides auto detection of Octal mode capabilities and opcodes. Therefore, this capability is manually added using new SPI_NOR_OCTAL_READ flag. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index aff5e6ff0b2c..4926e805a8cb 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -90,6 +90,7 @@ struct flash_info { #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 */ +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ int (*quad_enable)(struct spi_nor *nor); }; @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, { SPINOR_OP_READ_1_1_1_DTR, SPINOR_OP_READ_1_1_1_DTR_4B }, { SPINOR_OP_READ_1_2_2_DTR, SPINOR_OP_READ_1_2_2_DTR_4B }, @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, /* Micron */ - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES) }, + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, /* PMC */ { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, SNOR_PROTO_1_1_4); } + if (info->flags & SPI_NOR_OCTAL_READ) { + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_1_1_8], + 0, 8, SPINOR_OP_READ_1_1_8, + SNOR_PROTO_1_1_8); + } + /* Page Program settings. */ params->hwcaps.mask |= SNOR_HWCAPS_PP; spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 8b1acf68b7ac..ae9861ed7e0f 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -50,6 +50,7 @@ #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ @@ -73,6 +74,7 @@ #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: linux-arm-kernel Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports read/write over 8 IO lines simulatenously. Add support for Octal read mode for Micron mt35xu512aba. Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem to support newer JESD216C standard that provides auto detection of Octal mode capabilities and opcodes. Therefore, this capability is manually added using new SPI_NOR_OCTAL_READ flag. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index aff5e6ff0b2c..4926e805a8cb 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -90,6 +90,7 @@ struct flash_info { #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 */ +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ int (*quad_enable)(struct spi_nor *nor); }; @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, { SPINOR_OP_READ_1_1_1_DTR, SPINOR_OP_READ_1_1_1_DTR_4B }, { SPINOR_OP_READ_1_2_2_DTR, SPINOR_OP_READ_1_2_2_DTR_4B }, @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, /* Micron */ - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES) }, + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, /* PMC */ { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, SNOR_PROTO_1_1_4); } + if (info->flags & SPI_NOR_OCTAL_READ) { + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_1_1_8], + 0, 8, SPINOR_OP_READ_1_1_8, + SNOR_PROTO_1_1_8); + } + /* Page Program settings. */ params->hwcaps.mask |= SNOR_HWCAPS_PP; spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 8b1acf68b7ac..ae9861ed7e0f 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -50,6 +50,7 @@ #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ @@ -73,6 +74,7 @@ #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports read/write over 8 IO lines simulatenously. Add support for Octal read mode for Micron mt35xu512aba. Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem to support newer JESD216C standard that provides auto detection of Octal mode capabilities and opcodes. Therefore, this capability is manually added using new SPI_NOR_OCTAL_READ flag. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- include/linux/mtd/spi-nor.h | 2 ++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index aff5e6ff0b2c..4926e805a8cb 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -90,6 +90,7 @@ struct flash_info { #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 */ +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ int (*quad_enable)(struct spi_nor *nor); }; @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, { SPINOR_OP_READ_1_1_1_DTR, SPINOR_OP_READ_1_1_1_DTR_4B }, { SPINOR_OP_READ_1_2_2_DTR, SPINOR_OP_READ_1_2_2_DTR_4B }, @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, /* Micron */ - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES) }, + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, /* PMC */ { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, SNOR_PROTO_1_1_4); } + if (info->flags & SPI_NOR_OCTAL_READ) { + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; + spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_1_1_8], + 0, 8, SPINOR_OP_READ_1_1_8, + SNOR_PROTO_1_1_8); + } + /* Page Program settings. */ params->hwcaps.mask |= SNOR_HWCAPS_PP; spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index 8b1acf68b7ac..ae9861ed7e0f 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -50,6 +50,7 @@ #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ @@ -73,6 +74,7 @@ #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O SPI) */ #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad Output SPI) */ #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O SPI) */ +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal Output SPI) */ #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 bytes) */ #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* RE: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-03 16:56 ` Vignesh R @ 2018-10-04 6:51 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 63+ messages in thread From: Yogesh Narayan Gaur @ 2018-10-04 6:51 UTC (permalink / raw) To: Vignesh R, Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel Hi Vignesh, > -----Original Message----- > From: Vignesh R [mailto:vigneshr@ti.com] > Sent: Wednesday, October 3, 2018 10:26 PM > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > kernel@lists.infradead.org>; linux-mtd@lists.infradead.org; > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R > <vigneshr@ti.com> > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports > read/write over 8 IO lines simulatenously. Add support for Octal read mode for > Micron mt35xu512aba. > Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem > to support newer JESD216C standard that provides auto detection of Octal > mode capabilities and opcodes. Therefore, this capability is manually added > using new SPI_NOR_OCTAL_READ flag. > Thanks for sending the patch-set of adding octal support. If possible, can you share the MT35x datasheet? I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). Also have added support of Octal in driver/spi/spi.c framework. IMO, we would collaborate our patches. -- Regards Yogesh Gaur > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index > aff5e6ff0b2c..4926e805a8cb 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -90,6 +90,7 @@ struct flash_info { > #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 */ > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > int (*quad_enable)(struct spi_nor *nor); > }; > @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) > { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, > { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, > { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, > + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, > > { SPINOR_OP_READ_1_1_1_DTR, > SPINOR_OP_READ_1_1_1_DTR_4B }, > { SPINOR_OP_READ_1_2_2_DTR, > SPINOR_OP_READ_1_2_2_DTR_4B }, > @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { > { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | > USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, > > /* Micron */ > - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | > USE_FSR | SPI_NOR_4B_OPCODES) }, > + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | > USE_FSR > +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, > > /* PMC */ > { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, > @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, > SNOR_PROTO_1_1_4); > } > > + if (info->flags & SPI_NOR_OCTAL_READ) { > + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; > + spi_nor_set_read_settings(¶ms- > >reads[SNOR_CMD_READ_1_1_8], > + 0, 8, SPINOR_OP_READ_1_1_8, > + SNOR_PROTO_1_1_8); > + } > + > /* Page Program settings. */ > params->hwcaps.mask |= SNOR_HWCAPS_PP; > spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index > 8b1acf68b7ac..ae9861ed7e0f 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -50,6 +50,7 @@ > #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O > SPI) */ > #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad > Output SPI) */ > #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O > SPI) */ > +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal > Output SPI) */ > #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ > #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ > #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ > @@ -73,6 +74,7 @@ > #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O > SPI) */ > #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad > Output SPI) */ > #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O > SPI) */ > +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal > Output SPI) */ > #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 > bytes) */ > #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ > #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ > -- > 2.19.0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 6:51 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 63+ messages in thread From: Yogesh Narayan Gaur @ 2018-10-04 6:51 UTC (permalink / raw) To: linux-arm-kernel Hi Vignesh, > -----Original Message----- > From: Vignesh R [mailto:vigneshr at ti.com] > Sent: Wednesday, October 3, 2018 10:26 PM > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > kernel at lists.infradead.org>; linux-mtd at lists.infradead.org; > devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Vignesh R > <vigneshr@ti.com> > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports > read/write over 8 IO lines simulatenously. Add support for Octal read mode for > Micron mt35xu512aba. > Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem > to support newer JESD216C standard that provides auto detection of Octal > mode capabilities and opcodes. Therefore, this capability is manually added > using new SPI_NOR_OCTAL_READ flag. > Thanks for sending the patch-set of adding octal support. If possible, can you share the MT35x datasheet? I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). Also have added support of Octal in driver/spi/spi.c framework. IMO, we would collaborate our patches. -- Regards Yogesh Gaur > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index > aff5e6ff0b2c..4926e805a8cb 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -90,6 +90,7 @@ struct flash_info { > #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 */ > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > int (*quad_enable)(struct spi_nor *nor); > }; > @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) > { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, > { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, > { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, > + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, > > { SPINOR_OP_READ_1_1_1_DTR, > SPINOR_OP_READ_1_1_1_DTR_4B }, > { SPINOR_OP_READ_1_2_2_DTR, > SPINOR_OP_READ_1_2_2_DTR_4B }, > @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { > { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | > USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, > > /* Micron */ > - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | > USE_FSR | SPI_NOR_4B_OPCODES) }, > + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | > USE_FSR > +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, > > /* PMC */ > { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, > @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, > SNOR_PROTO_1_1_4); > } > > + if (info->flags & SPI_NOR_OCTAL_READ) { > + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; > + spi_nor_set_read_settings(¶ms- > >reads[SNOR_CMD_READ_1_1_8], > + 0, 8, SPINOR_OP_READ_1_1_8, > + SNOR_PROTO_1_1_8); > + } > + > /* Page Program settings. */ > params->hwcaps.mask |= SNOR_HWCAPS_PP; > spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index > 8b1acf68b7ac..ae9861ed7e0f 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -50,6 +50,7 @@ > #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O > SPI) */ > #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad > Output SPI) */ > #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O > SPI) */ > +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal > Output SPI) */ > #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ > #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ > #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ > @@ -73,6 +74,7 @@ > #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O > SPI) */ > #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad > Output SPI) */ > #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O > SPI) */ > +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal > Output SPI) */ > #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 > bytes) */ > #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ > #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ > -- > 2.19.0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 6:51 ` Yogesh Narayan Gaur @ 2018-10-04 7:39 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 7:39 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Vignesh R, Marek Vasut, Rob Herring, Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, juliensu, zhengxunli, masonccyang +Julien, Zhengxunli and Mason from Macronix Hi Yogesh, On Thu, 4 Oct 2018 06:51:41 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Vignesh, > > > -----Original Message----- > > From: Vignesh R [mailto:vigneshr@ti.com] > > Sent: Wednesday, October 3, 2018 10:26 PM > > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > > kernel@lists.infradead.org>; linux-mtd@lists.infradead.org; > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R > > <vigneshr@ti.com> > > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba > > > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports > > read/write over 8 IO lines simulatenously. Add support for Octal read mode for > > Micron mt35xu512aba. > > Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem > > to support newer JESD216C standard that provides auto detection of Octal > > mode capabilities and opcodes. Therefore, this capability is manually added > > using new SPI_NOR_OCTAL_READ flag. > > > > Thanks for sending the patch-set of adding octal support. > If possible, can you share the MT35x datasheet? > > I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). > Also have added support of Octal in driver/spi/spi.c framework. > > IMO, we would collaborate our patches. Looks like we are of stepping on each others toes here (see this branch [1]). I guess it's not a problem if we agree on who is working on what. Yogesh, you already sent "spi: add flags for octal I/O data transfer" [3] which is only adding the new OCTAL flags but is not patching spi.c and spi-mem.c to take those new flags into account. Here is my version of this patch [2] (it's still missing an update of SPI_MEM_MAX_BUSWIDTH). Let me know what you want to do (rework your version to address the problem or take mine). Regarding other patches in [2], they're mainly here to add support for X-X-X and DTR modes and get the m25p80 logic integrated in spi-nor.c so that we can really check which NOR operations are supported by the SPI controller. Regards, Boris [1]https://github.com/bbrezillon/linux/commits/spi-nor/octo [2]https://github.com/bbrezillon/linux/commit/9854a8fdd23f64e79859fd07a71d4a1c57b812f2 [3]https://patchwork.ozlabs.org/patch/894916/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 7:39 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 7:39 UTC (permalink / raw) To: linux-arm-kernel +Julien, Zhengxunli and Mason from Macronix Hi Yogesh, On Thu, 4 Oct 2018 06:51:41 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > Hi Vignesh, > > > -----Original Message----- > > From: Vignesh R [mailto:vigneshr at ti.com] > > Sent: Wednesday, October 3, 2018 10:26 PM > > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > > kernel at lists.infradead.org>; linux-mtd at lists.infradead.org; > > devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Vignesh R > > <vigneshr@ti.com> > > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba > > > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports > > read/write over 8 IO lines simulatenously. Add support for Octal read mode for > > Micron mt35xu512aba. > > Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem > > to support newer JESD216C standard that provides auto detection of Octal > > mode capabilities and opcodes. Therefore, this capability is manually added > > using new SPI_NOR_OCTAL_READ flag. > > > > Thanks for sending the patch-set of adding octal support. > If possible, can you share the MT35x datasheet? > > I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). > Also have added support of Octal in driver/spi/spi.c framework. > > IMO, we would collaborate our patches. Looks like we are of stepping on each others toes here (see this branch [1]). I guess it's not a problem if we agree on who is working on what. Yogesh, you already sent "spi: add flags for octal I/O data transfer" [3] which is only adding the new OCTAL flags but is not patching spi.c and spi-mem.c to take those new flags into account. Here is my version of this patch [2] (it's still missing an update of SPI_MEM_MAX_BUSWIDTH). Let me know what you want to do (rework your version to address the problem or take mine). Regarding other patches in [2], they're mainly here to add support for X-X-X and DTR modes and get the m25p80 logic integrated in spi-nor.c so that we can really check which NOR operations are supported by the SPI controller. Regards, Boris [1]https://github.com/bbrezillon/linux/commits/spi-nor/octo [2]https://github.com/bbrezillon/linux/commit/9854a8fdd23f64e79859fd07a71d4a1c57b812f2 [3]https://patchwork.ozlabs.org/patch/894916/ ^ permalink raw reply [flat|nested] 63+ messages in thread
* RE: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 7:39 ` Boris Brezillon @ 2018-10-04 8:47 ` Yogesh Narayan Gaur -1 siblings, 0 replies; 63+ messages in thread From: Yogesh Narayan Gaur @ 2018-10-04 8:47 UTC (permalink / raw) To: Boris Brezillon Cc: Vignesh R, Marek Vasut, Rob Herring, Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, juliensu, zhengxunli, masonccyang Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon@bootlin.com] > Sent: Thursday, October 4, 2018 1:09 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: Vignesh R <vigneshr@ti.com>; Marek Vasut <marek.vasut@gmail.com>; Rob > Herring <robh+dt@kernel.org>; Brian Norris <computersforpeace@gmail.com>; > Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>; linux- > mtd@lists.infradead.org; devicetree@vger.kernel.org; linux- > kernel@vger.kernel.org; juliensu@mxic.com.tw; zhengxunli@mxic.com.tw; > masonccyang@mxic.com.tw > Subject: Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for > mt35xu512aba > > +Julien, Zhengxunli and Mason from Macronix > > Hi Yogesh, > > On Thu, 4 Oct 2018 06:51:41 +0000 > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > Hi Vignesh, > > > > > -----Original Message----- > > > From: Vignesh R [mailto:vigneshr@ti.com] > > > Sent: Wednesday, October 3, 2018 10:26 PM > > > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > > > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > > > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > > > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > > > kernel@lists.infradead.org>; linux-mtd@lists.infradead.org; > > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R > > > <vigneshr@ti.com> > > > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for > > > mt35xu512aba > > > > > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. > > > It supports read/write over 8 IO lines simulatenously. Add support > > > for Octal read mode for Micron mt35xu512aba. > > > Unfortunately, this flash is only complaint to SFDP JESD216B and > > > does not seem to support newer JESD216C standard that provides auto > > > detection of Octal mode capabilities and opcodes. Therefore, this > > > capability is manually added using new SPI_NOR_OCTAL_READ flag. > > > > > > > Thanks for sending the patch-set of adding octal support. > > If possible, can you share the MT35x datasheet? > > > > I also have the patch ready in which I have added support for Read (1-1-8 and > 1-8-8) protocol and Write (1-1-8 and 1-8-8). > > Also have added support of Octal in driver/spi/spi.c framework. > > > > IMO, we would collaborate our patches. > > Looks like we are of stepping on each others toes here (see this branch [1]). I > guess it's not a problem if we agree on who is working on what. > > Yogesh, you already sent "spi: add flags for octal I/O data transfer" [3] which is > only adding the new OCTAL flags but is not patching spi.c and spi-mem.c to take > those new flags into account. Here is my version of this patch [2] (it's still > missing an update of SPI_MEM_MAX_BUSWIDTH). Let me know what you want > to do (rework your version to address the problem or take mine). > I haven't said that I have sent the patches. My patches are ready and needed to be sent for review. In these patches, I am adding support for X-X-X protocol for octal support and integrating them with spi and flash m25p80 interface. Would send the patches by today evening for review. Regards Yogesh Gaur > Regarding other patches in [2], they're mainly here to add support for X-X-X and > DTR modes and get the m25p80 logic integrated in spi-nor.c so that we can > really check which NOR operations are supported by the SPI controller. > > Regards, > > Boris > > [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fbbrezillon%2Flinux%2Fcommits%2Fspi- > nor%2Focto&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C3ad > 4b6f2a4c9470e98f308d629cc8362%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C636742355682081158&sdata=vXg7nwZ6dLrUxoNw9t41GYMp > oPdNWUWhLM6wZPmrIec%3D&reserved=0 > [2]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fbbrezillon%2Flinux%2Fcommit%2F9854a8fdd23f64e79859fd07a71d4 > a1c57b812f2&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C3ad > 4b6f2a4c9470e98f308d629cc8362%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C636742355682081158&sdata=yEZqGYprHS8q2wuisFLpHg8bMj > uuWDrl3ggWlA8LRoc%3D&reserved=0 > [3]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > chwork.ozlabs.org%2Fpatch%2F894916%2F&data=02%7C01%7Cyogeshnar > ayan.gaur%40nxp.com%7C3ad4b6f2a4c9470e98f308d629cc8362%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636742355682081158&sdata=t > 5DFvXgDOlyLn7pMieue9BB5q24DNiJMywGvNrWAYOo%3D&reserved=0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 8:47 ` Yogesh Narayan Gaur 0 siblings, 0 replies; 63+ messages in thread From: Yogesh Narayan Gaur @ 2018-10-04 8:47 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, > -----Original Message----- > From: Boris Brezillon [mailto:boris.brezillon at bootlin.com] > Sent: Thursday, October 4, 2018 1:09 PM > To: Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> > Cc: Vignesh R <vigneshr@ti.com>; Marek Vasut <marek.vasut@gmail.com>; Rob > Herring <robh+dt@kernel.org>; Brian Norris <computersforpeace@gmail.com>; > Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>; linux- > mtd at lists.infradead.org; devicetree at vger.kernel.org; linux- > kernel at vger.kernel.org; juliensu at mxic.com.tw; zhengxunli at mxic.com.tw; > masonccyang at mxic.com.tw > Subject: Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for > mt35xu512aba > > +Julien, Zhengxunli and Mason from Macronix > > Hi Yogesh, > > On Thu, 4 Oct 2018 06:51:41 +0000 > Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > Hi Vignesh, > > > > > -----Original Message----- > > > From: Vignesh R [mailto:vigneshr at ti.com] > > > Sent: Wednesday, October 3, 2018 10:26 PM > > > To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut > > > <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> > > > Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur > > > <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- > > > kernel at lists.infradead.org>; linux-mtd at lists.infradead.org; > > > devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Vignesh R > > > <vigneshr@ti.com> > > > Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for > > > mt35xu512aba > > > > > > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. > > > It supports read/write over 8 IO lines simulatenously. Add support > > > for Octal read mode for Micron mt35xu512aba. > > > Unfortunately, this flash is only complaint to SFDP JESD216B and > > > does not seem to support newer JESD216C standard that provides auto > > > detection of Octal mode capabilities and opcodes. Therefore, this > > > capability is manually added using new SPI_NOR_OCTAL_READ flag. > > > > > > > Thanks for sending the patch-set of adding octal support. > > If possible, can you share the MT35x datasheet? > > > > I also have the patch ready in which I have added support for Read (1-1-8 and > 1-8-8) protocol and Write (1-1-8 and 1-8-8). > > Also have added support of Octal in driver/spi/spi.c framework. > > > > IMO, we would collaborate our patches. > > Looks like we are of stepping on each others toes here (see this branch [1]). I > guess it's not a problem if we agree on who is working on what. > > Yogesh, you already sent "spi: add flags for octal I/O data transfer" [3] which is > only adding the new OCTAL flags but is not patching spi.c and spi-mem.c to take > those new flags into account. Here is my version of this patch [2] (it's still > missing an update of SPI_MEM_MAX_BUSWIDTH). Let me know what you want > to do (rework your version to address the problem or take mine). > I haven't said that I have sent the patches. My patches are ready and needed to be sent for review. In these patches, I am adding support for X-X-X protocol for octal support and integrating them with spi and flash m25p80 interface. Would send the patches by today evening for review. Regards Yogesh Gaur > Regarding other patches in [2], they're mainly here to add support for X-X-X and > DTR modes and get the m25p80 logic integrated in spi-nor.c so that we can > really check which NOR operations are supported by the SPI controller. > > Regards, > > Boris > > [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fbbrezillon%2Flinux%2Fcommits%2Fspi- > nor%2Focto&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C3ad > 4b6f2a4c9470e98f308d629cc8362%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C636742355682081158&sdata=vXg7nwZ6dLrUxoNw9t41GYMp > oPdNWUWhLM6wZPmrIec%3D&reserved=0 > [2]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fbbrezillon%2Flinux%2Fcommit%2F9854a8fdd23f64e79859fd07a71d4 > a1c57b812f2&data=02%7C01%7Cyogeshnarayan.gaur%40nxp.com%7C3ad > 4b6f2a4c9470e98f308d629cc8362%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C636742355682081158&sdata=yEZqGYprHS8q2wuisFLpHg8bMj > uuWDrl3ggWlA8LRoc%3D&reserved=0 > [3]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpat > chwork.ozlabs.org%2Fpatch%2F894916%2F&data=02%7C01%7Cyogeshnar > ayan.gaur%40nxp.com%7C3ad4b6f2a4c9470e98f308d629cc8362%7C686ea1d3 > bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636742355682081158&sdata=t > 5DFvXgDOlyLn7pMieue9BB5q24DNiJMywGvNrWAYOo%3D&reserved=0 ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 8:47 ` Yogesh Narayan Gaur (?) @ 2018-10-04 9:10 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:10 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Vignesh R, Marek Vasut, Rob Herring, Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, juliensu, zhengxunli, masonccyang On Thu, 4 Oct 2018 08:47:33 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > > Yogesh, you already sent "spi: add flags for octal I/O data > > transfer" [3] which is only adding the new OCTAL flags but is not > > patching spi.c and spi-mem.c to take those new flags into account. > > Here is my version of this patch [2] (it's still missing an update > > of SPI_MEM_MAX_BUSWIDTH). Let me know what you want to do (rework > > your version to address the problem or take mine). > I haven't said that I have sent the patches. Well, you at least sent one of them, I know it because I was in CC :P. > My patches are ready and needed to be sent for review. I initially told you to drop those patches because we didn't have a user yet, that's about to change, so I guess we're all good. > In these patches, I am adding support for X-X-X protocol for octal > support and integrating them with spi and flash m25p80 interface. From what I've seen you're not adding support of 8-8-8 but for 1-8-8 an 1-1-8, which is a lot easier to deal with (it's completely stateless, which is what the spi-nor expects). Unless you're talking about other patches you haven't sent yet... ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 9:10 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:10 UTC (permalink / raw) To: linux-arm-kernel On Thu, 4 Oct 2018 08:47:33 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > > Yogesh, you already sent "spi: add flags for octal I/O data > > transfer" [3] which is only adding the new OCTAL flags but is not > > patching spi.c and spi-mem.c to take those new flags into account. > > Here is my version of this patch [2] (it's still missing an update > > of SPI_MEM_MAX_BUSWIDTH). Let me know what you want to do (rework > > your version to address the problem or take mine). > I haven't said that I have sent the patches. Well, you at least sent one of them, I know it because I was in CC :P. > My patches are ready and needed to be sent for review. I initially told you to drop those patches because we didn't have a user yet, that's about to change, so I guess we're all good. > In these patches, I am adding support for X-X-X protocol for octal > support and integrating them with spi and flash m25p80 interface. >From what I've seen you're not adding support of 8-8-8 but for 1-8-8 an 1-1-8, which is a lot easier to deal with (it's completely stateless, which is what the spi-nor expects). Unless you're talking about other patches you haven't sent yet... ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 9:10 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:10 UTC (permalink / raw) To: Yogesh Narayan Gaur Cc: Vignesh R, Marek Vasut, Rob Herring, Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, juliensu, zhengxunli, masonccyang On Thu, 4 Oct 2018 08:47:33 +0000 Yogesh Narayan Gaur <yogeshnarayan.gaur@nxp.com> wrote: > > > > Yogesh, you already sent "spi: add flags for octal I/O data > > transfer" [3] which is only adding the new OCTAL flags but is not > > patching spi.c and spi-mem.c to take those new flags into account. > > Here is my version of this patch [2] (it's still missing an update > > of SPI_MEM_MAX_BUSWIDTH). Let me know what you want to do (rework > > your version to address the problem or take mine). > I haven't said that I have sent the patches. Well, you at least sent one of them, I know it because I was in CC :P. > My patches are ready and needed to be sent for review. I initially told you to drop those patches because we didn't have a user yet, that's about to change, so I guess we're all good. > In these patches, I am adding support for X-X-X protocol for octal > support and integrating them with spi and flash m25p80 interface. >From what I've seen you're not adding support of 8-8-8 but for 1-8-8 an 1-1-8, which is a lot easier to deal with (it's completely stateless, which is what the spi-nor expects). Unless you're talking about other patches you haven't sent yet... ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 6:51 ` Yogesh Narayan Gaur (?) @ 2018-10-04 10:38 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:38 UTC (permalink / raw) To: Yogesh Narayan Gaur, Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel Hi, On Thursday 04 October 2018 12:21 PM, Yogesh Narayan Gaur wrote: > Hi Vignesh, > >> -----Original Message----- >> From: Vignesh R [mailto:vigneshr@ti.com] >> Sent: Wednesday, October 3, 2018 10:26 PM >> To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut >> <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> >> Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur >> <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- >> kernel@lists.infradead.org>; linux-mtd@lists.infradead.org; >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R >> <vigneshr@ti.com> >> Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba >> >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports >> read/write over 8 IO lines simulatenously. Add support for Octal read mode for >> Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem >> to support newer JESD216C standard that provides auto detection of Octal >> mode capabilities and opcodes. Therefore, this capability is manually added >> using new SPI_NOR_OCTAL_READ flag. >> > > Thanks for sending the patch-set of adding octal support. > If possible, can you share the MT35x datasheet? > I dont have datasheet, this patch is based on prior patches from here: http://patchwork.ozlabs.org/patch/740942/ > I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). > Also have added support of Octal in driver/spi/spi.c framework. > > IMO, we would collaborate our patches. That would be great, thanks! Regards Vignesh > -- > Regards > Yogesh Gaur > >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index >> aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ >> >> int (*quad_enable)(struct spi_nor *nor); >> }; >> @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) >> { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, >> { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, >> { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, >> + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, >> >> { SPINOR_OP_READ_1_1_1_DTR, >> SPINOR_OP_READ_1_1_1_DTR_4B }, >> { SPINOR_OP_READ_1_2_2_DTR, >> SPINOR_OP_READ_1_2_2_DTR_4B }, >> @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { >> { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | >> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, >> >> /* Micron */ >> - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR | SPI_NOR_4B_OPCODES) }, >> + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR >> +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, >> >> /* PMC */ >> { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, >> @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, >> SNOR_PROTO_1_1_4); >> } >> >> + if (info->flags & SPI_NOR_OCTAL_READ) { >> + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; >> + spi_nor_set_read_settings(¶ms- >>> reads[SNOR_CMD_READ_1_1_8], >> + 0, 8, SPINOR_OP_READ_1_1_8, >> + SNOR_PROTO_1_1_8); >> + } >> + >> /* Page Program settings. */ >> params->hwcaps.mask |= SNOR_HWCAPS_PP; >> spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index >> 8b1acf68b7ac..ae9861ed7e0f 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -50,6 +50,7 @@ >> #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ >> #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ >> @@ -73,6 +74,7 @@ >> #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 >> bytes) */ >> #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ >> -- >> 2.19.0 > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 10:38 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:38 UTC (permalink / raw) To: linux-arm-kernel Hi, On Thursday 04 October 2018 12:21 PM, Yogesh Narayan Gaur wrote: > Hi Vignesh, > >> -----Original Message----- >> From: Vignesh R [mailto:vigneshr at ti.com] >> Sent: Wednesday, October 3, 2018 10:26 PM >> To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut >> <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> >> Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur >> <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- >> kernel at lists.infradead.org>; linux-mtd at lists.infradead.org; >> devicetree at vger.kernel.org; linux-kernel at vger.kernel.org; Vignesh R >> <vigneshr@ti.com> >> Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba >> >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports >> read/write over 8 IO lines simulatenously. Add support for Octal read mode for >> Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem >> to support newer JESD216C standard that provides auto detection of Octal >> mode capabilities and opcodes. Therefore, this capability is manually added >> using new SPI_NOR_OCTAL_READ flag. >> > > Thanks for sending the patch-set of adding octal support. > If possible, can you share the MT35x datasheet? > I dont have datasheet, this patch is based on prior patches from here: http://patchwork.ozlabs.org/patch/740942/ > I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). > Also have added support of Octal in driver/spi/spi.c framework. > > IMO, we would collaborate our patches. That would be great, thanks! Regards Vignesh > -- > Regards > Yogesh Gaur > >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index >> aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ >> >> int (*quad_enable)(struct spi_nor *nor); >> }; >> @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) >> { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, >> { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, >> { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, >> + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, >> >> { SPINOR_OP_READ_1_1_1_DTR, >> SPINOR_OP_READ_1_1_1_DTR_4B }, >> { SPINOR_OP_READ_1_2_2_DTR, >> SPINOR_OP_READ_1_2_2_DTR_4B }, >> @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { >> { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | >> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, >> >> /* Micron */ >> - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR | SPI_NOR_4B_OPCODES) }, >> + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR >> +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, >> >> /* PMC */ >> { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, >> @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, >> SNOR_PROTO_1_1_4); >> } >> >> + if (info->flags & SPI_NOR_OCTAL_READ) { >> + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; >> + spi_nor_set_read_settings(¶ms- >>> reads[SNOR_CMD_READ_1_1_8], >> + 0, 8, SPINOR_OP_READ_1_1_8, >> + SNOR_PROTO_1_1_8); >> + } >> + >> /* Page Program settings. */ >> params->hwcaps.mask |= SNOR_HWCAPS_PP; >> spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index >> 8b1acf68b7ac..ae9861ed7e0f 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -50,6 +50,7 @@ >> #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ >> #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ >> @@ -73,6 +74,7 @@ >> #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 >> bytes) */ >> #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ >> -- >> 2.19.0 > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 10:38 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:38 UTC (permalink / raw) To: Yogesh Narayan Gaur, Boris Brezillon, Marek Vasut, Rob Herring Cc: devicetree, Brian Norris, linux-mtd, linux-kernel, Linux ARM Mailing List Hi, On Thursday 04 October 2018 12:21 PM, Yogesh Narayan Gaur wrote: > Hi Vignesh, > >> -----Original Message----- >> From: Vignesh R [mailto:vigneshr@ti.com] >> Sent: Wednesday, October 3, 2018 10:26 PM >> To: Boris Brezillon <boris.brezillon@bootlin.com>; Marek Vasut >> <marek.vasut@gmail.com>; Rob Herring <robh+dt@kernel.org> >> Cc: Brian Norris <computersforpeace@gmail.com>; Yogesh Narayan Gaur >> <yogeshnarayan.gaur@nxp.com>; Linux ARM Mailing List <linux-arm- >> kernel@lists.infradead.org>; linux-mtd@lists.infradead.org; >> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Vignesh R >> <vigneshr@ti.com> >> Subject: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba >> >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It supports >> read/write over 8 IO lines simulatenously. Add support for Octal read mode for >> Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not seem >> to support newer JESD216C standard that provides auto detection of Octal >> mode capabilities and opcodes. Therefore, this capability is manually added >> using new SPI_NOR_OCTAL_READ flag. >> > > Thanks for sending the patch-set of adding octal support. > If possible, can you share the MT35x datasheet? > I dont have datasheet, this patch is based on prior patches from here: http://patchwork.ozlabs.org/patch/740942/ > I also have the patch ready in which I have added support for Read (1-1-8 and 1-8-8) protocol and Write (1-1-8 and 1-8-8). > Also have added support of Octal in driver/spi/spi.c framework. > > IMO, we would collaborate our patches. That would be great, thanks! Regards Vignesh > -- > Regards > Yogesh Gaur > >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index >> aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ >> >> int (*quad_enable)(struct spi_nor *nor); >> }; >> @@ -209,6 +210,7 @@ static inline u8 spi_nor_convert_3to4_read(u8 opcode) >> { SPINOR_OP_READ_1_2_2, SPINOR_OP_READ_1_2_2_4B }, >> { SPINOR_OP_READ_1_1_4, SPINOR_OP_READ_1_1_4_4B }, >> { SPINOR_OP_READ_1_4_4, SPINOR_OP_READ_1_4_4_4B }, >> + { SPINOR_OP_READ_1_1_8, SPINOR_OP_READ_1_1_8_4B }, >> >> { SPINOR_OP_READ_1_1_1_DTR, >> SPINOR_OP_READ_1_1_1_DTR_4B }, >> { SPINOR_OP_READ_1_2_2_DTR, >> SPINOR_OP_READ_1_2_2_DTR_4B }, >> @@ -1406,7 +1408,7 @@ static const struct flash_info spi_nor_ids[] = { >> { "mt25qu02g", INFO(0x20bb22, 0, 64 * 1024, 4096, SECT_4K | >> USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) }, >> >> /* Micron */ >> - { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR | SPI_NOR_4B_OPCODES) }, >> + { "mt35xu512aba", INFO(0x2c5b1a, 0, 128 * 1024, 512, SECT_4K | >> USE_FSR >> +| SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) }, >> >> /* PMC */ >> { "pm25lv512", INFO(0, 0, 32 * 1024, 2, SECT_4K_PMC) }, >> @@ -3199,6 +3201,13 @@ static int spi_nor_init_params(struct spi_nor *nor, >> SNOR_PROTO_1_1_4); >> } >> >> + if (info->flags & SPI_NOR_OCTAL_READ) { >> + params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_8; >> + spi_nor_set_read_settings(¶ms- >>> reads[SNOR_CMD_READ_1_1_8], >> + 0, 8, SPINOR_OP_READ_1_1_8, >> + SNOR_PROTO_1_1_8); >> + } >> + >> /* Page Program settings. */ >> params->hwcaps.mask |= SNOR_HWCAPS_PP; >> spi_nor_set_pp_settings(¶ms->page_programs[SNOR_CMD_PP], >> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index >> 8b1acf68b7ac..ae9861ed7e0f 100644 >> --- a/include/linux/mtd/spi-nor.h >> +++ b/include/linux/mtd/spi-nor.h >> @@ -50,6 +50,7 @@ >> #define SPINOR_OP_READ_1_2_2 0xbb /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4 0x6b /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4 0xeb /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8 0x8b /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP 0x02 /* Page program (up to 256 bytes) */ >> #define SPINOR_OP_PP_1_1_4 0x32 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4 0x38 /* Quad page program */ >> @@ -73,6 +74,7 @@ >> #define SPINOR_OP_READ_1_2_2_4B 0xbc /* Read data bytes (Dual I/O >> SPI) */ >> #define SPINOR_OP_READ_1_1_4_4B 0x6c /* Read data bytes (Quad >> Output SPI) */ >> #define SPINOR_OP_READ_1_4_4_4B 0xec /* Read data bytes (Quad I/O >> SPI) */ >> +#define SPINOR_OP_READ_1_1_8_4B 0x7c /* Read data bytes (Octal >> Output SPI) */ >> #define SPINOR_OP_PP_4B 0x12 /* Page program (up to 256 >> bytes) */ >> #define SPINOR_OP_PP_1_1_4_4B 0x34 /* Quad page program */ >> #define SPINOR_OP_PP_1_4_4_4B 0x3e /* Quad page program */ >> -- >> 2.19.0 > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-03 16:56 ` Vignesh R (?) @ 2018-10-04 9:45 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Wed, 3 Oct 2018 22:26:01 +0530 Vignesh R <vigneshr@ti.com> wrote: > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > supports read/write over 8 IO lines simulatenously. Add support for > Octal read mode for Micron mt35xu512aba. > Unfortunately, this flash is only complaint to SFDP JESD216B and does not > seem to support newer JESD216C standard that provides auto detection of > Octal mode capabilities and opcodes. Therefore, this capability is > manually added using new SPI_NOR_OCTAL_READ flag. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index aff5e6ff0b2c..4926e805a8cb 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -90,6 +90,7 @@ struct flash_info { > #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 */ > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ Hm, we'll need to clarify what OCTAL means. I see at least 3 different modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could be qualified as "octal" modes. So how about renaming this macro SPI_NOR_1_1_8_READ. Also, I fear we'll soon run out of bits in ->flags if we keep adding one flag per mode which is why I proposed a solution to let flash chips tweak the flash parameters as they wish [1][2]. I'm not saying we should do it now, but we should definitely plan for something like that. [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 9:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:45 UTC (permalink / raw) To: linux-arm-kernel On Wed, 3 Oct 2018 22:26:01 +0530 Vignesh R <vigneshr@ti.com> wrote: > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > supports read/write over 8 IO lines simulatenously. Add support for > Octal read mode for Micron mt35xu512aba. > Unfortunately, this flash is only complaint to SFDP JESD216B and does not > seem to support newer JESD216C standard that provides auto detection of > Octal mode capabilities and opcodes. Therefore, this capability is > manually added using new SPI_NOR_OCTAL_READ flag. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index aff5e6ff0b2c..4926e805a8cb 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -90,6 +90,7 @@ struct flash_info { > #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 */ > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ Hm, we'll need to clarify what OCTAL means. I see at least 3 different modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could be qualified as "octal" modes. So how about renaming this macro SPI_NOR_1_1_8_READ. Also, I fear we'll soon run out of bits in ->flags if we keep adding one flag per mode which is why I proposed a solution to let flash chips tweak the flash parameters as they wish [1][2]. I'm not saying we should do it now, but we should definitely plan for something like that. [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 9:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 9:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Wed, 3 Oct 2018 22:26:01 +0530 Vignesh R <vigneshr@ti.com> wrote: > Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > supports read/write over 8 IO lines simulatenously. Add support for > Octal read mode for Micron mt35xu512aba. > Unfortunately, this flash is only complaint to SFDP JESD216B and does not > seem to support newer JESD216C standard that provides auto detection of > Octal mode capabilities and opcodes. Therefore, this capability is > manually added using new SPI_NOR_OCTAL_READ flag. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index aff5e6ff0b2c..4926e805a8cb 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -90,6 +90,7 @@ struct flash_info { > #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 */ > +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ Hm, we'll need to clarify what OCTAL means. I see at least 3 different modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could be qualified as "octal" modes. So how about renaming this macro SPI_NOR_1_1_8_READ. Also, I fear we'll soon run out of bits in ->flags if we keep adding one flag per mode which is why I proposed a solution to let flash chips tweak the flash parameters as they wish [1][2]. I'm not saying we should do it now, but we should definitely plan for something like that. [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 9:45 ` Boris Brezillon (?) @ 2018-10-04 11:12 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 11:12 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:01 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It >> supports read/write over 8 IO lines simulatenously. Add support for >> Octal read mode for Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not >> seem to support newer JESD216C standard that provides auto detection of >> Octal mode capabilities and opcodes. Therefore, this capability is >> manually added using new SPI_NOR_OCTAL_READ flag. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > be qualified as "octal" modes. > So how about renaming this macro SPI_NOR_1_1_8_READ. > My understanding is that, if a flash is Octal IO capable, then it supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and 4-4-4 modes. Moreover, these capabilities should be auto discoverable once flash start populating SFDP JESD216C tables (IIRC, JESD216B already takes care of QUAD IO modes). So, I don't think we need different flags for 1-1-8, 1-8-8 and 8-8-8. Please let me if that's not the case. For this patch, I wanted to start small and support only 1-1-8 mode which is the easiest. > Also, I fear we'll soon run out of bits in ->flags if we keep adding > one flag per mode which is why I proposed a solution to let flash > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > should do it now, but we should definitely plan for something like that. > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > Hmm, it almost seems like Macronix flash warrants its own driver now. -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 11:12 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 11:12 UTC (permalink / raw) To: linux-arm-kernel On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:01 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It >> supports read/write over 8 IO lines simulatenously. Add support for >> Octal read mode for Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not >> seem to support newer JESD216C standard that provides auto detection of >> Octal mode capabilities and opcodes. Therefore, this capability is >> manually added using new SPI_NOR_OCTAL_READ flag. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > be qualified as "octal" modes. > So how about renaming this macro SPI_NOR_1_1_8_READ. > My understanding is that, if a flash is Octal IO capable, then it supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and 4-4-4 modes. Moreover, these capabilities should be auto discoverable once flash start populating SFDP JESD216C tables (IIRC, JESD216B already takes care of QUAD IO modes). So, I don't think we need different flags for 1-1-8, 1-8-8 and 8-8-8. Please let me if that's not the case. For this patch, I wanted to start small and support only 1-1-8 mode which is the easiest. > Also, I fear we'll soon run out of bits in ->flags if we keep adding > one flag per mode which is why I proposed a solution to let flash > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > should do it now, but we should definitely plan for something like that. > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > Hmm, it almost seems like Macronix flash warrants its own driver now. -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 11:12 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 11:12 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:01 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It >> supports read/write over 8 IO lines simulatenously. Add support for >> Octal read mode for Micron mt35xu512aba. >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not >> seem to support newer JESD216C standard that provides auto detection of >> Octal mode capabilities and opcodes. Therefore, this capability is >> manually added using new SPI_NOR_OCTAL_READ flag. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- >> include/linux/mtd/spi-nor.h | 2 ++ >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index aff5e6ff0b2c..4926e805a8cb 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -90,6 +90,7 @@ struct flash_info { >> #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 */ >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > be qualified as "octal" modes. > So how about renaming this macro SPI_NOR_1_1_8_READ. > My understanding is that, if a flash is Octal IO capable, then it supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and 4-4-4 modes. Moreover, these capabilities should be auto discoverable once flash start populating SFDP JESD216C tables (IIRC, JESD216B already takes care of QUAD IO modes). So, I don't think we need different flags for 1-1-8, 1-8-8 and 8-8-8. Please let me if that's not the case. For this patch, I wanted to start small and support only 1-1-8 mode which is the easiest. > Also, I fear we'll soon run out of bits in ->flags if we keep adding > one flag per mode which is why I proposed a solution to let flash > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > should do it now, but we should definitely plan for something like that. > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > Hmm, it almost seems like Macronix flash warrants its own driver now. -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba 2018-10-04 11:12 ` Vignesh R (?) @ 2018-10-04 11:27 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:27 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Thu, 4 Oct 2018 16:42:22 +0530 Vignesh R <vigneshr@ti.com> wrote: > On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:01 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > >> supports read/write over 8 IO lines simulatenously. Add support for > >> Octal read mode for Micron mt35xu512aba. > >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not > >> seem to support newer JESD216C standard that provides auto detection of > >> Octal mode capabilities and opcodes. Therefore, this capability is > >> manually added using new SPI_NOR_OCTAL_READ flag. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > >> include/linux/mtd/spi-nor.h | 2 ++ > >> 2 files changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > >> index aff5e6ff0b2c..4926e805a8cb 100644 > >> --- a/drivers/mtd/spi-nor/spi-nor.c > >> +++ b/drivers/mtd/spi-nor/spi-nor.c > >> @@ -90,6 +90,7 @@ struct flash_info { > >> #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 */ > >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > > be qualified as "octal" modes. > > So how about renaming this macro SPI_NOR_1_1_8_READ. > > > > My understanding is that, if a flash is Octal IO capable, then it > supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the > current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and > 4-4-4 modes. I already have one NOR which is not following this rule (mx25uw51245g) and is only supporting 1-1-1 and 8-8-8, nothing in between. > Moreover, these capabilities should be auto discoverable once flash > start populating SFDP JESD216C tables (IIRC, JESD216B already takes care > of QUAD IO modes). So, I don't think we need different flags for 1-1-8, > 1-8-8 and 8-8-8. Please let me if that's not the case. Except we already have NORs out there that do not have a valid SFDP table but still support a subset of the octal modes (mx25uw51245g is in this case, but I'm pretty sure there are others). > > For this patch, I wanted to start small and support only 1-1-8 mode > which is the easiest. Which is fine, just wanted to know what SPI_NOR_OCTAL_READ meant. > > > > Also, I fear we'll soon run out of bits in ->flags if we keep adding > > one flag per mode which is why I proposed a solution to let flash > > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > > should do it now, but we should definitely plan for something like that. > > > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > > > > Hmm, it almost seems like Macronix flash warrants its own driver now. > Actually, we already have quite a bit of code that is vendor (and even chip) specific in spi-nor.c, and I indeed think it would be beneficial to have one driver per manufacturer so that the core is not polluted by those chip/manufacturer specific hacks. The thing is, the spi_nor interface (and the way hwcaps selection works) is not ready for that. ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 11:27 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:27 UTC (permalink / raw) To: linux-arm-kernel On Thu, 4 Oct 2018 16:42:22 +0530 Vignesh R <vigneshr@ti.com> wrote: > On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:01 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > >> supports read/write over 8 IO lines simulatenously. Add support for > >> Octal read mode for Micron mt35xu512aba. > >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not > >> seem to support newer JESD216C standard that provides auto detection of > >> Octal mode capabilities and opcodes. Therefore, this capability is > >> manually added using new SPI_NOR_OCTAL_READ flag. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > >> include/linux/mtd/spi-nor.h | 2 ++ > >> 2 files changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > >> index aff5e6ff0b2c..4926e805a8cb 100644 > >> --- a/drivers/mtd/spi-nor/spi-nor.c > >> +++ b/drivers/mtd/spi-nor/spi-nor.c > >> @@ -90,6 +90,7 @@ struct flash_info { > >> #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 */ > >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > > be qualified as "octal" modes. > > So how about renaming this macro SPI_NOR_1_1_8_READ. > > > > My understanding is that, if a flash is Octal IO capable, then it > supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the > current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and > 4-4-4 modes. I already have one NOR which is not following this rule (mx25uw51245g) and is only supporting 1-1-1 and 8-8-8, nothing in between. > Moreover, these capabilities should be auto discoverable once flash > start populating SFDP JESD216C tables (IIRC, JESD216B already takes care > of QUAD IO modes). So, I don't think we need different flags for 1-1-8, > 1-8-8 and 8-8-8. Please let me if that's not the case. Except we already have NORs out there that do not have a valid SFDP table but still support a subset of the octal modes (mx25uw51245g is in this case, but I'm pretty sure there are others). > > For this patch, I wanted to start small and support only 1-1-8 mode > which is the easiest. Which is fine, just wanted to know what SPI_NOR_OCTAL_READ meant. > > > > Also, I fear we'll soon run out of bits in ->flags if we keep adding > > one flag per mode which is why I proposed a solution to let flash > > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > > should do it now, but we should definitely plan for something like that. > > > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > > > > Hmm, it almost seems like Macronix flash warrants its own driver now. > Actually, we already have quite a bit of code that is vendor (and even chip) specific in spi-nor.c, and I indeed think it would be beneficial to have one driver per manufacturer so that the core is not polluted by those chip/manufacturer specific hacks. The thing is, the spi_nor interface (and the way hwcaps selection works) is not ready for that. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba @ 2018-10-04 11:27 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:27 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Thu, 4 Oct 2018 16:42:22 +0530 Vignesh R <vigneshr@ti.com> wrote: > On Thursday 04 October 2018 03:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:01 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Micron's mt35xu512aba flash is an Octal flash that has x8 IO lines. It > >> supports read/write over 8 IO lines simulatenously. Add support for > >> Octal read mode for Micron mt35xu512aba. > >> Unfortunately, this flash is only complaint to SFDP JESD216B and does not > >> seem to support newer JESD216C standard that provides auto detection of > >> Octal mode capabilities and opcodes. Therefore, this capability is > >> manually added using new SPI_NOR_OCTAL_READ flag. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > >> include/linux/mtd/spi-nor.h | 2 ++ > >> 2 files changed, 12 insertions(+), 1 deletion(-) > >> > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > >> index aff5e6ff0b2c..4926e805a8cb 100644 > >> --- a/drivers/mtd/spi-nor/spi-nor.c > >> +++ b/drivers/mtd/spi-nor/spi-nor.c > >> @@ -90,6 +90,7 @@ struct flash_info { > >> #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 */ > >> +#define SPI_NOR_OCTAL_READ BIT(15) /* Flash supports Octal Read */ > > > > Hm, we'll need to clarify what OCTAL means. I see at least 3 different > > modes using 8 IO lines (1-1-8, 1-8-8 and 8-8-8) and all of them could > > be qualified as "octal" modes. > > So how about renaming this macro SPI_NOR_1_1_8_READ. > > > > My understanding is that, if a flash is Octal IO capable, then it > supports all mode of Octal IO (1-1-8, 1-8-8 and 8-8-8). At least in the > current code, I see SPI_NOR_QUAD_READ seems to imply 1-1-4, 1-4-4 and > 4-4-4 modes. I already have one NOR which is not following this rule (mx25uw51245g) and is only supporting 1-1-1 and 8-8-8, nothing in between. > Moreover, these capabilities should be auto discoverable once flash > start populating SFDP JESD216C tables (IIRC, JESD216B already takes care > of QUAD IO modes). So, I don't think we need different flags for 1-1-8, > 1-8-8 and 8-8-8. Please let me if that's not the case. Except we already have NORs out there that do not have a valid SFDP table but still support a subset of the octal modes (mx25uw51245g is in this case, but I'm pretty sure there are others). > > For this patch, I wanted to start small and support only 1-1-8 mode > which is the easiest. Which is fine, just wanted to know what SPI_NOR_OCTAL_READ meant. > > > > Also, I fear we'll soon run out of bits in ->flags if we keep adding > > one flag per mode which is why I proposed a solution to let flash > > chips tweak the flash parameters as they wish [1][2]. I'm not saying we > > should do it now, but we should definitely plan for something like that. > > > > [1]https://github.com/bbrezillon/linux/commit/9c672e4c85a91f1b0803c9c6e4b8f3aae5d79ffb > > [2]https://github.com/bbrezillon/linux/commit/3a5515c8821314c06a3d84f9861aefe476bb711e > > > > Hmm, it almost seems like Macronix flash warrants its own driver now. > Actually, we already have quite a bit of code that is vendor (and even chip) specific in spi-nor.c, and I indeed think it would be beneficial to have one driver per manufacturer so that the core is not polluted by those chip/manufacturer specific hacks. The thing is, the spi_nor interface (and the way hwcaps selection works) is not ready for that. ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC 2018-10-03 16:56 ` Vignesh R (?) @ 2018-10-03 16:56 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: linux-arm-kernel AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence QSPI controller but supports Octal IO(x8 data lines) and Double Data Rate(DDR) mode. Add new compatible to support OSPI controller on TI's AM654 SoCs. Signed-off-by: Vignesh R <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt index bb2075df9b38..4345c3a6f530 100644 --- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt +++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt @@ -4,6 +4,7 @@ Required properties: - compatible : should be one of the following: Generic default - "cdns,qspi-nor". For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor". + For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor". - reg : Contains two entries, each of which is a tuple consisting of a physical address and length. The first entry is the address and length of the controller register set. The second entry is the -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC 2018-10-03 16:56 ` Vignesh R (?) @ 2018-10-15 19:11 ` Rob Herring -1 siblings, 0 replies; 63+ messages in thread From: Rob Herring @ 2018-10-15 19:11 UTC (permalink / raw) To: Vignesh R Cc: Boris Brezillon, Marek Vasut, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R On Wed, 3 Oct 2018 22:26:02 +0530, Vignesh R wrote: > AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence > QSPI controller but supports Octal IO(x8 data lines) and Double Data > Rate(DDR) mode. Add new compatible to support OSPI controller on TI's > AM654 SoCs. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC @ 2018-10-15 19:11 ` Rob Herring 0 siblings, 0 replies; 63+ messages in thread From: Rob Herring @ 2018-10-15 19:11 UTC (permalink / raw) To: linux-arm-kernel On Wed, 3 Oct 2018 22:26:02 +0530, Vignesh R wrote: > AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence > QSPI controller but supports Octal IO(x8 data lines) and Double Data > Rate(DDR) mode. Add new compatible to support OSPI controller on TI's > AM654 SoCs. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC @ 2018-10-15 19:11 ` Rob Herring 0 siblings, 0 replies; 63+ messages in thread From: Rob Herring @ 2018-10-15 19:11 UTC (permalink / raw) Cc: Boris Brezillon, Marek Vasut, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R On Wed, 3 Oct 2018 22:26:02 +0530, Vignesh R wrote: > AM654 SoC has Cadence Octal SPI controller, which is similar to Cadence > QSPI controller but supports Octal IO(x8 data lines) and Double Data > Rate(DDR) mode. Add new compatible to support OSPI controller on TI's > AM654 SoCs. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring <robh@kernel.org> ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller 2018-10-03 16:56 ` Vignesh R (?) @ 2018-10-03 16:56 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R Cadence OSPI controller IP supports Octal IO (x8 IO lines), It also has an integrated PHY. IP register layout is very similar to existing QSPI IP except for additional bits to support Octal and Octal DDR mode. Therefore, extend current driver to support Octal mode. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index e24db817154e..48b00e75a879 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -101,6 +101,7 @@ struct cqspi_st { #define CQSPI_INST_TYPE_SINGLE 0 #define CQSPI_INST_TYPE_DUAL 1 #define CQSPI_INST_TYPE_QUAD 2 +#define CQSPI_INST_TYPE_OCTAL 3 #define CQSPI_DUMMY_CLKS_PER_BYTE 8 #define CQSPI_DUMMY_BYTES_MAX 4 @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) case SNOR_PROTO_1_1_4: f_pdata->data_width = CQSPI_INST_TYPE_QUAD; break; + case SNOR_PROTO_1_1_8: + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; + break; default: return -EINVAL; } @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) SNOR_HWCAPS_READ_FAST | SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | + SNOR_HWCAPS_READ_1_1_8 | SNOR_HWCAPS_PP, }; struct platform_device *pdev = cqspi->pdev; @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { .compatible = "ti,k2g-qspi", .data = (void *)CQSPI_NEEDS_WR_DELAY, }, + { + .compatible = "ti,am654-ospi", + .data = (void *)CQSPI_NEEDS_WR_DELAY, + }, { /* end of table */ } }; -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: linux-arm-kernel Cadence OSPI controller IP supports Octal IO (x8 IO lines), It also has an integrated PHY. IP register layout is very similar to existing QSPI IP except for additional bits to support Octal and Octal DDR mode. Therefore, extend current driver to support Octal mode. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index e24db817154e..48b00e75a879 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -101,6 +101,7 @@ struct cqspi_st { #define CQSPI_INST_TYPE_SINGLE 0 #define CQSPI_INST_TYPE_DUAL 1 #define CQSPI_INST_TYPE_QUAD 2 +#define CQSPI_INST_TYPE_OCTAL 3 #define CQSPI_DUMMY_CLKS_PER_BYTE 8 #define CQSPI_DUMMY_BYTES_MAX 4 @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) case SNOR_PROTO_1_1_4: f_pdata->data_width = CQSPI_INST_TYPE_QUAD; break; + case SNOR_PROTO_1_1_8: + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; + break; default: return -EINVAL; } @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) SNOR_HWCAPS_READ_FAST | SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | + SNOR_HWCAPS_READ_1_1_8 | SNOR_HWCAPS_PP, }; struct platform_device *pdev = cqspi->pdev; @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { .compatible = "ti,k2g-qspi", .data = (void *)CQSPI_NEEDS_WR_DELAY, }, + { + .compatible = "ti,am654-ospi", + .data = (void *)CQSPI_NEEDS_WR_DELAY, + }, { /* end of table */ } }; -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-10-03 16:56 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-03 16:56 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut, Rob Herring Cc: Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Vignesh R Cadence OSPI controller IP supports Octal IO (x8 IO lines), It also has an integrated PHY. IP register layout is very similar to existing QSPI IP except for additional bits to support Octal and Octal DDR mode. Therefore, extend current driver to support Octal mode. Signed-off-by: Vignesh R <vigneshr@ti.com> --- drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c index e24db817154e..48b00e75a879 100644 --- a/drivers/mtd/spi-nor/cadence-quadspi.c +++ b/drivers/mtd/spi-nor/cadence-quadspi.c @@ -101,6 +101,7 @@ struct cqspi_st { #define CQSPI_INST_TYPE_SINGLE 0 #define CQSPI_INST_TYPE_DUAL 1 #define CQSPI_INST_TYPE_QUAD 2 +#define CQSPI_INST_TYPE_OCTAL 3 #define CQSPI_DUMMY_CLKS_PER_BYTE 8 #define CQSPI_DUMMY_BYTES_MAX 4 @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) case SNOR_PROTO_1_1_4: f_pdata->data_width = CQSPI_INST_TYPE_QUAD; break; + case SNOR_PROTO_1_1_8: + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; + break; default: return -EINVAL; } @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) SNOR_HWCAPS_READ_FAST | SNOR_HWCAPS_READ_1_1_2 | SNOR_HWCAPS_READ_1_1_4 | + SNOR_HWCAPS_READ_1_1_8 | SNOR_HWCAPS_PP, }; struct platform_device *pdev = cqspi->pdev; @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { .compatible = "ti,k2g-qspi", .data = (void *)CQSPI_NEEDS_WR_DELAY, }, + { + .compatible = "ti,am654-ospi", + .data = (void *)CQSPI_NEEDS_WR_DELAY, + }, { /* end of table */ } }; -- 2.19.0 ^ permalink raw reply related [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller 2018-10-03 16:56 ` Vignesh R (?) @ 2018-12-10 8:45 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Wed, 3 Oct 2018 22:26:03 +0530 Vignesh R <vigneshr@ti.com> wrote: > Cadence OSPI controller IP supports Octal IO (x8 IO lines), > It also has an integrated PHY. IP register layout is very > similar to existing QSPI IP except for additional bits to support Octal > and Octal DDR mode. Therefore, extend current driver to support Octal > mode. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > index e24db817154e..48b00e75a879 100644 > --- a/drivers/mtd/spi-nor/cadence-quadspi.c > +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > @@ -101,6 +101,7 @@ struct cqspi_st { > #define CQSPI_INST_TYPE_SINGLE 0 > #define CQSPI_INST_TYPE_DUAL 1 > #define CQSPI_INST_TYPE_QUAD 2 > +#define CQSPI_INST_TYPE_OCTAL 3 > > #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > #define CQSPI_DUMMY_BYTES_MAX 4 > @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > case SNOR_PROTO_1_1_4: > f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > break; > + case SNOR_PROTO_1_1_8: > + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > + break; > default: > return -EINVAL; > } > @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > SNOR_HWCAPS_READ_FAST | > SNOR_HWCAPS_READ_1_1_2 | > SNOR_HWCAPS_READ_1_1_4 | > + SNOR_HWCAPS_READ_1_1_8 | Is this really supported on qspi versions of this IP? I guess not given the description in the commit message and the name of the new compatible (ospi instead of qspi). > SNOR_HWCAPS_PP, > }; > struct platform_device *pdev = cqspi->pdev; > @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { > .compatible = "ti,k2g-qspi", > .data = (void *)CQSPI_NEEDS_WR_DELAY, > }, > + { > + .compatible = "ti,am654-ospi", > + .data = (void *)CQSPI_NEEDS_WR_DELAY, > + }, > { /* end of table */ } > }; > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 8:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: devicetree, Yogesh Gaur, linux-kernel, Marek Vasut, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List On Wed, 3 Oct 2018 22:26:03 +0530 Vignesh R <vigneshr@ti.com> wrote: > Cadence OSPI controller IP supports Octal IO (x8 IO lines), > It also has an integrated PHY. IP register layout is very > similar to existing QSPI IP except for additional bits to support Octal > and Octal DDR mode. Therefore, extend current driver to support Octal > mode. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > index e24db817154e..48b00e75a879 100644 > --- a/drivers/mtd/spi-nor/cadence-quadspi.c > +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > @@ -101,6 +101,7 @@ struct cqspi_st { > #define CQSPI_INST_TYPE_SINGLE 0 > #define CQSPI_INST_TYPE_DUAL 1 > #define CQSPI_INST_TYPE_QUAD 2 > +#define CQSPI_INST_TYPE_OCTAL 3 > > #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > #define CQSPI_DUMMY_BYTES_MAX 4 > @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > case SNOR_PROTO_1_1_4: > f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > break; > + case SNOR_PROTO_1_1_8: > + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > + break; > default: > return -EINVAL; > } > @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > SNOR_HWCAPS_READ_FAST | > SNOR_HWCAPS_READ_1_1_2 | > SNOR_HWCAPS_READ_1_1_4 | > + SNOR_HWCAPS_READ_1_1_8 | Is this really supported on qspi versions of this IP? I guess not given the description in the commit message and the name of the new compatible (ospi instead of qspi). > SNOR_HWCAPS_PP, > }; > struct platform_device *pdev = cqspi->pdev; > @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { > .compatible = "ti,k2g-qspi", > .data = (void *)CQSPI_NEEDS_WR_DELAY, > }, > + { > + .compatible = "ti,am654-ospi", > + .data = (void *)CQSPI_NEEDS_WR_DELAY, > + }, > { /* end of table */ } > }; > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 8:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Wed, 3 Oct 2018 22:26:03 +0530 Vignesh R <vigneshr@ti.com> wrote: > Cadence OSPI controller IP supports Octal IO (x8 IO lines), > It also has an integrated PHY. IP register layout is very > similar to existing QSPI IP except for additional bits to support Octal > and Octal DDR mode. Therefore, extend current driver to support Octal > mode. > > Signed-off-by: Vignesh R <vigneshr@ti.com> > --- > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > index e24db817154e..48b00e75a879 100644 > --- a/drivers/mtd/spi-nor/cadence-quadspi.c > +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > @@ -101,6 +101,7 @@ struct cqspi_st { > #define CQSPI_INST_TYPE_SINGLE 0 > #define CQSPI_INST_TYPE_DUAL 1 > #define CQSPI_INST_TYPE_QUAD 2 > +#define CQSPI_INST_TYPE_OCTAL 3 > > #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > #define CQSPI_DUMMY_BYTES_MAX 4 > @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > case SNOR_PROTO_1_1_4: > f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > break; > + case SNOR_PROTO_1_1_8: > + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > + break; > default: > return -EINVAL; > } > @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > SNOR_HWCAPS_READ_FAST | > SNOR_HWCAPS_READ_1_1_2 | > SNOR_HWCAPS_READ_1_1_4 | > + SNOR_HWCAPS_READ_1_1_8 | Is this really supported on qspi versions of this IP? I guess not given the description in the commit message and the name of the new compatible (ospi instead of qspi). > SNOR_HWCAPS_PP, > }; > struct platform_device *pdev = cqspi->pdev; > @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { > .compatible = "ti,k2g-qspi", > .data = (void *)CQSPI_NEEDS_WR_DELAY, > }, > + { > + .compatible = "ti,am654-ospi", > + .data = (void *)CQSPI_NEEDS_WR_DELAY, > + }, > { /* end of table */ } > }; > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller 2018-12-10 8:45 ` Boris Brezillon (?) @ 2018-12-10 11:19 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-10 11:19 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On 10/12/18 2:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:03 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), >> It also has an integrated PHY. IP register layout is very >> similar to existing QSPI IP except for additional bits to support Octal >> and Octal DDR mode. Therefore, extend current driver to support Octal >> mode. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c >> index e24db817154e..48b00e75a879 100644 >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c >> @@ -101,6 +101,7 @@ struct cqspi_st { >> #define CQSPI_INST_TYPE_SINGLE 0 >> #define CQSPI_INST_TYPE_DUAL 1 >> #define CQSPI_INST_TYPE_QUAD 2 >> +#define CQSPI_INST_TYPE_OCTAL 3 >> >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 >> #define CQSPI_DUMMY_BYTES_MAX 4 >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) >> case SNOR_PROTO_1_1_4: >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; >> break; >> + case SNOR_PROTO_1_1_8: >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; >> + break; >> default: >> return -EINVAL; >> } >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) >> SNOR_HWCAPS_READ_FAST | >> SNOR_HWCAPS_READ_1_1_2 | >> SNOR_HWCAPS_READ_1_1_4 | >> + SNOR_HWCAPS_READ_1_1_8 | > > Is this really supported on qspi versions of this IP? I guess not given > the description in the commit message and the name of the new > compatible (ospi instead of qspi). No, qspi version does not support Octal mode. I guess you are pointing out its logically wrong for driver with "*-qspi" compatible to declare SNOR_HWCAPS_READ_1_1_8 capability. Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. > >> SNOR_HWCAPS_PP, >> }; >> struct platform_device *pdev = cqspi->pdev; >> @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { >> .compatible = "ti,k2g-qspi", >> .data = (void *)CQSPI_NEEDS_WR_DELAY, >> }, >> + { >> + .compatible = "ti,am654-ospi", >> + .data = (void *)CQSPI_NEEDS_WR_DELAY, >> + }, >> { /* end of table */ } >> }; >> > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 11:19 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-10 11:19 UTC (permalink / raw) To: Boris Brezillon Cc: devicetree, Yogesh Gaur, linux-kernel, Marek Vasut, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List On 10/12/18 2:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:03 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), >> It also has an integrated PHY. IP register layout is very >> similar to existing QSPI IP except for additional bits to support Octal >> and Octal DDR mode. Therefore, extend current driver to support Octal >> mode. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c >> index e24db817154e..48b00e75a879 100644 >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c >> @@ -101,6 +101,7 @@ struct cqspi_st { >> #define CQSPI_INST_TYPE_SINGLE 0 >> #define CQSPI_INST_TYPE_DUAL 1 >> #define CQSPI_INST_TYPE_QUAD 2 >> +#define CQSPI_INST_TYPE_OCTAL 3 >> >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 >> #define CQSPI_DUMMY_BYTES_MAX 4 >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) >> case SNOR_PROTO_1_1_4: >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; >> break; >> + case SNOR_PROTO_1_1_8: >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; >> + break; >> default: >> return -EINVAL; >> } >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) >> SNOR_HWCAPS_READ_FAST | >> SNOR_HWCAPS_READ_1_1_2 | >> SNOR_HWCAPS_READ_1_1_4 | >> + SNOR_HWCAPS_READ_1_1_8 | > > Is this really supported on qspi versions of this IP? I guess not given > the description in the commit message and the name of the new > compatible (ospi instead of qspi). No, qspi version does not support Octal mode. I guess you are pointing out its logically wrong for driver with "*-qspi" compatible to declare SNOR_HWCAPS_READ_1_1_8 capability. Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. > >> SNOR_HWCAPS_PP, >> }; >> struct platform_device *pdev = cqspi->pdev; >> @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { >> .compatible = "ti,k2g-qspi", >> .data = (void *)CQSPI_NEEDS_WR_DELAY, >> }, >> + { >> + .compatible = "ti,am654-ospi", >> + .data = (void *)CQSPI_NEEDS_WR_DELAY, >> + }, >> { /* end of table */ } >> }; >> > -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 11:19 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-10 11:19 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On 10/12/18 2:15 PM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:03 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), >> It also has an integrated PHY. IP register layout is very >> similar to existing QSPI IP except for additional bits to support Octal >> and Octal DDR mode. Therefore, extend current driver to support Octal >> mode. >> >> Signed-off-by: Vignesh R <vigneshr@ti.com> >> --- >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c >> index e24db817154e..48b00e75a879 100644 >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c >> @@ -101,6 +101,7 @@ struct cqspi_st { >> #define CQSPI_INST_TYPE_SINGLE 0 >> #define CQSPI_INST_TYPE_DUAL 1 >> #define CQSPI_INST_TYPE_QUAD 2 >> +#define CQSPI_INST_TYPE_OCTAL 3 >> >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 >> #define CQSPI_DUMMY_BYTES_MAX 4 >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) >> case SNOR_PROTO_1_1_4: >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; >> break; >> + case SNOR_PROTO_1_1_8: >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; >> + break; >> default: >> return -EINVAL; >> } >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) >> SNOR_HWCAPS_READ_FAST | >> SNOR_HWCAPS_READ_1_1_2 | >> SNOR_HWCAPS_READ_1_1_4 | >> + SNOR_HWCAPS_READ_1_1_8 | > > Is this really supported on qspi versions of this IP? I guess not given > the description in the commit message and the name of the new > compatible (ospi instead of qspi). No, qspi version does not support Octal mode. I guess you are pointing out its logically wrong for driver with "*-qspi" compatible to declare SNOR_HWCAPS_READ_1_1_8 capability. Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. > >> SNOR_HWCAPS_PP, >> }; >> struct platform_device *pdev = cqspi->pdev; >> @@ -1456,6 +1461,10 @@ static const struct of_device_id cqspi_dt_ids[] = { >> .compatible = "ti,k2g-qspi", >> .data = (void *)CQSPI_NEEDS_WR_DELAY, >> }, >> + { >> + .compatible = "ti,am654-ospi", >> + .data = (void *)CQSPI_NEEDS_WR_DELAY, >> + }, >> { /* end of table */ } >> }; >> > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller 2018-12-10 11:19 ` Vignesh R (?) @ 2018-12-10 11:28 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 11:28 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Mon, 10 Dec 2018 16:49:29 +0530 Vignesh R <vigneshr@ti.com> wrote: > On 10/12/18 2:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:03 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), > >> It also has an integrated PHY. IP register layout is very > >> similar to existing QSPI IP except for additional bits to support Octal > >> and Octal DDR mode. Therefore, extend current driver to support Octal > >> mode. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > >> index e24db817154e..48b00e75a879 100644 > >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c > >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > >> @@ -101,6 +101,7 @@ struct cqspi_st { > >> #define CQSPI_INST_TYPE_SINGLE 0 > >> #define CQSPI_INST_TYPE_DUAL 1 > >> #define CQSPI_INST_TYPE_QUAD 2 > >> +#define CQSPI_INST_TYPE_OCTAL 3 > >> > >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > >> #define CQSPI_DUMMY_BYTES_MAX 4 > >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > >> case SNOR_PROTO_1_1_4: > >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > >> break; > >> + case SNOR_PROTO_1_1_8: > >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > >> + break; > >> default: > >> return -EINVAL; > >> } > >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > >> SNOR_HWCAPS_READ_FAST | > >> SNOR_HWCAPS_READ_1_1_2 | > >> SNOR_HWCAPS_READ_1_1_4 | > >> + SNOR_HWCAPS_READ_1_1_8 | > > > > Is this really supported on qspi versions of this IP? I guess not given > > the description in the commit message and the name of the new > > compatible (ospi instead of qspi). > > No, qspi version does not support Octal mode. I guess you are pointing > out its logically wrong for driver with "*-qspi" compatible to declare > SNOR_HWCAPS_READ_1_1_8 capability. Exactly. > Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 11:28 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 11:28 UTC (permalink / raw) To: Vignesh R Cc: devicetree, Yogesh Gaur, linux-kernel, Marek Vasut, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List On Mon, 10 Dec 2018 16:49:29 +0530 Vignesh R <vigneshr@ti.com> wrote: > On 10/12/18 2:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:03 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), > >> It also has an integrated PHY. IP register layout is very > >> similar to existing QSPI IP except for additional bits to support Octal > >> and Octal DDR mode. Therefore, extend current driver to support Octal > >> mode. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > >> index e24db817154e..48b00e75a879 100644 > >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c > >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > >> @@ -101,6 +101,7 @@ struct cqspi_st { > >> #define CQSPI_INST_TYPE_SINGLE 0 > >> #define CQSPI_INST_TYPE_DUAL 1 > >> #define CQSPI_INST_TYPE_QUAD 2 > >> +#define CQSPI_INST_TYPE_OCTAL 3 > >> > >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > >> #define CQSPI_DUMMY_BYTES_MAX 4 > >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > >> case SNOR_PROTO_1_1_4: > >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > >> break; > >> + case SNOR_PROTO_1_1_8: > >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > >> + break; > >> default: > >> return -EINVAL; > >> } > >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > >> SNOR_HWCAPS_READ_FAST | > >> SNOR_HWCAPS_READ_1_1_2 | > >> SNOR_HWCAPS_READ_1_1_4 | > >> + SNOR_HWCAPS_READ_1_1_8 | > > > > Is this really supported on qspi versions of this IP? I guess not given > > the description in the commit message and the name of the new > > compatible (ospi instead of qspi). > > No, qspi version does not support Octal mode. I guess you are pointing > out its logically wrong for driver with "*-qspi" compatible to declare > SNOR_HWCAPS_READ_1_1_8 capability. Exactly. > Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. Thanks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller @ 2018-12-10 11:28 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 11:28 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel On Mon, 10 Dec 2018 16:49:29 +0530 Vignesh R <vigneshr@ti.com> wrote: > On 10/12/18 2:15 PM, Boris Brezillon wrote: > > On Wed, 3 Oct 2018 22:26:03 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >> Cadence OSPI controller IP supports Octal IO (x8 IO lines), > >> It also has an integrated PHY. IP register layout is very > >> similar to existing QSPI IP except for additional bits to support Octal > >> and Octal DDR mode. Therefore, extend current driver to support Octal > >> mode. > >> > >> Signed-off-by: Vignesh R <vigneshr@ti.com> > >> --- > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c b/drivers/mtd/spi-nor/cadence-quadspi.c > >> index e24db817154e..48b00e75a879 100644 > >> --- a/drivers/mtd/spi-nor/cadence-quadspi.c > >> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > >> @@ -101,6 +101,7 @@ struct cqspi_st { > >> #define CQSPI_INST_TYPE_SINGLE 0 > >> #define CQSPI_INST_TYPE_DUAL 1 > >> #define CQSPI_INST_TYPE_QUAD 2 > >> +#define CQSPI_INST_TYPE_OCTAL 3 > >> > >> #define CQSPI_DUMMY_CLKS_PER_BYTE 8 > >> #define CQSPI_DUMMY_BYTES_MAX 4 > >> @@ -898,6 +899,9 @@ static int cqspi_set_protocol(struct spi_nor *nor, const int read) > >> case SNOR_PROTO_1_1_4: > >> f_pdata->data_width = CQSPI_INST_TYPE_QUAD; > >> break; > >> + case SNOR_PROTO_1_1_8: > >> + f_pdata->data_width = CQSPI_INST_TYPE_OCTAL; > >> + break; > >> default: > >> return -EINVAL; > >> } > >> @@ -1205,6 +1209,7 @@ static int cqspi_setup_flash(struct cqspi_st *cqspi, struct device_node *np) > >> SNOR_HWCAPS_READ_FAST | > >> SNOR_HWCAPS_READ_1_1_2 | > >> SNOR_HWCAPS_READ_1_1_4 | > >> + SNOR_HWCAPS_READ_1_1_8 | > > > > Is this really supported on qspi versions of this IP? I guess not given > > the description in the commit message and the name of the new > > compatible (ospi instead of qspi). > > No, qspi version does not support Octal mode. I guess you are pointing > out its logically wrong for driver with "*-qspi" compatible to declare > SNOR_HWCAPS_READ_1_1_8 capability. Exactly. > Will update patch to declare SNOR_HWCAPS_READ_1_1_8 based on compatible. Thanks. ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-03 16:56 ` Vignesh R @ 2018-10-03 19:20 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-03 19:20 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus On Wed, 3 Oct 2018 22:26:00 +0530 Vignesh R <vigneshr@ti.com> wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller The patchset looks good to me, I'll just wait the next release cycle before applying it, since I'd prefer to have it stay a bit longer in -next. This should leave enough time to let other people review this stuff. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ On a slightly different topic, do you plan to convert the Cadence driver to spi-mem? And if you don't, is it because you don't have time or because some features are missing in spi-mem (I remember you mentioned a few things back when you were reviewing the spi-mem series)? > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-03 19:20 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-03 19:20 UTC (permalink / raw) To: linux-arm-kernel On Wed, 3 Oct 2018 22:26:00 +0530 Vignesh R <vigneshr@ti.com> wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller The patchset looks good to me, I'll just wait the next release cycle before applying it, since I'd prefer to have it stay a bit longer in -next. This should leave enough time to let other people review this stuff. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ On a slightly different topic, do you plan to convert the Cadence driver to spi-mem? And if you don't, is it because you don't have time or because some features are missing in spi-mem (I remember you mentioned a few things back when you were reviewing the spi-mem series)? > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-03 19:20 ` Boris Brezillon (?) @ 2018-10-04 10:35 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:35 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus On Thursday 04 October 2018 12:50 AM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:00 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> This series adds support for octal mode of mt35x flash. Also, adds >> support for OSPI version of Cadence QSPI controller. >> >> Based on top of patches adding basic support for mt35xu512aba here: >> https://patchwork.ozlabs.org/cover/971437/ >> >> Vignesh R (3): >> mtd: spi-nor: Add Octal mode support for mt35xu512aba >> dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC >> mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > The patchset looks good to me, I'll just wait the next release cycle > before applying it, since I'd prefer to have it stay a bit longer in > -next. This should leave enough time to let other people review this > stuff. > Ok, thats fine... >> >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > On a slightly different topic, do you plan to convert the Cadence > driver to spi-mem? And if you don't, is it because you don't have time > or because some features are missing in spi-mem (I remember you > mentioned a few things back when you were reviewing the spi-mem series)? > I do not have plans to convert cadence QSPI driver to spi-mem yet, mainly due to lack of time. Also, not sure if original author Marek and other altera people are okay with that. I see couple of issues in the way of conversion: 1. I would wait to know what direction would direct mapping APIs[1] go before starting spi-mem conversion for Cadence QSPI driver. Else, we have may to re write again if direct mapping APIs are merged. 2. New Cadence OSPI IP has an integrated PHY to support high throughput OSPI flashes operating up 200MHz in Octal DDR mode. In order to work with such flashes, PHY DLLs need to be calibrated. Highly simplified calibration sequence is as below(See [2] for actual sequence): -Read flash ID at low speed and store it. -Enable PHY and set DLLs to a defined initial value -Increment RX DLL value -Read flash ID and check for correctness of data read -repeat above two steps until a band of passing values is obtained for RX DLL where flash ID is correctly read. -DLL needs to set to middle of the passing band. I am trying to figure out how to fit this into the spi-mem framework as controller would to need to store READ ID opcode and expected JEDEC ID before starting calibration sequence. [1]https://patchwork.ozlabs.org/cover/924041/ [2]http://www.ti.com/lit/ug/spruid7a/spruid7a.pdf(12.3.2.4.14 PHY Module page 9770-9772) -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-04 10:35 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:35 UTC (permalink / raw) To: linux-arm-kernel On Thursday 04 October 2018 12:50 AM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:00 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> This series adds support for octal mode of mt35x flash. Also, adds >> support for OSPI version of Cadence QSPI controller. >> >> Based on top of patches adding basic support for mt35xu512aba here: >> https://patchwork.ozlabs.org/cover/971437/ >> >> Vignesh R (3): >> mtd: spi-nor: Add Octal mode support for mt35xu512aba >> dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC >> mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > The patchset looks good to me, I'll just wait the next release cycle > before applying it, since I'd prefer to have it stay a bit longer in > -next. This should leave enough time to let other people review this > stuff. > Ok, thats fine... >> >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > On a slightly different topic, do you plan to convert the Cadence > driver to spi-mem? And if you don't, is it because you don't have time > or because some features are missing in spi-mem (I remember you > mentioned a few things back when you were reviewing the spi-mem series)? > I do not have plans to convert cadence QSPI driver to spi-mem yet, mainly due to lack of time. Also, not sure if original author Marek and other altera people are okay with that. I see couple of issues in the way of conversion: 1. I would wait to know what direction would direct mapping APIs[1] go before starting spi-mem conversion for Cadence QSPI driver. Else, we have may to re write again if direct mapping APIs are merged. 2. New Cadence OSPI IP has an integrated PHY to support high throughput OSPI flashes operating up 200MHz in Octal DDR mode. In order to work with such flashes, PHY DLLs need to be calibrated. Highly simplified calibration sequence is as below(See [2] for actual sequence): -Read flash ID at low speed and store it. -Enable PHY and set DLLs to a defined initial value -Increment RX DLL value -Read flash ID and check for correctness of data read -repeat above two steps until a band of passing values is obtained for RX DLL where flash ID is correctly read. -DLL needs to set to middle of the passing band. I am trying to figure out how to fit this into the spi-mem framework as controller would to need to store READ ID opcode and expected JEDEC ID before starting calibration sequence. [1]https://patchwork.ozlabs.org/cover/924041/ [2]http://www.ti.com/lit/ug/spruid7a/spruid7a.pdf(12.3.2.4.14 PHY Module page 9770-9772) -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-04 10:35 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-04 10:35 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus On Thursday 04 October 2018 12:50 AM, Boris Brezillon wrote: > On Wed, 3 Oct 2018 22:26:00 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >> This series adds support for octal mode of mt35x flash. Also, adds >> support for OSPI version of Cadence QSPI controller. >> >> Based on top of patches adding basic support for mt35xu512aba here: >> https://patchwork.ozlabs.org/cover/971437/ >> >> Vignesh R (3): >> mtd: spi-nor: Add Octal mode support for mt35xu512aba >> dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC >> mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > The patchset looks good to me, I'll just wait the next release cycle > before applying it, since I'd prefer to have it stay a bit longer in > -next. This should leave enough time to let other people review this > stuff. > Ok, thats fine... >> >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > On a slightly different topic, do you plan to convert the Cadence > driver to spi-mem? And if you don't, is it because you don't have time > or because some features are missing in spi-mem (I remember you > mentioned a few things back when you were reviewing the spi-mem series)? > I do not have plans to convert cadence QSPI driver to spi-mem yet, mainly due to lack of time. Also, not sure if original author Marek and other altera people are okay with that. I see couple of issues in the way of conversion: 1. I would wait to know what direction would direct mapping APIs[1] go before starting spi-mem conversion for Cadence QSPI driver. Else, we have may to re write again if direct mapping APIs are merged. 2. New Cadence OSPI IP has an integrated PHY to support high throughput OSPI flashes operating up 200MHz in Octal DDR mode. In order to work with such flashes, PHY DLLs need to be calibrated. Highly simplified calibration sequence is as below(See [2] for actual sequence): -Read flash ID at low speed and store it. -Enable PHY and set DLLs to a defined initial value -Increment RX DLL value -Read flash ID and check for correctness of data read -repeat above two steps until a band of passing values is obtained for RX DLL where flash ID is correctly read. -DLL needs to set to middle of the passing band. I am trying to figure out how to fit this into the spi-mem framework as controller would to need to store READ ID opcode and expected JEDEC ID before starting calibration sequence. [1]https://patchwork.ozlabs.org/cover/924041/ [2]http://www.ti.com/lit/ug/spruid7a/spruid7a.pdf(12.3.2.4.14 PHY Module page 9770-9772) -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-04 10:35 ` Vignesh R (?) @ 2018-10-04 11:17 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:17 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus On Thu, 4 Oct 2018 16:05:36 +0530 Vignesh R <vigneshr@ti.com> wrote: > >> > >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > > > On a slightly different topic, do you plan to convert the Cadence > > driver to spi-mem? And if you don't, is it because you don't have time > > or because some features are missing in spi-mem (I remember you > > mentioned a few things back when you were reviewing the spi-mem series)? > > > > I do not have plans to convert cadence QSPI driver to spi-mem yet, > mainly due to lack of time. Also, not sure if original author Marek and > other altera people are okay with that. > > I see couple of issues in the way of conversion: > 1. I would wait to know what direction would direct mapping APIs[1] go > before starting spi-mem conversion for Cadence QSPI driver. Else, we > have may to re write again if direct mapping APIs are merged. I'd suggest reviewing the proposal I posted so that you can influence the design of this new API ;-). > 2. New Cadence OSPI IP has an integrated PHY to support high throughput > OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > with such flashes, PHY DLLs need to be calibrated. Highly simplified > calibration sequence is as below(See [2] for actual sequence): > -Read flash ID at low speed and store it. > -Enable PHY and set DLLs to a defined initial value > -Increment RX DLL value > -Read flash ID and check for correctness of data read > -repeat above two steps until a band of passing values is obtained for > RX DLL where flash ID is correctly read. > -DLL needs to set to middle of the passing band. Is the Read ID operation hardcoded or do you just use it as a way to trigger predictable transfers on the IO bus? > > I am trying to figure out how to fit this into the spi-mem framework as > controller would to need to store READ ID opcode and expected JEDEC ID > before starting calibration sequence. I think this should be split in 2: - the SPI NOR framework passing the operation to use to do the calibration (here a READ ID) - the SPI controller framework replaying the same operation with different DLL configs until it finds the best match So, it would basically be added as a new hook: int (*calibrate)(struct spi_mem *mem, const struct spi_mem_op *tmpl); and a new function provided by the spi-mem API int spi_mem_calibrate(struct spi_mem *mem, const struct spi_mem_op *tmpl); and calibration outcome would be somehow attached to the spi_mem object. This way we stay memory agnostic but still provide the necessary blocks at the spi-mem level to do such callibrations. Would that work? ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-04 11:17 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:17 UTC (permalink / raw) To: linux-arm-kernel On Thu, 4 Oct 2018 16:05:36 +0530 Vignesh R <vigneshr@ti.com> wrote: > >> > >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > > > On a slightly different topic, do you plan to convert the Cadence > > driver to spi-mem? And if you don't, is it because you don't have time > > or because some features are missing in spi-mem (I remember you > > mentioned a few things back when you were reviewing the spi-mem series)? > > > > I do not have plans to convert cadence QSPI driver to spi-mem yet, > mainly due to lack of time. Also, not sure if original author Marek and > other altera people are okay with that. > > I see couple of issues in the way of conversion: > 1. I would wait to know what direction would direct mapping APIs[1] go > before starting spi-mem conversion for Cadence QSPI driver. Else, we > have may to re write again if direct mapping APIs are merged. I'd suggest reviewing the proposal I posted so that you can influence the design of this new API ;-). > 2. New Cadence OSPI IP has an integrated PHY to support high throughput > OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > with such flashes, PHY DLLs need to be calibrated. Highly simplified > calibration sequence is as below(See [2] for actual sequence): > -Read flash ID at low speed and store it. > -Enable PHY and set DLLs to a defined initial value > -Increment RX DLL value > -Read flash ID and check for correctness of data read > -repeat above two steps until a band of passing values is obtained for > RX DLL where flash ID is correctly read. > -DLL needs to set to middle of the passing band. Is the Read ID operation hardcoded or do you just use it as a way to trigger predictable transfers on the IO bus? > > I am trying to figure out how to fit this into the spi-mem framework as > controller would to need to store READ ID opcode and expected JEDEC ID > before starting calibration sequence. I think this should be split in 2: - the SPI NOR framework passing the operation to use to do the calibration (here a READ ID) - the SPI controller framework replaying the same operation with different DLL configs until it finds the best match So, it would basically be added as a new hook: int (*calibrate)(struct spi_mem *mem, const struct spi_mem_op *tmpl); and a new function provided by the spi-mem API int spi_mem_calibrate(struct spi_mem *mem, const struct spi_mem_op *tmpl); and calibration outcome would be somehow attached to the spi_mem object. This way we stay memory agnostic but still provide the necessary blocks at the spi-mem level to do such callibrations. Would that work? ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-04 11:17 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-04 11:17 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus On Thu, 4 Oct 2018 16:05:36 +0530 Vignesh R <vigneshr@ti.com> wrote: > >> > >> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > > > On a slightly different topic, do you plan to convert the Cadence > > driver to spi-mem? And if you don't, is it because you don't have time > > or because some features are missing in spi-mem (I remember you > > mentioned a few things back when you were reviewing the spi-mem series)? > > > > I do not have plans to convert cadence QSPI driver to spi-mem yet, > mainly due to lack of time. Also, not sure if original author Marek and > other altera people are okay with that. > > I see couple of issues in the way of conversion: > 1. I would wait to know what direction would direct mapping APIs[1] go > before starting spi-mem conversion for Cadence QSPI driver. Else, we > have may to re write again if direct mapping APIs are merged. I'd suggest reviewing the proposal I posted so that you can influence the design of this new API ;-). > 2. New Cadence OSPI IP has an integrated PHY to support high throughput > OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > with such flashes, PHY DLLs need to be calibrated. Highly simplified > calibration sequence is as below(See [2] for actual sequence): > -Read flash ID at low speed and store it. > -Enable PHY and set DLLs to a defined initial value > -Increment RX DLL value > -Read flash ID and check for correctness of data read > -repeat above two steps until a band of passing values is obtained for > RX DLL where flash ID is correctly read. > -DLL needs to set to middle of the passing band. Is the Read ID operation hardcoded or do you just use it as a way to trigger predictable transfers on the IO bus? > > I am trying to figure out how to fit this into the spi-mem framework as > controller would to need to store READ ID opcode and expected JEDEC ID > before starting calibration sequence. I think this should be split in 2: - the SPI NOR framework passing the operation to use to do the calibration (here a READ ID) - the SPI controller framework replaying the same operation with different DLL configs until it finds the best match So, it would basically be added as a new hook: int (*calibrate)(struct spi_mem *mem, const struct spi_mem_op *tmpl); and a new function provided by the spi-mem API int spi_mem_calibrate(struct spi_mem *mem, const struct spi_mem_op *tmpl); and calibration outcome would be somehow attached to the spi_mem object. This way we stay memory agnostic but still provide the necessary blocks at the spi-mem level to do such callibrations. Would that work? ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-04 11:17 ` Boris Brezillon @ 2018-10-08 15:36 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-08 15:36 UTC (permalink / raw) To: Boris Brezillon Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus Hi Boris, Sorry I missed this mail. On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > On Thu, 4 Oct 2018 16:05:36 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >>>> >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ >>> >>> On a slightly different topic, do you plan to convert the Cadence >>> driver to spi-mem? And if you don't, is it because you don't have time >>> or because some features are missing in spi-mem (I remember you >>> mentioned a few things back when you were reviewing the spi-mem series)? >>> >> >> I do not have plans to convert cadence QSPI driver to spi-mem yet, >> mainly due to lack of time. Also, not sure if original author Marek and >> other altera people are okay with that. >> >> I see couple of issues in the way of conversion: >> 1. I would wait to know what direction would direct mapping APIs[1] go >> before starting spi-mem conversion for Cadence QSPI driver. Else, we >> have may to re write again if direct mapping APIs are merged. > > I'd suggest reviewing the proposal I posted so that you can influence > the design of this new API ;-). > I did take a look and proposal seems fine. Will try to prototype and test cadence QSPI driver with these. Thanks for the patches! >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work >> with such flashes, PHY DLLs need to be calibrated. Highly simplified >> calibration sequence is as below(See [2] for actual sequence): >> -Read flash ID at low speed and store it. >> -Enable PHY and set DLLs to a defined initial value >> -Increment RX DLL value >> -Read flash ID and check for correctness of data read >> -repeat above two steps until a band of passing values is obtained for >> RX DLL where flash ID is correctly read. >> -DLL needs to set to middle of the passing band. > > Is the Read ID operation hardcoded or do you just use it as a way to > trigger predictable transfers on the IO bus? > Just a way to trigger predictable data reads. >> >> I am trying to figure out how to fit this into the spi-mem framework as >> controller would to need to store READ ID opcode and expected JEDEC ID >> before starting calibration sequence. > > I think this should be split in 2: > > - the SPI NOR framework passing the operation to use to do the > calibration (here a READ ID) > - the SPI controller framework replaying the same operation with > different DLL configs until it finds the best match > > So, it would basically be added as a new hook: > > int (*calibrate)(struct spi_mem *mem, > const struct spi_mem_op *tmpl); > > and a new function provided by the spi-mem API > > int spi_mem_calibrate(struct spi_mem *mem, > const struct spi_mem_op *tmpl); > > and calibration outcome would be somehow attached to the spi_mem > object. > > This way we stay memory agnostic but still provide the necessary blocks > at the spi-mem level to do such callibrations. > > Would that work? > That would work and hopefully is not intrusive to spi-mem framework. -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-08 15:36 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-10-08 15:36 UTC (permalink / raw) To: linux-arm-kernel Hi Boris, Sorry I missed this mail. On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > On Thu, 4 Oct 2018 16:05:36 +0530 > Vignesh R <vigneshr@ti.com> wrote: > >>>> >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ >>> >>> On a slightly different topic, do you plan to convert the Cadence >>> driver to spi-mem? And if you don't, is it because you don't have time >>> or because some features are missing in spi-mem (I remember you >>> mentioned a few things back when you were reviewing the spi-mem series)? >>> >> >> I do not have plans to convert cadence QSPI driver to spi-mem yet, >> mainly due to lack of time. Also, not sure if original author Marek and >> other altera people are okay with that. >> >> I see couple of issues in the way of conversion: >> 1. I would wait to know what direction would direct mapping APIs[1] go >> before starting spi-mem conversion for Cadence QSPI driver. Else, we >> have may to re write again if direct mapping APIs are merged. > > I'd suggest reviewing the proposal I posted so that you can influence > the design of this new API ;-). > I did take a look and proposal seems fine. Will try to prototype and test cadence QSPI driver with these. Thanks for the patches! >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work >> with such flashes, PHY DLLs need to be calibrated. Highly simplified >> calibration sequence is as below(See [2] for actual sequence): >> -Read flash ID at low speed and store it. >> -Enable PHY and set DLLs to a defined initial value >> -Increment RX DLL value >> -Read flash ID and check for correctness of data read >> -repeat above two steps until a band of passing values is obtained for >> RX DLL where flash ID is correctly read. >> -DLL needs to set to middle of the passing band. > > Is the Read ID operation hardcoded or do you just use it as a way to > trigger predictable transfers on the IO bus? > Just a way to trigger predictable data reads. >> >> I am trying to figure out how to fit this into the spi-mem framework as >> controller would to need to store READ ID opcode and expected JEDEC ID >> before starting calibration sequence. > > I think this should be split in 2: > > - the SPI NOR framework passing the operation to use to do the > calibration (here a READ ID) > - the SPI controller framework replaying the same operation with > different DLL configs until it finds the best match > > So, it would basically be added as a new hook: > > int (*calibrate)(struct spi_mem *mem, > const struct spi_mem_op *tmpl); > > and a new function provided by the spi-mem API > > int spi_mem_calibrate(struct spi_mem *mem, > const struct spi_mem_op *tmpl); > > and calibration outcome would be somehow attached to the spi_mem > object. > > This way we stay memory agnostic but still provide the necessary blocks > at the spi-mem level to do such callibrations. > > Would that work? > That would work and hopefully is not intrusive to spi-mem framework. -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-08 15:36 ` Vignesh R @ 2018-10-12 8:52 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-12 8:52 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, devicetree, Yogesh Gaur, linux-kernel, linux-mtd, Brian Norris, Linux ARM Mailing List, Tudor Ambarus Hi Vignesh, On Mon, 8 Oct 2018 21:06:02 +0530 Vignesh R <vigneshr@ti.com> wrote: > Hi Boris, > > Sorry I missed this mail. > > On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > > On Thu, 4 Oct 2018 16:05:36 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >>>> > >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >>> > >>> On a slightly different topic, do you plan to convert the Cadence > >>> driver to spi-mem? And if you don't, is it because you don't have time > >>> or because some features are missing in spi-mem (I remember you > >>> mentioned a few things back when you were reviewing the spi-mem series)? > >>> > >> > >> I do not have plans to convert cadence QSPI driver to spi-mem yet, > >> mainly due to lack of time. Also, not sure if original author Marek and > >> other altera people are okay with that. > >> > >> I see couple of issues in the way of conversion: > >> 1. I would wait to know what direction would direct mapping APIs[1] go > >> before starting spi-mem conversion for Cadence QSPI driver. Else, we > >> have may to re write again if direct mapping APIs are merged. > > > > I'd suggest reviewing the proposal I posted so that you can influence > > the design of this new API ;-). > > > > I did take a look and proposal seems fine. Will try to prototype and > test cadence QSPI driver with these. Thanks for the patches! That's great news! Let me know how it goes, and don't hesitate to ask if you have any questions. > > > >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput > >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > >> with such flashes, PHY DLLs need to be calibrated. Highly simplified > >> calibration sequence is as below(See [2] for actual sequence): > >> -Read flash ID at low speed and store it. > >> -Enable PHY and set DLLs to a defined initial value > >> -Increment RX DLL value > >> -Read flash ID and check for correctness of data read > >> -repeat above two steps until a band of passing values is obtained for > >> RX DLL where flash ID is correctly read. > >> -DLL needs to set to middle of the passing band. > > > > Is the Read ID operation hardcoded or do you just use it as a way to > > trigger predictable transfers on the IO bus? > > > > Just a way to trigger predictable data reads. Good. > > >> > >> I am trying to figure out how to fit this into the spi-mem framework as > >> controller would to need to store READ ID opcode and expected JEDEC ID > >> before starting calibration sequence. > > > > I think this should be split in 2: > > > > - the SPI NOR framework passing the operation to use to do the > > calibration (here a READ ID) > > - the SPI controller framework replaying the same operation with > > different DLL configs until it finds the best match > > > > So, it would basically be added as a new hook: > > > > int (*calibrate)(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and a new function provided by the spi-mem API > > > > int spi_mem_calibrate(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and calibration outcome would be somehow attached to the spi_mem > > object. > > > > This way we stay memory agnostic but still provide the necessary blocks > > at the spi-mem level to do such callibrations. > > > > Would that work? > > > > That would work and hopefully is not intrusive to spi-mem framework. > Okay. Don't hesitate to post a proposal along those lines and I'll try to review it. Thanks, Boris ^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-10-12 8:52 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-10-12 8:52 UTC (permalink / raw) To: linux-arm-kernel Hi Vignesh, On Mon, 8 Oct 2018 21:06:02 +0530 Vignesh R <vigneshr@ti.com> wrote: > Hi Boris, > > Sorry I missed this mail. > > On Thursday 04 October 2018 04:47 PM, Boris Brezillon wrote: > > On Thu, 4 Oct 2018 16:05:36 +0530 > > Vignesh R <vigneshr@ti.com> wrote: > > > >>>> > >>>> .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > >>>> drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > >>> > >>> On a slightly different topic, do you plan to convert the Cadence > >>> driver to spi-mem? And if you don't, is it because you don't have time > >>> or because some features are missing in spi-mem (I remember you > >>> mentioned a few things back when you were reviewing the spi-mem series)? > >>> > >> > >> I do not have plans to convert cadence QSPI driver to spi-mem yet, > >> mainly due to lack of time. Also, not sure if original author Marek and > >> other altera people are okay with that. > >> > >> I see couple of issues in the way of conversion: > >> 1. I would wait to know what direction would direct mapping APIs[1] go > >> before starting spi-mem conversion for Cadence QSPI driver. Else, we > >> have may to re write again if direct mapping APIs are merged. > > > > I'd suggest reviewing the proposal I posted so that you can influence > > the design of this new API ;-). > > > > I did take a look and proposal seems fine. Will try to prototype and > test cadence QSPI driver with these. Thanks for the patches! That's great news! Let me know how it goes, and don't hesitate to ask if you have any questions. > > > >> 2. New Cadence OSPI IP has an integrated PHY to support high throughput > >> OSPI flashes operating up 200MHz in Octal DDR mode. In order to work > >> with such flashes, PHY DLLs need to be calibrated. Highly simplified > >> calibration sequence is as below(See [2] for actual sequence): > >> -Read flash ID at low speed and store it. > >> -Enable PHY and set DLLs to a defined initial value > >> -Increment RX DLL value > >> -Read flash ID and check for correctness of data read > >> -repeat above two steps until a band of passing values is obtained for > >> RX DLL where flash ID is correctly read. > >> -DLL needs to set to middle of the passing band. > > > > Is the Read ID operation hardcoded or do you just use it as a way to > > trigger predictable transfers on the IO bus? > > > > Just a way to trigger predictable data reads. Good. > > >> > >> I am trying to figure out how to fit this into the spi-mem framework as > >> controller would to need to store READ ID opcode and expected JEDEC ID > >> before starting calibration sequence. > > > > I think this should be split in 2: > > > > - the SPI NOR framework passing the operation to use to do the > > calibration (here a READ ID) > > - the SPI controller framework replaying the same operation with > > different DLL configs until it finds the best match > > > > So, it would basically be added as a new hook: > > > > int (*calibrate)(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and a new function provided by the spi-mem API > > > > int spi_mem_calibrate(struct spi_mem *mem, > > const struct spi_mem_op *tmpl); > > > > and calibration outcome would be somehow attached to the spi_mem > > object. > > > > This way we stay memory agnostic but still provide the necessary blocks > > at the spi-mem level to do such callibrations. > > > > Would that work? > > > > That would work and hopefully is not intrusive to spi-mem framework. > Okay. Don't hesitate to post a proposal along those lines and I'll try to review it. Thanks, Boris ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-10-03 16:56 ` Vignesh R (?) @ 2018-12-09 8:47 ` Vignesh R -1 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-09 8:47 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut Cc: Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel Hi Boris, On 03/10/18 10:26 PM, Vignesh R wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Could you consider above two patches for v4.21 once [1][2] are merged? [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Let me know if this needs to be re-posted. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-12-09 8:47 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-09 8:47 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut Cc: devicetree, Yogesh Gaur, linux-kernel, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List Hi Boris, On 03/10/18 10:26 PM, Vignesh R wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Could you consider above two patches for v4.21 once [1][2] are merged? [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Let me know if this needs to be re-posted. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-12-09 8:47 ` Vignesh R 0 siblings, 0 replies; 63+ messages in thread From: Vignesh R @ 2018-12-09 8:47 UTC (permalink / raw) To: Boris Brezillon, Marek Vasut Cc: devicetree, Yogesh Gaur, linux-kernel, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List Hi Boris, On 03/10/18 10:26 PM, Vignesh R wrote: > This series adds support for octal mode of mt35x flash. Also, adds > support for OSPI version of Cadence QSPI controller. > > Based on top of patches adding basic support for mt35xu512aba here: > https://patchwork.ozlabs.org/cover/971437/ > > Vignesh R (3): > mtd: spi-nor: Add Octal mode support for mt35xu512aba > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Could you consider above two patches for v4.21 once [1][2] are merged? [1] https://patchwork.ozlabs.org/patch/1006717/ [2] https://patchwork.ozlabs.org/patch/1006715/ Let me know if this needs to be re-posted. > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > include/linux/mtd/spi-nor.h | 2 ++ > 4 files changed, 22 insertions(+), 1 deletion(-) > -- Regards Vignesh ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support 2018-12-09 8:47 ` Vignesh R (?) @ 2018-12-10 8:45 ` Boris Brezillon -1 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Tudor Ambarus On Sun, 9 Dec 2018 14:17:18 +0530 Vignesh R <vigneshr@ti.com> wrote: > Hi Boris, > > On 03/10/18 10:26 PM, Vignesh R wrote: > > This series adds support for octal mode of mt35x flash. Also, adds > > support for OSPI version of Cadence QSPI controller. > > > > Based on top of patches adding basic support for mt35xu512aba here: > > https://patchwork.ozlabs.org/cover/971437/ > > > > Vignesh R (3): > > mtd: spi-nor: Add Octal mode support for mt35xu512aba > > > > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > Could you consider above two patches for v4.21 once [1][2] are merged? > > [1] https://patchwork.ozlabs.org/patch/1006717/ > [2] https://patchwork.ozlabs.org/patch/1006715/ I asked Tudor to have a look at those patches. I'll apply them once I have his R-b. > > Let me know if this needs to be re-posted. > > > > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > > include/linux/mtd/spi-nor.h | 2 ++ > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-12-10 8:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: devicetree, Yogesh Gaur, Tudor Ambarus, linux-kernel, Marek Vasut, Rob Herring, linux-mtd, Brian Norris, Linux ARM Mailing List On Sun, 9 Dec 2018 14:17:18 +0530 Vignesh R <vigneshr@ti.com> wrote: > Hi Boris, > > On 03/10/18 10:26 PM, Vignesh R wrote: > > This series adds support for octal mode of mt35x flash. Also, adds > > support for OSPI version of Cadence QSPI controller. > > > > Based on top of patches adding basic support for mt35xu512aba here: > > https://patchwork.ozlabs.org/cover/971437/ > > > > Vignesh R (3): > > mtd: spi-nor: Add Octal mode support for mt35xu512aba > > > > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > Could you consider above two patches for v4.21 once [1][2] are merged? > > [1] https://patchwork.ozlabs.org/patch/1006717/ > [2] https://patchwork.ozlabs.org/patch/1006715/ I asked Tudor to have a look at those patches. I'll apply them once I have his R-b. > > Let me know if this needs to be re-posted. > > > > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > > include/linux/mtd/spi-nor.h | 2 ++ > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/3] spi-nor: Add Octal SPI support @ 2018-12-10 8:45 ` Boris Brezillon 0 siblings, 0 replies; 63+ messages in thread From: Boris Brezillon @ 2018-12-10 8:45 UTC (permalink / raw) To: Vignesh R Cc: Marek Vasut, Rob Herring, Brian Norris, Yogesh Gaur, Linux ARM Mailing List, linux-mtd, devicetree, linux-kernel, Tudor Ambarus On Sun, 9 Dec 2018 14:17:18 +0530 Vignesh R <vigneshr@ti.com> wrote: > Hi Boris, > > On 03/10/18 10:26 PM, Vignesh R wrote: > > This series adds support for octal mode of mt35x flash. Also, adds > > support for OSPI version of Cadence QSPI controller. > > > > Based on top of patches adding basic support for mt35xu512aba here: > > https://patchwork.ozlabs.org/cover/971437/ > > > > Vignesh R (3): > > mtd: spi-nor: Add Octal mode support for mt35xu512aba > > > > dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC > > mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller > > Could you consider above two patches for v4.21 once [1][2] are merged? > > [1] https://patchwork.ozlabs.org/patch/1006717/ > [2] https://patchwork.ozlabs.org/patch/1006715/ I asked Tudor to have a look at those patches. I'll apply them once I have his R-b. > > Let me know if this needs to be re-posted. > > > > > .../devicetree/bindings/mtd/cadence-quadspi.txt | 1 + > > drivers/mtd/spi-nor/cadence-quadspi.c | 9 +++++++++ > > drivers/mtd/spi-nor/spi-nor.c | 11 ++++++++++- > > include/linux/mtd/spi-nor.h | 2 ++ > > 4 files changed, 22 insertions(+), 1 deletion(-) > > > ^ permalink raw reply [flat|nested] 63+ messages in thread
end of thread, other threads:[~2018-12-10 11:28 UTC | newest] Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-03 16:56 [PATCH 0/3] spi-nor: Add Octal SPI support Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` [PATCH 1/3] mtd: spi-nor: Add Octal mode support for mt35xu512aba Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-04 6:51 ` Yogesh Narayan Gaur 2018-10-04 6:51 ` Yogesh Narayan Gaur 2018-10-04 7:39 ` Boris Brezillon 2018-10-04 7:39 ` Boris Brezillon 2018-10-04 8:47 ` Yogesh Narayan Gaur 2018-10-04 8:47 ` Yogesh Narayan Gaur 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 9:10 ` Boris Brezillon 2018-10-04 10:38 ` Vignesh R 2018-10-04 10:38 ` Vignesh R 2018-10-04 10:38 ` Vignesh R 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 9:45 ` Boris Brezillon 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:12 ` Vignesh R 2018-10-04 11:27 ` Boris Brezillon 2018-10-04 11:27 ` Boris Brezillon 2018-10-04 11:27 ` Boris Brezillon 2018-10-03 16:56 ` [PATCH 2/3] dt-bindings: cadence-quadspi: Add new compatible for AM654 SoC Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-15 19:11 ` Rob Herring 2018-10-15 19:11 ` Rob Herring 2018-10-15 19:11 ` Rob Herring 2018-10-03 16:56 ` [PATCH 3/3] mtd: spi-nor: cadence-quadspi: Add support for Octal SPI controller Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-10-03 16:56 ` Vignesh R 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:19 ` Vignesh R 2018-12-10 11:28 ` Boris Brezillon 2018-12-10 11:28 ` Boris Brezillon 2018-12-10 11:28 ` Boris Brezillon 2018-10-03 19:20 ` [PATCH 0/3] spi-nor: Add Octal SPI support Boris Brezillon 2018-10-03 19:20 ` Boris Brezillon 2018-10-04 10:35 ` Vignesh R 2018-10-04 10:35 ` Vignesh R 2018-10-04 10:35 ` Vignesh R 2018-10-04 11:17 ` Boris Brezillon 2018-10-04 11:17 ` Boris Brezillon 2018-10-04 11:17 ` Boris Brezillon 2018-10-08 15:36 ` Vignesh R 2018-10-08 15:36 ` Vignesh R 2018-10-12 8:52 ` Boris Brezillon 2018-10-12 8:52 ` Boris Brezillon 2018-12-09 8:47 ` Vignesh R 2018-12-09 8:47 ` Vignesh R 2018-12-09 8:47 ` Vignesh R 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon 2018-12-10 8:45 ` Boris Brezillon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.