On Fri, Nov 27, 2015 at 2:05 PM, Jean-Christophe DUBOIS <j...@tribudubois.net> wrote: > Le 27/11/2015 21:26, Peter Crosthwaite a écrit : >> >> On Fri, Nov 27, 2015 at 11:54 AM, Jean-Christophe DUBOIS >> <j...@tribudubois.net> wrote: >>> >>> Le 27/11/2015 03:39, Peter Crosthwaite a écrit : >>> >>> On Wed, Nov 25, 2015 at 11:16 PM, Jean-Christophe Dubois >>> <j...@tribudubois.net> wrote: >>> >>> Signed-off-by: Jean-Christophe Dubois <j...@tribudubois.net> >>> >>> This seems to slow down boot performance for i.MX25 Linux. Admittedly, >>> the issue looks to be in timeout code for an unmodelled periph (NAND): >>> >>> ------------[ cut here ]------------ >>> WARNING: CPU: 0 PID: 1 at >>> >>> /home/pcrost/poky/build/tmp/work-shared/qemuarmv5imx/kernel-source/drivers/mtd/nand/mxc_nand.c:464 >>> wait_op_done+0xf0/0x114() >>> timeout! useirq=0 >>> Modules linked in: >>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.1 #1 >>> Hardware name: Freescale i.MX25 (Device Tree Support) >>> [<c000eec8>] (unwind_backtrace) from [<c000d2b0>] (show_stack+0x10/0x14) >>> [<c000d2b0>] (show_stack) from [<c0019154>] >>> (warn_slowpath_common+0x74/0xac) >>> [<c0019154>] (warn_slowpath_common) from [<c00191bc>] >>> (warn_slowpath_fmt+0x30/0x40) >>> [<c00191bc>] (warn_slowpath_fmt) from [<c036eaa0>] >>> (wait_op_done+0xf0/0x114) >>> [<c036eaa0>] (wait_op_done) from [<c0369698>] >>> (nand_scan_ident+0xdc/0x1560) >>> [<c0369698>] (nand_scan_ident) from [<c036e6a8>] >>> (mxcnd_probe+0x378/0x5c0) >>> [<c036e6a8>] (mxcnd_probe) from [<c03081a4>] >>> (platform_drv_probe+0x44/0xac) >>> [<c03081a4>] (platform_drv_probe) from [<c0306654>] >>> (driver_probe_device+0x180/0x2c4) >>> [<c0306654>] (driver_probe_device) from [<c0306824>] >>> (__driver_attach+0x8c/0x90) >>> [<c0306824>] (__driver_attach) from [<c0304a80>] >>> (bus_for_each_dev+0x70/0xa0) >>> [<c0304a80>] (bus_for_each_dev) from [<c0305d08>] >>> (bus_add_driver+0x188/0x210) >>> [<c0305d08>] (bus_add_driver) from [<c03071d4>] >>> (driver_register+0x78/0xf8) >>> [<c03071d4>] (driver_register) from [<c00095e0>] >>> (do_one_initcall+0x84/0x1f0) >>> [<c00095e0>] (do_one_initcall) from [<c071bd24>] >>> (kernel_init_freeable+0x108/0x1c8) >>> [<c071bd24>] (kernel_init_freeable) from [<c0541a0c>] >>> (kernel_init+0x8/0xec) >>> [<c0541a0c>] (kernel_init) from [<c000a340>] (ret_from_fork+0x14/0x34) >>> ---[ end trace 13248cb1a1bbcb9c ]--- >>> >>> <<Delay happens here>> >>> >>> nand: No NAND device found >>> ... >>> >>> Without this patch, the delay is around 2 seconds, with this patch it >>> is 10+. Any idea what would cause it? Are you removing the NAND from >>> DTS for your testing and do we not care about these errors paths? >>> >>> Regards, >>> Peter >>> >>> The kernel I am testing with is 3.19.0 but without without DTS tree. >>> Linux version 3.19.0 (jcd@jcd-U31SG) (gcc version 4.6.3 (GCC) ) #2 Mon >>> Jun >>> 22 00:32:04 CEST 2015 >>> >>> So I am not up to date on this side and I might not test the same devices >>> as >>> you do as I generated a "minimal" kernel for my test. >>> >> So the DTB+defconfig boot is actually in pretty good shape. That NAND >> thing is the only real bootlog issue. All other missing peripherals >> fail gracefully. > > > I tried the latest kernel (4.4.0 rc2) with full defconfig and dtb and I am > getting the same timeout issue even with the i.MX31 CCM module. > > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 1 at drivers/mtd/nand/mxc_nand.c:464 > wait_op_done+0xe0/0x104() > timeout! useirq=0 > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Not tainted 4.4.0-rc2-00118-g1724734 #1 > Hardware name: Freescale i.MX25 (Device Tree Support) > [<c000eb8c>] (unwind_backtrace) from [<c000d014>] (show_stack+0x10/0x14) > [<c000d014>] (show_stack) from [<c0018c10>] (warn_slowpath_common+0x78/0xb0) > [<c0018c10>] (warn_slowpath_common) from [<c0018cdc>] > (warn_slowpath_fmt+0x30/0x40) > [<c0018cdc>] (warn_slowpath_fmt) from [<c035ace4>] (wait_op_done+0xe0/0x104) > [<c035ace4>] (wait_op_done) from [<c035a86c>] (mxc_nand_command+0x150/0x4a8) > [<c035a86c>] (mxc_nand_command) from [<c03546d8>] > (nand_scan_ident+0xe4/0x1580) > [<c03546d8>] (nand_scan_ident) from [<c035a25c>] (mxcnd_probe+0x370/0x5a0) > [<c035a25c>] (mxcnd_probe) from [<c02f0698>] (platform_drv_probe+0x54/0xa4) > [<c02f0698>] (platform_drv_probe) from [<c02eec08>] > (driver_probe_device+0x1e4/0x2a8) > [<c02eec08>] (driver_probe_device) from [<c02eed58>] > (__driver_attach+0x8c/0x90) > [<c02eed58>] (__driver_attach) from [<c02ed484>] > (bus_for_each_dev+0x5c/0x8c) > [<c02ed484>] (bus_for_each_dev) from [<c02ee380>] > (bus_add_driver+0x160/0x1f8) > [<c02ee380>] (bus_add_driver) from [<c02ef814>] (driver_register+0x78/0xf4) > [<c02ef814>] (driver_register) from [<c0009600>] > (do_one_initcall+0x84/0x1f4) > [<c0009600>] (do_one_initcall) from [<c0708cf0>] > (kernel_init_freeable+0xf8/0x1bc) > [<c0708cf0>] (kernel_init_freeable) from [<c05373d8>] (kernel_init+0x8/0xe4) > [<c05373d8>] (kernel_init) from [<c000a370>] (ret_from_fork+0x14/0x24) > ---[ end trace 03bc7274bbc34493 ]--- > nand: No NAND device found > > I tried it with mainline qemu (so without any of my changes) and I still run > in the problem. > > So not sure it is related to the change in the i.MX25 CCM device. >
The NAND failure is always present and not an issue. Just I observe a large change in the timeout delay with this patch applied. Regards, Peter > JC > > > >> >>> Anyway, testing the timer code I found that running "sleep 60" on both >>> PTF >>> doesn't give the expected 60 seconds in "real world time": >>> >>> On i.MX31 (using i.MX31 CCM) => 47 seconds >>> On i.MX25 (using i.MX31 CCM) => 52 seconds (before change. close enough?) >> >> Confirmed this result, exactly the same here. >> >>> On i.MX25 (using i.MX25 CCM) => 80 seconds >>> >>> Another indication, the bogomips: >>> >>> On i.MX31 (using i.MX31 CCM) => 78 >>> On i.MX25 (using i.MX31 CCM) => 87 (before change. close enough?) >>> On i.MX25 (using i.MX25 CCM) => 133 >>> >> I wouldn't worry about this, this is rarely accurate in QEMU. >> >> Regards, >> Peter >> >>> So, yes, for some reason "time goes slower" after switching to i.MX25 CCM >>> ... (but it was also going too fast before with i.MX31 CCM) >>> >>> As the CCM doesn't really provide any clock (just a clock value) >>> something >>> must not be right in the way the i.MX GPT timer is computing time. >>> >>> I need to look after this. >>> >>> JC >>> >>> --- >>> >>> Changes since v1: >>> * rework loging to match other i.MX drivers >>> >>> Changes since v2: >>> * We moved to an inheritance QOM scheme >>> >>> Changes since v3: >>> * Rework logging based on comments. >>> >>> hw/arm/fsl-imx25.c | 2 +- >>> hw/misc/Makefile.objs | 1 + >>> hw/misc/imx25_ccm.c | 276 >>> ++++++++++++++++++++++++++++++++++++++++++++ >>> include/hw/arm/fsl-imx25.h | 4 +- >>> include/hw/misc/imx25_ccm.h | 59 ++++++++++ >>> 5 files changed, 339 insertions(+), 3 deletions(-) >>> create mode 100644 hw/misc/imx25_ccm.c >>> create mode 100644 include/hw/misc/imx25_ccm.h >>> >>> >
