qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jean-Christophe DUBOIS
Subject: Re: [Qemu-devel] [PATCH v4 3/3] i.MX: Add an i.MX25 specific CCM class/instance.
Date: Mon, 30 Nov 2015 00:46:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

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.

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]