| Message ID | 1341389164-24409-2-git-send-email-shmulik.ladkani@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2012-07-04 at 11:06 +0300, Shmulik Ladkani wrote: > Introduce 'ubi->bad_peb_limit', which specifies an upper limit of PEBs > ubi expects to go bad. > Currently, it is initialized to a fixed percentage of total PEBs in the > ubi device (configurable via CONFIG_MTD_UBI_BEB_LIMIT). > > The 'bad_peb_limit' is intended to be used for calculating the amount of > PEBs ubi needs to reserve for bad eraseblock handling. > > Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> > --- > arch/arm/configs/sam9_l9260_defconfig | 1 + I've also amended the Kconfig text a tiny bit and dropped the defconfig changes - let's have them separately as a single patch at the end of the series.
On Wed, 18 Jul 2012 13:40:53 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote: > I've also amended the Kconfig text a tiny bit and dropped the defconfig > changes - let's have them separately as a single patch at the end of the > series. Wouldn't having the defconfig change as the last patch break things for those defconfigs that had explicitly set CONFIG_MTD_UBI_BEB_RESERVE other than the default? Meaning, if the one-before-last would be "kill CONFIG_MTD_UBI_BEB_RESERVE", then those defconfigs that had _explicitly_ set a BEB_RESERVE value, which do not YET set a BEB_LIMIT value, will have their BEB_LIMIT as the default - but they actually meant a specific value other than the default. This is why I tried to: - set the CONFIG_MTD_UBI_BEB_LIMIT in defconfigs as part of the commit which introduces this config (copy same value as their RESERVE config) - kill all CONFIG_MTD_UBI_BEB_RESERVE references from defconfigs as part of the commit which kills it Regards, Shmulik
On Thu, 2012-07-19 at 09:16 +0300, Shmulik Ladkani wrote: > On Wed, 18 Jul 2012 13:40:53 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote: > > I've also amended the Kconfig text a tiny bit and dropped the defconfig > > changes - let's have them separately as a single patch at the end of the > > series. > > Wouldn't having the defconfig change as the last patch break things for > those defconfigs that had explicitly set CONFIG_MTD_UBI_BEB_RESERVE > other than the default? OK, fair enough, but let's have it as a 2 separate patches anyway. It is not a big deal to first change the defconfig, and then actually add the new option.
diff --git a/arch/arm/configs/sam9_l9260_defconfig b/arch/arm/configs/sam9_l9260_defconfig index ecf2531..f6917c9 100644 --- a/arch/arm/configs/sam9_l9260_defconfig +++ b/arch/arm/configs/sam9_l9260_defconfig @@ -40,6 +40,7 @@ CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_NAND_PLATFORM=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_BEB_RESERVE=3 +CONFIG_MTD_UBI_BEB_LIMIT=3 CONFIG_MTD_UBI_GLUEBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y diff --git a/drivers/mtd/ubi/Kconfig b/drivers/mtd/ubi/Kconfig index 738ee8d..8df256f 100644 --- a/drivers/mtd/ubi/Kconfig +++ b/drivers/mtd/ubi/Kconfig @@ -42,6 +42,17 @@ config MTD_UBI_BEB_RESERVE eraseblocks (e.g. NOR flash), this value is ignored and nothing is reserved. Leave the default value if unsure. +config MTD_UBI_BEB_LIMIT + int "Percentage of maximum expected bad eraseblocks" + default 2 + range 0 25 + help + This option specifies the maximum bad eraseblocks UBI expects on the + ubi device (percents of total number of flash eraseblocks). + If the underlying flash does not admit of bad eraseblocks (e.g. NOR + flash), this value is ignored. + Leave the default value if unsure. + config MTD_UBI_GLUEBI tristate "MTD devices emulation driver (gluebi)" help diff --git a/drivers/mtd/ubi/build.c b/drivers/mtd/ubi/build.c index 2c5ed5c..62cc6ce 100644 --- a/drivers/mtd/ubi/build.c +++ b/drivers/mtd/ubi/build.c @@ -607,8 +607,19 @@ static int io_init(struct ubi_device *ubi) ubi->peb_count = mtd_div_by_eb(ubi->mtd->size, ubi->mtd); ubi->flash_size = ubi->mtd->size; - if (mtd_can_have_bb(ubi->mtd)) + if (mtd_can_have_bb(ubi->mtd)) { ubi->bad_allowed = 1; + if (CONFIG_MTD_UBI_BEB_LIMIT > 0) { + int percent = CONFIG_MTD_UBI_BEB_LIMIT; + int beb_limit; + + beb_limit = mult_frac(ubi->peb_count, percent, 100); + /* round it up */ + if (mult_frac(beb_limit, 100, percent) < ubi->peb_count) + beb_limit++; + ubi->bad_peb_limit = beb_limit; + } + } if (ubi->mtd->type == MTD_NORFLASH) { ubi_assert(ubi->mtd->writesize == 1); diff --git a/drivers/mtd/ubi/ubi.h b/drivers/mtd/ubi/ubi.h index a1a81c9..b5217ef 100644 --- a/drivers/mtd/ubi/ubi.h +++ b/drivers/mtd/ubi/ubi.h @@ -363,6 +363,7 @@ struct ubi_wl_entry; * @flash_size: underlying MTD device size (in bytes) * @peb_count: count of physical eraseblocks on the MTD device * @peb_size: physical eraseblock size + * @bad_peb_limit: top limit of expected bad physical eraseblocks * @bad_peb_count: count of bad physical eraseblocks * @good_peb_count: count of good physical eraseblocks * @corr_peb_count: count of corrupted physical eraseblocks (preserved and not @@ -410,6 +411,7 @@ struct ubi_device { int avail_pebs; int beb_rsvd_pebs; int beb_rsvd_level; + int bad_peb_limit; int autoresize_vol_id; int vtbl_slots;
Introduce 'ubi->bad_peb_limit', which specifies an upper limit of PEBs ubi expects to go bad. Currently, it is initialized to a fixed percentage of total PEBs in the ubi device (configurable via CONFIG_MTD_UBI_BEB_LIMIT). The 'bad_peb_limit' is intended to be used for calculating the amount of PEBs ubi needs to reserve for bad eraseblock handling. Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com> --- arch/arm/configs/sam9_l9260_defconfig | 1 + drivers/mtd/ubi/Kconfig | 11 +++++++++++ drivers/mtd/ubi/build.c | 13 ++++++++++++- drivers/mtd/ubi/ubi.h | 2 ++ 4 files changed, 26 insertions(+), 1 deletions(-)