From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2QnT-0001kv-Ix for qemu-devel@nongnu.org; Fri, 27 Nov 2015 16:43:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2QnS-0006S2-07 for qemu-devel@nongnu.org; Fri, 27 Nov 2015 16:43:15 -0500 References: <5658B4EA.8070005@tribudubois.net> From: Guenter Roeck Message-ID: <5658CE67.2010201@roeck-us.net> Date: Fri, 27 Nov 2015 13:43:03 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v4 3/3] i.MX: Add an i.MX25 specific CCM class/instance. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite , Jean-Christophe DUBOIS Cc: Peter Maydell , qemu-arm@nongnu.org, "qemu-devel@nongnu.org Developers" , Peter Crosthwaite On 11/27/2015 12:26 PM, Peter Crosthwaite wrote: > On Fri, Nov 27, 2015 at 11:54 AM, Jean-Christophe DUBOIS > wrote: >> Le 27/11/2015 03:39, Peter Crosthwaite a écrit : >> >> On Wed, Nov 25, 2015 at 11:16 PM, Jean-Christophe Dubois >> wrote: >> >> Signed-off-by: Jean-Christophe Dubois >> >> 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) >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14) >> [] (show_stack) from [] (warn_slowpath_common+0x74/0xac) >> [] (warn_slowpath_common) from [] >> (warn_slowpath_fmt+0x30/0x40) >> [] (warn_slowpath_fmt) from [] (wait_op_done+0xf0/0x114) >> [] (wait_op_done) from [] (nand_scan_ident+0xdc/0x1560) >> [] (nand_scan_ident) from [] (mxcnd_probe+0x378/0x5c0) >> [] (mxcnd_probe) from [] (platform_drv_probe+0x44/0xac) >> [] (platform_drv_probe) from [] >> (driver_probe_device+0x180/0x2c4) >> [] (driver_probe_device) from [] >> (__driver_attach+0x8c/0x90) >> [] (__driver_attach) from [] >> (bus_for_each_dev+0x70/0xa0) >> [] (bus_for_each_dev) from [] >> (bus_add_driver+0x188/0x210) >> [] (bus_add_driver) from [] (driver_register+0x78/0xf8) >> [] (driver_register) from [] >> (do_one_initcall+0x84/0x1f0) >> [] (do_one_initcall) from [] >> (kernel_init_freeable+0x108/0x1c8) >> [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec) >> [] (kernel_init) from [] (ret_from_fork+0x14/0x34) >> ---[ end trace 13248cb1a1bbcb9c ]--- >> >> <> >> >> 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. > In my runtime linux kernel tests, I disable CONFIG_MTD_NAND_MXC to avoid the nand problem - both the log message and the long boot time. Guenter >> 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 >> >> >