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 jon-hun...@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
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, 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 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 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 matthieu.cas...@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 -- 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 matthieu.cas...@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 -- 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 matthieu.cas...@parrot.com 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 matthieu.cas...@parrot.com --- 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
