Skip to contentSkip to conversation

Open issues after 2.6.38 merge window

DISCUSSION Tony Lindgren 9 participants 27 messages Jan 14, 2011 – Jan 27, 2011

Subsystems (4)
Arm (32-bit) Arm sub-architectures OMAP2+ support OMAP1 support
lore
Share & tools
lore

Tony Lindgren

author maintainer
#0 lore raw

Hi all,

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

Any other issues?

Regards,

Tony

author maintainer
#1 lore raw
Quoted 2 lines · Tony Lindgren

- NFS root oopses while mounting root

Looks like this one is now fixed.

Tony

#2 lore raw
In reply to Tony Lindgren
Quoted 4 lines · On Fri, 14 Jan 2011 11:47:58 -0800 Tony Lindgren <[email protected]> wrote:

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

my 2c to Panda power down problem:

Nishanth helped me recently to debug why my board does this power down and it seems to be caused by a broken hw. I.e. we were using exactly same bootloader and kernel and only my board was not working.

Signature · 1 line
Jarkko
author maintainer
#3 lore raw
Quoted 5 lines · Jarkko Nikula
Quoted 2 lines · On Fri, 14 Jan 2011 11:47:58 -0800 Tony Lindgren <[email protected]> wrote:

- omap4 panda powers down after boot (watchdog?)

Quoted 7 lines
Quoted 2 lines

- omap3 ldp board powers down after boot?

my 2c to Panda power down problem:

Nishanth helped me recently to debug why my board does this power down and it seems to be caused by a broken hw. I.e. we were using exactly same bootloader and kernel and only my board was not working.

Hmm, mine was working just fine until about a week ago. I did update the bootloader also though. What's the recommended x-loader + u-boot combo for panda?

Tony

#4 lore raw

Tony Lindgren wrote, on 01/14/2011 02:54 PM:

Quoted 10 lines · Jarkko Nikula
Quoted 9 lines
Quoted 4 lines · On Fri, 14 Jan 2011 11:47:58 -0800 Tony Lindgren<[email protected]> wrote:

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

my 2c to Panda power down problem:

Quoted 7 lines
Quoted 3 lines

Nishanth helped me recently to debug why my board does this power down and it seems to be caused by a broken hw. I.e. we were using exactly same bootloader and kernel and only my board was not working.

Hmm, mine was working just fine until about a week ago. I did update the bootloader also though. What's the recommended x-loader + u-boot combo for panda?

The combination I had used was:
x-loader: http://gitorious.org/x-loader/x-loader
u-boot: http://git.denx.de/?p=u-boot.git;a=summary

The issue on the board potentially could be solder issue and RMA was recommended.

Signature · 2 lines
Regards,
Nishanth Menon
#5 lore raw
In reply to Tony Lindgren

Tony,

i've been testing the 2.6.37 kernel on ES2.0, ES2.1, ES2.2 using the following:

x-loader:
git://gitorious.org/x-loader/x-loader.git
branch: master
6f3a261 omap1: remove support for 1710 and 1510
defconfig: omap4430panda_config

U-boot:
git://git.denx.de/u-boot.git
tag: v2010.12
defconfig: omap4_panda_config

kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
tag: v2.6.37
defconfig: omap2plus_defconfig

i've not seen the power off issue you have described.

thanks
Dave

Quoted 24 lines · Tony Lindgren

Hi all,

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

Any other issues?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author maintainer
#6 lore raw
Quoted 11 lines · David Anders

Tony,

i've been testing the 2.6.37 kernel on ES2.0, ES2.1, ES2.2 using the following:

x-loader:
git://gitorious.org/x-loader/x-loader.git
branch: master
6f3a261 omap1: remove support for 1710 and 1510
defconfig: omap4430panda_config

Quoted 4 lines

U-boot:
git://git.denx.de/u-boot.git
tag: v2010.12
defconfig: omap4_panda_config

That's what I'm using too.

Quoted 6 lines

kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
tag: v2.6.37
defconfig: omap2plus_defconfig

i've not seen the power off issue you have described.

Hmm well it happens also with v2.6.37, so sounds like it's a u-boot or hardware issue. I'll debug a bit further.

Tony

author maintainer
#7 lore raw
Quoted 24 lines · Tony Lindgren
Quoted 11 lines · David Anders

Tony,

i've been testing the 2.6.37 kernel on ES2.0, ES2.1, ES2.2 using the following:

x-loader:
git://gitorious.org/x-loader/x-loader.git
branch: master
6f3a261 omap1: remove support for 1710 and 1510
defconfig: omap4430panda_config

Quoted 4 lines

U-boot:
git://git.denx.de/u-boot.git
tag: v2010.12
defconfig: omap4_panda_config

That's what I'm using too.

Quoted 5 lines

kernel:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
tag: v2.6.37
defconfig: omap2plus_defconfig

