mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issue
Han Xu
maintainerPATCH 1/2 mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issue
set the GPMI CTRL1 GANGED_RDYBUSY bit so dirver can sense the R/B signal from all CS.
For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch.
[ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01
After applying the patch
[ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01
--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 6 ++++-- drivers/mtd/nand/raw/gpmi-nand/gpmi-regs.h | 1 + 2 files changed, 5 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +4 -2
@@ -181,9 +181,11 @@ static int gpmi_init(struct gpmi_nand_data *this)/* * Decouple the chip select from dma channel. We use dma0 for all -* the chips. +* the chips, force all NAND RDY_BUSY inputs to be sourced from +* RDY_BUSY0. */ -writel (BM_GPMI_CTRL1_DECOUPLE_CS , r->gpmi_regs +HW_GPMI_CTRL1_SET ); +writel (BM_GPMI_CTRL1_DECOUPLE_CS |BM_GPMI_CTRL1_GANGED_RDYBUSY , + r->gpmi_regs +HW_GPMI_CTRL1_SET ); err_out:pm_runtime_mark_last_busy (this->dev);
drivers/mtd/nand/raw/gpmi-nand/gpmi-regs.h +1 -0
@@ -107,6 +107,7 @@#define BV_GPMI_CTRL1_WRN_DLY_SEL_7_TO_12NS 0x2#define BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY 0x3 +#define BM_GPMI_CTRL1_GANGED_RDYBUSY (1 << 19)#define BM_GPMI_CTRL1_BCH_MODE (1 << 18)#define BP_GPMI_CTRL1_DLL_ENABLE 17
Signature · 6 lines
2.17.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Han Xu
maintainerPATCH 2/2 mtd: rawnand: gpmi: Fix the random DMA timeout issue
To get better performance, current gpmi driver collected and chained all small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end.
But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows:
Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below,
63.216351 | 1) | gpmi_ecc_read_page() {
63.216352 | 1) 0.750 us | gpmi_bch_layout_std();
63.216354 | 1) | gpmi_nfc_exec_op() {
63.216355 | 1) | gpmi_chain_command() {
63.216356 | 1) | mxs_dma_prep_slave_sg() {
63.216357 | 1) | /* mxs chan ccw idx: 0 */
63.216358 | 1) 1.750 us | }
63.216359 | 1) | mxs_dma_prep_slave_sg() {
63.216360 | 1) | /* mxs chan ccw idx: 1 */
63.216361 | 1) 2.000 us | }
63.216361 | 1) 6.500 us | }
63.216362 | 1) | gpmi_chain_command() {
63.216363 | 1) | mxs_dma_prep_slave_sg() {
63.216364 | 1) | /* mxs chan ccw idx: 2 */
63.216365 | 1) 1.750 us | }
63.216366 | 1) | mxs_dma_prep_slave_sg() {
63.216367 | 1) | /* mxs chan ccw idx: 3 */
63.216367 | 1) 1.750 us | }
63.216368 | 1) 5.875 us | }
63.216369 | 1) | /* gpmi_chain_wait_ready */
63.216370 | 1) | mxs_dma_prep_slave_sg() {
63.216372 | 1) | /* mxs chan ccw idx: 4 */
63.216373 | 1) 3.000 us | }
63.216374 | 1) | /* gpmi_chain_data_read */
63.216376 | 1) | mxs_dma_prep_slave_sg() {
63.216377 | 1) | /* mxs chan ccw idx: 5 */
63.216378 | 1) 2.000 us | }
63.216379 | 1) 1.125 us | mxs_dma_tx_submit();
63.216381 | 1) 1.000 us | mxs_dma_enable_chan();
63.216712 | 0) 2.625 us | mxs_dma_int_handler();
63.216717 | 0) 4.250 us | bch_irq();
63.216723 | 0) 1.250 us | mxs_dma_tasklet();
63.216723 | 1) | /* jiffies left 250 */
63.216725 | 1) ! 372.000 us | }
63.216726 | 1) 2.625 us | gpmi_count_bitflips();
63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled, sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore, another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened.
63.218923 | 1) | gpmi_ecc_read_page() {
63.218924 | 1) 0.625 us | gpmi_bch_layout_std();
63.218926 | 1) | gpmi_nfc_exec_op() {
63.218927 | 1) | gpmi_chain_command() {
63.218928 | 1) | mxs_dma_prep_slave_sg() {
63.218929 | 1) | /* mxs chan ccw idx: 0 */
63.218929 | 1) 1.625 us | }
63.218931 | 1) | mxs_dma_prep_slave_sg() {
63.218931 | 1) | /* mxs chan ccw idx: 1 */
63.218932 | 1) 1.750 us | }
63.218933 | 1) 5.875 us | }
63.218934 | 1) | gpmi_chain_command() {
63.218934 | 1) | mxs_dma_prep_slave_sg() {
63.218935 | 1) | /* mxs chan ccw idx: 2 */
63.218936 | 1) 1.875 us | }
63.218937 | 1) | mxs_dma_prep_slave_sg() {
63.218938 | 1) | /* mxs chan ccw idx: 3 */
63.218939 | 1) 1.625 us | }
63.218939 | 1) 5.875 us | }
63.218940 | 1) | /* gpmi_chain_wait_ready */
63.218941 | 1) | mxs_dma_prep_slave_sg() {
63.218942 | 1) | /* mxs chan ccw idx: 4 */
63.218942 | 1) 1.625 us | }
63.218943 | 1) | /* gpmi_chain_data_read */
63.218944 | 1) | mxs_dma_prep_slave_sg() {
63.218945 | 1) | /* mxs chan ccw idx: 5 */
63.218947 | 1) 2.375 us | }
63.218948 | 1) 0.625 us | mxs_dma_tx_submit();
63.218949 | 1) 1.000 us | mxs_dma_enable_chan();
63.219276 | 0) 5.125 us | bch_irq(); <----
63.219283 | 1) | /* jiffies left 250 */
63.219285 | 1) ! 358.625 us | }
63.219286 | 1) 2.750 us | gpmi_count_bitflips();
63.219289 | 1) ! 366.000 us | }
63.219290 | 1) | gpmi_ecc_read_page() {
63.219291 | 1) 0.750 us | gpmi_bch_layout_std();
63.219293 | 1) | gpmi_nfc_exec_op() {
63.219294 | 1) | gpmi_chain_command() {
63.219295 | 1) | mxs_dma_prep_slave_sg() {
63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <----
63.219296 | 1) | /* mxs chan ccw idx: 6 */
63.219297 | 1) 2.250 us | }
63.219298 | 1) | mxs_dma_prep_slave_sg() {
63.219298 | 0) 1.000 us | mxs_dma_tasklet();
63.219299 | 1) | /* mxs chan ccw idx: 0 */
63.219300 | 1) 1.625 us | }
63.219300 | 1) 6.375 us | }
63.219301 | 1) | gpmi_chain_command() {
63.219302 | 1) | mxs_dma_prep_slave_sg() {
63.219303 | 1) | /* mxs chan ccw idx: 1 */
63.219304 | 1) 1.625 us | }
63.219305 | 1) | mxs_dma_prep_slave_sg() {
63.219306 | 1) | /* mxs chan ccw idx: 2 */
63.219306 | 1) 1.875 us | }
63.219307 | 1) 6.000 us | }
63.219308 | 1) | /* gpmi_chain_wait_ready */
63.219308 | 1) | mxs_dma_prep_slave_sg() {
63.219309 | 1) | /* mxs chan ccw idx: 3 */
63.219310 | 1) 2.000 us | }
63.219311 | 1) | /* gpmi_chain_data_read */
63.219312 | 1) | mxs_dma_prep_slave_sg() {
63.219313 | 1) | /* mxs chan ccw idx: 4 */
63.219314 | 1) 1.750 us | }
63.219315 | 1) 0.625 us | mxs_dma_tx_submit();
63.219316 | 1) 0.875 us | mxs_dma_enable_chan();
64.224227 | 1) | /* jiffies left 0 */In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op exits, but DMA IRQ still not happened yet until the middle of following gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout.
To fix the issue, when there is bch ops in DMA chain, the gpmi_nfc_exec_op should wait for both completions rather than bch completion only.
--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 32 +++++++++++++++------- 1 file changed, 22 insertions(+), 10 deletions(-)
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +22 -10
@@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +// SPDX-License-Identifier: GPL- .0+ /* * Freescale GPMI NAND Flash Driver *
@@ -2256,7 +2256,7 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,void *buf_read =NULL ;const void *buf_write =NULL ;bool direct = false; -struct completion *completion; +struct completion *dma_completion, *bch_completion;unsigned long to;if (check_only)
@@ -2353,22 +2353,24 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip, this->resources.bch_regs + HW_BCH_FLASH0LAYOUT1); } + desc->callback = dma_irq_callback; + desc->callback_param = this; + dma_completion = &this->dma_done; + bch_completion =NULL ; + +init_completion (dma_completion); +if (this->bch && buf_read) {writel (BM_BCH_CTRL_COMPLETE_IRQ_EN , this->resources.bch_regs +HW_BCH_CTRL_SET ); - completion = &this->bch_done; - }else { - desc->callback = dma_irq_callback; - desc->callback_param = this; - completion = &this->dma_done; + bch_completion = &this->bch_done; +init_completion (bch_completion); } -init_completion (completion); -dmaengine_submit (desc);dma_async_issue_pending (get_dma_chan (this)); - to =wait_for_completion_timeout (completion,msecs_to_jiffies (1000 )); + to =wait_for_completion_timeout (dma_completion,msecs_to_jiffies (1000 ));if (!to) {dev_err (this->dev,"DMA timeout, last DMA\n" );gpmi_dump_info (this);
@@ -2376,6 +2378,16 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip, goto unmap; } +if (this->bch && buf_read) { + to =wait_for_completion_timeout (bch_completion,msecs_to_jiffies (1000 )); +if (!to) { +dev_err (this->dev,"BCH timeout, last DMA\n" ); +gpmi_dump_info (this); + ret = -ETIMEDOUT ; + goto unmap; + } + } +writel (BM_BCH_CTRL_COMPLETE_IRQ_EN , this->resources.bch_regs +HW_BCH_CTRL_CLR );gpmi_clear_bch (this);
Signature · 6 lines
2.17.1 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Re: [PATCH 2/2] mtd: rawnand: gpmi: Fix the random DMA timeout issue
Quoted 142 lines · Han Xu
To get better performance, current gpmi driver collected and chained all small DMA transfers in
gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end.But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows:
Take
gpmi_ecc_read_page()as an example,gpmi_nfc_exec_opcollected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below,63.216351 | 1) | gpmi_ecc_read_page() { 63.216352 | 1) 0.750 us | gpmi_bch_layout_std(); 63.216354 | 1) | gpmi_nfc_exec_op() { 63.216355 | 1) | gpmi_chain_command() { 63.216356 | 1) | mxs_dma_prep_slave_sg() { 63.216357 | 1) | /* mxs chan ccw idx: 0 */ 63.216358 | 1) 1.750 us | } 63.216359 | 1) | mxs_dma_prep_slave_sg() { 63.216360 | 1) | /* mxs chan ccw idx: 1 */ 63.216361 | 1) 2.000 us | } 63.216361 | 1) 6.500 us | } 63.216362 | 1) | gpmi_chain_command() { 63.216363 | 1) | mxs_dma_prep_slave_sg() { 63.216364 | 1) | /* mxs chan ccw idx: 2 */ 63.216365 | 1) 1.750 us | } 63.216366 | 1) | mxs_dma_prep_slave_sg() { 63.216367 | 1) | /* mxs chan ccw idx: 3 */ 63.216367 | 1) 1.750 us | } 63.216368 | 1) 5.875 us | } 63.216369 | 1) | /* gpmi_chain_wait_ready */ 63.216370 | 1) | mxs_dma_prep_slave_sg() { 63.216372 | 1) | /* mxs chan ccw idx: 4 */ 63.216373 | 1) 3.000 us | } 63.216374 | 1) | /* gpmi_chain_data_read */ 63.216376 | 1) | mxs_dma_prep_slave_sg() { 63.216377 | 1) | /* mxs chan ccw idx: 5 */ 63.216378 | 1) 2.000 us | } 63.216379 | 1) 1.125 us | mxs_dma_tx_submit(); 63.216381 | 1) 1.000 us | mxs_dma_enable_chan(); 63.216712 | 0) 2.625 us | mxs_dma_int_handler(); 63.216717 | 0) 4.250 us | bch_irq(); 63.216723 | 0) 1.250 us | mxs_dma_tasklet(); 63.216723 | 1) | /* jiffies left 250 */ 63.216725 | 1) ! 372.000 us | } 63.216726 | 1) 2.625 us | gpmi_count_bitflips(); 63.216730 | 1) ! 379.125 us | }but it's not gurantee that bch irq handled always after dma irq handled, sometimes
bch_irqcomes first andgpmi_nfc_exec_opwon't wait anymore, anothergpmi_nfc_exec_opmay get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened.63.218923 | 1) | gpmi_ecc_read_page() { 63.218924 | 1) 0.625 us | gpmi_bch_layout_std(); 63.218926 | 1) | gpmi_nfc_exec_op() { 63.218927 | 1) | gpmi_chain_command() { 63.218928 | 1) | mxs_dma_prep_slave_sg() { 63.218929 | 1) | /* mxs chan ccw idx: 0 */ 63.218929 | 1) 1.625 us | } 63.218931 | 1) | mxs_dma_prep_slave_sg() { 63.218931 | 1) | /* mxs chan ccw idx: 1 */ 63.218932 | 1) 1.750 us | } 63.218933 | 1) 5.875 us | } 63.218934 | 1) | gpmi_chain_command() { 63.218934 | 1) | mxs_dma_prep_slave_sg() { 63.218935 | 1) | /* mxs chan ccw idx: 2 */ 63.218936 | 1) 1.875 us | } 63.218937 | 1) | mxs_dma_prep_slave_sg() { 63.218938 | 1) | /* mxs chan ccw idx: 3 */ 63.218939 | 1) 1.625 us | } 63.218939 | 1) 5.875 us | } 63.218940 | 1) | /* gpmi_chain_wait_ready */ 63.218941 | 1) | mxs_dma_prep_slave_sg() { 63.218942 | 1) | /* mxs chan ccw idx: 4 */ 63.218942 | 1) 1.625 us | } 63.218943 | 1) | /* gpmi_chain_data_read */ 63.218944 | 1) | mxs_dma_prep_slave_sg() { 63.218945 | 1) | /* mxs chan ccw idx: 5 */ 63.218947 | 1) 2.375 us | } 63.218948 | 1) 0.625 us | mxs_dma_tx_submit(); 63.218949 | 1) 1.000 us | mxs_dma_enable_chan(); 63.219276 | 0) 5.125 us | bch_irq(); <---- 63.219283 | 1) | /* jiffies left 250 */ 63.219285 | 1) ! 358.625 us | } 63.219286 | 1) 2.750 us | gpmi_count_bitflips(); 63.219289 | 1) ! 366.000 us | } 63.219290 | 1) | gpmi_ecc_read_page() { 63.219291 | 1) 0.750 us | gpmi_bch_layout_std(); 63.219293 | 1) | gpmi_nfc_exec_op() { 63.219294 | 1) | gpmi_chain_command() { 63.219295 | 1) | mxs_dma_prep_slave_sg() { 63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <---- 63.219296 | 1) | /* mxs chan ccw idx: 6 */ 63.219297 | 1) 2.250 us | } 63.219298 | 1) | mxs_dma_prep_slave_sg() { 63.219298 | 0) 1.000 us | mxs_dma_tasklet(); 63.219299 | 1) | /* mxs chan ccw idx: 0 */ 63.219300 | 1) 1.625 us | } 63.219300 | 1) 6.375 us | } 63.219301 | 1) | gpmi_chain_command() { 63.219302 | 1) | mxs_dma_prep_slave_sg() { 63.219303 | 1) | /* mxs chan ccw idx: 1 */ 63.219304 | 1) 1.625 us | } 63.219305 | 1) | mxs_dma_prep_slave_sg() { 63.219306 | 1) | /* mxs chan ccw idx: 2 */ 63.219306 | 1) 1.875 us | } 63.219307 | 1) 6.000 us | } 63.219308 | 1) | /* gpmi_chain_wait_ready */ 63.219308 | 1) | mxs_dma_prep_slave_sg() { 63.219309 | 1) | /* mxs chan ccw idx: 3 */ 63.219310 | 1) 2.000 us | } 63.219311 | 1) | /* gpmi_chain_data_read */ 63.219312 | 1) | mxs_dma_prep_slave_sg() { 63.219313 | 1) | /* mxs chan ccw idx: 4 */ 63.219314 | 1) 1.750 us | } 63.219315 | 1) 0.625 us | mxs_dma_tx_submit(); 63.219316 | 1) 0.875 us | mxs_dma_enable_chan(); 64.224227 | 1) | /* jiffies left 0 */In the first
gpmi_nfc_exec_op,bch_irqcomes first andgpmi_nfc_exec_opexits, but DMA IRQ still not happened yet until the middle of followinggpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout.To fix the issue, when there is bch ops in DMA chain, the
gpmi_nfc_exec_opshould wait for both completions rather than bch completion only.Fixes ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op")Signed-off-by Han Xu <[email protected]>--- drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 32 +++++++++++++++------- 1 file changed, 22 insertions(+), 10 deletions(-)drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +0
-0
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c line 1
Quoted 2 lines
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +1
-1@@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0+ +// SPDX-License-Identifier: GPL- .0+
Ups?
Quoted 36 lines
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +10
-8@@ -2353,22 +2353,24 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip, this->resources.bch_regs + HW_BCH_FLASH0LAYOUT1); } + desc->callback = dma_irq_callback; + desc->callback_param = this; + dma_completion = &this->dma_done; + bch_completion =NULL ; + +init_completion (dma_completion); +if (this->bch && buf_read) {writel (BM_BCH_CTRL_COMPLETE_IRQ_EN , this->resources.bch_regs +HW_BCH_CTRL_SET ); - completion = &this->bch_done; - }else { - desc->callback = dma_irq_callback; - desc->callback_param = this; - completion = &this->dma_done; + bch_completion = &this->bch_done; +init_completion (bch_completion); } -init_completion (completion); -dmaengine_submit (desc);dma_async_issue_pending (get_dma_chan (this)); - to =wait_for_completion_timeout (completion,msecs_to_jiffies (1000 )); + to =wait_for_completion_timeout (dma_completion,msecs_to_jiffies (1000 ));if (!to) {dev_err (this->dev,"DMA timeout, last DMA\n" );gpmi_dump_info (this);@@ -2376,6 +2378,16 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip, goto unmap; }
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c static int gpmi_nfc_exec_op(struct nand_chip *chip, · line 2389
Quoted 10 lines
drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c +9
-0+if (this->bch && buf_read) { + to =wait_for_completion_timeout (bch_completion,msecs_to_jiffies (1000 )); +if (!to) { +dev_err (this->dev,"BCH timeout, last DMA\n" ); +gpmi_dump_info (this); + ret = -ETIMEDOUT ; + goto unmap; + } + }
Technically when reading we are not interested in the dma_completion, but only in the bch completion. We are only interested that the dma interrupt handler has been executed before we start the next command. This might cause a little performance loss, but this is probably negligible compared to the effort we have to do to synchronize the dma handler to the correspoding events.
So with the accidently slipped in hunk removed I am fine with the patch and you can add my:
Sascha
Signature · 8 lines
Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 14 lines · Han Xu
set the GPMI CTRL1
GANGED_RDYBUSYbit so dirver can sense the R/B signal from all CS.For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch.
[ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01After applying the patch
Quoted 8 lines
[ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOB size: 448 [ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01Fixes 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code into single file")
I don't see how 3045f8e36963 changes his behaviour. Are you sure it worked without this patch?
Sascha
Signature · 8 lines
Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Han Xu
maintainerQuoted 36 lines
-----Original Message-----
From: Sascha Hauer <[email protected]>
Sent: Monday, December 7, 2020 3:50 AM
To: Han Xu <[email protected]>
Cc: [email protected]; [email protected]
Subject: [EXT] Re: [PATCH 1/2] mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issueCaution: EXT Email
Quoted 9 lines · Han Xu
set the GPMI CTRL1
GANGED_RDYBUSYbit so dirver can sense the R/B signal from all CS.For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch.
[ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 8 lines
[ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01After applying the patch
[ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 4 lines
[ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01
Quoted 5 lines
Quoted 2 lines
Fixes 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code intosingle file")
I don't see how
3045f8e36963changes his behaviour. Are you sure it worked without this patch?
After several rounds files merge and code move, it's hard to find when this issue first involved, the driver still works for single CS NAND but CTRL1 GANGED_RDYBUSY must be set for multi-CS NAND chips.
Quoted 14 lines
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 |
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.peng
utronix.de%2F&data=04%7C01%7Chan.xu%40nxp.com%7Cfeed58dd05004a 8f81f208d89a957af4%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637 429314087020152%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZyW3svz HvL1soAA%2BUi6FCe%2B8ZUm2gubwEK6P%2BO9T2%2FI%3D&reserved=0 |
Quoted 2 lines
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Quoted 39 lines · Han Xu
Quoted 39 lines
-----Original Message-----
From: Sascha Hauer <[email protected]>
Sent: Monday, December 7, 2020 3:50 AM
To: Han Xu <[email protected]>
Cc: [email protected]; [email protected]
Subject: [EXT] Re: [PATCH 1/2] mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issueCaution: EXT Email
Quoted 9 lines · Han Xu
set the GPMI CTRL1
GANGED_RDYBUSYbit so dirver can sense the R/B signal from all CS.For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch.
[ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 8 lines
[ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01After applying the patch
[ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 6 lines
[ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01Fixes 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code intosingle file")
Quoted 6 lines
Quoted 2 lines
I don't see how
3045f8e36963changes his behaviour. Are you sure it worked without this patch?After several rounds files merge and code move, it's hard to find when this issue first involved, the driver still works for single CS NAND but CTRL1
GANGED_RDYBUSYmust be set for multi-CS NAND chips.
3045f8e36963 only re-arranges the code without any functional change, so I strongly doubt that a commit writing a register with a newly introduced register bit ixes it.
Please drop this "Fixes:" tag.
Sascha
Signature · 8 lines
Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
Miquel Raynal
maintainerHello,
Sascha Hauer <[email protected]> wrote on Mon, 7 Dec 2020 17:43:46 +0100:
Quoted 47 lines · Han Xu
Quoted 39 lines
Quoted 39 lines
-----Original Message-----
From: Sascha Hauer <[email protected]>
Sent: Monday, December 7, 2020 3:50 AM
To: Han Xu <[email protected]>
Cc: [email protected]; [email protected]
Subject: [EXT] Re: [PATCH 1/2] mtd: rawnand: gpmi: Fix the driver only sense CS0 R/B issueCaution: EXT Email
Quoted 9 lines · Han Xu
set the GPMI CTRL1
GANGED_RDYBUSYbit so dirver can sense the R/B signal from all CS.For the NAND chip MT29F64G08AFAAAWP, only the first chip detected without the patch.
[ 3.764118] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770613] nand: Micron MT29F64G08AFAAAWP [ 3.774752] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 8 lines
[ 3.786421] Bad block table found at page 524160, version 0x01 [ 3.792730] Bad block table found at page 524032, version 0x01After applying the patch
[ 3.764445] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0x68 [ 3.770941] nand: Micron MT29F64G08AFAAAWP [ 3.775080] nand: 4096 MiB, SLC, erase size: 1024 KiB, page size: 8192, OOBsize: 448
Quoted 6 lines
[ 3.784390] nand: 2 chips detected [ 3.790900] Bad block table found at page 524160, version 0x01 [ 3.796776] Bad block table found at page 1048448, version 0x01Fixes 3045f8e36963 ("mtd: rawnand: gpmi: move all driver code intosingle file")
Quoted 6 lines
Quoted 2 lines
I don't see how
3045f8e36963changes his behaviour. Are you sure it worked without this patch?After several rounds files merge and code move, it's hard to find when this issue first involved, the driver still works for single CS NAND but CTRL1
GANGED_RDYBUSYmust be set for multi-CS NAND chips.
Quoted 5 lines
3045f8e36963only re-arranges the code without any functional change, so I strongly doubt that a commit writing a register with a newly introduced register bit ixes it.Please drop this "Fixes:" tag.
I will drop the tag when applying.
Quoted 3 lines
Sascha
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/