Patchwork [1/3] mtd nand : onfi need to be probed in 8 bits mode

login
register
mail settings
Submitter Matthieu CASTET
Date Nov. 6, 2012, 10:51 a.m.
Message ID <1352199105-30215-1-git-send-email-matthieu.castet@parrot.com>
Download mbox | patch
Permalink /patch/197462/
State Accepted
Commit ff3206b2450499203532af2505a7f6f8413e92c0
Headers show

Comments

Matthieu CASTET - Nov. 6, 2012, 10:51 a.m.
- NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
- NAND_CMD_PARAM want 8 bits data

Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
---
 drivers/mtd/nand/nand_base.c |    2 ++
 1 file changed, 2 insertions(+)
Artem Bityutskiy - Dec. 3, 2012, 10:20 a.m.
On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
> - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
> - NAND_CMD_PARAM want 8 bits data
> 
> Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>

Pushed this one to l2-mtd.git, thanks!
Paul Walmsley - Dec. 24, 2012, 12:29 a.m.
Hi

On Mon, 3 Dec 2012, Artem Bityutskiy wrote:

> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
> > - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
> > - NAND_CMD_PARAM want 8 bits data
> > 
> > Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
> 
> Pushed this one to l2-mtd.git, thanks!

This patch (commit ff3206b2450499203532af2505a7f6f8413e92c0 in mainline) 
is causing warnings on OMAP3730 Beagle XM, OMAP3530 Beagle, and DM37xx EVM 
as of v3.8-rc1:

[    1.349456] ------------[ cut here ]------------
[    1.351959] WARNING: at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()
[    1.356292] Modules linked in:
[    1.357971] [<c001bf50>] (unwind_backtrace+0x0/0xf0) from [<c0045cec>] (warn_slowpath_common+0x4c/0x64)
[    1.363037] [<c0045cec>] (warn_slowpath_common+0x4c/0x64) from [<c0045d20>] (warn_slowpath_null+0x1c/0x24)
[    1.368194] [<c0045d20>] (warn_slowpath_null+0x1c/0x24) from [<c039d304>] (nand_scan_ident+0xdb4/0xf90)
[    1.373229] [<c039d304>] (nand_scan_ident+0xdb4/0xf90) from [<c03a2448>] (omap_nand_probe+0x2e8/0x678)
[    1.378234] [<c03a2448>] (omap_nand_probe+0x2e8/0x678) from [<c0357f84>] (platform_drv_probe+0x18/0x1c)
[    1.383239] [<c0357f84>] (platform_drv_probe+0x18/0x1c) from [<c0356b84>] (driver_probe_device+0x84/0x224)
[    1.388458] [<c0356b84>] (driver_probe_device+0x84/0x224) from [<c0356db8>] (__driver_attach+0x94/0x98)
[    1.393493] [<c0356db8>] (__driver_attach+0x94/0x98) from [<c0355330>] (bus_for_each_dev+0x50/0x7c)
[    1.398315] [<c0355330>] (bus_for_each_dev+0x50/0x7c) from [<c0356250>] (bus_add_driver+0xa0/0x2a0)
[    1.403198] [<c0356250>] (bus_add_driver+0xa0/0x2a0) from [<c03572ec>] (driver_register+0x78/0x18c)
[    1.408020] [<c03572ec>] (driver_register+0x78/0x18c) from [<c00086a4>] (do_one_initcall+0x34/0x194)
[    1.412933] [<c00086a4>] (do_one_initcall+0x34/0x194) from [<c0528188>] (kernel_init+0x154/0x2ec)
[    1.417724] [<c0528188>] (kernel_init+0x154/0x2ec) from [<c0013d50>] (ret_from_fork+0x14/0x24)
[    1.422454] ---[ end trace 7f5c9fb048cfa61e ]---

The patch also looks bogus.  The patch states that "ONFI need to be probed 
in 8 bits mode" (sic).  But if that's so, shouldn't 
nand_flash_detect_onfi()  just fail immediately, rather than warn?


- Paul
Matthieu CASTET - Jan. 2, 2013, 9:51 a.m.
Hi Paul,

