Re: [Qemu-arm] [PATCH v4 3/3] i.MX: Add an i.MX25 specific CCM class/instance.

[Guenter Roeck]

On 11/27/2015 12:26 PM, Peter Crosthwaite wrote:
> On Fri, Nov 27, 2015 at 11:54 AM, Jean-Christophe DUBOIS
> <address@hidden> wrote:
> > Le 27/11/2015 03:39, Peter Crosthwaite a écrit :
> >
> > On Wed, Nov 25, 2015 at 11:16 PM, Jean-Christophe Dubois
> > <address@hidden> wrote:
> >
> > Signed-off-by: Jean-Christophe Dubois <address@hidden>
> >
> > 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 (address@hidden) (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