From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH] mtd: rawnand: onfi: read parameter pages in one go
Date: Thu, 16 May 2024 10:13:50 +0200 [thread overview]
Message-ID: <20240516101350.78e5ee29@xps-13> (raw)
In-Reply-To: <20240514134140.1050141-1-s.hauer@pengutronix.de>
Hi Sascha,
s.hauer@pengutronix.de wrote on Tue, 14 May 2024 15:41:40 +0200:
> nand_read_data_op() is not supported by all NAND controllers.
> nand_change_read_column_op() is not supported or at least is hard to
> support by NAND controllers that use a different page layout than
> expected by the NAND core.
I'm sorry but RNDOUT is not so hard to support, and I know no NAND
controller without this feature (I think even the first mxc controller
supports it?). However, the command does not exist on small page NANDs
(512 bytes). TBH I have never seen such a device myself, so I wonder
how spread they still are.
What may not be supported however are the DATA_IN cycles.
> Instead of relying on these functions
> just read the three parameter pages in one go.
Bitflips in parameter pages are very rare, they are normally quite
robust. The proposed solution impacts *all* NANDs, because the I/O
chip speed is at its lowest. There is no reason in most cases to do
that.
I agree there is a problem with the patch I proposed and we need to
settle. And we simply cannot make RNDOUT calls randomly here as long as
we want to support small page NANDs.
I believe we should do something like:
nand_read_param_page_op(0)
if (corrupted) {
if (supported.datain)
data_in(); /* this is faster */
else
nand_read_param_page_op(1)
}
I'll try to draft something (also applies to the jedec discovery).
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Richard Weinberger <richard@nod.at>
Subject: Re: [PATCH] mtd: rawnand: onfi: read parameter pages in one go
Date: Thu, 16 May 2024 10:13:50 +0200 [thread overview]
Message-ID: <20240516101350.78e5ee29@xps-13> (raw)
In-Reply-To: <20240514134140.1050141-1-s.hauer@pengutronix.de>
Hi Sascha,
s.hauer@pengutronix.de wrote on Tue, 14 May 2024 15:41:40 +0200:
> nand_read_data_op() is not supported by all NAND controllers.
> nand_change_read_column_op() is not supported or at least is hard to
> support by NAND controllers that use a different page layout than
> expected by the NAND core.
I'm sorry but RNDOUT is not so hard to support, and I know no NAND
controller without this feature (I think even the first mxc controller
supports it?). However, the command does not exist on small page NANDs
(512 bytes). TBH I have never seen such a device myself, so I wonder
how spread they still are.
What may not be supported however are the DATA_IN cycles.
> Instead of relying on these functions
> just read the three parameter pages in one go.
Bitflips in parameter pages are very rare, they are normally quite
robust. The proposed solution impacts *all* NANDs, because the I/O
chip speed is at its lowest. There is no reason in most cases to do
that.
I agree there is a problem with the patch I proposed and we need to
settle. And we simply cannot make RNDOUT calls randomly here as long as
we want to support small page NANDs.
I believe we should do something like:
nand_read_param_page_op(0)
if (corrupted) {
if (supported.datain)
data_in(); /* this is faster */
else
nand_read_param_page_op(1)
}
I'll try to draft something (also applies to the jedec discovery).
Thanks,
Miquèl
next prev parent reply other threads:[~2024-05-16 8:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 13:41 [PATCH] mtd: rawnand: onfi: read parameter pages in one go Sascha Hauer
2024-05-14 13:41 ` Sascha Hauer
2024-05-16 8:13 ` Miquel Raynal [this message]
2024-05-16 8:13 ` Miquel Raynal
2024-05-16 9:58 ` Miquel Raynal
2024-05-16 9:58 ` Miquel Raynal
2024-05-16 11:48 ` Sascha Hauer
2024-05-16 11:48 ` Sascha Hauer
2024-05-16 13:09 ` Miquel Raynal
2024-05-16 13:09 ` 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=20240516101350.78e5ee29@xps-13 \
--to=miquel.raynal@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=s.hauer@pengutronix.de \
/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.