From: Roger Quadros <rogerq@ti.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>,
Tony Lindgren <tony@atomide.com>
Cc: <javier@dowhile0.org>, <fcooper@ti.com>, <nsekhar@ti.com>,
<linux-mtd@lists.infradead.org>, <linux-omap@vger.kernel.org>,
<computersforpeace@gmail.com>, <dwmw2@infradead.org>,
<ezequiel@vanguardiasur.com.ar>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms
Date: Mon, 18 Apr 2016 15:52:58 +0300 [thread overview]
Message-ID: <5714D8AA.9040304@ti.com> (raw)
In-Reply-To: <5714D3A4.2050405@ti.com>
On 18/04/16 15:31, Roger Quadros wrote:
> On 16/04/16 11:57, Boris Brezillon wrote:
>> On Fri, 15 Apr 2016 09:19:51 -0700
>> Tony Lindgren <tony@atomide.com> wrote:
>>
>>>
>>>> Or should I just pull this immutable branch in my current nand/next and
>>>> let you pull the same immutable branch in omap-soc. I mean, would this
>>>> prevent conflicts when our branches are merged into linux-next, no
>>>> matter the order.
>>>
>>> Ideally just one or more branches with just minimal changes in
>>> them against -rc1. But you may have other dependencies in
>>> your NAND tree so that may no longer be doable :) Usually if
>>> I merge something that may need to get merged into other
>>> branches, I just apply them into a separate branch against -rc1
>>> to start with, then merge that branch in.
>>
>> Okay, in this case, that's pretty much what I did from the beginning,
>> except the immutable branch was provided by Roger (based on 4.6-rc1).
>> Thanks for this detailed explanation, I'll try to remember that when
>> I'll need to provide an immutable branch for another subsystem.
>>
>> Roger, my request remains, could you check/test my conflict resolution
>> (branch nand/next-with-gpmc-rework)?
>
> I couldn't test that branch yet as nand/next is broken on omap platforms
> (at least on dra7-evm).
>
> The commit where it breaks is:
> a662ef4 mtd: nand: omap2: use mtd_ooblayout_xxx() helpers where appropriate
>
> I'm trying to figure out what went wrong there. Failure log below.
OK. I was able to fix it when at commit a662ef4 with the below patch.
Looks like we need to read exactly the ECC bytes through the ECC engine and not
the entire OOB region.
--cheers,
-oger
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index e622a1b..46b61d2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1547,8 +1547,8 @@ static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
chip->read_buf(mtd, buf, mtd->writesize);
/* Read oob bytes */
- chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
- chip->read_buf(mtd, chip->oob_poi, mtd->oobsize);
+ chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize + chip->ecc.layout->eccpos[0], -1);
+ chip->read_buf(mtd, chip->oob_poi, chip->ecc.total);
/* Calculate ecc bytes */
chip->ecc.calculate(mtd, buf, ecc_calc);
next prev parent reply other threads:[~2016-04-18 12:53 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 10:08 [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Roger Quadros
2016-04-07 10:08 ` [PATCH v6 01/17] ARM: OMAP2+: gpmc: Add platform data Roger Quadros
2016-04-07 10:08 ` [PATCH v6 02/17] ARM: OMAP2+: gpmc: Add gpmc timings and settings to " Roger Quadros
2016-04-07 10:08 ` [PATCH v6 03/17] memory: omap-gpmc: Introduce GPMC to NAND interface Roger Quadros
2016-04-07 10:08 ` [PATCH v6 04/17] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status Roger Quadros
2016-04-07 10:08 ` [PATCH v6 05/17] memory: omap-gpmc: Implement IRQ domain for NAND IRQs Roger Quadros
2016-04-11 14:52 ` Rob Herring
2016-04-07 10:08 ` [PATCH v6 06/17] mtd: nand: omap: Use gpmc_omap_get_nand_ops() to get NAND registers Roger Quadros
2016-04-07 10:08 ` [PATCH v6 07/17] mtd: nand: omap: Switch to using GPMC-NAND ops for writebuffer empty check Roger Quadros
2016-04-07 10:08 ` [PATCH v6 08/17] mtd: nand: omap: Copy platform data parameters to omap_nand_info data Roger Quadros
2016-04-07 10:08 ` [PATCH v6 09/17] mtd: nand: omap: Clean up device tree support Roger Quadros
2016-04-07 10:08 ` [PATCH v6 10/17] mtd: nand: omap: Update DT binding documentation Roger Quadros
2016-04-07 10:08 ` [PATCH v6 11/17] memory: omap-gpmc: Prevent mapping into 1st 16MB Roger Quadros
2016-04-07 10:08 ` [PATCH v6 12/17] memory: omap-gpmc: Move device tree binding to correct location Roger Quadros
2016-04-07 10:08 ` [PATCH v6 13/17] memory: omap-gpmc: Support general purpose input for WAITPINs Roger Quadros
2016-04-11 15:00 ` Rob Herring
2016-04-07 10:08 ` [PATCH v6 14/17] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring Roger Quadros
2016-04-07 10:08 ` [PATCH v6 15/17] memory: omap-gpmc: Support WAIT pin edge interrupts Roger Quadros
2016-04-11 15:03 ` Rob Herring
2016-04-07 10:08 ` [PATCH v6 16/17] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs Roger Quadros
2016-04-07 10:08 ` [PATCH v6 17/17] mtd: nand: omap2: Implement NAND ready using gpiolib Roger Quadros
2016-04-11 15:04 ` Rob Herring
2016-04-13 21:25 ` [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms Tony Lindgren
2016-04-15 9:34 ` Roger Quadros
2016-04-15 10:09 ` Boris Brezillon
2016-04-15 10:54 ` Roger Quadros
2016-04-15 11:12 ` Boris Brezillon
2016-04-15 11:51 ` Boris Brezillon
2016-04-15 15:41 ` Tony Lindgren
2016-04-15 16:05 ` Boris Brezillon
2016-04-15 16:19 ` Tony Lindgren
2016-04-16 8:57 ` Boris Brezillon
2016-04-18 12:31 ` Roger Quadros
2016-04-18 12:52 ` Roger Quadros [this message]
2016-04-18 13:13 ` Boris Brezillon
2016-04-18 13:48 ` Roger Quadros
2016-04-18 14:10 ` Boris Brezillon
2016-04-18 14:39 ` Roger Quadros
2016-04-18 14:57 ` Boris Brezillon
2016-04-19 12:46 ` Roger Quadros
2016-04-19 12:50 ` Boris Brezillon
2016-04-19 20:11 ` Boris Brezillon
2016-04-20 8:58 ` Roger Quadros
2016-04-20 14:45 ` Tony Lindgren
2016-04-19 13:22 ` Boris Brezillon
2016-04-19 14:26 ` Roger Quadros
2016-04-19 14:49 ` Roger Quadros
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=5714D8AA.9040304@ti.com \
--to=rogerq@ti.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=ezequiel@vanguardiasur.com.ar \
--cc=fcooper@ti.com \
--cc=javier@dowhile0.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=tony@atomide.com \
/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).