From: Richard Weinberger <richard@nod.at>
To: Ben Shelton <ben.shelton@ni.com>,
dwmw2@infradead.org, computersforpeace@gmail.com,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
dedekind1@gmail.com
Cc: Jeff Westfahl <jeff.westfahl@ni.com>
Subject: Re: [PATCH 2/3] mtd: nand: implement 'max_bad_blocks' mtd function
Date: Thu, 14 May 2015 11:43:03 +0200 [thread overview]
Message-ID: <55546E27.6000909@nod.at> (raw)
In-Reply-To: <1431357596-29959-3-git-send-email-ben.shelton@ni.com>
Am 11.05.2015 um 17:19 schrieb Ben Shelton:
> From: Jeff Westfahl <jeff.westfahl@ni.com>
>
> Implement the new mtd function 'max_bad_blocks'. Use the "bad blocks
> maximum per LUN" field in the ONFI parameter page to find the maximum
> number of bad blocks to reserve for an MTD, taking into account the
> number of LUNs in the NAND device and how many LUNs the MTD spans.
>
> From the ONFI 1.0 spec: "This field contains the maximum number of
> blocks that may be defective at manufacture and over the life of the
> device per LUN. The maximum rating assumes that the host is following
> the block endurance requirements and the ECC requirements reported in
> the parameter page."
>
> Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com>
> ---
> drivers/mtd/nand/nand_base.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index c2e1232..a97d08e 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2884,6 +2884,40 @@ static int nand_block_markbad(struct mtd_info *mtd, loff_t ofs)
> }
>
> /**
> + * nand_max_bad_blocks - [MTD Interface] Max number of bad blocks for an mtd
> + * @mtd: MTD device structure
> + * @ofs: offset relative to mtd start
> + * @len: length of mtd
> + */
> +static int nand_max_bad_blocks(struct mtd_info *mtd, loff_t ofs, size_t len)
> +{
> + struct nand_chip *chip = mtd->priv;
> + uint32_t part_start_block;
> + uint32_t part_end_block;
> + uint32_t part_start_lun;
> + uint32_t part_end_lun;
> +
> + /* ONFI is used to determine the maximum bad block count. */
> + if (!chip->onfi_version)
> + return -ENOTSUPP;
> +
> + /* Get the start and end of the partition in erase blocks. */
> + part_start_block = mtd_div_by_eb(ofs, mtd);
> + part_end_block = mtd_div_by_eb(len, mtd) + part_start_block - 1;
> +
> + /* Get the start and end LUNs of the partition. */
> + part_start_lun = part_start_block / chip->onfi_params.blocks_per_lun;
> + part_end_lun = part_end_block / chip->onfi_params.blocks_per_lun;
> +
> + /*
> + * Look up the bad blocks per unit and multiply by the number of units
> + * that the partition spans.
> + */
> + return chip->onfi_params.bb_per_lun *
> + (part_end_lun - part_start_lun + 1);
Hmm, doesn't that calculation assume that all bad blocks are uniformly distributed across
the whole chip?
Not sure if is a good idea to focus on the best case. Currently UBI assumes the worst case.
Thanks,
//richard
next prev parent reply other threads:[~2015-05-14 9:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 15:19 [PATCH 0/3] mtd: use ONFI bad blocks per LUN to calculate UBIFS bad PEB limit Ben Shelton
2015-05-11 15:19 ` [PATCH 1/3] mtd: introduce function max_bad_blocks Ben Shelton
2015-05-11 15:19 ` [PATCH 2/3] mtd: nand: implement 'max_bad_blocks' mtd function Ben Shelton
2015-05-14 9:43 ` Richard Weinberger [this message]
2015-05-11 15:19 ` [PATCH 3/3] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit Ben Shelton
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=55546E27.6000909@nod.at \
--to=richard@nod.at \
--cc=ben.shelton@ni.com \
--cc=computersforpeace@gmail.com \
--cc=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=jeff.westfahl@ni.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
/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.