Paul Walmsley a écrit :
> Hi
> 
> On Mon, 3 Dec 2012, Artem Bityutskiy wrote:
> 
>> On Tue, 2012-11-06 at 11:51 +0100, Matthieu CASTET wrote:
>>> - NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20)
>>> - NAND_CMD_PARAM want 8 bits data
>>>
>>> Signed-off-by: Matthieu CASTET <matthieu.castet@parrot.com>
>> Pushed this one to l2-mtd.git, thanks!
> 
> This patch (commit ff3206b2450499203532af2505a7f6f8413e92c0 in mainline) 
> is causing warnings on OMAP3730 Beagle XM, OMAP3530 Beagle, and DM37xx EVM 
> as of v3.8-rc1:
> 
> [    1.349456] ------------[ cut here ]------------
> [    1.351959] WARNING: at drivers/mtd/nand/nand_base.c:2861 nand_scan_ident+0xdb4/0xf90()
> [    1.356292] Modules linked in:
> [    1.357971] [<c001bf50>] (unwind_backtrace+0x0/0xf0) from [<c0045cec>] (warn_slowpath_common+0x4c/0x64)
> [    1.363037] [<c0045cec>] (warn_slowpath_common+0x4c/0x64) from [<c0045d20>] (warn_slowpath_null+0x1c/0x24)
> [    1.368194] [<c0045d20>] (warn_slowpath_null+0x1c/0x24) from [<c039d304>] (nand_scan_ident+0xdb4/0xf90)
> [    1.373229] [<c039d304>] (nand_scan_ident+0xdb4/0xf90) from [<c03a2448>] (omap_nand_probe+0x2e8/0x678)
> [    1.378234] [<c03a2448>] (omap_nand_probe+0x2e8/0x678) from [<c0357f84>] (platform_drv_probe+0x18/0x1c)
> [    1.383239] [<c0357f84>] (platform_drv_probe+0x18/0x1c) from [<c0356b84>] (driver_probe_device+0x84/0x224)
> [    1.388458] [<c0356b84>] (driver_probe_device+0x84/0x224) from [<c0356db8>] (__driver_attach+0x94/0x98)
> [    1.393493] [<c0356db8>] (__driver_attach+0x94/0x98) from [<c0355330>] (bus_for_each_dev+0x50/0x7c)
> [    1.398315] [<c0355330>] (bus_for_each_dev+0x50/0x7c) from [<c0356250>] (bus_add_driver+0xa0/0x2a0)
> [    1.403198] [<c0356250>] (bus_add_driver+0xa0/0x2a0) from [<c03572ec>] (driver_register+0x78/0x18c)
> [    1.408020] [<c03572ec>] (driver_register+0x78/0x18c) from [<c00086a4>] (do_one_initcall+0x34/0x194)
> [    1.412933] [<c00086a4>] (do_one_initcall+0x34/0x194) from [<c0528188>] (kernel_init+0x154/0x2ec)
> [    1.417724] [<c0528188>] (kernel_init+0x154/0x2ec) from [<c0013d50>] (ret_from_fork+0x14/0x24)
> [    1.422454] ---[ end trace 7f5c9fb048cfa61e ]---
> 
> The patch also looks bogus.  The patch states that "ONFI need to be probed 
> in 8 bits mode" (sic).  But if that's so, shouldn't 
> nand_flash_detect_onfi()  just fail immediately, rather than warn?
> 
I put a warning in order we fix drivers instead of a silent failure.

The omap driver was fixed in the same series with
http://article.gmane.org/gmane.linux.ports.arm.omap/88551 and
http://article.gmane.org/gmane.linux.ports.arm.omap/88549

For drivers that can't support ONFI, I don't know what to do.
May we should be replace the WARN_ON by a printk and early return.

Matthieu
Paul Walmsley - Jan. 3, 2013, 5:10 p.m.
Hi

On Wed, 2 Jan 2013, Matthieu CASTET wrote:

> I put a warning in order we fix drivers instead of a silent failure.
> 
> The omap driver was fixed in the same series with
> http://article.gmane.org/gmane.linux.ports.arm.omap/88551 and

... which got merged by Artem.

> http://article.gmane.org/gmane.linux.ports.arm.omap/88549

... which did not get merged because Tony requested that it should be 
based on top of his cleanup work (which takes priority over adding new 
features):

http://thread.gmane.org/gmane.linux.ports.arm.omap/88550/focus=88549

Could you please update this "omap3 nand : use NAND_BUSWIDTH_AUTO" patch 
on v3.8-rc2 and repost?

> For drivers that can't support ONFI, I don't know what to do.
> May we should be replace the WARN_ON by a printk and early return.

