From: Boris Brezillon <boris.brezillon@collabora.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Michal Simek <monstr@monstr.eu>,
Vignesh Raghavendra <vigneshr@ti.com>,
Tudor Ambarus <Tudor.Ambarus@microchip.com>,
Richard Weinberger <richard@nod.at>,
linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Naga Sureshkumar Relli <nagasure@xilinx.com>
Subject: Re: [PATCH 07/10] mtd: rawnand: Help supporting controllers that are not able to split operations
Date: Sat, 25 Apr 2020 11:11:05 +0200 [thread overview]
Message-ID: <20200425111105.4a5a7861@collabora.com> (raw)
In-Reply-To: <20200424173631.14311-8-miquel.raynal@bootlin.com>
On Fri, 24 Apr 2020 19:36:28 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> While performing any NAND operation is as simple as following the
> cores order and send "command", "address" and "data" cycles as
> provided in a list of instructions, certain controllers are "too
> clever" and are not able to split the sending of these cycles.
>
> Try to find out at boot time if the controller will be problematic and
> flag it. Additional changes will make use of this flag to workaround
> the capricious controllers by proposing "packed" operations as an
> alternative.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/raw/internals.h | 5 ++++
> drivers/mtd/nand/raw/nand_base.c | 44 ++++++++++++++++++++++++++++++++
> include/linux/mtd/rawnand.h | 8 ++++++
> 3 files changed, 57 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/internals.h b/drivers/mtd/nand/raw/internals.h
> index 9d0caadf940e..38898b8639ee 100644
> --- a/drivers/mtd/nand/raw/internals.h
> +++ b/drivers/mtd/nand/raw/internals.h
> @@ -130,6 +130,11 @@ static inline bool nand_has_setup_data_iface(struct nand_chip *chip)
> return true;
> }
>
> +static inline bool nand_pack_ops(struct nand_chip *chip)
> +{
> + return (chip->options & NAND_PACK_OPS);
> +}
> +
> /* BBT functions */
> int nand_markbad_bbt(struct nand_chip *chip, loff_t offs);
> int nand_isreserved_bbt(struct nand_chip *chip, loff_t offs);
> diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
> index 15a9189b2307..6e4eabb9dc11 100644
> --- a/drivers/mtd/nand/raw/nand_base.c
> +++ b/drivers/mtd/nand/raw/nand_base.c
> @@ -5031,6 +5031,44 @@ static int nand_dt_init(struct nand_chip *chip)
> return 0;
> }
>
> +/**
> + * nand_controller_needs_packed_op - Check the controller habilities to perform
> + * a set of split operations that the core is
> + * very likely to try. If one of them do not
> + * pass, then try to pack operations together.
> + * @chip: The NAND chip
> + *
> + * Returns @true if packing is needed, false otherwise.
> + */
> +static bool nand_controller_needs_packed_op(struct nand_chip *chip)
> +{
> + u8 tmp[8];
> + struct nand_op_instr data_in_instrs[] = {
> + NAND_OP_DATA_IN(8, tmp, 0),
> + };
> + struct nand_op_instr data_out_instrs[] = {
> + NAND_OP_DATA_OUT(8, tmp, 0),
> + };
> + struct nand_operation ops[] = {
> + NAND_OPERATION(0, data_in_instrs),
> + NAND_OPERATION(0, data_out_instrs),
> + };
> + int ret, i;
> +
> + if (!nand_has_exec_op(chip))
> + return false;
> +
> + for (i = 0; i < ARRAY_SIZE(ops); i++) {
> + ret = chip->controller->ops->exec_op(chip, &ops[i], true);
> + if (ret) {
> + pr_debug("Using ->exec_op() packed operations only\n");
> + return true;
> + }
> + }
Hm, I'm not sure that's enough to detect all weird cases that the
controller might support or not. The check should really be done on
actual operations with accurate sizes instead of using a randomly chosen
8byte data in/out pattern to decide whether all ops need to be
monolithic or not.
So, let's take a step back and analyze your use cases. You seem to have
3 here:
1/ read param page
2/ program page
3/ read page
For #1, we can just do the check before executing the operation because
it's only done once at init time (not in the read/write/erase path
where we care about perfs). For that one I'd suggest extending the
nand_read_param_page_op() function to take a check_only parameter and
doing the check directly in nand_{onfi,jedec}_detect().
For #2 and #3, I'd rather have per operation flags to pick the right
variant, but maybe a simpler option would be to add new helpers for
those monolithic read/write until we come up with a generic way to
determine which variants of each perf-sensitive sequences should be
used based on exec_op() checks.
int nand_monolithic_read_page_raw(struct nand_chip *chip, u8 *buf,
int oob_required, int page)
{
struct mtd_info *mtd = nand_to_mtd(chip);
unsigned int size = mtd->writesize;
u8 *read_buf = buf;
int ret;
if (oob_required) {
size += mtd->oobsize;
if (buf != chip->data_buf) {
chip->pagecache.page = -1;
read_buf = chip->data_buf;
}
}
ret = nand_read_page_op(chip, page, 0, read_buf, size);
if (ret)
return ret;
if (buf != read_buf)
memcpy(buf, read_buf, mtd->writesize)
return 0;
}
int nand_monolithic_write_page_raw(struct nand_chip *chip, const u8 *buf,
int oob_required, int page)
{
struct mtd_info *mtd = nand_to_mtd(chip);
unsigned int size = mtd->writesize;
const u8 *write_buf = buf;
int ret;
if (oob_required) {
size += mtd->oobsize;
if (buf != chip->data_buf) {
chip->pagecache.page = -1;
memcpy(chip->data_buf, buf, mtd->writesize);
write_buf = chip->data_buf;
}
}
return nand_prog_page_op(chip, page, 0, write_buf, size);
}
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2020-04-25 9:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-24 17:36 [PATCH 00/10] Supporting restricted NAND controllers Miquel Raynal
2020-04-24 17:36 ` [PATCH 01/10] mtd: rawnand: Translate obscure bitfields into readable macros Miquel Raynal
2020-04-25 8:33 ` Boris Brezillon
2020-04-28 9:46 ` Miquel Raynal
2020-04-24 17:36 ` [PATCH 02/10] mtd: rawnand: Reorder the nand_chip->options flags Miquel Raynal
2020-04-25 8:36 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 03/10] mtd: rawnand: Rename a NAND chip option Miquel Raynal
2020-04-25 8:39 ` Boris Brezillon
2020-04-28 12:05 ` Miquel Raynal
2020-04-24 17:36 ` [PATCH 04/10] mtd: rawnand: Fix comments about the use of bufpoi Miquel Raynal
2020-04-25 8:40 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 05/10] mtd: rawnand: Rename the use_bufpoi variables Miquel Raynal
2020-04-25 8:44 ` Boris Brezillon
2020-04-28 9:05 ` Miquel Raynal
2020-04-28 9:11 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 06/10] mtd: rawnand: Avoid indirect access to ->data_buf() Miquel Raynal
2020-04-25 8:45 ` Boris Brezillon
2020-04-24 17:36 ` [PATCH 07/10] mtd: rawnand: Help supporting controllers that are not able to split operations Miquel Raynal
2020-04-25 9:11 ` Boris Brezillon [this message]
2020-04-24 17:36 ` [PATCH 08/10] mtd: rawnand: onfi: Add an alternative parameter page read Miquel Raynal
2020-04-24 17:36 ` [PATCH 09/10] mtd: rawnand: jedec: " Miquel Raynal
2020-04-24 17:36 ` [PATCH 10/10] mtd: rawnand: Fallback on easier operations when needed 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=20200425111105.4a5a7861@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=Tudor.Ambarus@microchip.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=monstr@monstr.eu \
--cc=nagasure@xilinx.com \
--cc=richard@nod.at \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).