All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helmut Grohne <helmut.grohne@intenta.de>
To: Naga Sureshkumar Relli <nagasure@xilinx.com>
Cc: "bbrezillon@kernel.org" <bbrezillon@kernel.org>,
	"richard@nod.at" <richard@nod.at>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"miquel.raynal@bootlin.com" <miquel.raynal@bootlin.com>,
	"nagasureshkumarrelli@gmail.com" <nagasureshkumarrelli@gmail.com>,
	Michal Simek <michals@xilinx.com>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>
Subject: Re: [LINUX PATCH v14] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Date: Thu, 25 Apr 2019 13:23:37 +0200	[thread overview]
Message-ID: <20190425112337.wno2a6dccptffldz@laureti-dev> (raw)
In-Reply-To: <DM6PR02MB47797E4A5ADFC87DE4B04A81AF3C0@DM6PR02MB4779.namprd02.prod.outlook.com>

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

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Helmut Grohne <helmut.grohne@intenta.de>
To: Naga Sureshkumar Relli <nagasure@xilinx.com>
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 v14] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Date: Thu, 25 Apr 2019 13:23:37 +0200	[thread overview]
Message-ID: <20190425112337.wno2a6dccptffldz@laureti-dev> (raw)
In-Reply-To: <DM6PR02MB47797E4A5ADFC87DE4B04A81AF3C0@DM6PR02MB4779.namprd02.prod.outlook.com>

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

  reply	other threads:[~2019-04-25 11:24 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-15 11:10 [LINUX PATCH v14] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface Naga Sureshkumar Relli
2019-04-15 11:10 ` Naga Sureshkumar Relli
2019-04-23 12:45 ` Helmut Grohne
2019-04-23 12:45   ` Helmut Grohne
2019-04-24  5:04   ` Naga Sureshkumar Relli
2019-04-24  5:04     ` Naga Sureshkumar Relli
2019-04-25 11:23     ` Helmut Grohne [this message]
2019-04-25 11:23       ` Helmut Grohne
2019-04-25 11:23 ` Helmut Grohne
2019-04-25 11:23   ` Helmut Grohne
2019-04-29  8:08   ` Miquel Raynal
2019-04-29  8:08     ` Miquel Raynal
2019-04-29 11:31   ` Naga Sureshkumar Relli
2019-04-29 11:31     ` Naga Sureshkumar Relli
2019-04-29 12:18     ` Helmut Grohne
2019-04-29 12:18       ` Helmut Grohne
2019-04-29 12:35       ` Naga Sureshkumar Relli
2019-04-29 12:35         ` Naga Sureshkumar Relli
2019-06-13 10:18       ` Naga Sureshkumar Relli
2019-06-13 10:18         ` Naga Sureshkumar Relli
2019-06-13 11:37         ` Helmut Grohne
2019-06-13 11:37           ` Helmut Grohne
2019-04-29 12:23     ` Miquel Raynal
2019-04-29 12:23       ` Miquel Raynal
2019-04-29 12:43       ` Naga Sureshkumar Relli
2019-04-29 12:43         ` Naga Sureshkumar Relli

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=20190425112337.wno2a6dccptffldz@laureti-dev \
    --to=helmut.grohne@intenta.de \
    --cc=bbrezillon@kernel.org \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --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=nagasure@xilinx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.