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

[Jean-Christophe DUBOIS <jcd@tribudubois.net>]

Le 27/11/2015 21:26, Peter Crosthwaite a écrit :
> On Fri, Nov 27, 2015 at 11:54 AM, Jean-Christophe DUBOIS
> <jcd@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
>> <jcd@tribudubois.net> wrote:
>>
>> Signed-off-by: Jean-Christophe Dubois <jcd@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.
>
>> 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.

The 47 sec for i.MX31 is because Qemu sets the IPG/GPT clock to 50 MHz 
but the Linux guest code for some reason detects only a 39 MHz GPT 
clock. The decrepancy explains that the time then goes faster for the 
Linux guest (sleep 60 wait in fact for 47 real seconds).

I need to find why Linux is not retrieving the "correct" freq value from 
Qemu.

JC

>
>> 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
>>
>>