From: Abhishek Sahu <absahu@codeaurora.org>
To: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, Andy Gross <andy.gross@linaro.org>
Subject: Re: [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function
Date: Fri, 20 Jul 2018 17:46:38 +0530 [thread overview]
Message-ID: <7ab0be154272b71f9beb2a7fb830c7be@codeaurora.org> (raw)
In-Reply-To: <20180718234358.6bb5e8a0@bbrezillon>
Hi Boris,
On 2018-07-19 03:13, Boris Brezillon wrote:
> On Wed, 18 Jul 2018 23:23:50 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
>> Boris,
>>
>> Can you please check the change in qcom_nandc_write_oob() is
>> valid? I think it is but as this is a bit of a hack I prefer double
>> checking.
>
> Indeed, it's hack-ish.
>
>>
>> Thanks,
>> Miquèl
>>
>>
>> Abhishek Sahu <absahu@codeaurora.org> wrote on Fri, 6 Jul 2018
>> 13:21:56 +0530:
>>
>> > The NAND base layer calls write_oob() by setting bytes at
>> > chip->badblockpos with value non 0xFF for updating bad block status.
>> > The QCOM NAND controller skips the bad block bytes while doing normal
>> > write with ECC enabled. When initial support for this driver was
>> > added, the driver specific function was added temporarily for
>> > block_markbad() with assumption to change for raw read in NAND base
>> > layer. Moving to raw read for block_markbad() seems to take more time
>> > so this patch removes driver specific block_markbad() function by
>> > using following HACK in write_oob() function.
>> >
>> > Check for BBM bytes in OOB and accordingly do raw write for updating
>> > BBM bytes in NAND flash or normal write for updating available OOB
>> > bytes.
>
> Why don't we change that instead of patching the qcom driver to guess
> when the core tries to mark a block bad? If you're afraid of breaking
> existing drivers that might rely on the "write/read BBM in non-raw
> mode" solution (I'm sure some drivers are), you can always add a new
> flag in chip->options (NAND_ACCESS_BBM_IN_RAW_MODE) and only use raw
> accessors when this flag is set.
>
We started with that Only
http://patchwork.ozlabs.org/patch/508565/
and since we didn't conclude, we went for driver
specific bad block check and mark bad block functions.
Now, we wanted to get rid of driver specific functions
1. For bad block check, we found the way to get the BBM bytes
with ECC read. Controller updates BBM in separate register
which we can read and update the same in OOB. Patch #1 of
series does the same.
2. For bad block mark, there is no way to update in ECC mode
that's why we went for HACK to get rid of driver specific
function.
If adding flag is fine now then this HACK won't be required.
Moving to RAW mode for every one still looks risky.
Thanks,
Abhishek
next prev parent reply other threads:[~2018-07-20 12:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-06 7:51 [PATCH 0/5] Update for removing driver specific BBM functions Abhishek Sahu
2018-07-06 7:51 ` [PATCH 1/5] mtd: rawnand: qcom: remove driver specific bad block check function Abhishek Sahu
2018-07-06 7:51 ` [PATCH 2/5] mtd: rawnand: qcom: remove driver specific block_markbad function Abhishek Sahu
2018-07-18 21:23 ` Miquel Raynal
2018-07-18 21:43 ` Boris Brezillon
2018-07-20 12:16 ` Abhishek Sahu [this message]
2018-07-20 13:03 ` Boris Brezillon
2018-11-04 15:56 ` Boris Brezillon
2018-11-09 6:18 ` Abhishek Sahu
2018-07-06 7:51 ` [PATCH 3/5] mtd: rawnand: qcom: fix NAND register write errors Abhishek Sahu
2018-07-06 7:51 ` [PATCH 4/5] mtd: rawnand: qcom: update BBT related flags Abhishek Sahu
2018-07-18 21:15 ` Miquel Raynal
2018-07-18 21:36 ` Boris Brezillon
2018-07-18 21:41 ` Miquel Raynal
2018-07-18 21:42 ` Miquel Raynal
2018-07-20 7:14 ` Abhishek Sahu
2018-07-06 7:51 ` [PATCH 5/5] mtd: rawnand: qcom: reorganization by removing read/write helpers Abhishek Sahu
2018-07-18 21:29 ` Miquel Raynal
2018-07-18 21:54 ` Boris Brezillon
2018-07-28 10:20 ` 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=7ab0be154272b71f9beb2a7fb830c7be@codeaurora.org \
--to=absahu@codeaurora.org \
--cc=andy.gross@linaro.org \
--cc=boris.brezillon@bootlin.com \
--cc=computersforpeace@gmail.com \
--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).