Received: by 10.192.165.156 with SMTP id m28csp1667543imm; Thu, 12 Apr 2018 01:06:52 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+jWrv4KVCt5fGVTf8haJFhyf9lCOD8YxgKgS5nw8jk7xreTvQqI2FKM9Kbo3E3fQCQ+ekX X-Received: by 10.99.53.142 with SMTP id c136mr1367983pga.37.1523520412469; Thu, 12 Apr 2018 01:06:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523520412; cv=none; d=google.com; s=arc-20160816; b=vg86yyAunJFHuizBHSEALDb4XqdD1R9gMhbbkiErcfFITwsi3iWlvOHaYLjKQSZhFZ grs5K5Orkv4VgrQZtweVgAVjJTLG+Qc5T8makW4I1KDbZywj2m/GtzXBZdU0CKcPos4B No2UTL5k6c0vHnmnhS6JYGyJI7ns3tbi0H+TABAAqrMi+WIDGWB6kC65h/GyGJw49ige F1qV/WS0s0BMliKl24ZpamSXXsNmlPt5zqbhaNcu5+5d6VilXhExGBBhzLInvIsfQBSi 24Olo1x8ftFQcopyj1gpQU27GzgF0C6oSYdSzpQ3E9aNZbujiC7uWQx05gYYjmP3UMdB Ud9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=yjWHs3diBpa4hMM5pjeCqEiNYAJwrqXWUSxVC28599c=; b=l5+6kUljCBoDaT0cHJ2IDR2iwuyznKse48XbQwrve11MY5gT1PjJQHcE0wFwxsWaGt PX5w0TXd6ijTEuLCp2UuNsqlpdhdwbLfacW/QCjtHDpDkVk7itGHOnDWPJdcn2bachc4 rJw9sts06ouBrsj0+9wubk7BFMPywe+DWaYmYusv33CwhFbtoXRVizHauVfXUlTNBLGF OSAMpB3+DenabVSSxF4qcxUt/Mrp3zBAbW+01NYcbcVm/GdS0XKpi8FmtAHIbl9EHX2F 1GIm6bgxbefUN2X2kfh9zNEo/MlTV0Dn/4tEdYy8keJdwcnchbukY9DGXO5iompT68ar RaRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QCxsUGf8; dkim=pass header.i=@codeaurora.org header.s=default header.b=huHOcnRz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f2si1895580pgn.320.2018.04.12.01.06.14; Thu, 12 Apr 2018 01:06:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=QCxsUGf8; dkim=pass header.i=@codeaurora.org header.s=default header.b=huHOcnRz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752840AbeDLIBA (ORCPT + 99 others); Thu, 12 Apr 2018 04:01:00 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:52780 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752810AbeDLIA7 (ORCPT ); Thu, 12 Apr 2018 04:00:59 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 90EED60FB1; Thu, 12 Apr 2018 08:00:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523520058; bh=XDYDGT4W/xsYiHcOCwilIR8YldUrypn3AqmDq/wKc+U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QCxsUGf8LtruAzwJYU3RImFaOrAxyV2+ihbNDi3tKxh/9kAVHE9FoLXuvsjzC3Wpt wewf/KIwD/HR6qTuqAdlewExOuZ7P/jQVCqJtZqQeagKrayDUyWzh0zI9Iy8titnI2 vaYftdOMgvL4IIE56mX81XDGT0fkkSgf2hI9gIOs= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 794A660F5F; Thu, 12 Apr 2018 08:00:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1523520056; bh=XDYDGT4W/xsYiHcOCwilIR8YldUrypn3AqmDq/wKc+U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=huHOcnRzJECyD5rzKlponsbjK97w/H9JLWCnGef/Eq5D2xvyN+Vkr4pXb9efFvUiL qXBKtxxGW78qE+fsQaV6elOOpASbNz/+7bxxeIQ58JLDU/Rg6ngJW6Qiq0D1JlPI7h 0edUaXBlj40ChXjHhcH+31UtUT31EMx3QB2WW0h8= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 12 Apr 2018 13:30:56 +0530 From: Abhishek Sahu To: Miquel Raynal Cc: Boris Brezillon , Archit Taneja , Richard Weinberger , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Vasut , linux-mtd@lists.infradead.org, Cyrille Pitchen , Andy Gross , Brian Norris , David Woodhouse Subject: Re: [PATCH 9/9] mtd: nand: qcom: erased page bitflips detection In-Reply-To: <20180410123003.34f4cfaa@xps13> References: <1522845745-6624-1-git-send-email-absahu@codeaurora.org> <1522845745-6624-10-git-send-email-absahu@codeaurora.org> <20180410123003.34f4cfaa@xps13> Message-ID: X-Sender: absahu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-04-10 16:00, Miquel Raynal wrote: > Hi Abhishek, > > On Wed, 4 Apr 2018 18:12:25 +0530, Abhishek Sahu > wrote: > >> Some of the newer nand parts can have bit flips in an erased >> page due to the process technology used. In this case, qpic > > AFAIK, this has always been possible, it was just rare. > Yes Miquel. It was rare earlier. Now, we are observing this more for newer parts coming. >> nand controller is not able to identify that page as an erased >> page. Currently the driver calls nand_check_erased_ecc_chunk for >> identifying the erased pages but this won’t work always since the >> checking is being with ECC engine returned data. In case of >> bitflips, the ECC engine tries to correct the data and then it >> generates the uncorrectable error. Now, this data is not equal to >> original raw data. For erased CW identification, the raw data >> should be read again from NAND device and this >> nand_check_erased_ecc_chunk function should be called for raw >> data only. > > Absolutely. > >> >> Now following logic is being added to identify the erased >> codeword bitflips. >> >> 1. In most of the case, not all the codewords will have bitflips >> and only single CW will have bitflips. So, there is no need to >> read the complete raw page data. The NAND raw read can be >> scheduled for any CW in page. The NAND controller works on CW >> basis and it will update the status register after each CW read. >> Maintain the bitmask for the CW which generated the uncorrectable >> error. >> 2. Schedule the raw flash read from NAND flash device to >> NAND controller buffer for all these CWs between first and last >> uncorrectable errors CWs. Copy the content from NAND controller >> buffer to actual data buffer only for the uncorrectable errors >> CWs so that other CW data content won’t be affected, and >> unnecessary data copy can be avoided. > > In case of uncorrectable error, the penalty is huge anyway. > Yes. We can't avoid that. But we are reducing that by doing raw read for few subpages in which we got uncorrectale error. >> 3. Both DATA and OOB need to be checked for number of 0. The >> top-level API can be called with only data buf or oob buf so use >> chip->databuf if data buf is null and chip->oob_poi if >> oob buf is null for copying the raw bytes temporarily. > > You can do that. But when you do, you should tell the core you used > that buffer and that it cannot rely on what is inside. Please > invalidate the page cache with: > > chip->pagebuf = -1; > Thanks Miquel. I will check and update the patch. >> 4. For each CW, check the number of 0 in cw_data and usable >> oob bytes, The bbm and spare bytes bit flip won’t affect the ECC >> so don’t check the number of bitflips in this area. > > OOB is an area in which you are supposed to find the BBM, the ECC bytes > and the spare bytes. Spare bytes == usable OOB bytes. And the BBM > should be protected too. I don't get this sentence but I don't see its > application neither in the code? > QCOM NAND layout does not support the BBM ECC protection. IN OOB, For all the possible layouts (4 bit RS/4 bit BCH/8 bit BCH) it has 16 usable OOB bytes which is protected with ECC. All the bytes in OOB other than BBM, ECC bytes and usable OOB bytes are ununsed. You can refer qcom_nand_host_setup for layout detail. Thanks, Abhishek