Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2013838imm; Sun, 27 May 2018 23:13:56 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIEYZhbuhAVqNhIzLD5cdweb2J7RYAqQHvp5XE5gEzUgzL0H7xOQ//beWqJ8BJw+fn/cOD1 X-Received: by 2002:a17:902:bd93:: with SMTP id q19-v6mr3813600pls.342.1527488035976; Sun, 27 May 2018 23:13:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527488035; cv=none; d=google.com; s=arc-20160816; b=kPeccMRtTJESq3CJ9pJfxOt1jCIhoymO0Yr9aVHM695EGwe85AyFI9Xq+SDOkY1c9H sdN7THr8WeQ5tJU6lqeLoSYJ41slgfsq499M6AXMkr8V7lYeeMR1Z/OBIVekYV3UZXyT U+CfbHAv2Mnhn4C6DxUJnGqIpcm/MZLN0g6hhRZPzrvcAHTaPezuJfZC7+BK0aqpjKDk sBXQ58fFrsxAXREYrMsa9A5M4lVC+OBpQUSVWjzhqWMag8S6oLvd5fJJrmzcNeSImxda mLtNnJbUXDJeg33IXtBcBpzq0uGjNaxxUcJ0YF1Ab8DdY1fiWAsN6rYcekA9fIKjDUH4 Xj0g== 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=b6ExV6jd6b/bTppMqRjO1sX3GtjlQH90ViYKI91E81c=; b=RZykQLIPD9a+WEjYeyCqHXBYx9CTCN+OIORlpllWL5SJIXldore/qBg1KSAhsiMXei aI+/r4obwYuANdSPlFTekmckZ9hBjARPf7uFXxKreENliBJeQMWxuujmJqfHmJozpzhW L6S0+UDmm6zw1vGJsFRfZ25Be6M1VPwt3Nk/H8yg2muGXVG5H67V0+k2ljxRXZCd5HjO MJK8+M330rLDds3KoUzMqHRe1rDhqjOVHjXOhEYI3wuttCeYIqCXLVe+7p7Jhothwlrk 9sY9wG28Lgqy/3ZV/S5m90mKp9NybL0v6fFpmDtFc4fKXYrPUgvv+XsJpjsHvO8TwB0W 8s4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=L1FYPjlv; dkim=pass header.i=@codeaurora.org header.s=default header.b=cwHoPThu; 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 z23-v6si30443273plo.492.2018.05.27.23.13.41; Sun, 27 May 2018 23:13:55 -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=L1FYPjlv; dkim=pass header.i=@codeaurora.org header.s=default header.b=cwHoPThu; 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 S1753409AbeE1GNP (ORCPT + 99 others); Mon, 28 May 2018 02:13:15 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:33106 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751785AbeE1GM7 (ORCPT ); Mon, 28 May 2018 02:12:59 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 2C03460ACA; Mon, 28 May 2018 06:12:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527487979; bh=CNPYDw0x8w+zVBeJafloNhwUvdR4jWI8PTXkJq7sS4U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=L1FYPjlvSmMJHAo27gIdjpIM6juH6LUJfJdrTBOBJDMApShTAQfmMBo3P+NFfrh5n 2blJfVjtWKA8i/ibX20W1XpfIzbw4UOl70J8YCNBkPZGB2n8tuV15YlTnr3Zty36ty zTF7aqt1KZOZLpCFM9+TOpOCqKwZvjmKdO4hUIz0= 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 ABFC1601D7; Mon, 28 May 2018 06:12:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527487977; bh=CNPYDw0x8w+zVBeJafloNhwUvdR4jWI8PTXkJq7sS4U=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cwHoPThuhfiTLy5iI+VPIPK5hPm6Mn9yh3xQvU8aPjFCNJAYoZRaihfAT5RnxaJym IQWH7ycZgMw4fPlmh6yaARMXikpi07lLtGw7DosnMsj0KzzKGF7UiW8ngatjD1a1Fc lJgLWw3sFz6V5LqLWjxWdax2HesBr0LjKzderH8g= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 28 May 2018 11:42:57 +0530 From: Abhishek Sahu To: Miquel Raynal 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 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check In-Reply-To: <20180526104629.74315561@xps13> References: <1527250904-21988-1-git-send-email-absahu@codeaurora.org> <1527250904-21988-14-git-send-email-absahu@codeaurora.org> <20180526104629.74315561@xps13> Message-ID: <90ae248edf8a06a1d35e2da458f75af5@codeaurora.org> 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-05-26 14:16, Miquel Raynal wrote: > Hi Abhishek, > > On Fri, 25 May 2018 17:51:41 +0530, Abhishek Sahu > wrote: > >> The QCOM NAND controller layout is such that, the bad block byte >> offset for last codeword will come to first byte in spare area. > > "is the first spare byte"? > > >> Currently, the raw read for last codeword is being done with >> copy_last_cw function. It does following 2 things: > > "It does the following:" > >> >> 1. Read the last codeword bytes from NAND chip to NAND >> controller internal HW buffer. >> 2. Copy all these bytes from HW buffer to actual buffer. >> >> For bad block check, maximum two bytes are required so instead of >> copying the complete bytes in step 2, only those bbm_size bytes >> can be copied. >> >> This patch does minor code reorganization for the same. After >> this, copy_last_cw function won’t be required. > > "This patch does minor code reorganization to just retrieve these two > bytes when checking for bad blocks, allowing to remove > copy_last_cw() now useless." > Thanks Miquel. I will update all these. >> >> Signed-off-by: Abhishek Sahu >> --- >> * Changes from v2: >> 1. Changed commit message and comments slightly >> >> * Changes from v1: >> NEW CHANGE >> >> drivers/mtd/nand/raw/qcom_nandc.c | 66 >> +++++++++++++++------------------------ >> 1 file changed, 25 insertions(+), 41 deletions(-) >> >> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c >> b/drivers/mtd/nand/raw/qcom_nandc.c >> index d693b5f..f72bc8a 100644 >> --- a/drivers/mtd/nand/raw/qcom_nandc.c >> +++ b/drivers/mtd/nand/raw/qcom_nandc.c >> @@ -1769,41 +1769,6 @@ static int read_page_ecc(struct qcom_nand_host >> *host, u8 *data_buf, >> return parse_read_errors(host, data_buf_start, oob_buf_start); >> } >> >> -/* >> - * a helper that copies the last step/codeword of a page (containing >> free oob) >> - * into our local buffer >> - */ >> -static int copy_last_cw(struct qcom_nand_host *host, int page) >> -{ >> - struct nand_chip *chip = &host->chip; >> - struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip); >> - struct nand_ecc_ctrl *ecc = &chip->ecc; >> - int size; >> - int ret; >> - >> - clear_read_regs(nandc); >> - >> - size = host->use_ecc ? host->cw_data : host->cw_size; >> - >> - /* prepare a clean read buffer */ >> - memset(nandc->data_buffer, 0xff, size); >> - >> - set_address(host, host->cw_size * (ecc->steps - 1), page); >> - update_rw_regs(host, 1, true); >> - >> - config_nand_single_cw_page_read(nandc); >> - >> - read_data_dma(nandc, FLASH_BUF_ACC, nandc->data_buffer, size, 0); >> - >> - ret = submit_descs(nandc); >> - if (ret) >> - dev_err(nandc->dev, "failed to copy last codeword\n"); >> - >> - free_descs(nandc); >> - >> - return ret; >> -} >> - >> /* implements ecc->read_page() */ >> static int qcom_nandc_read_page(struct mtd_info *mtd, struct >> nand_chip *chip, >> uint8_t *buf, int oob_required, int page) >> @@ -2118,6 +2083,7 @@ static int qcom_nandc_block_bad(struct mtd_info >> *mtd, loff_t ofs) >> struct nand_ecc_ctrl *ecc = &chip->ecc; >> int page, ret, bbpos, bad = 0; >> u32 flash_status; >> + u8 *bbm_bytes_buf = chip->data_buf; >> >> page = (int)(ofs >> chip->page_shift) & chip->pagemask; >> >> @@ -2128,11 +2094,31 @@ static int qcom_nandc_block_bad(struct >> mtd_info *mtd, loff_t ofs) >> * that contains the BBM >> */ >> host->use_ecc = false; >> + bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1); > > Are we sure there is no layout with only 1 step? All the layouts are such that, the BBM will come in first byte of spare area. For 4 bit ECC, the cw_size is 528 so for 2K page 2048 - 528 * 3 = 464 So for last CW, the 464 is BBM (i.e 2048th byte) in full page. > >> >> clear_bam_transaction(nandc); >> - ret = copy_last_cw(host, page); >> - if (ret) >> + clear_read_regs(nandc); >> + >> + set_address(host, host->cw_size * (ecc->steps - 1), page); >> + update_rw_regs(host, 1, true); >> + >> + /* >> + * The last codeword data will be copied from NAND device to NAND >> + * controller internal HW buffer. Copy only required BBM size bytes >> + * from this HW buffer to bbm_bytes_buf which is present at >> + * bbpos offset. >> + */ >> + nandc_set_read_loc(nandc, 0, bbpos, host->bbm_size, 1); >> + config_nand_single_cw_page_read(nandc); >> + read_data_dma(nandc, FLASH_BUF_ACC + bbpos, bbm_bytes_buf, >> + host->bbm_size, 0); >> + >> + ret = submit_descs(nandc); >> + free_descs(nandc); >> + if (ret) { >> + dev_err(nandc->dev, "failed to copy bad block bytes\n"); >> goto err; >> + } >> >> flash_status = le32_to_cpu(nandc->reg_read_buf[0]); >> >> @@ -2141,12 +2127,10 @@ static int qcom_nandc_block_bad(struct >> mtd_info *mtd, loff_t ofs) >> goto err; >> } >> >> - bbpos = mtd->writesize - host->cw_size * (ecc->steps - 1); >> - >> - bad = nandc->data_buffer[bbpos] != 0xff; >> + bad = bbm_bytes_buf[0] != 0xff; > > This is suspect as it still points to the beginning of the data buffer. > Can you please check you did not meant bbm_bytes_buf[bbpos]? > The main thing here is nandc_set_read_loc(nandc, 0, bbpos, host->bbm_size, 1); After reading one complete CW from NAND, the data will be still in NAND HW buffer. The above register tells that we need to read data from bbpos of size host->bbm_size (which is 1 byte for 8 bus witdh and 2 byte for 16 bus width) in bbm_bytes_buf. So bbm_bytes_buf[0] will contain the BBM first byte. and bbm_bytes_buf[1] will contain the BBM second byte. Regards, Abhishek >> >> if (chip->options & NAND_BUSWIDTH_16) >> - bad = bad || (nandc->data_buffer[bbpos + 1] != 0xff); >> + bad = bad || (bbm_bytes_buf[1] != 0xff); >> err: >> return bad; >> } > > > Thanks, > Miquèl