Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 ? 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
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 0001-omap3-nand-use-NAND_BUSWIDTH_AUTO.patch Description: application/mbox
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 >> 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] [] (unwind_backtrace+0x0/0xf0) from [] > (warn_slowpath_common+0x4c/0x64) > [1.363037] [] (warn_slowpath_common+0x4c/0x64) from > [] (warn_slowpath_null+0x1c/0x24) > [1.368194] [] (warn_slowpath_null+0x1c/0x24) from [] > (nand_scan_ident+0xdb4/0xf90) > [1.373229] [] (nand_scan_ident+0xdb4/0xf90) from [] > (omap_nand_probe+0x2e8/0x678) > [1.378234] [] (omap_nand_probe+0x2e8/0x678) from [] > (platform_drv_probe+0x18/0x1c) > [1.383239] [] (platform_drv_probe+0x18/0x1c) from [] > (driver_probe_device+0x84/0x224) > [1.388458] [] (driver_probe_device+0x84/0x224) from > [] (__driver_attach+0x94/0x98) > [1.393493] [] (__driver_attach+0x94/0x98) from [] > (bus_for_each_dev+0x50/0x7c) > [1.398315] [] (bus_for_each_dev+0x50/0x7c) from [] > (bus_add_driver+0xa0/0x2a0) > [1.403198] [] (bus_add_driver+0xa0/0x2a0) from [] > (driver_register+0x78/0x18c) > [1.408020] [] (driver_register+0x78/0x18c) from [] > (do_one_initcall+0x34/0x194) > [1.412933] [] (do_one_initcall+0x34/0x194) from [] > (kernel_init+0x154/0x2ec) > [1.417724] [] (kernel_init+0x154/0x2ec) from [] > (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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 > > 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] [] (unwind_backtrace+0x0/0xf0) from [] (warn_slowpath_common+0x4c/0x64) [1.363037] [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_null+0x1c/0x24) [1.368194] [] (warn_slowpath_null+0x1c/0x24) from [] (nand_scan_ident+0xdb4/0xf90) [1.373229] [] (nand_scan_ident+0xdb4/0xf90) from [] (omap_nand_probe+0x2e8/0x678) [1.378234] [] (omap_nand_probe+0x2e8/0x678) from [] (platform_drv_probe+0x18/0x1c) [1.383239] [] (platform_drv_probe+0x18/0x1c) from [] (driver_probe_device+0x84/0x224) [1.388458] [] (driver_probe_device+0x84/0x224) from [] (__driver_attach+0x94/0x98) [1.393493] [] (__driver_attach+0x94/0x98) from [] (bus_for_each_dev+0x50/0x7c) [1.398315] [] (bus_for_each_dev+0x50/0x7c) from [] (bus_add_driver+0xa0/0x2a0) [1.403198] [] (bus_add_driver+0xa0/0x2a0) from [] (driver_register+0x78/0x18c) [1.408020] [] (driver_register+0x78/0x18c) from [] (do_one_initcall+0x34/0x194) [1.412933] [] (do_one_initcall+0x34/0x194) from [] (kernel_init+0x154/0x2ec) [1.417724] [] (kernel_init+0x154/0x2ec) from [] (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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
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 Pushed this one to l2-mtd.git, thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
- 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 --- drivers/mtd/nand/nand_base.c |2 ++ 1 file changed, 2 insertions(+) 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' || -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
