From: Abhishek Sahu <absahu@codeaurora.org>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Boris Brezillon <boris.brezillon@bootlin.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, Andy Gross <andy.gross@linaro.org>,
Archit Taneja <architt@codeaurora.org>
Subject: Re: [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check
Date: Mon, 28 May 2018 15:40:52 +0530 [thread overview]
Message-ID: <53caff8799d30b6a81ac10f63a7c56c4@codeaurora.org> (raw)
In-Reply-To: <20180528090352.254022ed@xps13>
On 2018-05-28 12:33, Miquel Raynal wrote:
> Hi Abhishek,
>
>> >> /* 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
>
> My question was more about small page NANDs. But I suppose it works
> too if ecc->steps == 1.
>
Correct Miquel.
>>
>> 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.
>
> I see: idx 0 in bbm_bytes_buf is the data at offset bbpos. Then
> it's ok.
>
>>
>> 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);
>
> Sorry, my mistake, I did not see the above line.
>
> However, technically, the BBM could be located in the first, second or
> last page of the block. You should check the three of them are 0xFF
> before declaring the block is not bad.
>
> The more I look at the function, the more I wonder if you actually need
> it. Why does the generic nand_block_bad() implementation in the core
> do not fit?
The BBM bytes can be accessed in raw mode only for QCOM NAND
Contoller. We started with following patch for initial patches
http://patchwork.ozlabs.org/patch/508565/
I am also not very much sure, how can we go ahead now.
Ideally we need to use generic function only which
requires raw_read.
Thanks,
Abhishek
next prev parent reply other threads:[~2018-05-28 10:11 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 12:21 [PATCH v3 00/16] Update for QCOM NAND driver Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 01/16] mtd: rawnand: helper function for setting up ECC configuration Abhishek Sahu
2018-05-26 8:42 ` Miquel Raynal
2018-05-28 5:46 ` Abhishek Sahu
2018-06-07 12:37 ` Miquel Raynal
2018-06-11 9:16 ` Abhishek Sahu
2018-06-18 10:04 ` Miquel Raynal
2018-05-29 19:30 ` Boris Brezillon
2018-05-30 0:28 ` Masahiro Yamada
2018-05-30 6:21 ` Abhishek Sahu
2018-05-30 7:38 ` Masahiro Yamada
2018-05-30 8:53 ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 02/16] mtd: rawnand: denali: use helper function for ecc setup Abhishek Sahu
2018-05-27 9:26 ` Masahiro Yamada
2018-05-25 12:21 ` [PATCH v3 03/16] dt-bindings: qcom_nandc: make nand-ecc-strength optional Abhishek Sahu
2018-05-26 8:42 ` Miquel Raynal
2018-05-28 5:53 ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 04/16] dt-bindings: qcom_nandc: remove nand-ecc-step-size Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 05/16] mtd: rawnand: qcom: remove dt property nand-ecc-step-size Abhishek Sahu
2018-05-26 8:42 ` Miquel Raynal
2018-05-28 5:55 ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 06/16] mtd: rawnand: qcom: use the ecc strength from device parameter Abhishek Sahu
2018-05-26 8:43 ` Miquel Raynal
2018-05-28 6:01 ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 07/16] mtd: rawnand: qcom: wait for desc completion in all BAM channels Abhishek Sahu
2018-05-26 8:43 ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 08/16] mtd: rawnand: qcom: erased page detection for uncorrectable errors only Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 09/16] mtd: rawnand: qcom: fix null pointer access for erased page detection Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 10/16] mtd: rawnand: qcom: parse read errors for read oob also Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 11/16] mtd: rawnand: qcom: modify write_oob to remove read codeword part Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 12/16] mtd: rawnand: qcom: fix return value for raw page read Abhishek Sahu
2018-05-26 8:43 ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 13/16] mtd: rawnand: qcom: minor code reorganization for bad block check Abhishek Sahu
2018-05-26 8:46 ` Miquel Raynal
2018-05-28 6:12 ` Abhishek Sahu
2018-05-28 7:03 ` Miquel Raynal
2018-05-28 10:10 ` Abhishek Sahu [this message]
2018-06-07 12:53 ` Miquel Raynal
2018-06-11 13:22 ` Abhishek Sahu
2018-06-18 11:35 ` Miquel Raynal
2018-06-20 7:04 ` Abhishek Sahu
2018-05-26 8:58 ` Miquel Raynal
2018-05-28 6:16 ` Abhishek Sahu
2018-05-28 7:09 ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 14/16] mtd: rawnand: qcom: check for operation errors in case of raw read Abhishek Sahu
2018-05-26 8:58 ` Miquel Raynal
2018-05-25 12:21 ` [PATCH v3 15/16] mtd: rawnand: qcom: helper function for " Abhishek Sahu
2018-05-27 13:53 ` Miquel Raynal
2018-05-28 7:34 ` Abhishek Sahu
2018-06-07 12:43 ` Miquel Raynal
2018-06-11 9:19 ` Abhishek Sahu
2018-05-25 12:21 ` [PATCH v3 16/16] mtd: rawnand: qcom: erased page bitflips detection Abhishek Sahu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53caff8799d30b6a81ac10f63a7c56c4@codeaurora.org \
--to=absahu@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=architt@codeaurora.org \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).