RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>First of all, can you fix your mail so that you have a proper 'From'? >That should be your real name (not bpqw), so that it gives a proper patch >author. >If you can't get your mail header to have the right 'From:' line, then it also >works to begin your mail with: Sorry for this confusion. This bpqw email is our software public mailbox dedicated to submit linux patch. Because our personal email title include Chinese name, this will result to messy code in from item. I have ever submit one patch many times by my personal mail, but I always didn't accept maintainer's response. So I think, maybe my patch with Chinese name has been moved into maintainer's junk folder. I don't know my mail from-field with Chinese name can or not be accepted, if can, I will submit next version patch by my personal mail. >> This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. >> >> For Micron SPI NOR flash,enabling or disabling quad I/O protocol is >> controlled by EVCR (Enhanced Volatile Configuration Register), Quad I/O >> protocol bit 7. >> When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O >> mode. >What's the difference between using EVCR and the ENTER QUAD I/O MODE >(35h) command I see in some of your datasheets? Are both supported on all >Micron quad I/O SPI NOR flash? There is no difference between using EVCR and the ENTER QUAD I/O MODE command. But, for some Micron spi nor, there no ENTER Quad I/O command(35h),such as n25q064. for all current Micron spi nor, if it support quad I/O mode, Using EVCR definitely be supported. So, we recommend that enable QUAD I/O mode by writing ECVR. >Also, which SPI NOR is this enabled for? I don't see any Micron entries in >spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag. Yes, we now don't see any Micron entries in spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag. But Micron spi nor in spi_nor_ids[] all support Quad I/O mode. maybe customer want to use default mode(extended I/O mode), When submitted relevant patch, they didn't SPI_NOR_QUAD_READ flag in the spi_nor_ids[]. This patch is just for wanting to enable Micron Quad I/O mode. >> Signed-off-by: bean huo >> Acked-by: Marek Vasut >> --- >> v1-v2: >> Modified to that capture wait_till_ready() >> return value,if error,directly return its >> the value. >> v2-v3: >> Directly use the reurning error value of >> read_reg and write_reg,instead of -EINVAL. >> v3-v4: >> Modify commit logs that wraped into 80 columns >> v4-v5: >> Rebuild new patch based on latest linux-mtd >Please rebase on l2-mtd.git. Sorry if that wasn't clear earlier. OK,I will rebase it and sumbit a new version. Thanks for your suggestion. >> +dev_err(nor->dev, >> +"error while writing EVCR register\n"); >Join the above two lines? Will be fixed it in the next version. >> +return ret; >> +} >> + >> +ret = wait_till_ready(nor); >It's spi_nor_wait_till_ready(), now. OK, will be fixed it. >> >> #define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */ >> >> +#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */ >Like with other register bitfields (SR, FSR), please place a comment above to >describe the register, like: OK, will be fixed it. >Brian All in all ,thanks for your response and valuable suggestions. I will rebuild a new version, and submit it . ---Bean Huo--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>You probably aren't based on l2-mtd.git. Your patch still doesn't build.
>I can fix it up if it's easy, but FYI. Still reviewing...
>Brian
Hi, Brian
Thanks for your hard work. Finally received your response, I am very happy.
How about this patch? Whether or not rebuild it based on lastest l2-mtd?
Look forward to your letter.thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
You probably aren't based on l2-mtd.git. Your patch still doesn't build.
I can fix it up if it's easy, but FYI. Still reviewing...
Brian
Hi, Brian
Thanks for your hard work. Finally received your response, I am very happy.
How about this patch? Whether or not rebuild it based on lastest l2-mtd?
Look forward to your letter.thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
First of all, can you fix your mail so that you have a proper 'From'? That should be your real name (not bpqw), so that it gives a proper patch author. If you can't get your mail header to have the right 'From:' line, then it also works to begin your mail with: Sorry for this confusion. This bpqw email is our software public mailbox dedicated to submit linux patch. Because our personal email title include Chinese name, this will result to messy code in from item. I have ever submit one patch many times by my personal mail, but I always didn't accept maintainer's response. So I think, maybe my patch with Chinese name has been moved into maintainer's junk folder. I don't know my mail from-field with Chinese name can or not be accepted, if can, I will submit next version patch by my personal mail. This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7. When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode. What's the difference between using EVCR and the ENTER QUAD I/O MODE (35h) command I see in some of your datasheets? Are both supported on all Micron quad I/O SPI NOR flash? There is no difference between using EVCR and the ENTER QUAD I/O MODE command. But, for some Micron spi nor, there no ENTER Quad I/O command(35h),such as n25q064. for all current Micron spi nor, if it support quad I/O mode, Using EVCR definitely be supported. So, we recommend that enable QUAD I/O mode by writing ECVR. Also, which SPI NOR is this enabled for? I don't see any Micron entries in spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag. Yes, we now don't see any Micron entries in spi_nor_ids[] which contain the SPI_NOR_QUAD_READ flag. But Micron spi nor in spi_nor_ids[] all support Quad I/O mode. maybe customer want to use default mode(extended I/O mode), When submitted relevant patch, they didn't SPI_NOR_QUAD_READ flag in the spi_nor_ids[]. This patch is just for wanting to enable Micron Quad I/O mode. Signed-off-by: bean huo bean...@micron.com Acked-by: Marek Vasut ma...@denx.de --- v1-v2: Modified to that capture wait_till_ready() return value,if error,directly return its the value. v2-v3: Directly use the reurning error value of read_reg and write_reg,instead of -EINVAL. v3-v4: Modify commit logs that wraped into 80 columns v4-v5: Rebuild new patch based on latest linux-mtd Please rebase on l2-mtd.git. Sorry if that wasn't clear earlier. OK,I will rebase it and sumbit a new version. Thanks for your suggestion. +dev_err(nor-dev, +error while writing EVCR register\n); Join the above two lines? Will be fixed it in the next version. +return ret; +} + +ret = wait_till_ready(nor); It's spi_nor_wait_till_ready(), now. OK, will be fixed it. #define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */ +#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */ Like with other register bitfields (SR, FSR), please place a comment above to describe the register, like: OK, will be fixed it. Brian All in all ,thanks for your response and valuable suggestions. I will rebuild a new version, and submit it . ---Bean Huo--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>> This maybe your spi controller is still extended mode, Once EVCR bit 7 >> is set to 0, the spi nor device will operate in quad >> I/O.Command-address-data line is 4-x-4. >> So after send WRITE EVCR command , spi controller also must transfer >> to quad I/O Mode,and set its Command-address-data line also Should be 4-x-4 . >Thanks, this helped. I added some code to snoop the command stream for WRITE >EVCR with quad mode, >and then set up the quad mode in the controller. Seems kinda ugly, but >working now. >-Graham Yes ,if enable spi nor Quad I/O, firstly, must check spi controller if support Quad I/O protocol, and after enable spi nor Quad I/O mode ,spi controller also must be transferred to Quad I/O protocol. Their two side must be matched together. Maybe spi controller can do this changes. Hi,Brian Can you give me some tips about this patch? Thanks! -Bean Huo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This maybe your spi controller is still extended mode, Once EVCR bit 7 is set to 0, the spi nor device will operate in quad I/O.Command-address-data line is 4-x-4. So after send WRITE EVCR command , spi controller also must transfer to quad I/O Mode,and set its Command-address-data line also Should be 4-x-4 . Thanks, this helped. I added some code to snoop the command stream for WRITE EVCR with quad mode, and then set up the quad mode in the controller. Seems kinda ugly, but working now. -Graham Yes ,if enable spi nor Quad I/O, firstly, must check spi controller if support Quad I/O protocol, and after enable spi nor Quad I/O mode ,spi controller also must be transferred to Quad I/O protocol. Their two side must be matched together. Maybe spi controller can do this changes. Hi,Brian Can you give me some tips about this patch? Thanks! -Bean Huo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V3 PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology,Inc.is an American multinational corporation based in Boise, Idaho,best known for producing many forms of semiconductor devices.This includes DRAM,SDRAM,flash memory,eMMC and SSDs. Signed-off-by: Bean Huo --- V2: - Add signed-off-by - Modify commit logs that wrapped to less than 80 columns V3: - Remove the same signed-off-by owner's mailbox - Modify proper name of signed-off-by .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
>Patch looks okay to me content-wise, but you might want to use proper names >and >capitalization for the From: and Signed-off-by: lines. bpqw doesn't look like >a real name to me, and "bean huo" should probably be "Bean Huo". >Thierry Thanks,will modify it and submit V3. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
Patch looks okay to me content-wise, but you might want to use proper names and capitalization for the From: and Signed-off-by: lines. bpqw doesn't look like a real name to me, and bean huo should probably be Bean Huo. Thierry Thanks,will modify it and submit V3. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V3 PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology,Inc.is an American multinational corporation based in Boise, Idaho,best known for producing many forms of semiconductor devices.This includes DRAM,SDRAM,flash memory,eMMC and SSDs. Signed-off-by: Bean Huo b...@micron.com --- V2: - Add signed-off-by - Modify commit logs that wrapped to less than 80 columns V3: - Remove the same signed-off-by owner's mailbox - Modify proper name of signed-off-by .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>I have almost verified all the micros parts for operating quad mode and the
>quad enable bit is
>volatile by default and no need to set it on software.
>Why this code is meant for - does micron has changed this bit operation on
>newly added parts?
>thanks!
>--
>Jagan.
For Micron Spi norflash,if you want to make it work Quad I/O mode,you can do it
by set
Two registers,Nonvolatile Configuration resister(NVCR) and Enhanced volatile
confuration register(EVCR),
but according to spi-nor.c,and micron spi nor,we recommend that if want to
enable Micron spi nor Quad I/O
mode,the best way is to set EVCR.
Of course,you can use Quad/Dual operation command to read/write Micron spi nor
in the spi nor Extended I/O mode.
But their command-address-data is different.
The purpose of this patch is only to enable Micron spi nor Quad I/O mode,if
want to make Micron spi nor work
Under Quad I/O mode.
Hi,Brian
How about this patch?Please give me some tips,thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
>Signed-off-by: bean huo >Signed-off-by: bpqw >--- >V2: > - Add signed-off-by > - Modify commit logs that wrapped to less than 80 columns Dear maintainers: Please give some tips,if this patch is OK?thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>Hi, I'm having trouble with this patch using a Cadence QSPI controller and >Micron n25q00 part. >I can use quad commands in Extended SPI mode, but I can't make this EVCR Quad >mode work. Yes,but if you use quad commands in Extended spi mode,only for Quad commands,the command line is DQ0, Address/data line is DQ0,DQ1,DQ2 and DQ3(1-x-4). But if in Quad I/O mode,for all the commands,the command/address/data line will be 4,they are DQ0,DQ1,DQ2 and DQ3(4-x-4). >The Cadence QSPI Controller has fields to configure the quad transfer, and can >support quad opcode, >quad address, and quad data, or some combination. There is a chart in the >docs which shows the combinations for various read commands. >Problem is, I've tried all of the combinations and all I get is FF with this >EVCR patch. This maybe your spi controller is still extended mode, Once EVCR bit 7 is set to 0, the spi nor device will operate in quad I/O.Command-address-data line is 4-x-4. So after send WRITE EVCR command , spi controller also must transfer to quad I/O Mode,and set its Command-address-data line also Should be 4-x-4 . >If I don't set the quad mode in the EVCR, then I can use quad read commands no >problem. Yes,you don't set the quad mode in the EVCR,you can use quad read commands,but this patch is for enable Micron SPI nor Quad I/O mode, If you want to enable it ,you must set EVCR. >Bottom line, with the Cadence QSPI controller, if I use quad commands in >Extended SPI mode, then all good. If I use this EVCR quad mode, then all bad. >Anybody else have a Cadence QSPI controller and using EVCR quad mode >successfully? >Thanks, >Graham Moore Hi,Brian Whether this patch can be merged?thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
Hi, I'm having trouble with this patch using a Cadence QSPI controller and Micron n25q00 part. I can use quad commands in Extended SPI mode, but I can't make this EVCR Quad mode work. Yes,but if you use quad commands in Extended spi mode,only for Quad commands,the command line is DQ0, Address/data line is DQ0,DQ1,DQ2 and DQ3(1-x-4). But if in Quad I/O mode,for all the commands,the command/address/data line will be 4,they are DQ0,DQ1,DQ2 and DQ3(4-x-4). The Cadence QSPI Controller has fields to configure the quad transfer, and can support quad opcode, quad address, and quad data, or some combination. There is a chart in the docs which shows the combinations for various read commands. Problem is, I've tried all of the combinations and all I get is FF with this EVCR patch. This maybe your spi controller is still extended mode, Once EVCR bit 7 is set to 0, the spi nor device will operate in quad I/O.Command-address-data line is 4-x-4. So after send WRITE EVCR command , spi controller also must transfer to quad I/O Mode,and set its Command-address-data line also Should be 4-x-4 . If I don't set the quad mode in the EVCR, then I can use quad read commands no problem. Yes,you don't set the quad mode in the EVCR,you can use quad read commands,but this patch is for enable Micron SPI nor Quad I/O mode, If you want to enable it ,you must set EVCR. Bottom line, with the Cadence QSPI controller, if I use quad commands in Extended SPI mode, then all good. If I use this EVCR quad mode, then all bad. Anybody else have a Cadence QSPI controller and using EVCR quad mode successfully? Thanks, Graham Moore Hi,Brian Whether this patch can be merged?thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
Signed-off-by: bean huo bean...@micron.com Signed-off-by: bpqw b...@micron.com --- V2: - Add signed-off-by - Modify commit logs that wrapped to less than 80 columns Dear maintainers: Please give some tips,if this patch is OK?thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
I have almost verified all the micros parts for operating quad mode and the
quad enable bit is
volatile by default and no need to set it on software.
Why this code is meant for - does micron has changed this bit operation on
newly added parts?
thanks!
--
Jagan.
For Micron Spi norflash,if you want to make it work Quad I/O mode,you can do it
by set
Two registers,Nonvolatile Configuration resister(NVCR) and Enhanced volatile
confuration register(EVCR),
but according to spi-nor.c,and micron spi nor,we recommend that if want to
enable Micron spi nor Quad I/O
mode,the best way is to set EVCR.
Of course,you can use Quad/Dual operation command to read/write Micron spi nor
in the spi nor Extended I/O mode.
But their command-address-data is different.
The purpose of this patch is only to enable Micron spi nor Quad I/O mode,if
want to make Micron spi nor work
Under Quad I/O mode.
Hi,Brian
How about this patch?Please give me some tips,thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:
Modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:
Directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
v3-v4:
Modify commit logs that wraped into 80 columns
v4-v5:
Rebuild new patch based on latest linux-mtd
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c51ee52..2a31742 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -874,6 +874,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -886,6 +925,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 046a0a2..42e7e37 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v4] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>> This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. >Also, your patch is still corrupt and cannot be applied as-is. >Please double-check your mailer settings and resend once you have something I >can apply. >Brian Hi,Brian Thanks your patience.this maybe linux kernel has been updated again. My patch based linux kernel is old. I will rebuild a new patch based on latest linux-mtd,and submit it today. This patch has been waiting for your reply too long time.I really hope that this patch to be accepted as soon as possible, otherwise I will rebuild it again,and one by one. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v4] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. Also, your patch is still corrupt and cannot be applied as-is. Please double-check your mailer settings and resend once you have something I can apply. Brian Hi,Brian Thanks your patience.this maybe linux kernel has been updated again. My patch based linux kernel is old. I will rebuild a new patch based on latest linux-mtd,and submit it today. This patch has been waiting for your reply too long time.I really hope that this patch to be accepted as soon as possible, otherwise I will rebuild it again,and one by one. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo bean...@micron.com
Acked-by: Marek Vasut ma...@denx.de
---
v1-v2:
Modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:
Directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
v3-v4:
Modify commit logs that wraped into 80 columns
v4-v5:
Rebuild new patch based on latest linux-mtd
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index c51ee52..2a31742 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -874,6 +874,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -886,6 +925,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 046a0a2..42e7e37 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v4] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
V3-v4:
Modify commit logs that wraped into 80 columns
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology,Inc.is an American multinational corporation based in Boise, Idaho,best known for producing many forms of semiconductor devices.This includes DRAM,SDRAM,flash memory,eMMC and SSDs. Signed-off-by: bean huo Signed-off-by: bpqw --- V2: - Add signed-off-by - Modify commit logs that wrapped to less than 80 columns .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 V2] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology,Inc.is an American multinational corporation based in Boise, Idaho,best known for producing many forms of semiconductor devices.This includes DRAM,SDRAM,flash memory,eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com Signed-off-by: bpqw b...@micron.com --- V2: - Add signed-off-by - Modify commit logs that wrapped to less than 80 columns .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v4] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo bean...@micron.com
Acked-by: Marek Vasut ma...@denx.de
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
V3-v4:
Modify commit logs that wraped into 80 columns
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
>This patch is used to add vendor prefix for >Micron Technology Inc in the vendor-prefixes.txt file. >Micron Technology, Inc. is an American >multinational corporation based in Boise, >Idaho, best known for producing many forms >of semiconductor devices. This includes DRAM, >SDRAM, flash memory, eMMC and SSDs. >Signed-off-by: bean huo Dear linux developer: Is there maintainer in this mail list? Can give me a result for this simple patch?if can be accepted or not? Or give me some suggections? It has been long time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com Dear linux developer: Is there maintainer in this mail list? Can give me a result for this simple patch?if can be accepted or not? Or give me some suggections? It has been long time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. >For Micron SPI NOR flash, enabling or disabling quad I/O >protocol is controlled by EVCR (Enhanced Volatile Configuration >Register), Quad I/O protocol bit 7.When EVCR bit 7 is reset to 0, >the SPI NOR flash will operate in quad I/O mode. >Signed-off-by: bean huo >Acked-by: Marek Vasut Hi,Brian How about this patch?if can be accepted? It has been long time. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes. For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode. Signed-off-by: bean huo bean...@micron.com Acked-by: Marek Vasut ma...@denx.de Hi,Brian How about this patch?if can be accepted? It has been long time. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
Hi,rafal
Maybe this patch is not very reasonable.But for fix this case,I will develop a
new patch that
is just used to add extended ID for micron spi nor in the spi_nor_ids[].
Thanks for your review my patch.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
Hi,Mark >This is the *third* time you've sent this patch this week, please stop and >allow a reasonable time for the maintainers to respond, a few weeks would be >normal. I'm sorry,I'm new linux patch deveploper and this is my second patch. Maybe my experience is not rich,there is a little impatient,I will pay attention on this later, thank you for reminding me. >Please also take a look at the submission format in SubmittingPatches - >commit logs should be wrapped to less than 80 columns I have added return key after 80 columns, but I don't know why I sent mail contents will remove return key automatically.So you may see more than 80 columns in your email. >and you've not added your own signoff to the patch (or at least >you're using a different name and e-mail address to that in the patch). Ok,bean...@micron.com is my personal e-mail.but I cann't send a format pain text mail by it,so I apply for another mail address,just used it for send patch. Thanks again for your review my patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
Hi,Mark This is the *third* time you've sent this patch this week, please stop and allow a reasonable time for the maintainers to respond, a few weeks would be normal. I'm sorry,I'm new linux patch deveploper and this is my second patch. Maybe my experience is not rich,there is a little impatient,I will pay attention on this later, thank you for reminding me. Please also take a look at the submission format in SubmittingPatches - commit logs should be wrapped to less than 80 columns I have added return key after 80 columns, but I don't know why I sent mail contents will remove return key automatically.So you may see more than 80 columns in your email. and you've not added your own signoff to the patch (or at least you're using a different name and e-mail address to that in the patch). Ok,bean...@micron.com is my personal e-mail.but I cann't send a format pain text mail by it,so I apply for another mail address,just used it for send patch. Thanks again for your review my patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
Hi,rafal
Maybe this patch is not very reasonable.But for fix this case,I will develop a
new patch that
is just used to add extended ID for micron spi nor in the spi_nor_ids[].
Thanks for your review my patch.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 1/1 v3] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo bean...@micron.com
Acked-by: Marek Vasut ma...@denx.de
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
>This patch is used to add vendor prefix for Micron Technology Inc in the >vendor-prefixes.txt file. >Micron Technology, Inc. is an American multinational corporation based in >Boise, Idaho, best known for producing many forms of semiconductor devices. >This includes DRAM, SDRAM, flash memory, eMMC and SSDs. >Signed-off-by: bean huo Hi, If this patch is OK?? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com Hi, If this patch is OK?? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] devicetree: bindings: Add vendor prefix for Micron Technology Co., Ltd.
This patch is used to add vendor prefix for Micron Technology Inc in the vendor-prefixes.txt file. Micron Technology, Inc. is an American multinational corporation based in Boise, Idaho, best known for producing many forms of semiconductor devices. This includes DRAM, SDRAM, flash memory, eMMC and SSDs. Signed-off-by: bean huo bean...@micron.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 723999d..a7bbf6e 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -92,6 +92,7 @@ maxim Maxim Integrated Products mediatek MediaTek Inc. micrel Micrel Inc. microchip Microchip Technology Inc. +micron Micron Technology Inc. mitsubishi Mitsubishi Electric Corporation mosaixtech Mosaix Technologies, Inc. moxa Moxa -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
Acked-by: Marek Vasut
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo bean...@micron.com
Acked-by: Marek Vasut ma...@denx.de
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
>I really wasn't looking into details yet and I'm aware my patch does something
>else. I just say we should first fix the regression and then base next patches
>on top of that regression fix. I'm not NACKing your changes :)
I will take into account for your patch,and will cover all these isse in my
next version patch.
By the way ,I still don't understand why you specify id NULL in you patch:
+ if (id) {
+ info = (void *)id->driver_data;
+ if (info->jedec_id) {
+ dev_warn(dev,
+"passed SPI device ID (%s) contains JEDEC,
ignoring it, driver should be fixed!\n",
+id->name);
+ id = NULL;
}
}
+ if (!id) {
+ id = nor->read_id(nor);
+ if (IS_ERR(id))
+ return PTR_ERR(id);
+ }
+ info = (void *)id->driver_data;
+
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
I really wasn't looking into details yet and I'm aware my patch does something
else. I just say we should first fix the regression and then base next patches
on top of that regression fix. I'm not NACKing your changes :)
I will take into account for your patch,and will cover all these isse in my
next version patch.
By the way ,I still don't understand why you specify id NULL in you patch:
+ if (id) {
+ info = (void *)id-driver_data;
+ if (info-jedec_id) {
+ dev_warn(dev,
+passed SPI device ID (%s) contains JEDEC,
ignoring it, driver should be fixed!\n,
+id-name);
+ id = NULL;
}
}
+ if (!id) {
+ id = nor-read_id(nor);
+ if (IS_ERR(id))
+ return PTR_ERR(id);
+ }
+ info = (void *)id-driver_data;
+
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
>Acked-by: Marek Vasut Hi,brian How about this patch? And can be accepted by linux-mtd? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
>Won't $info contain an undefined value in case the newly added condition isn't
>met ? The old code initialized $info to a certain value always, the new code
>does not do that.
Hi,Marek Vasut
Thanks.the $info has been defined before as below:
info = (void *)id->driver_data;
Unless id has not been initialized before.If having the following situation,
current linux codes will not properly match platform device data:
For example:
const struct spi_device_id spi_nor_ids[] = {
..
..
..
{ "n25q064", INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ "n25q128a11", INFO(0x20bb18, 0, 64 * 1024, 256, 0) },//former right
platform point will be overwrote by this data info.
{ "n25q128a13", INFO(0x20bb18, 0x1234, 64 * 1024, 512, SECT_4K)
},//this is the right platform data,I want to match this data info.
{ "n25q256a",INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
{ "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
..
..
..
};
EXPORT_SYMBOL_GPL(spi_nor_ids);
Maybe my patch should take into account that ID is NULL,
I want to change my patch following, could you please give me some suggestions:
struct flash_info *tmpinfo;
tmpinfo = (void *)jid->driver_data;
if (id == NULL || tmpinfo->jedec_id != info->jedec_id ||
(info->ext_id != 0 && tmpinfo->ext_id != info->ext_id)) {
dev_warn(dev, "found %s, expected %s\n",
jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
}
RE: [PATCH 1/1 v2] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
Won't $info contain an undefined value in case the newly added condition isn't
met ? The old code initialized $info to a certain value always, the new code
does not do that.
Hi,Marek Vasut
Thanks.the $info has been defined before as below:
info = (void *)id-driver_data;
Unless id has not been initialized before.If having the following situation,
current linux codes will not properly match platform device data:
For example:
const struct spi_device_id spi_nor_ids[] = {
..
..
..
{ n25q064, INFO(0x20ba17, 0, 64 * 1024, 128, 0) },
{ n25q128a11, INFO(0x20bb18, 0, 64 * 1024, 256, 0) },//former right
platform point will be overwrote by this data info.
{ n25q128a13, INFO(0x20bb18, 0x1234, 64 * 1024, 512, SECT_4K)
},//this is the right platform data,I want to match this data info.
{ n25q256a,INFO(0x20ba19, 0, 64 * 1024, 512, SECT_4K) },
{ n25q512a,INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
..
..
..
};
EXPORT_SYMBOL_GPL(spi_nor_ids);
Maybe my patch should take into account that ID is NULL,
I want to change my patch following, could you please give me some suggestions:
struct flash_info *tmpinfo;
tmpinfo = (void *)jid-driver_data;
if (id == NULL || tmpinfo-jedec_id != info-jedec_id ||
(info-ext_id != 0 tmpinfo-ext_id != info-ext_id)) {
dev_warn(dev, found %s, expected %s\n,
jid-name, id-name);
id = jid;
info = (void *)jid-driver_data;
}
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
Acked-by: Marek Vasut ma...@denx.de Hi,brian How about this patch? And can be accepted by linux-mtd? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
This patch used to modify the method of spi_nor_scan overwrite platform Id.
If type of platform data match with the name of spi_nor_ids set,
and JEDEC ID also match with INFO ID of spi_nor_ids set,spi device
ID point(this is before probed according to device name) shouldn't be
overwrote.Otherwise,this point will be overwrote by new spi_nor_ids
set point that probed according to JEDEC ID.
Signed-off-by: bean huo
---
drivers/mtd/spi-nor/spi-nor.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..3675503 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -963,16 +963,21 @@ int spi_nor_scan(struct spi_nor *nor, const struct
spi_device_id *id,
return PTR_ERR(jid);
} else if (jid != id) {
/*
-* JEDEC knows better, so overwrite platform ID. We
-* can't trust partitions any longer, but we'll let
-* mtd apply them anyway, since some partitions may be
-* marked read-only, and we don't want to lose that
-* information, even if it's not 100% accurate.
+* If type of platform data match with the name of
+* spi_nor_ids set,and JEDEC ID also match with
+* INFO ID of spi_nor_ids set,shouldn't overwrite
+* spi device info point.Otherwise,will overwrite
+* it.
*/
- dev_warn(dev, "found %s, expected %s\n",
-jid->name, id->name);
+ struct flash_info *tmpinfo;
+
+ tmpinfo = (void *)jid->driver_data;
+ if (tmpinfo->jedec_id != info->jedec_id) {
+ dev_warn(dev, "found %s, expected %s\n",
+ jid->name, id->name);
id = jid;
info = (void *)jid->driver_data;
+ }
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] driver:mtd:spi-nor:fix spi_nor_scan overwrite platform ID point
This patch used to modify the method of spi_nor_scan overwrite platform Id.
If type of platform data match with the name of spi_nor_ids set,
and JEDEC ID also match with INFO ID of spi_nor_ids set,spi device
ID point(this is before probed according to device name) shouldn't be
overwrote.Otherwise,this point will be overwrote by new spi_nor_ids
set point that probed according to JEDEC ID.
Signed-off-by: bean huo bean...@micron.com
---
drivers/mtd/spi-nor/spi-nor.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..3675503 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -963,16 +963,21 @@ int spi_nor_scan(struct spi_nor *nor, const struct
spi_device_id *id,
return PTR_ERR(jid);
} else if (jid != id) {
/*
-* JEDEC knows better, so overwrite platform ID. We
-* can't trust partitions any longer, but we'll let
-* mtd apply them anyway, since some partitions may be
-* marked read-only, and we don't want to lose that
-* information, even if it's not 100% accurate.
+* If type of platform data match with the name of
+* spi_nor_ids set,and JEDEC ID also match with
+* INFO ID of spi_nor_ids set,shouldn't overwrite
+* spi device info point.Otherwise,will overwrite
+* it.
*/
- dev_warn(dev, found %s, expected %s\n,
-jid-name, id-name);
+ struct flash_info *tmpinfo;
+
+ tmpinfo = (void *)jid-driver_data;
+ if (tmpinfo-jedec_id != info-jedec_id) {
+ dev_warn(dev, found %s, expected %s\n,
+ jid-name, id-name);
id = jid;
info = (void *)jid-driver_data;
+ }
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
>> Signed-off-by: bean huo >I don't see anything obviously wrong. >Acked-by: Marek Vasut Hi,Brian How do you think about this patch? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
Signed-off-by: bean huo bean...@micron.com I don't see anything obviously wrong. Acked-by: Marek Vasut ma...@denx.de Hi,Brian How do you think about this patch? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return ret;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v3] driver:mtd:spi-nor: Add Micron quad I/O support
This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
For Micron SPI NOR flash, enabling or disabling quad I/O protocol is controlled
by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
When EVCR bit 7 is reset to 0, the SPI NOR flash will operate in quad I/O mode.
Signed-off-by: bean huo bean...@micron.com
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
v2-v3:directly use the reurning error value of
read_reg and write_reg,instead of -EINVAL.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..486b167 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor) {
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return ret;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return ret;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id) {
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h index
9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
>> For Micron spi norflash,you can enable Quad spi transfer by clear
>> EVCR(Enhanced Volatile Configuration Register) Quad I/O protocol bit.
>
>OK, this information is nice and all, but what does this patch do? I can't
>learn this information from the commit message as it is, can I ?
>And , the purpose of the commit message is exactly to summarize the change the
>patch implements.
you don't understand what purpose of this patch! just as subject and commit
message described,
it is for enable Micron Quad spi transfer mode.do you read the spi-nor.c file?
please pay attention
to the set_quad_mode() function.by the way,I can add more commit message for
it,but I think
it is redundant,don't need.
>> +static int micron_quad_enable(struct spi_nor *nor) {
>> +int ret, val;
>> +
>> +ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
>> +if (ret < 0) {
>> +dev_err(nor->dev, "error %d reading EVCR\n", ret);
>> +return -EINVAL;
>> +}
>> +
>> +write_enable(nor);
>> +
>> +/* set EVCR ,enable quad I/O */
>> +nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
>> +ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
>> +if (ret < 0) {
>> +dev_err(nor->dev,
>> +"error while writing EVCR register\n");
>> +return -EINVAL;
>Why not just "return ret;" ?
>[...]
Ok,this is good,I will modify it in the next patch version.thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable Quad spi transfer by clear
EVCR(Enhanced Volatile Configuration Register) Quad I/O protocol bit.
OK, this information is nice and all, but what does this patch do? I can't
learn this information from the commit message as it is, can I ?
And , the purpose of the commit message is exactly to summarize the change the
patch implements.
you don't understand what purpose of this patch! just as subject and commit
message described,
it is for enable Micron Quad spi transfer mode.do you read the spi-nor.c file?
please pay attention
to the set_quad_mode() function.by the way,I can add more commit message for
it,but I think
it is redundant,don't need.
+static int micron_quad_enable(struct spi_nor *nor) {
+int ret, val;
+
+ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+if (ret 0) {
+dev_err(nor-dev, error %d reading EVCR\n, ret);
+return -EINVAL;
+}
+
+write_enable(nor);
+
+/* set EVCR ,enable quad I/O */
+nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+if (ret 0) {
+dev_err(nor-dev,
+error while writing EVCR register\n);
+return -EINVAL;
Why not just return ret; ?
[...]
Ok,this is good,I will modify it in the next patch version.thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable
Quad spi transfer by clear EVCR(Enhanced
Volatile Configuration Register) Quad I/O
protocol bit.
Signed-off-by: bean huo
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..0c3b4fd 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return -EINVAL;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 v2] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable
Quad spi transfer by clear EVCR(Enhanced
Volatile Configuration Register) Quad I/O
protocol bit.
Signed-off-by: bean huo bean...@micron.com
---
v1-v2:modified to that capture wait_till_ready()
return value,if error,directly return its
the value.
drivers/mtd/spi-nor/spi-nor.c | 46 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 52 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..0c3b4fd 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,45 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return -EINVAL;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return -EINVAL;
+ }
+
+ ret = wait_till_ready(nor);
+ if (ret)
+ return ret;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return -EINVAL;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +929,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] driver:mtd:spi-nor: Add Micron quad I/O support
>> +/* set EVCR ,enable quad I/O */
>> +nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
>> +ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
>> +if (ret < 0) {
>> +dev_err(nor->dev,
>> +"error while writing EVCR register\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (wait_till_ready(nor))
>> +return 1;
>Why does this not return proper error code or even better, return value from
>wait_till_ready() ?
>
>Other than that, there's nothing wrong with the patch I think.
Hi,Marek
Thanks for your review,you can find the same usage in the spi-nor.c.
Below method is OK? Or you can give me some suggestion.
if (wait_till_ready(nor))
return - EINVAL;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/1] driver:mtd:spi-nor: Add Micron quad I/O support
+/* set EVCR ,enable quad I/O */
+nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+if (ret 0) {
+dev_err(nor-dev,
+error while writing EVCR register\n);
+return -EINVAL;
+}
+
+if (wait_till_ready(nor))
+return 1;
Why does this not return proper error code or even better, return value from
wait_till_ready() ?
Other than that, there's nothing wrong with the patch I think.
Hi,Marek
Thanks for your review,you can find the same usage in the spi-nor.c.
Below method is OK? Or you can give me some suggestion.
if (wait_till_ready(nor))
return - EINVAL;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable Quad spi transfer
by clear EVCR(Enhanced Volatile Configuration Register)
Quad I/O protocol bit.
Signed-off-by: bean huo
---
drivers/mtd/spi-nor/spi-nor.c | 45 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 51 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..e72894f 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,44 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+ ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
+ if (ret < 0) {
+ dev_err(nor->dev,
+ "error while writing EVCR register\n");
+ return -EINVAL;
+ }
+
+ if (wait_till_ready(nor))
+ return 1;
+
+ /* read EVCR and check it */
+ ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
+ if (ret < 0) {
+ dev_err(nor->dev, "error %d reading EVCR\n", ret);
+ return -EINVAL;
+ }
+ if (val & EVCR_QUAD_EN_MICRON) {
+ dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +928,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor->dev, "Micron quad-read not enabled\n");
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] driver:mtd:spi-nor: Add Micron quad I/O support
For Micron spi norflash,you can enable Quad spi transfer
by clear EVCR(Enhanced Volatile Configuration Register)
Quad I/O protocol bit.
Signed-off-by: bean huo bean...@micron.com
---
drivers/mtd/spi-nor/spi-nor.c | 45 +
include/linux/mtd/spi-nor.h |6 ++
2 files changed, 51 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index b5ad6be..e72894f 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -878,6 +878,44 @@ static int spansion_quad_enable(struct spi_nor *nor)
return 0;
}
+static int micron_quad_enable(struct spi_nor *nor)
+{
+ int ret, val;
+
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return -EINVAL;
+ }
+
+ write_enable(nor);
+
+ /* set EVCR ,enable quad I/O */
+ nor-cmd_buf[0] = val ~EVCR_QUAD_EN_MICRON;
+ ret = nor-write_reg(nor, SPINOR_OP_WD_EVCR, nor-cmd_buf, 1, 0);
+ if (ret 0) {
+ dev_err(nor-dev,
+ error while writing EVCR register\n);
+ return -EINVAL;
+ }
+
+ if (wait_till_ready(nor))
+ return 1;
+
+ /* read EVCR and check it */
+ ret = nor-read_reg(nor, SPINOR_OP_RD_EVCR, val, 1);
+ if (ret 0) {
+ dev_err(nor-dev, error %d reading EVCR\n, ret);
+ return -EINVAL;
+ }
+ if (val EVCR_QUAD_EN_MICRON) {
+ dev_err(nor-dev, Micron EVCR Quad bit not clear\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
{
int status;
@@ -890,6 +928,13 @@ static int set_quad_mode(struct spi_nor *nor, u32 jedec_id)
return -EINVAL;
}
return status;
+ case CFI_MFR_ST:
+ status = micron_quad_enable(nor);
+ if (status) {
+ dev_err(nor-dev, Micron quad-read not enabled\n);
+ return -EINVAL;
+ }
+ return status;
default:
status = spansion_quad_enable(nor);
if (status) {
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 9e6294f..d71b659 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -56,6 +56,10 @@
/* Used for Spansion flashes only. */
#define SPINOR_OP_BRWR 0x17/* Bank register write */
+/* Used for Micron flashes only. */
+#define SPINOR_OP_RD_EVCR 0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR 0x61/* Write EVCR register */
+
/* Status Register bits. */
#define SR_WIP 1 /* Write in progress */
#define SR_WEL 2 /* Write enable latch */
@@ -67,6 +71,8 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+#define EVCR_QUAD_EN_MICRON0x80/* Micron Quad I/O */
+
/* Flag Status Register bits */
#define FSR_READY 0x80
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] mtd: cfi_cmdset_0002:add fixup for Micron M29EW after erase operation
For Micron M29EW,20ms delay is needed after erase operation.
Signed-off-by: BeanHuo
---
drivers/mtd/chips/cfi_cmdset_0002.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 5a4bfe3..9b0de91 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -509,6 +509,16 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
cfi_private *cfi)
cfi_udelay(500);
}
+static void cfi_fixup_m29ew_delay_after_erase(struct cfi_private *cfi)
+{
+ /*
+* Resolving the Delay After ERASE Issue @low temperature.
+* 20ms delay is needed after erase operation.
+*/
+ if (is_m29ew(cfi))
+ cfi_udelay(2);
+}
+
struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary) {
struct cfi_private *cfi = map->fldrv_priv; @@ -2397,6 +2407,7 @@ static
int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
ret = -EIO;
}
+ cfi_fixup_m29ew_delay_after_erase(cfi);
chip->state = FL_READY;
DISABLE_VPP(map);
put_chip(map, chip, adr);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] mtd: cfi_cmdset_0002:add fixup for Micron M29EW after erase operation
For Micron M29EW,20ms delay is needed after erase operation.
Signed-off-by: BeanHuo b...@micron.com
---
drivers/mtd/chips/cfi_cmdset_0002.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c
b/drivers/mtd/chips/cfi_cmdset_0002.c
index 5a4bfe3..9b0de91 100644
--- a/drivers/mtd/chips/cfi_cmdset_0002.c
+++ b/drivers/mtd/chips/cfi_cmdset_0002.c
@@ -509,6 +509,16 @@ static void cfi_fixup_m29ew_delay_after_resume(struct
cfi_private *cfi)
cfi_udelay(500);
}
+static void cfi_fixup_m29ew_delay_after_erase(struct cfi_private *cfi)
+{
+ /*
+* Resolving the Delay After ERASE Issue @low temperature.
+* 20ms delay is needed after erase operation.
+*/
+ if (is_m29ew(cfi))
+ cfi_udelay(2);
+}
+
struct mtd_info *cfi_cmdset_0002(struct map_info *map, int primary) {
struct cfi_private *cfi = map-fldrv_priv; @@ -2397,6 +2407,7 @@ static
int __xipram do_erase_oneblock(struct map_info *map, struct flchip *chip,
ret = -EIO;
}
+ cfi_fixup_m29ew_delay_after_erase(cfi);
chip-state = FL_READY;
DISABLE_VPP(map);
put_chip(map, chip, adr);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
>From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001
From: White Ding
Date: Thu, 24 Jul 2014 00:10:45 +0800
Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Do nand reset before write protect check.
If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.
As we know the status register can be refreshed, if we do some operation to
trigger it,
for example if we do erase/program operation to one block that is locked, then
READ STATUS,
the bit 7 of READ STATUS will be 0 indicate the device in write protect, then
if we do
erase/program operation to another block that is unlocked, the bit 7 of READ
STATUS will
be 1 indicate the device is not write protect.
Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low
(write protect),
but in this case the WP# maybe high if we do erase/program operation to a
locked block,
so we must reset the device if we want to check the WP# low or high through
STATUS READ and
check bit 7.
Signed-off-by: White Ding
---
drivers/mtd/nand/nand_base.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip->select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
@@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip->select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
--
1.7.9.5
White
-Original Message-
From: Brian Norris [mailto:computersforpe...@gmail.com]
Sent: Tuesday, August 05, 2014 6:48 AM
To: bpqw
Cc: dw...@infradead.org; b32...@freescale.com;
artem.bityuts...@linux.intel.com; r...@debian.org;
u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com;
linux-...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi,
On Mon, Jul 28, 2014 at 07:46:51AM +, bpqw wrote:
> >> Do nand reset before write protect check If we want to check the
> >> WP# low or high through STATUS READ and check bit 7, we must reset
> >> the device, other operation (eg.erase/program a locked block) can
> >> also clear the bit 7 of status register.
> >This description doesn't really tell me why we need this patch.
> If we want to use the lock/unlock function, we must confirm the WP# is high,
> if the WP# is low, the write protect is provided by WP#, we don't need
> LOKC/UNLOCK function.
> So before we use the LOCK/UNLOCK function we must confirm the WP# is high.
> We can check the WP# is high or low through READ STATUS and check the bit 7,
> but this only correct when we READ STATUS directly after RESET or Power On.
> If we don't add this patch, We can't check the WP# high or low just through
> READ STATUS and check bit7.
>
> >First of all, where is the 'lock' sequence specified? I see the commit that
> >introduced nand_lock() (without any users) which says Micron parts support
> >it, but I don't see it documented in the datasheet:
> The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this
> feature.
>
> > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0
> > Author: Vimal Singh
> > Date: Mon Feb 8 15:50:49 2010 +0530
>
> > mtd: nand: add lock/unlock routines
>
> >Now, supposing this is documented somewhere, are you seeing some kind
> >of out-of-spec behavior? Is this a controller quirk you're seeing?
> >Why should I need to reset the chip? I would presume that
>
> > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
>
> >would refresh the status properly. Is tha
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
From 0304e9618d8c3ef5360b611f881f1b1bed08be06 Mon Sep 17 00:00:00 2001
From: White Ding b...@micron.com
Date: Thu, 24 Jul 2014 00:10:45 +0800
Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Do nand reset before write protect check.
If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.
As we know the status register can be refreshed, if we do some operation to
trigger it,
for example if we do erase/program operation to one block that is locked, then
READ STATUS,
the bit 7 of READ STATUS will be 0 indicate the device in write protect, then
if we do
erase/program operation to another block that is unlocked, the bit 7 of READ
STATUS will
be 1 indicate the device is not write protect.
Suppose we checked the bit 7 of READ STATUS is 0 then judge the WP# is low
(write protect),
but in this case the WP# maybe high if we do erase/program operation to a
locked block,
so we must reset the device if we want to check the WP# low or high through
STATUS READ and
check bit 7.
Signed-off-by: White Ding b...@micron.com
---
drivers/mtd/nand/nand_base.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip-select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug(%s: device is write protected!\n,
@@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip-select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug(%s: device is write protected!\n,
--
1.7.9.5
White
-Original Message-
From: Brian Norris [mailto:computersforpe...@gmail.com]
Sent: Tuesday, August 05, 2014 6:48 AM
To: bpqw
Cc: dw...@infradead.org; b32...@freescale.com;
artem.bityuts...@linux.intel.com; r...@debian.org;
u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com;
linux-...@lists.infradead.org; linux-kernel@vger.kernel.org
Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi,
On Mon, Jul 28, 2014 at 07:46:51AM +, bpqw wrote:
Do nand reset before write protect check If we want to check the
WP# low or high through STATUS READ and check bit 7, we must reset
the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.
This description doesn't really tell me why we need this patch.
If we want to use the lock/unlock function, we must confirm the WP# is high,
if the WP# is low, the write protect is provided by WP#, we don't need
LOKC/UNLOCK function.
So before we use the LOCK/UNLOCK function we must confirm the WP# is high.
We can check the WP# is high or low through READ STATUS and check the bit 7,
but this only correct when we READ STATUS directly after RESET or Power On.
If we don't add this patch, We can't check the WP# high or low just through
READ STATUS and check bit7.
First of all, where is the 'lock' sequence specified? I see the commit that
introduced nand_lock() (without any users) which says Micron parts support
it, but I don't see it documented in the datasheet:
The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this
feature.
commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0
Author: Vimal Singh vimal.neww...@gmail.com
Date: Mon Feb 8 15:50:49 2010 +0530
mtd: nand: add lock/unlock routines
Now, supposing this is documented somewhere, are you seeing some kind
of out-of-spec behavior? Is this a controller quirk you're seeing?
Why should I need to reset the chip? I would presume that
chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
would refresh the status properly. Is that not the case?
chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly,
but we must do some operation to trigger it.
For example if we do rease/program operation to a block that is locked
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch? Do you have any other doubts? Br White Ding -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi Brain, >> Do nand reset before write protect check If we want to check the WP# >> low or high through STATUS READ and check bit 7, we must reset the >> device, other operation (eg.erase/program a locked block) can also >> clear the bit 7 of status register. >This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. >First of all, where is the 'lock' sequence specified? I see the commit that >introduced nand_lock() (without any users) which says Micron parts support it, >but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 > Author: Vimal Singh > Date: Mon Feb 8 15:50:49 2010 +0530 > mtd: nand: add lock/unlock routines >Now, supposing this is documented somewhere, are you seeing some kind >of out-of-spec behavior? Is this a controller quirk you're seeing? Why >should I need to reset the chip? I would presume that > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); >would refresh the status properly. Is that not the case? chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: > Do nand reset before write protect check If we want to check the WP# > low or high through STATUS READ and check bit 7, we must reset the > device, other operation (eg.erase/program a locked block) can also > clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? > Signed-off-by: White Ding > --- > drivers/mtd/nand/nand_base.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/mtd/nand/nand_base.c > b/drivers
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch? Do you have any other doubts? Br White Ding -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi Brain, Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? Signed-off-by: White Ding b...@micron.com --- drivers/mtd/nand/nand_base.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 41167e9..22dd3aa 100644 --- a/drivers/mtd/nand
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch do you have any other proposal? Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi Brain, >> Do nand reset before write protect check If we want to check the WP# >> low or high through STATUS READ and check bit 7, we must reset the >> device, other operation (eg.erase/program a locked block) can also >> clear the bit 7 of status register. >This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. >First of all, where is the 'lock' sequence specified? I see the commit that >introduced nand_lock() (without any users) which says Micron parts support it, >but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 > Author: Vimal Singh > Date: Mon Feb 8 15:50:49 2010 +0530 > mtd: nand: add lock/unlock routines >Now, supposing this is documented somewhere, are you seeing some kind >of out-of-spec behavior? Is this a controller quirk you're seeing? Why >should I need to reset the chip? I would presume that > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); >would refresh the status properly. Is that not the case? chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: > Do nand reset before write protect check If we want to check the WP# > low or high through STATUS READ and check bit 7, we must reset the > device, other operation (eg.erase/program a locked block) can also > clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? > Signed-off-by: Whi
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, How about my patch do you have any other proposal? Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: bpqw Sent: Monday, July 28, 2014 3:47 PM To: Brian Norris; bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi Brain, Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? Signed-off-by: White Ding b...@micron.com --- drivers/mtd/nand/nand_base.c | 18
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, >> Do nand reset before write protect check If we want to check the WP# >> low or high through STATUS READ and check bit 7, we must reset the >> device, other operation (eg.erase/program a locked block) can also >> clear the bit 7 of status register. >This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. >First of all, where is the 'lock' sequence specified? I see the commit that >introduced nand_lock() (without any users) which says Micron parts support it, >but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. > commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 > Author: Vimal Singh > Date: Mon Feb 8 15:50:49 2010 +0530 > mtd: nand: add lock/unlock routines >Now, supposing this is documented somewhere, are you seeing some kind of >out-of-spec behavior? Is this a controller quirk you're seeing? Why should I >need to reset the chip? I would presume that > chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); >would refresh the status properly. Is that not the case? chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: > Do nand reset before write protect check If we want to check the WP# > low or high through STATUS READ and check bit 7, we must reset the > device, other operation (eg.erase/program a locked block) can also > clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? > Signed-off-by: White Ding > --- > drivers/mtd/nand/nand_base.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/mtd/nand/nand_base.c > b/drivers/mtd/nand/nand_base.c index 41167e9..22dd3aa 100644 > --- a/drivers/mtd/nand/nand_base.c > +++ b/drivers/mtd/nand/nand_base.c > @@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, > uint64_t len) > > chip->select_chip(mtd, chipnr); > > + /* > + * Reset the chip. > + * If we want to check the WP through READ STATUS and check the bit 7 > + * we must reset the chip > + * some oper
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Hi Brain, Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. If we want to use the lock/unlock function, we must confirm the WP# is high, if the WP# is low, the write protect is provided by WP#, we don't need LOKC/UNLOCK function. So before we use the LOCK/UNLOCK function we must confirm the WP# is high. We can check the WP# is high or low through READ STATUS and check the bit 7, but this only correct when we READ STATUS directly after RESET or Power On. If we don't add this patch, We can't check the WP# high or low just through READ STATUS and check bit7. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: The LOCK/UNLOCK feature not apply all micron nand, only 1.8V device have this feature. commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1) can refresh the status properly, but we must do some operation to trigger it. For example if we do rease/program operation to a block that is locked, then READ STATUS, the bit 7 will be 0 that indicate the device is write protect. Then if we do erase/program operation to another block that is unlocked, the bit 7 of READ STATUS will be 1 indicate that the device is not write protect. Now if we don't do any operation just through chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); to check the WP# is high or low. Suppose we check the bit 7 of READ STATUS is 0 then we judge the WP# is low (write protect), but in this case the WP# may be high if we do erase/program operation to a locked block. Br White Ding EBU APAC Application Engineering Tel:86-21-38997078 Mobile: 86-13761729112 Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China -Original Message- From: Brian Norris [mailto:computersforpe...@gmail.com] Sent: Monday, July 28, 2014 2:10 PM To: bpqw Cc: dw...@infradead.org; b32...@freescale.com; artem.bityuts...@linux.intel.com; r...@debian.org; u.kleine-koe...@pengutronix.de; ezequiel.gar...@free-electrons.com; linux-...@lists.infradead.org; linux-kernel@vger.kernel.org Subject: Re: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function Hi White, You've responded to one of my messages, but your mail server is also sending bounce replies. You might want to contact your I.T. about this. (I'll let you know if I ever stop getting bounces.) On Thu, Jul 24, 2014 at 01:00:01AM +, bpqw wrote: Do nand reset before write protect check If we want to check the WP# low or high through STATUS READ and check bit 7, we must reset the device, other operation (eg.erase/program a locked block) can also clear the bit 7 of status register. This description doesn't really tell me why we need this patch. First of all, where is the 'lock' sequence specified? I see the commit that introduced nand_lock() (without any users) which says Micron parts support it, but I don't see it documented in the datasheet: commit 7d70f334ad2bf1b3aaa1f0699c0f442e14bcc9e0 Author: Vimal Singh vimal.neww...@gmail.com Date: Mon Feb 8 15:50:49 2010 +0530 mtd: nand: add lock/unlock routines Now, supposing this is documented somewhere, are you seeing some kind of out-of-spec behavior? Is this a controller quirk you're seeing? Why should I need to reset the chip? I would presume that chip-cmdfunc(mtd, NAND_CMD_STATUS, -1, -1); would refresh the status properly. Is that not the case? Signed-off-by: White Ding b...@micron.com --- drivers/mtd/nand/nand_base.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 41167e9..22dd3aa 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t len) chip-select_chip(mtd, chipnr); + /* + * Reset the chip. + * If we want to check the WP through READ STATUS and check the bit 7 + * we must reset the chip + * some operation can also clear the bit 7 of status register + * eg. erase/program a locked block + */ + chip-cmdfunc(mtd
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
>OK, I won't drop them yet. >As you note, there's no user-space support. There's actually no one using them >even in the kernel, which is why I considered dropping them. >If you want to use them, find a proper way to use them then! (I'm not >sure: do they match with mtd_lock() / ioctl(MEMLOCK) interface?) How about my patch, Do you think there is any other need to change? White -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
OK, I won't drop them yet. As you note, there's no user-space support. There's actually no one using them even in the kernel, which is why I considered dropping them. If you want to use them, find a proper way to use them then! (I'm not sure: do they match with mtd_lock() / ioctl(MEMLOCK) interface?) How about my patch, Do you think there is any other need to change? White -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Do nand reset before write protect check
If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.
Signed-off-by: White Ding
---
drivers/mtd/nand/nand_base.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip->select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
@@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip->select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip->cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug("%s: device is write protected!\n",
--
1.7.9.5
Br
White Ding
EBU APAC Application Engineering
Tel:86-21-38997078
Mobile: 86-13761729112
Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Subject: [PATCH 1/1] mtd:nand:fix nand_lock/unlock() function
Do nand reset before write protect check
If we want to check the WP# low or high through STATUS READ and check bit 7,
we must reset the device, other operation (eg.erase/program a locked block) can
also clear the bit 7 of status register.
Signed-off-by: White Ding b...@micron.com
---
drivers/mtd/nand/nand_base.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 41167e9..22dd3aa 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -965,6 +965,15 @@ int nand_unlock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip-select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug(%s: device is write protected!\n,
@@ -1015,6 +1024,15 @@ int nand_lock(struct mtd_info *mtd, loff_t ofs, uint64_t
len)
chip-select_chip(mtd, chipnr);
+ /*
+* Reset the chip.
+* If we want to check the WP through READ STATUS and check the bit 7
+* we must reset the chip
+* some operation can also clear the bit 7 of status register
+* eg. erase/program a locked block
+*/
+ chip-cmdfunc(mtd, NAND_CMD_RESET, -1, -1);
+
/* Check, if it is write protected */
if (nand_check_wp(mtd)) {
pr_debug(%s: device is write protected!\n,
--
1.7.9.5
Br
White Ding
EBU APAC Application Engineering
Tel:86-21-38997078
Mobile: 86-13761729112
Address: No 601 Fasai Rd, Waigaoqiao Free Trade Zone Pudong, Shanghai, China
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
