Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1431941imm; Sun, 27 May 2018 06:53:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoBStBYG54jJYA7cj3/UYk663nBKeyXfIZHdm4O3ZB5KlZMjS9GqGnBpAfNe5gwB9QxRdYV X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr7042738pls.237.1527429220342; Sun, 27 May 2018 06:53:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527429220; cv=none; d=google.com; s=arc-20160816; b=VQ4479sLSA9CTt6HveceMIEvPgj8PSH3Ox/sGMvyM0SHY5Ql4MDmjLRki4bQKE/vzz znZnS4kSexDY5NwlHfOjU1smM8V47099FWtstmqBGMm2YP8St7btb723f+I6MiE6V/zz s5qdrxVYYrPsdadwH/k82/ue8u1kldP5WCxpAsRZOzUoYEFvrrgRML2UxkvJb5KOBk6+ MpbDsvCwmoXTklQYrBOgz58pcUKS1xZ9xZw28NNlo7s700eLBoJaWbdH/HsUX7y3ZHoB RSfLLNE4sKt45b2/YkOUehOmcXmrhuUaItWZWO7Y5i6jam/eiU7CmrpYQor+PzK9ii2R F6Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=tgWiRhp3RASyrsK6X0rTxGZWctMajpoMToNVJ62CRIk=; b=HZX1LXSx90vWCAViNRzge4cWGw9mjMQjzN7zrskTfk/UcZfCZ0MXE97kkDSxnrtxJ7 dXlC7aDYQzdorKPbAJZIays18LDBIAPEEN+xdffGdcarH9mxL3JRpmELgMuTLytBU8R0 XQmVTk+wAHS/tNYkDv8a+js3o/veL3PcGKKmiMjFeJ3guksHKAuG6usICHewzbfvcFmx CO8aDM8Ib+95cRwiGe2OrExKCsXQyQZR5i70lWG0yfOjciKEuhS+bEEdUzXSmV5ZslZ2 gK6XXJktorpggnr/BAVsYlLlYPdnqJkgDGRaGmKUbsZAYjwkXC9HUtlJ4aHzlAXipTNB 8t/w== ARC-Authentication-Results: i=1; mx.google.com; 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 u70-v6si9031513pgc.376.2018.05.27.06.53.23; Sun, 27 May 2018 06:53:40 -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; 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 S1032625AbeE0NxR convert rfc822-to-8bit (ORCPT + 99 others); Sun, 27 May 2018 09:53:17 -0400 Received: from mail.bootlin.com ([62.4.15.54]:50709 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936400AbeE0NxP (ORCPT ); Sun, 27 May 2018 09:53:15 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id 5234E20750; Sun, 27 May 2018 15:53:14 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from xps13 (unknown [37.169.232.104]) by mail.bootlin.com (Postfix) with ESMTPSA id 35E952055A; Sun, 27 May 2018 15:53:13 +0200 (CEST) Date: Sun, 27 May 2018 15:53:11 +0200 From: Miquel Raynal To: Abhishek Sahu Cc: Boris Brezillon , David Woodhouse , Brian Norris , Marek Vasut , Richard Weinberger , Cyrille Pitchen , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org, Andy Gross , Archit Taneja Subject: Re: [PATCH v3 15/16] mtd: rawnand: qcom: helper function for raw read Message-ID: <20180527155311.4c05d7ab@xps13> In-Reply-To: <1527250904-21988-16-git-send-email-absahu@codeaurora.org> References: <1527250904-21988-1-git-send-email-absahu@codeaurora.org> <1527250904-21988-16-git-send-email-absahu@codeaurora.org> Organization: Bootlin X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Abhishek, On Fri, 25 May 2018 17:51:43 +0530, Abhishek Sahu wrote: > This patch does minor code reorganization for raw reads. > Currently the raw read is required for complete page but for > subsequent patches related with erased codeword bit flips > detection, only few CW should be read. So, this patch adds > helper function and introduces the read CW bitmask which > specifies which CW reads are required in complete page. > > Signed-off-by: Abhishek Sahu > --- > * Changes from v2: > NONE > > * Changes from v1: > 1. Included more detail in function comment > > drivers/mtd/nand/raw/qcom_nandc.c | 197 ++++++++++++++++++++++++-------------- > 1 file changed, 123 insertions(+), 74 deletions(-) > > diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c > index 87f900e..34143a4 100644 > --- a/drivers/mtd/nand/raw/qcom_nandc.c > +++ b/drivers/mtd/nand/raw/qcom_nandc.c > @@ -1588,6 +1588,127 @@ static int check_flash_errors(struct qcom_nand_host *host, int cw_cnt) > } > > /* > + * Helper to perform the page raw read operation. The read_cw_mask will be > + * used to specify the codewords (CW) for which the data should be read. The > + * single page contains multiple CW. > + * > + * Normally other NAND controllers store the data in main area and > + * ecc bytes in OOB area. So, if page size is 2048+64 then 2048 > + * data bytes will go in main area followed by ECC bytes. The QCOM NAND > + * controller follows different layout in which the data+OOB is internally > + * divided in 528/532 bytes CW and each CW contains 516 bytes followed by > + * ECC parity bytes for that CW. By this, 4 available OOB bytes per CW > + * will also be protected with ECC. > + * > + * For each CW read, following are the 2 steps: > + * 1. Read the codeword bytes from NAND chip to NAND controller internal HW > + * buffer. > + * 2. Copy all these bytes from this HW buffer to actual buffer. > + * > + * Sometime, only few CW data is required in complete page. The read_cw_mask > + * specifies which CW in a page needs to be read. Start address will be > + * determined with this CW mask to skip unnecessary data copy from NAND > + * flash device. Then, actual data copy from NAND controller HW internal buffer > + * to data buffer will be done only for the CWs, which have the mask set. > + */ > +static int > +nandc_read_page_raw(struct mtd_info *mtd, struct nand_chip *chip, > + u8 *data_buf, u8 *oob_buf, > + int page, unsigned long read_cw_mask) Please prefix the helper with "qcom_nandc" > +{ > + struct qcom_nand_host *host = to_qcom_nand_host(chip); > + struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip); > + struct nand_ecc_ctrl *ecc = &chip->ecc; > + int i, ret; > + int read_loc, start_step, last_step; > + > + nand_read_page_op(chip, page, 0, NULL, 0); > + > + host->use_ecc = false; > + start_step = ffs(read_cw_mask) - 1; > + last_step = fls(read_cw_mask); > + > + clear_bam_transaction(nandc); > + set_address(host, host->cw_size * start_step, page); > + update_rw_regs(host, last_step - start_step, true); > + config_nand_page_read(nandc); > + > + for (i = start_step; i < last_step; i++) { This comment applies for both patches 15 and 16: I would really prefer having a qcom_nandc_read_cw_raw() that reads only one CW. From qcom_nandc_read_page_raw() you would loop over all the CW calling qcom_nandc_read_cw_raw() helper (it's raw reads, we don't care about performances) and from ->read_page_raw() you would check CW with uncorrectable errors for being blank with that helper. You would avoid the not-so-nice logic where you read all the CW between the first bad one and the last bad one. Thanks, Miquèl