That sounds like a good idea to me.  The traceback seems excessive, since 
the NAND was usable before this series.


- Paul
Matthieu CASTET - Jan. 16, 2013, 2:28 p.m.
Hi,

Paul Walmsley a écrit :
> Hi
> 
> On Wed, 2 Jan 2013, Matthieu CASTET wrote:

> .... which did not get merged because Tony requested that it should be 
> based on top of his cleanup work (which takes priority over adding new 
> features):
> 
> http://thread.gmane.org/gmane.linux.ports.arm.omap/88550/focus=88549
> 
> Could you please update this "omap3 nand : use NAND_BUSWIDTH_AUTO" patch 
> on v3.8-rc2 and repost?

Do you know when this patchset will be submited to mtd ?
I think I will wait it is merged in mtd and redo my patch after that.

> 
>> For drivers that can't support ONFI, I don't know what to do.
>> May we should be replace the WARN_ON by a printk and early return.
> 
> That sounds like a good idea to me.  The traceback seems excessive, since 
> the NAND was usable before this series.
> 
I submited a patch for doing that.

Matthieu
Paul Walmsley - Jan. 16, 2013, 5:15 p.m.
Hi Matthieu,

On Wed, 16 Jan 2013, Matthieu CASTET wrote:

> Paul Walmsley a écrit :
> > On Wed, 2 Jan 2013, Matthieu CASTET wrote:
> 
> > .... which did not get merged because Tony requested that it should be 
> > based on top of his cleanup work (which takes priority over adding new 
> > features):
> > 
> > http://thread.gmane.org/gmane.linux.ports.arm.omap/88550/focus=88549
> > 
> > Could you please update this "omap3 nand : use NAND_BUSWIDTH_AUTO" patch 
> > on v3.8-rc2 and repost?
> 
> Do you know when this patchset will be submited to mtd ?
> I think I will wait it is merged in mtd and redo my patch after that.

As far as I know, it was merged during the v3.8 merge window.  So it's 
already in mainline.  

> >> For drivers that can't support ONFI, I don't know what to do.
> >> May we should be replace the WARN_ON by a printk and early return.
> > 
> > That sounds like a good idea to me.  The traceback seems excessive, since 
> > the NAND was usable before this series.
> > 
> I submited a patch for doing that.

Thanks for doing this, it's much appreciated!


- Paul
Paul Walmsley - Jan. 22, 2013, 2:27 a.m.
Hi Matthieu,

On Wed, 16 Jan 2013, Paul Walmsley wrote:

> On Wed, 16 Jan 2013, Matthieu CASTET wrote:
> 
> > Paul Walmsley a écrit :
> > > On Wed, 2 Jan 2013, Matthieu CASTET wrote:
> > 
> > > .... which did not get merged because Tony requested that it should be 
> > > based on top of his cleanup work (which takes priority over adding new 
> > > features):
> > > 
> > > http://thread.gmane.org/gmane.linux.ports.arm.omap/88550/focus=88549
> > > 
> > > Could you please update this "omap3 nand : use NAND_BUSWIDTH_AUTO" patch 
> > > on v3.8-rc2 and repost?
> > 
> > Do you know when this patchset will be submited to mtd ?
> > I think I will wait it is merged in mtd and redo my patch after that.
> 
> As far as I know, it was merged during the v3.8 merge window.  So it's 
> already in mainline.  

Any progress on updating and resending your "omap3 nand : use 
NAND_BUSWIDTH_AUTO" patch?  We're in danger of missing the 3.9 merge 
window if it takes too much longer.


- Paul
Paul Walmsley - Feb. 6, 2013, 11:21 p.m.
Hi Matthieu,

On Tue, 22 Jan 2013, Paul Walmsley wrote:

> Any progress on updating and resending your "omap3 nand : use 
> NAND_BUSWIDTH_AUTO" patch?  We're in danger of missing the 3.9 merge 
> window if it takes too much longer.

Could you let us know if you're planning to update and repost this one?

thanks,

- Paul
Matthieu CASTET - Feb. 7, 2013, 9:47 a.m.
Hi Paul,

Paul Walmsley a écrit :
> Hi Matthieu,
> 
> On Tue, 22 Jan 2013, Paul Walmsley wrote:
> 
>> Any progress on updating and resending your "omap3 nand : use 
>> NAND_BUSWIDTH_AUTO" patch?  We're in danger of missing the 3.9 merge 
>> window if it takes too much longer.
> 
> Could you let us know if you're planning to update and repost this one?
> 
Sorry for the delay I attached an updated version of the patch.

