From: Naga Sureshkumar Relli <nagasure@xilinx.com>
To: Helmut Grohne <helmut.grohne@intenta.de>
Cc: "bbrezillon@kernel.org" <bbrezillon@kernel.org>,
"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
"richard@nod.at" <richard@nod.at>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michal Simek <michals@xilinx.com>,
"nagasureshkumarrelli@gmail.com" <nagasureshkumarrelli@gmail.com>
Subject: RE: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Date: Fri, 29 Mar 2019 05:21:29 +0000 [thread overview]
Message-ID: <MWHPR02MB2623540BA389042E7795E071AF5A0@MWHPR02MB2623.namprd02.prod.outlook.com> (raw)
In-Reply-To: <20190328115106.i7ytk2uqno7i4h4u@laureti-dev>
Hi Helmut,
> -----Original Message-----
> From: Helmut Grohne <helmut.grohne@intenta.de>
> Sent: Thursday, March 28, 2019 5:21 PM
> To: Naga Sureshkumar Relli <nagasure@xilinx.com>
> Cc: bbrezillon@kernel.org; miquel.raynal@bootlin.com; richard@nod.at;
> dwmw2@infradead.org; computersforpeace@gmail.com; marek.vasut@gmail.com; linux-
> mtd@lists.infradead.org; linux-kernel@vger.kernel.org; Michal Simek <michals@xilinx.com>;
> nagasureshkumarrelli@gmail.com
> Subject: Re: [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand
> interface
>
> Hi Naga,
>
> On Wed, Mar 27, 2019 at 09:13:59AM +0000, Naga Sureshkumar Relli wrote:
> > It's a on-die ECC capable device. Did u mentioned nand-ecc-mode = "on-die" in dts.
> > The same part I tested by mentioning "on-die" property in dts and it worked for me.
> > Please share the dts entries for NAND.
> > Also if it is x8 bus then please mention nand-bus-width = <8>; If it
> > is x16 mention nand-bus-width = <16>;
>
> Thank you for pointing at the relevant properties. Indeed, these were missing in my previous
> tests. I am now using the following dt (generated from multiple fragments, giving the
> decompiled dt here):
>
> | memory-controller@e000e000 {
> | #address-cells = <0x2>;
> | #size-cells = <0x1>;
> | status = "okay";
> | clock-names = "memclk", "apb_pclk";
> | clocks = <0x1 0xb 0x1 0x2c>;
> | compatible = "arm,pl353-smc-r2p1", "arm,primecell";
> | interrupt-parent = <0x4>;
> | interrupts = <0x0 0x12 0x4>;
> | ranges = <0x0 0x0 0xe1000000 0x1000000>;
> | reg = <0xe000e000 0x1000>;
> |
> | flash@e1000000 {
> | status = "okay";
> | compatible = "arm,pl353-nand-r2p1";
> | reg = <0x0 0x0 0x1000000>;
> | #address-cells = <0x1>;
> | #size-cells = <0x1>;
> | nand-ecc-mode = "on-die";
> | nand-ecc-algo = "hamming";
> | nand-bus-width = <0x8>;
> | };
> | };
>
> With this dt, the device is successfully initialized and the data read is mostly intact. When
> using it with jffs2, I get loads of ECC errors though (offsets and lengths vary):
>
> | jffs2: mtd->read(0x800 bytes from 0xb60000) returned ECC error
>
> Reverting back to the out-of-tree driver (4.14), it works normally, so a hardware defect seems
> unlikely. I compared a register dump of the smc between those drivers and the only difference I
> could find was NAND timings (at 0xE000E180), which are much lower with the new drivers
> as it does not consume the arm,nand-cycle-* properties that the old driver consumed. I tried
> hard coding the previous timings, but the ECC errors persist. This leads me to conclude that
> timings are not the cause for what I am seeing.
>
> Is there anything else I can try to diagnose it?
Thanks for trying with new dts.
Previously we will pass the nand-cycle-* through dts.
But now framework is giving all the timing information of SDR. So we will just configure those
Timings. I will recheck the driver about the timings.
Till now I tried mtd-utils(mtd-debug) and ubifs.
I haven't tried jffs2. Let me give a try and will let you know.
Thanks,
Naga Sureshkumar Relli.
>
> Helmut
prev parent reply other threads:[~2019-03-29 5:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-09 6:37 [LINUX PATCH v13] rawnand: pl353: Add basic driver for arm pl353 smc nand interface Naga Sureshkumar Relli
2019-03-04 9:43 ` Miquel Raynal
2019-03-04 11:46 ` Naga Sureshkumar Relli
2019-03-11 4:36 ` Naga Sureshkumar Relli
2019-03-26 13:27 ` Helmut Grohne
2019-03-27 9:13 ` Naga Sureshkumar Relli
2019-03-28 11:51 ` Helmut Grohne
2019-03-29 5:21 ` Naga Sureshkumar Relli [this message]
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=MWHPR02MB2623540BA389042E7795E071AF5A0@MWHPR02MB2623.namprd02.prod.outlook.com \
--to=nagasure@xilinx.com \
--cc=bbrezillon@kernel.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=helmut.grohne@intenta.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=michals@xilinx.com \
--cc=miquel.raynal@bootlin.com \
--cc=nagasureshkumarrelli@gmail.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).