All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Marek Vasut <marek.vasut@gmail.com>,
	"Brian Norris" <computersforpeace@gmail.com>,
	David Woodhouse <dwmw2@infradead.org>,
	Bean Huo <beanhuo@micron.com>
Subject: Re: [2/3] mtd: rawnand: micron: Disable ECC earlier in the read path
Date: Mon, 16 Jul 2018 22:42:54 +0000	[thread overview]
Message-ID: <afe826dcb4934dea9795541ee0385542@svr-chch-ex1.atlnz.lc> (raw)
In-Reply-To: 20180716225538.542cb096@bbrezillon

On 17/07/18 08:55, Boris Brezillon wrote:
> On Mon, 16 Jul 2018 18:10:57 +0200
> Boris Brezillon <boris.brezillon@bootlin.com> wrote:
> 
>> On Mon, 16 Jul 2018 09:00:59 +0000
>> Chris Packham <Chris.Packham@alliedtelesis.co.nz> wrote:
>>
>>> Hi Boris,
>>>
>>> On 04/07/18 00:20, Boris Brezillon wrote:
>>>> We are about to support extracting the real number of bitflips for
>>>> 4-bits ECC when WRITE_RECOMMEND is returned. This requires re-reading
>>>> the page in raw mode to compare it to the corrected version, and this
>>>> logic will be placed in micron_nand_on_die_ecc_status_4().
>>>>
>>>> Moving the micron_nand_on_die_ecc_setup() will allow us to disable
>>>> ECC only once.
>>>>
>>>> As a result, we have to rework the exit path and add an error path
>>>> where the ECC is disabled.
>>>>
>>>> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
>>>
>>> As I said on the other thread this appears to cause a problem for me on
>>> the MT29F1G08ABAFAWP-ITE setup I have. I notice we're not able to find
>>> the BBT, not sure if that is symptom or cause.
> 
> It's most likely the symptom, not the cause.
> 
>>>>
>>>> diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c
>>>> index 63ac98a36ed7..b9cbaf125a98 100644
>>>> --- a/drivers/mtd/nand/raw/nand_micron.c
>>>> +++ b/drivers/mtd/nand/raw/nand_micron.c
>>>> @@ -197,30 +197,37 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip,
>>>>    
>>>>    	ret = nand_read_page_op(chip, page, 0, NULL, 0);
>>>>    	if (ret)
>>>> -		goto out;
>>>> +		goto err_disable_ecc;
>>>>    
>>>>    	ret = nand_status_op(chip, &status);
>>>>    	if (ret)
>>>> -		goto out;
>>>> +		goto err_disable_ecc;
>>>>    
>>>>    	ret = nand_exit_status_op(chip);
>>>>    	if (ret)
>>>> -		goto out;
>>>> +		goto err_disable_ecc;
>>>>    
>>>> -	if (chip->ecc.strength == 4)
>>>> -		max_bitflips = micron_nand_on_die_ecc_status_4(chip, status);
>>>> -	else
>>>> -		max_bitflips = micron_nand_on_die_ecc_status_8(chip, status);
>>>> +	micron_nand_on_die_ecc_setup(chip, false);
>>
>> Hm, can you try to move the micron_nand_on_die_ecc_setup(chip, false)
>> call just before nand_exit_status_op()?
>>
> 
> Just pushed a branch fixing that [1]. Can you test it? If it works,
> I'll ask Miquel to drop the initial set of patches and instead pick the
> fixed ones so that we don't break bisectibility.
> 
> [1]https://github.com/bbrezillon/linux-0day/commits/nand/next
> 

Still appears to have the same problem.

I'm guessing that since you can't actually disable ecc on this chip 
calling micron_nand_on_die_ecc_setup(chip, false); before reading the 
oob data interferes with it somehow (if I call it after there is no 
problem).

We could add code to qualify the attempt to disable ecc early based on 
it being optional/mandatory or just stick with it being disabled late.

  reply	other threads:[~2018-07-16 22:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-03 12:20 [PATCH 0/3] mtd: rawnand: micron: Get the actual number of bitflips Boris Brezillon
2018-07-03 12:20 ` [PATCH 1/3] mtd: rawnand: micron: Stop passing mtd to ecc_status() funcs Boris Brezillon
2018-07-03 12:20 ` [PATCH 2/3] mtd: rawnand: micron: Disable ECC earlier in the read path Boris Brezillon
2018-07-16  9:00   ` [2/3] " Chris Packham
2018-07-16 16:10     ` Boris Brezillon
2018-07-16 20:55       ` Boris Brezillon
2018-07-16 22:42         ` Chris Packham [this message]
2018-07-17 11:41           ` Boris Brezillon
2018-07-17 21:27             ` Chris Packham
2018-07-17 21:31               ` Boris Brezillon
2018-07-18  7:25                 ` Miquel Raynal
2018-07-03 12:20 ` [PATCH 3/3] mtd: rawnand: micron: Get the actual number of bitflips Boris Brezillon
2018-07-08 21:48 ` [PATCH 0/3] " Miquel Raynal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afe826dcb4934dea9795541ee0385542@svr-chch-ex1.atlnz.lc \
    --to=chris.packham@alliedtelesis.co.nz \
    --cc=beanhuo@micron.com \
    --cc=boris.brezillon@bootlin.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.