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

[Peter Crosthwaite]

On Fri, Nov 27, 2015 at 2:05 PM, Jean-Christophe DUBOIS
<address@hidden> wrote:
> Le 27/11/2015 21:26, Peter Crosthwaite a écrit :
>>
>> 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.
>
>
> 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
>>>
>>>
>