From patchwork Tue May 26 10:21:46 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: simon polette X-Patchwork-Id: 27644 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bilbo.ozlabs.org (Postfix) with ESMTPS id BA9DCB7069 for ; Tue, 26 May 2009 20:27:38 +1000 (EST) Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1M8tnG-0002q1-SQ; Tue, 26 May 2009 10:22:02 +0000 Received: from mail-ew0-f173.google.com ([209.85.219.173]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1M8tn1-0002nL-OQ for linux-mtd@lists.infradead.org; Tue, 26 May 2009 10:21:54 +0000 Received: by ewy21 with SMTP id 21so3884382ewy.18 for ; Tue, 26 May 2009 03:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tisSuGJrlTqi2DBRxY0dc6ayxuG1TVNGjWtjETx0Ekg=; b=Z17aJT8SoMXydxiWU0p/PvOgtrsxiX7IMAjv5AQKLcI26eeDdXk7rIsCYMXsibSDjY K+b0uCj6krjHkou5xt0FF0MOoE3O+wsWs7RfU60DmRtfVYL9cIeIq/humqJKMoSQ+uqE id6pXO2cH+ytGiYJEmoEaAFGpQmVLmy8AdKBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fKMzJObO+VBE8l4IAW2gZQAr+Kg3HaiE03zhNWI7imqBMpv5kdPvaveUxnbgMFvtVo X9Q2KsZcINVYJPzKm9FraTd/LmMe/IhAodUMqsokiYBUEuJbQ1j8AqfJbqgiybj49J6N Q3DGQH7AtnNAwxrJaHvqroOEjDmd/jQlX6j04= MIME-Version: 1.0 Received: by 10.216.73.193 with SMTP id v43mr3169263wed.157.1243333306528; Tue, 26 May 2009 03:21:46 -0700 (PDT) In-Reply-To: <72795ccb0905260247p6c204cc4w78eaafd28ffc3cf8@mail.gmail.com> References: <72795ccb0905250844w13ed9798me95d70614050f676@mail.gmail.com> <1243323142.21646.129.camel@localhost.localdomain> <72795ccb0905260240q6389dd35j681dbe50a6d4990f@mail.gmail.com> <1243331031.21646.134.camel@localhost.localdomain> <72795ccb0905260247p6c204cc4w78eaafd28ffc3cf8@mail.gmail.com> Date: Tue, 26 May 2009 12:21:46 +0200 Message-ID: <72795ccb0905260321n3b4646brb9adc90425b5304b@mail.gmail.com> Subject: Re: [PATCH] mtd: Nand Atmel: add On Flash BBT support From: simon polette To: dedekind@infradead.org X-Spam-Score: 0.0 (/) Cc: Gregory CLEMENT , linux-mtd , linux-arm-kernel@lists.arm.linux.org.uk, spolette@adetelgroup.com X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org 2009/5/26 simon polette : > 2009/5/26 Artem Bityutskiy : >> On Tue, 2009-05-26 at 11:40 +0200, simon polette wrote: >>> 2009/5/26 Artem Bityutskiy : >>> > On Mon, 2009-05-25 at 17:44 +0200, simon polette wrote: >>> >> +config       MTD_NAND_ATMEL_FLASH_BBT >>> >> +     bool "Use On-Flash Bad Block Table" >>> >> +     depends on MTD_NAND_ATMEL >>> >> +     help >>> >> +       This enables the On-Flash BBT, which mean that the bad blocks >>> >> +       will be scanned one time then the BBT will be stored >>> >> +       in flash, so scanning Nand flash for bad blocks will be no more >>> >> +       necessary for the next boots. >>> >> + >>> > >>> > I do not think you need a config option for this. It should be >>> > a module parameter instead. >>> > >>> > -- >>> > Best regards, >>> > Artem Bityutskiy (Битюцкий Артём) >>> > >>> > >>> >>> Yes, good idea, but do you think that I can keep a config option to >>> define the default state of that param, it means doing something like >>> : >>> #ifdef CONFIG_MTD_NAND_ATMEL_FLASH_BBT >>> static int use_on_flash_bbt = 1; >>> #else >>> static int use_on_flash_bbt = 0; >>> #endif >>> module_param(use_on_flash_bbt, int, 0); >> >> I think it is generally bad idea if each nand driver will >> introduce a separate config option for this kind of stuff. >> >> You may always boot your kernel with something like >> atmel_nand.on_flash_bbt=1 in the kernel parameters. >> >> -- >> Best regards, >> Artem Bityutskiy (Битюцкий Артём) >> >> > > Ok, I asked this question cause it's what have been done in the nand > diskonchip driver. > I'll send you a new patch soon. > > Best regards, > > Simon Polette > Adeneo - Adetelgroup > So here is the new patch : Signed-off-by: Simon Polette --- drivers/mtd/nand/atmel_nand.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) @@ -47,6 +48,9 @@ #define no_ecc 0 #endif +static int on_flash_bbt = 0; +module_param(on_flash_bbt, int, 0); + /* Register access macros */ #define ecc_readl(add, reg) \ __raw_readl(add + ATMEL_ECC_##reg) @@ -465,6 +469,11 @@ static int __init atmel_nand_probe(struct platform_device *pdev) } } + if (on_flash_bbt) { + printk("atmel_nand: Use On Flash BBT\n"); + nand_chip->options |= NAND_USE_FLASH_BBT; + } + /* first scan to find the device and get the page size */ if (nand_scan_ident(mtd, 1)) { res = -ENXIO; diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 47a33ce..e113594 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -24,6 +24,7 @@ #include #include +#include #include #include #include Signed-off-by: Simon Polette