misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com --- Changes v2: - Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1);
write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL); - (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0, - 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc, - NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL); + if (q_op.cmd_reg == OP_BLOCK_ERASE) + write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);
write_reg_dma(nandc, NAND_EXEC_CMD, 1, NAND_BAM_NEXT_SGL); read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually dropped the handling of the RESET_DEVICE command.
The rework itself was correct with supporting case where a single misc command is handled, but became problematic by the addition of exiting early if we didn't had an ERASE or an OP_PROGRAM_PAGE operation.
Add additional logic to handle the reset command and return early only if we don't have handling for the requested command.
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com --- Changes v2: - Add this patch
drivers/mtd/nand/raw/qcom_nandc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index 19d76e345a49..b8cff9240b28 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2815,7 +2815,7 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub host->cfg0_raw & ~(7 << CW_PER_PAGE)); nandc_set_reg(chip, NAND_DEV0_CFG1, host->cfg1_raw); instrs = 3; - } else { + } else if (q_op.cmd_reg != OP_RESET_DEVICE) { return 0; }
On Mon, Mar 25, 2024 at 11:30:48AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually dropped the handling of the RESET_DEVICE command.
The rework itself was correct with supporting case where a single misc command is handled, but became problematic by the addition of exiting early if we didn't had an ERASE or an OP_PROGRAM_PAGE operation.
Add additional logic to handle the reset command and return early only if we don't have handling for the requested command.
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Add this patch
drivers/mtd/nand/raw/qcom_nandc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index 19d76e345a49..b8cff9240b28 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2815,7 +2815,7 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub host->cfg0_raw & ~(7 << CW_PER_PAGE)); nandc_set_reg(chip, NAND_DEV0_CFG1, host->cfg1_raw); instrs = 3;
- } else {
- } else if (q_op.cmd_reg != OP_RESET_DEVICE) {
But this will fail if the previous patch is not applied. So this makes me think that you are trying to fix the OP_RESET_DEVICE command with these 2 patches.
- Mani
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);
So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Can you share the actual issue that you are seeing? Like error logs etc...
- Mani
On Tue, Mar 26, 2024 at 12:55:19PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Perhaps you are trying to fix the OP_RESET_DEVICE command altogether?
- Mani
On Tue, Mar 26, 2024 at 01:09:47PM +0530, Manivannan Sadhasivam wrote:
On Tue, Mar 26, 2024 at 12:55:19PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Perhaps you are trying to fix the OP_RESET_DEVICE command altogether?
Well with this only patch correct working of nandc on ipq806x is restored. I'm still very confused how since the misc command currently works only with the PROGRAM_PAGE and the BLOCK_ERASE (from ERASE1 and ERASE2)
Still the extra read was added with no explaination and I couldn't find this command cycle in any of the previous legacy function and the one introduced after the parser rework.
On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Can you share the actual issue that you are seeing? Like error logs etc...
Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is called. BLOCK_ERASE operation match also another operation from MTD read. (parser also maps to other stuff)
I will be away from the testing board for 7-10 days so I can't provide logs currently.
Hi,
ansuelsmth@gmail.com wrote on Wed, 27 Mar 2024 16:20:58 +0100:
On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Can you share the actual issue that you are seeing? Like error logs etc...
Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is called. BLOCK_ERASE operation match also another operation from MTD read. (parser also maps to other stuff)
I will be away from the testing board for 7-10 days so I can't provide logs currently.
So, shall we wait for additional logs from Christian or shall I merge the two-patches series? I'm not sure what's the status anymore.
Thanks, Miquèl
On Wed, Mar 27, 2024 at 05:51:31PM +0100, Miquel Raynal wrote:
Hi,
ansuelsmth@gmail.com wrote on Wed, 27 Mar 2024 16:20:58 +0100:
On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Can you share the actual issue that you are seeing? Like error logs etc...
Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is called. BLOCK_ERASE operation match also another operation from MTD read. (parser also maps to other stuff)
I will be away from the testing board for 7-10 days so I can't provide logs currently.
So, shall we wait for additional logs from Christian or shall I merge the two-patches series? I'm not sure what's the status anymore.
TBH, I don't know how OP_BLOCK_ERASE can fail without this change. But I can clearly see the 2 patches required for OP_RESET_DEVICE command. But merging the patches as it is doesn't look good to me.
So I think if Christian can club the two patches into 1 as like v1 and reword the commit message and subject to reflect the fact that OP_RESET_DEVICE command is being fixed would work for me.
- Mani
On Thu, Mar 28, 2024 at 09:17:32AM +0530, Manivannan Sadhasivam wrote:
On Wed, Mar 27, 2024 at 05:51:31PM +0100, Miquel Raynal wrote:
Hi,
ansuelsmth@gmail.com wrote on Wed, 27 Mar 2024 16:20:58 +0100:
On Tue, Mar 26, 2024 at 12:55:12PM +0530, Manivannan Sadhasivam wrote:
On Mon, Mar 25, 2024 at 11:30:47AM +0100, Christian Marangi wrote:
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was reworked and generalized but actually broke the handling of the ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear explaination causing the erase command to be broken on testing it on a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") Cc: stable@vger.kernel.org Signed-off-by: Christian Marangi ansuelsmth@gmail.com
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index b079605c84d3..19d76e345a49 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub nandc_set_reg(chip, NAND_EXEC_CMD, 1); write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
- if (q_op.cmd_reg == OP_BLOCK_ERASE)
write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);So this only avoids the call to, 'read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL)' if q_op.cmd_reg != OP_BLOCK_ERASE. But for q_op.cmd_reg == OP_BLOCK_ERASE, the result is the same.
I'm wondering how it results in fixing the OP_BLOCK_ERASE command.
Can you share the actual issue that you are seeing? Like error logs etc...
Issue is that nandc goes to ADM timeout as soon as a BLOCK_ERASE is called. BLOCK_ERASE operation match also another operation from MTD read. (parser also maps to other stuff)
I will be away from the testing board for 7-10 days so I can't provide logs currently.
So, shall we wait for additional logs from Christian or shall I merge the two-patches series? I'm not sure what's the status anymore.
TBH, I don't know how OP_BLOCK_ERASE can fail without this change. But I can clearly see the 2 patches required for OP_RESET_DEVICE command. But merging the patches as it is doesn't look good to me.
So I think if Christian can club the two patches into 1 as like v1 and reword the commit message and subject to reflect the fact that OP_RESET_DEVICE command is being fixed would work for me.
Ok will do, very confusing and sorry for not providing additiona log. I was adding support for ipq806x for 6.6 and notice the regression.
Will rework the patch.
linux-stable-mirror@lists.linaro.org
-
Christian Marangi -
Manivannan Sadhasivam -
Miquel Raynal