| Message ID | 1352199105-30215-1-git-send-email-matthieu.castet@parrot.com |
|---|---|
| State | Accepted |
| Commit | ff3206b2450499203532af2505a7f6f8413e92c0 |
| Headers | show |
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!
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
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
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
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
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
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
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
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 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
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
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' ||
- 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(+)