I was not able to test it : with mtd tree and my configuration I have to apply
https://patchwork.kernel.org/patch/1810441/
https://patchwork.kernel.org/patch/1884341/
http://comments.gmane.org/gmane.linux.ports.arm.omap/91096

in order the kernel build.

And after that the kernel doesn't seem to boot on my beagle board. Could you
test the patch ?


I have also a problem : how should I change nand bus size. It is done by
"gpmc_cs_configure(info->gpmc_cs, GPMC_CONFIG_DEV_SIZE, ...);", but now gpmc.h
header is not public anymore.

I have to do a '#include "../gpmc.h"'.


Matthieu
Matthieu CASTET - March 1, 2013, 2:02 p.m.
Matthieu CASTET a écrit :
> Hi Paul,
> 
> Paul Walmsley a écrit :
>> Hi Matthieu,
>>
>> On Tue, 22 Jan 2013, Paul Walmsley wrote:
>>
>>> Any progress on updating and resending your "omap3 nand : use 
>>> NAND_BUSWIDTH_AUTO" patch?  We're in danger of missing the 3.9 merge 
>>> window if it takes too much longer.
>> Could you let us know if you're planning to update and repost this one?
>>
> Sorry for the delay I attached an updated version of the patch.
> 
> I was not able to test it : with mtd tree and my configuration I have to apply
> https://patchwork.kernel.org/patch/1810441/
> https://patchwork.kernel.org/patch/1884341/
> http://comments.gmane.org/gmane.linux.ports.arm.omap/91096
> 
> in order the kernel build.
> 
> And after that the kernel doesn't seem to boot on my beagle board. Could you
> test the patch ?
> 
> 
> I have also a problem : how should I change nand bus size. It is done by
> "gpmc_cs_configure(info->gpmc_cs, GPMC_CONFIG_DEV_SIZE, ...);", but now gpmc.h
> header is not public anymore.
> 
> I have to do a '#include "../gpmc.h"'.
> 
> 
Any news on this ?


Matthieu
Paul Walmsley - April 2, 2013, 6:28 p.m.
Hi Matthieu,

On Fri, 1 Mar 2013, Matthieu CASTET wrote:

> Matthieu CASTET a écrit :
> > Paul Walmsley a écrit :
> >> On Tue, 22 Jan 2013, Paul Walmsley wrote:
> >>
> >>> Any progress on updating and resending your "omap3 nand : use 
> >>> NAND_BUSWIDTH_AUTO" patch?  We're in danger of missing the 3.9 merge 
> >>> window if it takes too much longer.
> >> Could you let us know if you're planning to update and repost this one?
> >>
> > Sorry for the delay I attached an updated version of the patch.
> > 
> > I was not able to test it : with mtd tree and my configuration I have to apply
> > https://patchwork.kernel.org/patch/1810441/
> > https://patchwork.kernel.org/patch/1884341/
> > http://comments.gmane.org/gmane.linux.ports.arm.omap/91096
> > 
> > in order the kernel build.
> > 
> > And after that the kernel doesn't seem to boot on my beagle board. Could you
> > test the patch ?
> > 
> > I have also a problem : how should I change nand bus size. It is done by
> > "gpmc_cs_configure(info->gpmc_cs, GPMC_CONFIG_DEV_SIZE, ...);", but now gpmc.h
> > header is not public anymore.
> > 
> > I have to do a '#include "../gpmc.h"'.
> > 
> > 
> Any news on this ?

Unfortunately, I don't have the time at the moment to track this issue.  
Could you follow up on this with Jon Hunter <jon-hunter@ti.com> ?  He's 
been working on the GPMC code for the last few merge windows and is 
basically the maintainer of it at this point.


- Paul

Patch

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5894c2c..abeb8e9 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2851,6 +2851,8 @@  static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
 	int i;
 	int val;
 
+	/* ONFI need to be probed in 8 bits mode */
+	WARN_ON(chip->options & NAND_BUSWIDTH_16);
 	/* Try ONFI for unknown chip or LP */
 	chip->cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
 	if (chip->read_byte(mtd) != 'O' || chip->read_byte(mtd) != 'N' ||