Quoted 4 lines
Quoted 1 line

i've not seen the power off issue you have described.

Hmm well it happens also with v2.6.37, so sounds like it's a u-boot or hardware issue. I'll debug a bit further.

Weird. While debugging the problem, I left just the u-boot console running for a few minutes to see if panda shuts down on it's own.

It did not, but instead it now stays running with the kernel booted also.. No idea why. Did not touch anything with u-boot..

Tony

#8 lore raw
In reply to Tony Lindgren

Am 14.01.2011 20:47, schrieb Tony Lindgren:

Quoted 16 lines

Hi all,

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

Any other issues?

Quoted 7 lines

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hello,

today I tried to enable the DVI output on Devkit8000 and got the following error.

When the DVI port is configured as omapdss.def_disp I can turn on and off the DVI, but not the display0 (LCD).

Thomas

My cmdline is:
console=ttyO2,115200n8 root=/dev/nfs nfsroot=192.168.1.102:/nfsroot ip=192.168.1.200 rootdelay=1 omapdss.def_disp=lcd omapfb.mode=lcd:800x480 vram=12M

# echo 1 > /sys/devices/omapdss/display1/enabled
[   27.399017] omapdss DPI: Could not find exact pixel clock. Requested
23500 kHz, got 24000 kHz
[   27.410156] Unable to handle kernel NULL pointer dereference at
virtual address 00000078
[   27.418731] pgd = ce438000
[   27.421844] [00000078] *pgd=8e432031, *pte=00000000, *ppte=00000000
[   27.428466] Internal error: Oops: 17 [#1] SMP
[   27.433044] last sysfs file: /sys/devices/omapdss/display1/enabled
[   27.439544] Modules linked in:
[   27.442779] CPU: 0    Not tainted  (2.6.37-rc5-09166-g28d7f6a #26)
[   27.449279] PC is at omapdss_dpi_display_enable+0x8c/0xd8
[   27.454956] LR is at omapdss_dpi_display_enable+0x88/0xd8
[   27.460632] pc : [<c026c110>]    lr : [<c026c10c>]    psr: 60000013
[   27.460632] sp : ce425f00  ip : 000026ca  fp : 00000002
[   27.472686] r10: cef240f8  r9 : c0439634  r8 : 00000002
[   27.478179] r7 : cef240e0  r6 : c05db110  r5 : 00000000  r4 : c05db108
[   27.485015] r3 : c0b61e7c  r2 : 00000740  r1 : cef19a50  r0 : 00000000
[   27.491882] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM 
Segment user
[   27.499359] Control: 10c5387d  Table: 8e438019  DAC: 00000015
[   27.505401] Process sh (pid: 546, stack limit = 0xce4242f8)
[   27.511260] Stack: (0xce425f00 to 0xce426000)
[   27.515838] 5f00: 00000000 c05db108 00000002 c0272370 c02723c0
c05db108 00000002 c02723cc
[   27.524444] 5f20: c05db108 c02695ec 00000002 cee5e148 ce425f80
c0299c1c 00000002 c016fd0c
[   27.533020] 5f40: 00000002 ce407080 400ea000 ce425f80 00000000
00000000 00000000 c01205a0
[   27.541625] 5f60: ce407080 400ea000 ce407080 400ea000 00000002
00000004 00000000 c01206c8
[   27.550201] 5f80: 00000000 00000000 00000002 00000000 00000002
402d35c8 00000002 c005a3e8
[   27.558807] 5fa0: ce424000 c005a220 00000002 402d35c8 00000001
400ea000 00000002 00000000
[   27.567382] 5fc0: 00000002 402d35c8 00000002 00000004 400ea000
40084000 0000000a 00000002
[   27.575988] 5fe0: 00000000 bea235f8 401f9e98 40256adc 60000010
00000001 00000000 00000000
[   27.584594] [<c026c110>] (omapdss_dpi_display_enable+0x8c/0xd8) from
[<c0272370>] (generic_panel_power_on+0x1c/0x50)
[   27.595672] [<c0272370>] (generic_panel_power_on+0x1c/0x50) from
[<c02723cc>] (generic_panel_enable+0xc/0x1c)
[   27.606079] [<c02723cc>] (generic_panel_enable+0xc/0x1c) from
[<c02695ec>] (display_enabled_store+0x50/0x74)
[   27.616424] [<c02695ec>] (display_enabled_store+0x50/0x74) from
[<c0299c1c>] (dev_attr_store+0x1c/0x20)
[   27.626312] [<c0299c1c>] (dev_attr_store+0x1c/0x20) from [<c016fd0c>]
(sysfs_write_file+0x10c/0x144)
[   27.635925] [<c016fd0c>] (sysfs_write_file+0x10c/0x144) from
[<c01205a0>] (vfs_write+0xb0/0x128)
[   27.645172] [<c01205a0>] (vfs_write+0xb0/0x128) from [<c01206c8>]
(sys_write+0x3c/0x68)
[   27.653594] [<c01206c8>] (sys_write+0x3c/0x68) from [<c005a220>]
(ret_fast_syscall+0x0/0x3c)
[   27.662445] Code: 1a000005 e59f004c ebff2da5 e59402b4 (e5903078)
[   27.669006] ---[ end trace f5536249261ca351 ]---
#9 lore raw
In reply to Tony Lindgren
Quoted 7 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Saturday, January 15, 2011 1:18 AM
To: [email protected]
Subject: Open issues after 2.6.38 merge window

Quoted 9 lines

Hi all,

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- omap4430 es1.0 hangs if L2X0 cache is enabled

Will have look at this one on Monday

Quoted 2 lines

- omap4 panda powers down after boot (watchdog?)

Must be watchdog

Quoted 2 lines

- omap3 ldp board powers down after boot?

I guess this was already concluded as a watchdog issue.

Quoted 2 lines

Any other issues?

I saw the build related pull request from you, so most of those gets sorted out.

- !CONFIG_RUNTIME_PM, boot crash because of watchdog.

Posted the patch for this but I need to verify one scenario pointed out by Paul Where if the boot-loader keeps watchdog enabled.

- omap2plus_defconfig build break because of SWP_EMULATE missing patch.

This one will gets fixed once the Catalin patch is merged

Regards,
Santosh

#10 lore raw

Tony,

Quoted 15 lines

-----Original Message-----
From: Santosh Shilimkar [mailto:[email protected]]
Sent: Saturday, January 15, 2011 10:50 AM
To: Tony Lindgren; [email protected]
Subject: RE: Open issues after 2.6.38 merge window

Quoted 9 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Tony Lindgren
Sent: Saturday, January 15, 2011 1:18 AM
To: [email protected]
Subject: Open issues after 2.6.38 merge window

Hi all,

Quoted 9 lines
Quoted 7 lines

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- omap4430 es1.0 hangs if L2X0 cache is enabled

Will have look at this one on Monday

I don't see the hang with L2X0 enable on my ES1.0 SDP with the latest Linus's head.

(Mainline 'e78bf5e6cbe837' + Paul's sync timer fix)

The kernel boots fine.

Regards
Santosh

author maintainer
#11 lore raw
Quoted 11 lines · Santosh Shilimkar
Quoted 5 lines
Quoted 3 lines

- omap4430 es1.0 hangs if L2X0 cache is enabled

Will have look at this one on Monday

I don't see the hang with L2X0 enable on my ES1.0 SDP with the latest Linus's head.

(Mainline 'e78bf5e6cbe837' + Paul's sync timer fix)

The kernel boots fine.

Just checked this again, for me it hangs at some random point.

Tony

#12 lore raw
In reply to Tony Lindgren

Hi,

Quoted 6 lines · Tony Lindgren

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

Quoted 7 lines

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
	Author: Russell King <[email protected]>
	Date:   Tue Jan 11 16:23:04 2011 +0000

	    ARM: sched_clock: allow init_sched_clock() to be called early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

A.

#13 lore raw
Quoted 34 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Aaro Koskinen
Sent: Monday, January 17, 2011 5:07 PM
To: Tony Lindgren; [email protected]
Cc: [email protected]
Subject: Re: Open issues after 2.6.38 merge window

Hi,

Quoted 6 lines · Tony Lindgren

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

Quoted 7 lines

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

Quoted 3 lines

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

Regards,
Santosh

Quoted 1 line

From 8a2d92faa2c21fda24124e75da3ba47930e1eaf6 Mon Sep 17 00:00:00 2001

From: Paul Walmsley <[email protected]>
Date: Sun, 16 Jan 2011 21:08:13 +0530
Subject: [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

Linus's master branch, currently at commit 1b59be2a6cdcb5a12e18d8315c07c94a624de48f ("Merge branch 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6"),
crashes during boot on OMAP4430 ES2.0 Panda:

[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] Unable to handle kernel NULL pointer dereference at virtual
address 00000000
[    0.000000] pgd = c0004000
[    0.000000] [00000000] *pgd=00000000
[    0.000000] Internal error: Oops: 80000005 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
[    0.000000] PC is at 0x0
[    0.000000] LR is at sched_clock_poll+0x2c/0x3c
[    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
[    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
[    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
[    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM
Segment kernel
[    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017

This is due to the recent ARM init_sched_clock() changes and the late initialization of the counter_32k clock source:

http://marc.info/?l=linux-omap&m=129513468605208&w=2

Fix by initializing the counter_32k clocksource during the machine timer initialization.

Reported-by Russell King <[email protected]>
Signed-off-by Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap1/time.c               |    7 +++++++
 arch/arm/mach-omap2/timer-gp.c           |   10 ++++++++--
 arch/arm/plat-omap/counter_32k.c         |    3 +--
 arch/arm/plat-omap/include/plat/common.h |    1 +
 4 files changed, 17 insertions(+), 4 deletions(-)
arch/arm/mach-omap1/time.c +7 -0
index ed7a61f..6ec65e5 100644
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
 
 	omap_init_mpu_timer(rate);
 	omap_init_clocksource(rate);
+	/*
+	 * XXX Since this file seems to deal mostly with the MPU timer,
+	 * this doesn't seem like the correct place for the sync timer
+	 * clocksource init.
+	 */
+	if (!cpu_is_omap7xx() && !cpu_is_omap15xx())
+		omap_init_clocksource_32k();
 }
 
 struct sys_timer omap_timer = {
(quoted diff) +0 -0

b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644

arch/arm/mach-omap2/timer-gp.c +8 -2
@@ -42,6 +42,8 @@
 
 #include "timer-gp.h"
 
+#include <plat/common.h>
+
 /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
 #define MAX_GPTIMER_ID		12
 

@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
 /*
  * When 32k-timer is enabled, don't use GPTimer for clocksource
  * instead, just leave default clocksource which uses the 32k
- * sync counter.  See clocksource setup in see plat-omap/common.c.
+ * sync counter.  See clocksource setup in plat-omap/timer-32k.c
  */
 
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+	omap_init_clocksource_32k();
+}
+
 #else
 /*
  * clocksource
(quoted diff) +0 -0

b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644

arch/arm/plat-omap/counter_32k.c +1 -2
@@ -160,7 +160,7 @@ void read_persistent_clock(struct timespec *ts)
 	*ts = *tsp;
 }
 
-static int __init omap_init_clocksource_32k(void)
+int __init omap_init_clocksource_32k(void)
 {
 	static char err[] __initdata = KERN_ERR
 			"%s: can't register clocksource!\n";

@@ -195,7 +195,6 @@ static int __init omap_init_clocksource_32k(void)
 	}
 	return 0;
 }
-arch_initcall(omap_init_clocksource_32k);
 
 #endif	/* !(defined(CONFIG_ARCH_OMAP730) ||

defined(CONFIG_ARCH_OMAP15XX)) */

(quoted diff) +0 -0

b/arch/arm/plat-omap/include/plat/common.h
index 6b8088e..84c707f 100644

arch/arm/plat-omap/include/plat/common.h +1 -0
@@ -35,6 +35,7 @@ struct sys_timer;
 
 extern void omap_map_common_io(void);
 extern struct sys_timer omap_timer;
+extern int __init omap_init_clocksource_32k(void);
 
 extern void omap_reserve(void);
Signature · 1 line
1.6.0.4

From 8a2d92faa2c21fda24124e75da3ba47930e1eaf6 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <[email protected]>
Date: Sun, 16 Jan 2011 21:08:13 +0530
Subject: [PATCH] OMAP: counter_32k: init clocksource as part of machine timer init

Linus's master branch, currently at commit 1b59be2a6cdcb5a12e18d8315c07c94a624de48f ("Merge branch 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6"),
crashes during boot on OMAP4430 ES2.0 Panda:

[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[    0.000000] pgd = c0004000
[    0.000000] [00000000] *pgd=00000000
[    0.000000] Internal error: Oops: 80000005 [#1] SMP
[    0.000000] last sysfs file:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Tainted: G        W    (2.6.37-07734-g2467802 #7)
[    0.000000] PC is at 0x0
[    0.000000] LR is at sched_clock_poll+0x2c/0x3c
[    0.000000] pc : [<00000000>]    lr : [<c0060b74>]    psr: 600001d3
[    0.000000] sp : c058bfd0  ip : c058a000  fp : 00000000
[    0.000000] r10: 00000000  r9 : 411fc092  r8 : 800330c8
[    0.000000] r7 : c05a08e0  r6 : c0034c48  r5 : c05ffc40  r4 : c0034c4c
[    0.000000] r3 : c05ffe6c  r2 : c05a0bc0  r1 : c059f098  r0 : 00000000
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 10c53c7f  Table: 8000404a  DAC: 00000017

This is due to the recent ARM init_sched_clock() changes and the late initialization of the counter_32k clock source:

http://marc.info/?l=linux-omap&m=129513468605208&w=2

Fix by initializing the counter_32k clocksource during the machine timer initialization.

Reported-by Russell King <[email protected]>
Signed-off-by Paul Walmsley <[email protected]>
---
 arch/arm/mach-omap1/time.c               |    7 +++++++
 arch/arm/mach-omap2/timer-gp.c           |   10 ++++++++--
 arch/arm/plat-omap/counter_32k.c         |    3 +--
 arch/arm/plat-omap/include/plat/common.h |    1 +
 4 files changed, 17 insertions(+), 4 deletions(-)
arch/arm/mach-omap1/time.c +7 -0
index ed7a61f..6ec65e5 100644
@@ -244,6 +244,13 @@ static void __init omap_timer_init(void)
 
 	omap_init_mpu_timer(rate);
 	omap_init_clocksource(rate);
+	/*
+	 * XXX Since this file seems to deal mostly with the MPU timer,
+	 * this doesn't seem like the correct place for the sync timer
+	 * clocksource init.
+	 */
+	if (!cpu_is_omap7xx() && !cpu_is_omap15xx())
+		omap_init_clocksource_32k();
 }
 
 struct sys_timer omap_timer = {
arch/arm/mach-omap2/timer-gp.c +8 -2
index 4e48e78..57d53e0 100644
@@ -42,6 +42,8 @@
 
 #include "timer-gp.h"
 
+#include <plat/common.h>
+
 /* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
 #define MAX_GPTIMER_ID		12
 

@@ -176,10 +178,14 @@ static void __init omap2_gp_clockevent_init(void)
 /* 
  * When 32k-timer is enabled, don't use GPTimer for clocksource
  * instead, just leave default clocksource which uses the 32k
- * sync counter.  See clocksource setup in see plat-omap/common.c. 
+ * sync counter.  See clocksource setup in plat-omap/timer-32k.c
  */
 
-static inline void __init omap2_gp_clocksource_init(void) {}
+static void __init omap2_gp_clocksource_init(void)
+{
+	omap_init_clocksource_32k();
+}
+
 #else
 /*
  * clocksource
arch/arm/plat-omap/counter_32k.c +1 -2
index ea46440..0367998 100644
@@ -160,7 +160,7 @@ void read_persistent_clock(struct timespec *ts)
 	*ts = *tsp;
 }
 
-static int __init omap_init_clocksource_32k(void)
+int __init omap_init_clocksource_32k(void)
 {
 	static char err[] __initdata = KERN_ERR
 			"%s: can't register clocksource!\n";

@@ -195,7 +195,6 @@ static int __init omap_init_clocksource_32k(void)
 	}
 	return 0;
 }
-arch_initcall(omap_init_clocksource_32k);
 
 #endif	/* !(defined(CONFIG_ARCH_OMAP730) || defined(CONFIG_ARCH_OMAP15XX)) */
arch/arm/plat-omap/include/plat/common.h +1 -0
index 6b8088e..84c707f 100644
@@ -35,6 +35,7 @@ struct sys_timer;
 
 extern void omap_map_common_io(void);
 extern struct sys_timer omap_timer;
+extern int __init omap_init_clocksource_32k(void);
 
 extern void omap_reserve(void);
Signature · 1 line
1.6.0.4
#14 lore raw
Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines · Tony Lindgren
Quoted 4 lines

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

This doesn't happen for me.

Quoted 9 lines
Quoted 9 lines
Quoted 2 lines

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
Quoted 7 lines
Quoted 6 lines

ARM: sched_clock: allow init_sched_clock() to be called
early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

There's an issue missing from Tony's list:

- running an omap2plus_defconfig kernel on SMP is unsafe to the point of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write.

This is because when CPU_32v6K is disabled - which is required to build a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP safe bitops only use instructions available to ARMv6K and above. They are reduced to local-irq-disabling, plain byte loads and stores.

So, running omap2plus_defconfig on SMP is risking filesystem corruption.

Patches for this are being worked on, but they won't be ready for -rc1. I strongly suggest someone restores some kind of build or runtime error (eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_ breaking omap2plus_defconfig) before someone ends up with a corrupted filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
#15 lore raw
Quoted 59 lines

-----Original Message-----
From: Russell King [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:42 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]
Subject: Re: Open issues after 2.6.38 merge window

Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines · Tony Lindgren
Quoted 4 lines

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

This doesn't happen for me.

Quoted 5 lines
Quoted 5 lines
Quoted 2 lines

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

Quoted 8 lines
Quoted 8 lines
(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

There's an issue missing from Tony's list:

- running an omap2plus_defconfig kernel on SMP is unsafe to the point
of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write.

This is because when CPU_32v6K is disabled - which is required to build
a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP
safe bitops only use instructions available to ARMv6K and above. They
are reduced to local-irq-disabling, plain byte loads and stores.

So, running omap2plus_defconfig on SMP is risking filesystem corruption.

Quoted 11 lines

Patches for this are being worked on, but they won't be ready for - rc1.
I strongly suggest someone restores some kind of build or runtime error
(eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_
breaking omap2plus_defconfig) before someone ends up with a corrupted
filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment.

Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config.

Regards,
Santosh

#16 lore raw
Quoted 70 lines · Santosh Shilimkar
Quoted 59 lines

-----Original Message-----
From: Russell King [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:42 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]
Subject: Re: Open issues after 2.6.38 merge window

Quoted 5 lines · Santosh Shilimkar
Quoted 5 lines · Tony Lindgren
Quoted 4 lines

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

- NFS root oopses while mounting root

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

This doesn't happen for me.

Quoted 5 lines
Quoted 5 lines
Quoted 2 lines

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

Quoted 8 lines
Quoted 8 lines
(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

There's an issue missing from Tony's list:

- running an omap2plus_defconfig kernel on SMP is unsafe to the point
of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write.

This is because when CPU_32v6K is disabled - which is required to build
a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP
safe bitops only use instructions available to ARMv6K and above. They
are reduced to local-irq-disabling, plain byte loads and stores.

So, running omap2plus_defconfig on SMP is risking filesystem corruption.

Quoted 11 lines

Patches for this are being worked on, but they won't be ready for - rc1.
I strongly suggest someone restores some kind of build or runtime error
(eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_
breaking omap2plus_defconfig) before someone ends up with a corrupted
filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment.

Quoted 2 lines

Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config.

With the problems addressed, I think that removal of !OMAP2 is not strictly required - but I don't like the idea of disabling CPU_32v6K in general as we can't ensure that this kind of thing doesn't happen in the future.

Not disabling CPU_32v6K also fixes the swp_emulate build problem too (which is why I've never seen it here.)

There are several V6K bits that need to be addressed (such as a single clrex vs two instruction strex) before we can properly build a kernel supporting V6 but also containing V6K extensions.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
author maintainer
#17 lore raw
Quoted 16 lines · Russell King
Quoted 15 lines · Santosh Shilimkar
Quoted 15 lines

-----Original Message-----
From: Russell King [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:42 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]
Subject: Re: Open issues after 2.6.38 merge window

Quoted 7 lines · Santosh Shilimkar
Quoted 7 lines · Tony Lindgren
Quoted 6 lines

Before I update out master branch, let's try to summarize the open issues after the merge window. Here's a list of issues in omap-fixes-for-linus that I'm aware of:

- NFS root oopses while mounting root

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

- omap4430 es1.0 hangs if L2X0 cache is enabled

- omap4 panda powers down after boot (watchdog?)

- omap3 ldp board powers down after boot?

This doesn't happen for me.

OK, good to hear that's a separate issue and fixed.

Quoted 47 lines
Quoted 47 lines
Quoted 47 lines
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines

Any other issues?

Amstrad E3 fails during the boot. Bisection points to:

Quoted 8 lines
Quoted 8 lines
(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

There's an issue missing from Tony's list:

- running an omap2plus_defconfig kernel on SMP is unsafe to the point
of being data corrupting for filesystems, especially for ext2/ext3 mounted read-write.

This is because when CPU_32v6K is disabled - which is required to build
a kernel to boot on ARMv6, it turns off the SMP safe bitops - the SMP
safe bitops only use instructions available to ARMv6K and above. They
are reduced to local-irq-disabling, plain byte loads and stores.

So, running omap2plus_defconfig on SMP is risking filesystem corruption.

Patches for this are being worked on, but they won't be ready for - rc1.
I strongly suggest someone restores some kind of build or runtime error
(eg, by removing CPU_32v6K's dependence on !OMAP2 - thereby _intentionally_
breaking omap2plus_defconfig) before someone ends up with a corrupted
filesystem. Or just make sure that everyone is aware that omap2plus_defconfig can eat filesystems at the moment.

Quoted 7 lines
Quoted 2 lines

Thanks. I missed your other patch of removing !OMAP2 from CPU_32v6K config.

With the problems addressed, I think that removal of !OMAP2 is not strictly required - but I don't like the idea of disabling CPU_32v6K in general as we can't ensure that this kind of thing doesn't happen in the future.

For the current -rc cycle, is the spinlock fix is enough while keeping CPU_32v6K disabled?

Quoted 6 lines

Not disabling CPU_32v6K also fixes the swp_emulate build problem too (which is why I've never seen it here.)

There are several V6K bits that need to be addressed (such as a single clrex vs two instruction strex) before we can properly build a kernel supporting V6 but also containing V6K extensions.

I agree building in the V6K extensions would the best solution in the long run.

Regards,

Tony

#18 lore raw
In reply to Santosh Shilimkar

Hi,

Quoted 6 lines · Santosh Shilimkar
Quoted 6 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
Quoted 7 lines
Quoted 6 lines

ARM: sched_clock: allow init_sched_clock() to be called
early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

I don't see how it could help? Amstrad E3 is OMAP 15xx.

A.

#19 lore raw
Quoted 20 lines

-----Original Message-----
From: Aaro Koskinen [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:52 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]; [email protected]
Subject: RE: Open issues after 2.6.38 merge window

Hi,

Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

Quoted 8 lines
Quoted 1 line
Quoted 1 line

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

I don't see how it could help? Amstrad E3 is OMAP 15xx.

I read patch again and omap15xx is skipped. Not sure why 15xx is skipped.

Regards,
Santosh

#20 lore raw
Quoted 22 lines · Santosh Shilimkar
Quoted 22 lines

-----Original Message-----
From: Aaro Koskinen [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:52 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]; [email protected]
Subject: RE: Open issues after 2.6.38 merge window

Hi,

Quoted 10 lines · Santosh Shilimkar
Quoted 10 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

I don't see how it could help? Amstrad E3 is OMAP 15xx.

I read patch again and omap15xx is skipped. Not sure why 15xx is skipped.

EWW. This is horrible - and too far complicated.

So if we build a kernel with OMAP730 or OMAP15xx support, the 32k counter support is disabled for every platform, which also removes sched_clock() support (as this uses the 32k timer).

If CONFIG_OMAP_32K_TIMER is also true (eg, because you enabled OMAP16xx) then we won't have the GP clocksource code. So a kernel which is configured for OMAP15xx + OMAP16xx won't have any clocksource code at all.

In effect, all this being done by _negative_ dependencies. As has been seen with deselecting the V6K configuration symbol, negative dependencies are Bad News(tm).

This code needs to be restructured for positive dependencies and proper selection of the appopriate clock sources - which then needs to be coupled into sched_clock() properly so OMAP15xx can also benefit from sched_clock() support.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
author maintainer
#21 lore raw
Quoted 43 lines · Russell King
Quoted 22 lines · Santosh Shilimkar
Quoted 22 lines

-----Original Message-----
From: Aaro Koskinen [mailto:[email protected]]
Sent: Monday, January 17, 2011 5:52 PM
To: Santosh Shilimkar
Cc: Aaro Koskinen; Tony Lindgren; [email protected]; [email protected]
Subject: RE: Open issues after 2.6.38 merge window

Hi,

Quoted 10 lines · Santosh Shilimkar
Quoted 10 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

The board does not have sched_clock(), although HAVE_SCHED_CLOCK

is

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines

defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

I don't see how it could help? Amstrad E3 is OMAP 15xx.

I read patch again and omap15xx is skipped. Not sure why 15xx is skipped.

EWW. This is horrible - and too far complicated.

So if we build a kernel with OMAP730 or OMAP15xx support, the 32k counter support is disabled for every platform, which also removes sched_clock() support (as this uses the 32k timer).

If CONFIG_OMAP_32K_TIMER is also true (eg, because you enabled OMAP16xx) then we won't have the GP clocksource code. So a kernel which is configured for OMAP15xx + OMAP16xx won't have any clocksource code at all.

Quoted 8 lines

In effect, all this being done by _negative_ dependencies. As has been seen with deselecting the V6K configuration symbol, negative dependencies are Bad News(tm).

This code needs to be restructured for positive dependencies and proper selection of the appopriate clock sources - which then needs to be coupled into sched_clock() properly so OMAP15xx can also benefit from sched_clock() support.

I'll take a look at fixing this. Sounds like we need both MPU timer and the 32K timer compiled in, then enable the right one based on runtime checks.

Regards,

Tony

#22 lore raw
In reply to Aaro Koskinen
Quoted 10 lines · Aaro Koskinen
Quoted 9 lines · Santosh Shilimkar
Quoted 9 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

Quoted 6 lines
Quoted 4 lines
Quoted 3 lines

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

I don't see how it could help? Amstrad E3 is OMAP 15xx.

OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support.

Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx.

- Paul

#23 lore raw
Quoted 17 lines · Paul Walmsley
Quoted 15 lines · Aaro Koskinen
Quoted 13 lines · Santosh Shilimkar
Quoted 9 lines

Amstrad E3 fails during the boot. Bisection points to:

(quoted diff) +0 -0
 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <[email protected]>
 	Date:   Tue Jan 11 16:23:04 2011 +0000
 
 	    ARM: sched_clock: allow init_sched_clock() to be called

early

Quoted 3 lines

The board does not have sched_clock(), although HAVE_SCHED_CLOCK is defined for all OMAP.

I guess above is sorted out by the attached patch from Paul.

Quoted 8 lines
Quoted 1 line

I don't see how it could help? Amstrad E3 is OMAP 15xx.

OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support.

Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx.

No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock. We just need to switch to the variable rate implementation rather than the fixed rate if we include OMAP15xx/7xx support.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
#24 lore raw
Quoted 11 lines · Russell King
Quoted 7 lines · Paul Walmsley

OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support.

Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx.

No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock.

There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER IP blocks are only present on OMAP1610 and later[1]. Nor is a SYNCTIMER_32K IP block present on OMAP15xx/7xx[2].

That said, the clocksource code in the OMAP tree could definitely use some cleanup. The SYNCTIMER_32K/counter_32k clocksource should be registered from the plat-omap/counter_32k.c. And your point about the compile-time negative dependencies is also a good one, now that omap1_defconfig exists.

- Paul

1. Current mainline source code for arch/arm/plat-omap/dmtimer.c, line 168:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/dmtimer.c;h=1d706cf63ca0e697521d38ab814d9889a1b70435;hb=refs/heads/master#l168

2. Current mainline source code for arch/arm/plat-omap/counter_32k.c, line 39:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/plat-omap/counter_32k.c;h=ea4644021fb9c0867c2e4ca4bd4bcb118e863f80;hb=refs/heads/master#l39

3. ibid.

#25 lore raw
Quoted 11 lines · Paul Walmsley
Quoted 9 lines · Russell King
Quoted 7 lines · Paul Walmsley

OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support.

Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx.

Quoted 6 lines
Quoted 2 lines

No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock.

There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER IP blocks are only present on OMAP1610 and later[1]. Nor is a SYNCTIMER_32K IP block present on OMAP15xx/7xx[2].

Yes I realise that. That doesn't negate what I said though. Let me show you how to do it:

static DEFINE_CLOCK_DATA(cd);

static inline u32 32k_read_cycles(void)
{
...
}

static inline u32 gpt_read_cycles(void)
{
...
}

#if defined(GPTIMER) && defined(32KTIMER)
static u32 (*omap_read_cycles)(void);
#elif defined(32KTIMER)
#define SC_MULT 4000000000u
#define SC_SHIFT 17
#define omap_read_cycles 32k_read_cycles
#else
#define SC_MULT gpt_value_if_fixed
#define SC_SHIFT gpt_value_if_fixed
#define omap_read_cycles gpt_read_cycles
#endif

unsigned long long notrace sched_clock(void)

{
	u32 cyc = omap_read_cycles();
#ifdef SC_MULT
	return cyc_to_fixed_sched_clock(&cd, cyc, (u32)~0, SC_MULT, SC_SHIFT);
#else
	return cyc_to_sched_clock(&cd, cyc, (u32)~0);

#endif
}

static void notrace omap_update_sched_clock(void)

{
	u32 cyc = omap_read_cycles();
	update_sched_clock(&cd, cyc, (u32)~0);
}

void omap_init_sched_clock(int gpt)

{
	unsigned long rate;
#ifndef omap_read_cycles
	omap_read_cycles = gpt ? gpt_read_cycles : 32k_read_cycles;

#endif

	if (gpt)
		rate = gpt_rate;
	else
		rate = 32768;
#ifdef SC_MULT
	init_fixed_sched_clock(&cd, omap_update_sched_clock, 32, rate
			       SC_MULT, SC_SHIFT);
#else
	init_sched_clock(&cd, omap_update_sched_clock, 32, rate);

#endif
}

Both a GPT _and_ 32K sched_clock implementation together, selectable at runtime or build time depending on what is selected. I'll give you that it isn't nice code, but it does what's required.

Signature · 3 lines
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
#26 lore raw
Quoted 20 lines · Russell King
Quoted 10 lines · Paul Walmsley
Quoted 9 lines · Russell King
Quoted 7 lines · Paul Walmsley

OMAP15xx uses the MPU timer for its clocksource, since OMAP15xx doesn't have GPTIMERs or the 32k sync timer, and the MPU timer code in mach-omap1/time.c wasn't updated for sched_clock() support.

Adding an init_fixed_sched_clock() into omap_init_clocksource() should fix the boot on OMAP15xx/7xx.

Quoted 6 lines
Quoted 2 lines

No, it needs fixing properly. There's no reason the gpt clocksource can't be used for sched_clock.

There's a very good reason why it can't on OMAP15xx/7xx. GPTIMER/DMTIMER IP blocks are only present on OMAP1610 and later[1]. Nor is a SYNCTIMER_32K IP block present on OMAP15xx/7xx[2].

Yes I realise that. That doesn't negate what I said though. Let me show you how to do it:

...

Quoted 3 lines

Both a GPT _and_ 32K sched_clock implementation together, selectable at runtime or build time depending on what is selected. I'll give you that it isn't nice code, but it does what's required.

Right. I agree that it is possible to support both GPTIMER and 32KiHz clocksources at runtime. But there should be a third case in that code also, a case for the OMAP1 MPU Timer IP blocks.

Of course, it would be technically possible to define "GPT"/"GPTIMER" to mean "MPU Timer" on OMAP15xx/OMAP7xx. However, later OMAP1 chips contain all three of the above-mentioned timer IP blocks: GPTIMERs[1], a SYNCTIMER_32K[2], and the MPU Timers[3]. Each of these timers also has distinct power, interconnect, and register access properties. So it seems less confusing to keep the MPU Timer case distinct from the GPTIMER/GPT case.

- Paul

1. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.5, "Dual-Mode Timer"

2. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.6, "32-kHz Synchronized Timer"

3. OMAP1611/12 Multimedia Processor Technical Reference Manual [SWPU066B], section 13.4, "OMAP3.2 Operating System Timer"