| Message ID | 1560336476-31763-2-git-send-email-sagar.kadam@sifive.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | mtd: spi-nor: add support for is25wp256 spi-nor flash | expand |
Hi, On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: [...] > @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, > if (ret) > return ret; > > - if (nor->addr_width) { > + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { > /* already configured from SFDP */ Hmm, why would you want to ignore addr_width that's read from SFDP table? Regards Vignesh > } else if (info->addr_width) { > nor->addr_width = info->addr_width; > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > index b3d360b..ff13297 100644 > --- a/include/linux/mtd/spi-nor.h > +++ b/include/linux/mtd/spi-nor.h > @@ -19,6 +19,7 @@ > #define SNOR_MFR_ATMEL CFI_MFR_ATMEL > #define SNOR_MFR_GIGADEVICE 0xc8 > #define SNOR_MFR_INTEL CFI_MFR_INTEL > +#define SNOR_MFR_ISSI 0x9d /* ISSI */ > #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */ > #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */ > #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX >
Hello Vignesh, Thanks for your review comments. On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > Hi, > > On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: > [...] > > > @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, > > if (ret) > > return ret; > > > > - if (nor->addr_width) { > > + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { > > /* already configured from SFDP */ > > Hmm, why would you want to ignore addr_width that's read from SFDP table? The SFDP table for ISSI device considered here, has addr_width set to 3 byte, and the flash considered here is 32MB. With 3 byte address width we won't be able to access flash memories higher address range. Hence I have ignored the addr width from SFDP. I have verified that with 3 byte address width, the flascp util fails while verifying the written data. Please let me know your views on this? BR, Sagar Kadam > Regards > Vignesh > > > > } else if (info->addr_width) { > > nor->addr_width = info->addr_width; > > diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > > index b3d360b..ff13297 100644 > > --- a/include/linux/mtd/spi-nor.h > > +++ b/include/linux/mtd/spi-nor.h > > @@ -19,6 +19,7 @@ > > #define SNOR_MFR_ATMEL CFI_MFR_ATMEL > > #define SNOR_MFR_GIGADEVICE 0xc8 > > #define SNOR_MFR_INTEL CFI_MFR_INTEL > > +#define SNOR_MFR_ISSI 0x9d /* ISSI */ > > #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */ > > #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */ > > #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX > >
Hi, On 17/06/19 8:48 PM, Sagar Kadam wrote: > Hello Vignesh, > > Thanks for your review comments. > > On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> >> Hi, >> >> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: >> [...] >> >>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, >>> if (ret) >>> return ret; >>> >>> - if (nor->addr_width) { >>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { >>> /* already configured from SFDP */ >> >> Hmm, why would you want to ignore addr_width that's read from SFDP table? > > The SFDP table for ISSI device considered here, has addr_width set to > 3 byte, and the flash considered > here is 32MB. With 3 byte address width we won't be able to access > flash memories higher address range. Is it specific to a particular ISSI part as indicated here[1]? If so, please submit solution agreed there i.e. use spi_nor_fixups callback [1]https://patchwork.ozlabs.org/patch/1056049/ > Hence I have ignored the addr width from SFDP. I have verified that > with 3 byte address width, the > flascp util fails while verifying the written data. Please let me > know your views on this? > If this affects multiple ISSI parts then: Instead of checking for mfr code, look for SNOR_F_4B_OPCODES flag in flash_info struct of the device and let it take precedence over SFDP in case size is over 16MB Regards Vignesh > BR, > Sagar Kadam > >> Regards >> Vignesh >> >> >>> } else if (info->addr_width) { >>> nor->addr_width = info->addr_width; >>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h >>> index b3d360b..ff13297 100644 >>> --- a/include/linux/mtd/spi-nor.h >>> +++ b/include/linux/mtd/spi-nor.h >>> @@ -19,6 +19,7 @@ >>> #define SNOR_MFR_ATMEL CFI_MFR_ATMEL >>> #define SNOR_MFR_GIGADEVICE 0xc8 >>> #define SNOR_MFR_INTEL CFI_MFR_INTEL >>> +#define SNOR_MFR_ISSI 0x9d /* ISSI */ >>> #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */ >>> #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */ >>> #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX >>>
Hello Vignesh, On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > Hi, > > On 17/06/19 8:48 PM, Sagar Kadam wrote: > > Hello Vignesh, > > > > Thanks for your review comments. > > > > On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> > >> Hi, > >> > >> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: > >> [...] > >> > >>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, > >>> if (ret) > >>> return ret; > >>> > >>> - if (nor->addr_width) { > >>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { > >>> /* already configured from SFDP */ > >> > >> Hmm, why would you want to ignore addr_width that's read from SFDP table? > > > > The SFDP table for ISSI device considered here, has addr_width set to > > 3 byte, and the flash considered > > here is 32MB. With 3 byte address width we won't be able to access > > flash memories higher address range. > > Is it specific to a particular ISSI part as indicated here[1]? If so, > please submit solution agreed there i.e. use spi_nor_fixups callback > > [1]https://patchwork.ozlabs.org/patch/1056049/ > Thanks for sharing the link. From what I understand here, it seems that "Address Bytes" of SFDP table for the device under consideration (is25lp256) supports 3 byte only Addressing mode (DWORD1[18:17] = 0b00. where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or 4 byte Addressing mode DWORD1[18:17] = 0b01. > > Hence I have ignored the addr width from SFDP. I have verified that > > with 3 byte address width, the > > flascp util fails while verifying the written data. Please let me > > know your views on this? > > > If this affects multiple ISSI parts then: > Instead of checking for mfr code, look for SNOR_F_4B_OPCODES flag in > flash_info struct of the device and let it take precedence over SFDP in > case size is over 16MB > So as per your suggestion I think second approach is a better one. I will send this in V6. Thanks & Regards, Sagar > Regards > Vignesh > > > BR, > > Sagar Kadam > > > >> Regards > >> Vignesh > >> > >> > >>> } else if (info->addr_width) { > >>> nor->addr_width = info->addr_width; > >>> diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h > >>> index b3d360b..ff13297 100644 > >>> --- a/include/linux/mtd/spi-nor.h > >>> +++ b/include/linux/mtd/spi-nor.h > >>> @@ -19,6 +19,7 @@ > >>> #define SNOR_MFR_ATMEL CFI_MFR_ATMEL > >>> #define SNOR_MFR_GIGADEVICE 0xc8 > >>> #define SNOR_MFR_INTEL CFI_MFR_INTEL > >>> +#define SNOR_MFR_ISSI 0x9d /* ISSI */ > >>> #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */ > >>> #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */ > >>> #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX > >>> > > -- > Regards > Vignesh
Hi, On 21/06/19 3:58 PM, Sagar Kadam wrote: > Hello Vignesh, > > On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> >> Hi, >> >> On 17/06/19 8:48 PM, Sagar Kadam wrote: >>> Hello Vignesh, >>> >>> Thanks for your review comments. >>> >>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >>>> >>>> Hi, >>>> >>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: >>>> [...] >>>> >>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, >>>>> if (ret) >>>>> return ret; >>>>> >>>>> - if (nor->addr_width) { >>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { >>>>> /* already configured from SFDP */ >>>> >>>> Hmm, why would you want to ignore addr_width that's read from SFDP table? >>> >>> The SFDP table for ISSI device considered here, has addr_width set to >>> 3 byte, and the flash considered >>> here is 32MB. With 3 byte address width we won't be able to access >>> flash memories higher address range. >> >> Is it specific to a particular ISSI part as indicated here[1]? If so, >> please submit solution agreed there i.e. use spi_nor_fixups callback >> >> [1]https://patchwork.ozlabs.org/patch/1056049/ >> > > Thanks for sharing the link. > From what I understand here, it seems that "Address Bytes" of SFDP > table for the device under > consideration (is25lp256) supports 3 byte only Addressing mode > (DWORD1[18:17] = 0b00. > where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or > 4 byte Addressing mode DWORD1[18:17] = 0b01. > Okay, so that SFDP table entry is correct. SPI NOR framework should using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below diff helps: --->8--- diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index c0a8837c0575..ebf32aebe5e9 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, break; case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: nor->addr_width = 4; break;
Hello Vignesh, On Mon, Jun 24, 2019 at 3:04 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > Hi, > > On 21/06/19 3:58 PM, Sagar Kadam wrote: > > Hello Vignesh, > > > > On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> > >> Hi, > >> > >> On 17/06/19 8:48 PM, Sagar Kadam wrote: > >>> Hello Vignesh, > >>> > >>> Thanks for your review comments. > >>> > >>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: > >>>> [...] > >>>> > >>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, > >>>>> if (ret) > >>>>> return ret; > >>>>> > >>>>> - if (nor->addr_width) { > >>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { > >>>>> /* already configured from SFDP */ > >>>> > >>>> Hmm, why would you want to ignore addr_width that's read from SFDP table? > >>> > >>> The SFDP table for ISSI device considered here, has addr_width set to > >>> 3 byte, and the flash considered > >>> here is 32MB. With 3 byte address width we won't be able to access > >>> flash memories higher address range. > >> > >> Is it specific to a particular ISSI part as indicated here[1]? If so, > >> please submit solution agreed there i.e. use spi_nor_fixups callback > >> > >> [1]https://patchwork.ozlabs.org/patch/1056049/ > >> > > > > Thanks for sharing the link. > > From what I understand here, it seems that "Address Bytes" of SFDP > > table for the device under > > consideration (is25lp256) supports 3 byte only Addressing mode > > (DWORD1[18:17] = 0b00. > > where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or > > 4 byte Addressing mode DWORD1[18:17] = 0b01. > > > > Okay, so that SFDP table entry is correct. SPI NOR framework should > using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below > diff helps: > Thank-you for the suggestion. I applied it, and observed, that data in SFDP table mentioned in document received from ISSI support doesn't match with what is actually present on the device (I have raised a query with issi support for the same) The WP device also has the same SFDP entry as the LP device (the one which you shared). So, will submit V7 with the solution agreed in the link you shared above. https://patchwork.ozlabs.org/patch/1056049/ Apologies for the confusion, so please excuse the v6 which I submitted earlier. Thanks & BR, Sagar Kadam > --->8--- > diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > index c0a8837c0575..ebf32aebe5e9 100644 > --- a/drivers/mtd/spi-nor/spi-nor.c > +++ b/drivers/mtd/spi-nor/spi-nor.c > @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, > break; > > case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: > + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: > nor->addr_width = 4; > break; > > > > > -- > Regards > Vignesh
On 24/06/19 6:10 PM, Sagar Kadam wrote: > Hello Vignesh, > > On Mon, Jun 24, 2019 at 3:04 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >> >> Hi, >> >> On 21/06/19 3:58 PM, Sagar Kadam wrote: >>> Hello Vignesh, >>> >>> On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: >>>> >>>> Hi, >>>> >>>> On 17/06/19 8:48 PM, Sagar Kadam wrote: >>>>> Hello Vignesh, >>>>> >>>>> Thanks for your review comments. >>>>> >>>>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: >>>>>> [...] >>>>>> >>>>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, >>>>>>> if (ret) >>>>>>> return ret; >>>>>>> >>>>>>> - if (nor->addr_width) { >>>>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { >>>>>>> /* already configured from SFDP */ >>>>>> >>>>>> Hmm, why would you want to ignore addr_width that's read from SFDP table? >>>>> >>>>> The SFDP table for ISSI device considered here, has addr_width set to >>>>> 3 byte, and the flash considered >>>>> here is 32MB. With 3 byte address width we won't be able to access >>>>> flash memories higher address range. >>>> >>>> Is it specific to a particular ISSI part as indicated here[1]? If so, >>>> please submit solution agreed there i.e. use spi_nor_fixups callback >>>> >>>> [1]https://patchwork.ozlabs.org/patch/1056049/ >>>> >>> >>> Thanks for sharing the link. >>> From what I understand here, it seems that "Address Bytes" of SFDP >>> table for the device under >>> consideration (is25lp256) supports 3 byte only Addressing mode >>> (DWORD1[18:17] = 0b00. >>> where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or >>> 4 byte Addressing mode DWORD1[18:17] = 0b01. >>> >> >> Okay, so that SFDP table entry is correct. SPI NOR framework should >> using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below >> diff helps: >> > Thank-you for the suggestion. > I applied it, and observed, that data in SFDP table mentioned in > document received > from ISSI support doesn't match with what is actually present on the > device (I have raised a query with issi support for the same) > The WP device also has the same SFDP entry as the LP device (the one > which you shared). > So, will submit V7 with the solution agreed in the link you shared above. > https://patchwork.ozlabs.org/patch/1056049/ > Apologies for the confusion, so please excuse the v6 which I submitted earlier. > There is an updated version of the patch: https://patchwork.ozlabs.org/patch/1071453/ You may want to align with Liu Xiang to avoid duplication of effort > Thanks & BR, > Sagar Kadam > >> --->8--- >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c >> index c0a8837c0575..ebf32aebe5e9 100644 >> --- a/drivers/mtd/spi-nor/spi-nor.c >> +++ b/drivers/mtd/spi-nor/spi-nor.c >> @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, >> break; >> >> case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: >> + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: >> nor->addr_width = 4; >> break; > > >> >> >> >> >> -- >> Regards >> Vignesh
Hi Vignesh, On Mon, Jun 24, 2019 at 6:37 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > > > > On 24/06/19 6:10 PM, Sagar Kadam wrote: > > Hello Vignesh, > > > > On Mon, Jun 24, 2019 at 3:04 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >> > >> Hi, > >> > >> On 21/06/19 3:58 PM, Sagar Kadam wrote: > >>> Hello Vignesh, > >>> > >>> On Fri, Jun 21, 2019 at 11:33 AM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On 17/06/19 8:48 PM, Sagar Kadam wrote: > >>>>> Hello Vignesh, > >>>>> > >>>>> Thanks for your review comments. > >>>>> > >>>>> On Sun, Jun 16, 2019 at 6:14 PM Vignesh Raghavendra <vigneshr@ti.com> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On 12-Jun-19 4:17 PM, Sagar Shrikant Kadam wrote: > >>>>>> [...] > >>>>>> > >>>>>>> @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, > >>>>>>> if (ret) > >>>>>>> return ret; > >>>>>>> > >>>>>>> - if (nor->addr_width) { > >>>>>>> + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { > >>>>>>> /* already configured from SFDP */ > >>>>>> > >>>>>> Hmm, why would you want to ignore addr_width that's read from SFDP table? > >>>>> > >>>>> The SFDP table for ISSI device considered here, has addr_width set to > >>>>> 3 byte, and the flash considered > >>>>> here is 32MB. With 3 byte address width we won't be able to access > >>>>> flash memories higher address range. > >>>> > >>>> Is it specific to a particular ISSI part as indicated here[1]? If so, > >>>> please submit solution agreed there i.e. use spi_nor_fixups callback > >>>> > >>>> [1]https://patchwork.ozlabs.org/patch/1056049/ > >>>> > >>> > >>> Thanks for sharing the link. > >>> From what I understand here, it seems that "Address Bytes" of SFDP > >>> table for the device under > >>> consideration (is25lp256) supports 3 byte only Addressing mode > >>> (DWORD1[18:17] = 0b00. > >>> where as that of ISSI device (is25LP/WP 256Mb/512/Mb/1Gb) support 3 or > >>> 4 byte Addressing mode DWORD1[18:17] = 0b01. > >>> > >> > >> Okay, so that SFDP table entry is correct. SPI NOR framework should > >> using 4 byte addressing if WORD1[18:17] = 0b01. Could you see if below > >> diff helps: > >> > > Thank-you for the suggestion. > > I applied it, and observed, that data in SFDP table mentioned in > > document received > > from ISSI support doesn't match with what is actually present on the > > device (I have raised a query with issi support for the same) > > The WP device also has the same SFDP entry as the LP device (the one > > which you shared). > > So, will submit V7 with the solution agreed in the link you shared above. > > https://patchwork.ozlabs.org/patch/1056049/ > > Apologies for the confusion, so please excuse the v6 which I submitted earlier. > > > > There is an updated version of the patch: > https://patchwork.ozlabs.org/patch/1071453/ > > You may want to align with Liu Xiang to avoid duplication of effort > Ok. It seems Liu Xiang, is working on supporting is25LP256 device, while the one considered here is WP Although both are very similar devices, they differ a bit maybe with Operating voltage, ID values, die revision etc.. I will sync-up with him about his v4 plan, and update you accordingly. Thanks for the link. BR, Sagar Kadam > > Thanks & BR, > > Sagar Kadam > > > >> --->8--- > >> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c > >> index c0a8837c0575..ebf32aebe5e9 100644 > >> --- a/drivers/mtd/spi-nor/spi-nor.c > >> +++ b/drivers/mtd/spi-nor/spi-nor.c > >> @@ -2808,6 +2808,7 @@ static int spi_nor_parse_bfpt(struct spi_nor *nor, > >> break; > >> > >> case BFPT_DWORD1_ADDRESS_BYTES_4_ONLY: > >> + case BFPT_DWORD1_ADDRESS_BYTES_3_OR_4: > >> nor->addr_width = 4; > >> break; > > > > > >> > >> > >> > >> > >> -- > >> Regards > >> Vignesh > > -- > Regards > Vignesh
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c index 73172d7..2d5a925 100644 --- a/drivers/mtd/spi-nor/spi-nor.c +++ b/drivers/mtd/spi-nor/spi-nor.c @@ -1834,6 +1834,10 @@ static int sr2_bit7_quad_enable(struct spi_nor *nor) SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, { "is25wp128", INFO(0x9d7018, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) }, + { "is25wp256", INFO(0x9d7019, 0, 64 * 1024, 1024, + SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | + SPI_NOR_4B_OPCODES) + }, /* Macronix */ { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) }, @@ -3652,6 +3656,10 @@ static int spi_nor_init_params(struct spi_nor *nor, case SNOR_MFR_MACRONIX: params->quad_enable = macronix_quad_enable; break; + case SNOR_MFR_ISSI: + params->quad_enable = macronix_quad_enable; + break; + case SNOR_MFR_ST: case SNOR_MFR_MICRON: @@ -4129,7 +4137,7 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, if (ret) return ret; - if (nor->addr_width) { + if (nor->addr_width && JEDEC_MFR(info) != SNOR_MFR_ISSI) { /* already configured from SFDP */ } else if (info->addr_width) { nor->addr_width = info->addr_width; diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index b3d360b..ff13297 100644 --- a/include/linux/mtd/spi-nor.h +++ b/include/linux/mtd/spi-nor.h @@ -19,6 +19,7 @@ #define SNOR_MFR_ATMEL CFI_MFR_ATMEL #define SNOR_MFR_GIGADEVICE 0xc8 #define SNOR_MFR_INTEL CFI_MFR_INTEL +#define SNOR_MFR_ISSI 0x9d /* ISSI */ #define SNOR_MFR_ST CFI_MFR_ST /* ST Micro */ #define SNOR_MFR_MICRON CFI_MFR_MICRON /* Micron */ #define SNOR_MFR_MACRONIX CFI_MFR_MACRONIX
Update spi_nor_id table for is25wp256 (32MB)device from ISSI, present on HiFive Unleashed dev board (Rev: A00). Set method to enable quad mode for ISSI device in flash parameters table. Based on code originally written by Wesley Terpstra <wesley@sifive.com> and/or Palmer Dabbelt <palmer@sifive.com> https://github.com/riscv/riscv-linux/commit/c94e267766d62bc9a669611c3d0c8ed5ea26569b Signed-off-by: Sagar Shrikant Kadam <sagar.kadam@sifive.com> --- drivers/mtd/spi-nor/spi-nor.c | 10 +++++++++- include/linux/mtd/spi-nor.h | 1 + 2 files changed, 10 insertions(+), 1 deletion(-)