[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190425112337.wno2a6dccptffldz@laureti-dev>
Date: Thu, 25 Apr 2019 13:23:37 +0200
From: Helmut Grohne <helmut.grohne@...enta.de>
To: Naga Sureshkumar Relli <nagasure@...inx.com>
CC: "bbrezillon@...nel.org" <bbrezillon@...nel.org>,
"miquel.raynal@...tlin.com" <miquel.raynal@...tlin.com>,
"richard@....at" <richard@....at>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"computersforpeace@...il.com" <computersforpeace@...il.com>,
"marek.vasut@...il.com" <marek.vasut@...il.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Michal Simek <michals@...inx.com>,
"nagasureshkumarrelli@...il.com" <nagasureshkumarrelli@...il.com>
Subject: Re: [LINUX PATCH v14] mtd: rawnand: pl353: Add basic driver for arm
pl353 smc nand interface
On Wed, Apr 24, 2019 at 05:04:38AM +0000, Naga Sureshkumar Relli wrote:
> > You previously used cond_resched (via nand_wait_ready) here. Why did you change it to
> > cpu_relax()?
> I just replicated the pl353_wait_for_ecc_done() API definition.
> But did you see any issue with this?
> Anyway I will replace it with cond_resched(), instead of cpu_releax()
This was an observation and it made me ask for reasons. I did not have
any practical issues here.
> Did you follow the same thing that you tried earlier?
> i.e. updated "nand-bus-width" property and "nand-ecc-mode" ?
Yes, I used the same device tree that made v13 partially work here.
> > After trying the driver, the flash chip was bricked. Neither the old driver nor the uboot-xlnx
> > driver nor the Xilinx fsbl are able to talk to the chip afterwards. This behaviour persists even
> > after a full power cycle. I'll try reinitializing the flash chip next. I've only seen this behaviour
> > once, so there is a slight chance that the cause is something else.
> Sometimes I also faced the same problem during driver development.
> What I did is, in standalone nandps driver example, I forcibly created BBT in the init and once
> it is done. I just reloaded the actual example. Then after wards u-boot and Linux are able to scan
> the BBT.
I confirm. It was just the BBT being bad. It can also be recreated using
u-boot with "nand scrib.chip".
I also spent some time reviewing the code and will send another mail
about that.
Helmut
Powered by blists - more mailing lists