Open issues after 2.6.38 merge window

Open issues after 2.6.38 merge window

[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

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110114 11:47]:
> 
> - NFS root oopses while mounting root

Looks like this one is now fixed.

Tony

Re: Open issues after 2.6.38 merge window

[Jarkko Nikula]

On Fri, 14 Jan 2011 11:47:58 -0800
Tony Lindgren <tony@atomide.com> 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.

-- 
Jarkko

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Jarkko Nikula <jhnikula@gmail.com> [110114 12:34]:
> On Fri, 14 Jan 2011 11:47:58 -0800
> Tony Lindgren <tony@atomide.com> 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.

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

Re: Open issues after 2.6.38 merge window

[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

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



On 01/14/2011 01:47 PM, Tony Lindgren wrote:
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

Re: Open issues after 2.6.38 merge window

[Nishanth Menon]

Tony Lindgren wrote, on 01/14/2011 02:54 PM:
> * Jarkko Nikula<jhnikula@gmail.com>  [110114 12:34]:
>> On Fri, 14 Jan 2011 11:47:58 -0800
>> Tony Lindgren<tony@atomide.com>  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.
>
> 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.

-- 
Regards,
Nishanth Menon

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* David Anders <x0132446@ti.com> [110114 12:56]:
> 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

That's what I'm using too.
 
> 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

Re: Open issues after 2.6.38 merge window

[Thomas Weber]

Am 14.01.2011 20:47, schrieb 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 majordomo@vger.kernel.org
> 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 ]---

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [110114 15:38]:
> * David Anders <x0132446@ti.com> [110114 12:56]:
> > 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
> 
> That's what I'm using too.
>  
> > 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.

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

RE: Open issues after 2.6.38 merge window

[Santosh Shilimkar]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Saturday, January 15, 2011 1:18 AM
> To: linux-omap@vger.kernel.org
> Subject: Open issues after 2.6.38 merge window
>
> 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

> - omap4 panda powers down after boot (watchdog?)
>
Must be watchdog

> - omap3 ldp board powers down after boot?
>
I guess this was already concluded as a watchdog issue.


> 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

RE: Open issues after 2.6.38 merge window

[Santosh Shilimkar]

Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar@ti.com]
> Sent: Saturday, January 15, 2011 10:50 AM
> To: Tony Lindgren; linux-omap@vger.kernel.org
> Subject: RE: Open issues after 2.6.38 merge window
>
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Saturday, January 15, 2011 1:18 AM
> > To: linux-omap@vger.kernel.org
> > Subject: Open issues after 2.6.38 merge window
> >
> > 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
>
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

Re: Open issues after 2.6.38 merge window

[Aaro Koskinen]

Hi,

On Fri, 14 Jan 2011, Tony Lindgren wrote:
> 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?

Amstrad E3 fails during the boot. Bisection points to:

 	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
 	Author: Russell King <rmk+kernel@arm.linux.org.uk>
 	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.

RE: Open issues after 2.6.38 merge window

[Santosh Shilimkar]

[-- Attachment #1: Type: text/plain, Size: 5866 bytes --]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Aaro Koskinen
> Sent: Monday, January 17, 2011 5:07 PM
> To: Tony Lindgren; rmk+kernel@arm.linux.org.uk
> Cc: linux-omap@vger.kernel.org
> Subject: Re: Open issues after 2.6.38 merge window
>
> Hi,
>
> On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > 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?
>
> Amstrad E3 fails during the boot. Bisection points to:
>
>  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
>  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
>  	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.
>
I guess above is sorted out by the attached patch from Paul.

Regards,
Santosh


>From 8a2d92faa2c21fda24124e75da3ba47930e1eaf6 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <paul@pwsan.com>
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 <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -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 = {
diff --git a/arch/arm/mach-omap2/timer-gp.c
b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -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
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -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)) */

diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 6b8088e..84c707f 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -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);

-- 
1.6.0.4

[-- Attachment #2: 0001-OMAP-counter_32k-init-clocksource-as-part-of-machi.patch --]
[-- Type: application/octet-stream, Size: 4633 bytes --]

From 8a2d92faa2c21fda24124e75da3ba47930e1eaf6 Mon Sep 17 00:00:00 2001
From: Paul Walmsley <paul@pwsan.com>
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 <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c
index ed7a61f..6ec65e5 100644
--- a/arch/arm/mach-omap1/time.c
+++ b/arch/arm/mach-omap1/time.c
@@ -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 = {
diff --git a/arch/arm/mach-omap2/timer-gp.c b/arch/arm/mach-omap2/timer-gp.c
index 4e48e78..57d53e0 100644
--- a/arch/arm/mach-omap2/timer-gp.c
+++ b/arch/arm/mach-omap2/timer-gp.c
@@ -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
diff --git a/arch/arm/plat-omap/counter_32k.c b/arch/arm/plat-omap/counter_32k.c
index ea46440..0367998 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -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)) */
 
diff --git a/arch/arm/plat-omap/include/plat/common.h b/arch/arm/plat-omap/include/plat/common.h
index 6b8088e..84c707f 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -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);
 
-- 
1.6.0.4

Re: Open issues after 2.6.38 merge window

[Russell King]

On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote:
> > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > > 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?

This doesn't happen for me.

> > >
> > > Any other issues?
> >
> > Amstrad E3 fails during the boot. Bisection points to:
> >
> >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> >  	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.
> >
> 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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

RE: Open issues after 2.6.38 merge window

[Santosh Shilimkar]

> -----Original Message-----
> From: Russell King [mailto:rmk@arm.linux.org.uk]
> Sent: Monday, January 17, 2011 5:42 PM
> To: Santosh Shilimkar
> Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org
> Subject: Re: Open issues after 2.6.38 merge window
>
> On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote:
> > > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > > > 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?
>
> This doesn't happen for me.
>
> > > >
> > > > Any other issues?
> > >
> > > Amstrad E3 fails during the boot. Bisection points to:
> > >
> > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > >  	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.
> > >
> > 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.
>
Thanks. I missed your other patch of removing !OMAP2 from
CPU_32v6K config.

Regards,
Santosh

RE: Open issues after 2.6.38 merge window

[Aaro Koskinen]

Hi,

On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
>> Amstrad E3 fails during the boot. Bisection points to:
>>
>>  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
>>  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
>>  	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.
>>
> 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.

Re: Open issues after 2.6.38 merge window

[Russell King]

On Mon, Jan 17, 2011 at 05:49:00PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Russell King [mailto:rmk@arm.linux.org.uk]
> > Sent: Monday, January 17, 2011 5:42 PM
> > To: Santosh Shilimkar
> > Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org
> > Subject: Re: Open issues after 2.6.38 merge window
> >
> > On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote:
> > > > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > > > > 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?
> >
> > This doesn't happen for me.
> >
> > > > >
> > > > > Any other issues?
> > > >
> > > > Amstrad E3 fails during the boot. Bisection points to:
> > > >
> > > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > >  	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.
> > > >
> > > 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.
> >
> 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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

RE: Open issues after 2.6.38 merge window

[Santosh Shilimkar]

> -----Original Message-----
> From: Aaro Koskinen [mailto:aaro.koskinen@nokia.com]
> Sent: Monday, January 17, 2011 5:52 PM
> To: Santosh Shilimkar
> Cc: Aaro Koskinen; Tony Lindgren; rmk+kernel@arm.linux.org.uk;
> linux-omap@vger.kernel.org
> Subject: RE: Open issues after 2.6.38 merge window
>
> Hi,
>
> On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
> >> Amstrad E3 fails during the boot. Bisection points to:
> >>
> >>  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> >>  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> >>  	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.
> >>
> > 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

Re: Open issues after 2.6.38 merge window

[Russell King]

On Mon, Jan 17, 2011 at 06:05:36PM +0530, Santosh Shilimkar wrote:
> > -----Original Message-----
> > From: Aaro Koskinen [mailto:aaro.koskinen@nokia.com]
> > Sent: Monday, January 17, 2011 5:52 PM
> > To: Santosh Shilimkar
> > Cc: Aaro Koskinen; Tony Lindgren; rmk+kernel@arm.linux.org.uk;
> > linux-omap@vger.kernel.org
> > Subject: RE: Open issues after 2.6.38 merge window
> >
> > Hi,
> >
> > On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
> > >> Amstrad E3 fails during the boot. Bisection points to:
> > >>
> > >>  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > >>  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > >>  	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.
> > >>
> > > 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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Russell King <rmk@arm.linux.org.uk> [110117 04:49]:
> On Mon, Jan 17, 2011 at 06:05:36PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Aaro Koskinen [mailto:aaro.koskinen@nokia.com]
> > > Sent: Monday, January 17, 2011 5:52 PM
> > > To: Santosh Shilimkar
> > > Cc: Aaro Koskinen; Tony Lindgren; rmk+kernel@arm.linux.org.uk;
> > > linux-omap@vger.kernel.org
> > > Subject: RE: Open issues after 2.6.38 merge window
> > >
> > > Hi,
> > >
> > > On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
> > > >> Amstrad E3 fails during the boot. Bisection points to:
> > > >>
> > > >>  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > > >>  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > >>  	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.
> > > >>
> > > > 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.

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

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Russell King <rmk@arm.linux.org.uk> [110117 04:24]:
> On Mon, Jan 17, 2011 at 05:49:00PM +0530, Santosh Shilimkar wrote:
> > > -----Original Message-----
> > > From: Russell King [mailto:rmk@arm.linux.org.uk]
> > > Sent: Monday, January 17, 2011 5:42 PM
> > > To: Santosh Shilimkar
> > > Cc: Aaro Koskinen; Tony Lindgren; linux-omap@vger.kernel.org
> > > Subject: Re: Open issues after 2.6.38 merge window
> > >
> > > On Mon, Jan 17, 2011 at 05:29:01PM +0530, Santosh Shilimkar wrote:
> > > > > On Fri, 14 Jan 2011, Tony Lindgren wrote:
> > > > > > 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?
> > >
> > > This doesn't happen for me.

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

> > > > > >
> > > > > > Any other issues?
> > > > >
> > > > > Amstrad E3 fails during the boot. Bisection points to:
> > > > >
> > > > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > > > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > > >  	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.
> > > > >
> > > > 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.
> > >
> > 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?
 
> 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

RE: Open issues after 2.6.38 merge window

[Paul Walmsley]

On Mon, 17 Jan 2011, Aaro Koskinen wrote:

> On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
> > > Amstrad E3 fails during the boot. Bisection points to:
> > > 
> > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > >  	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.
> > > 
> > 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

Re: Open issues after 2.6.38 merge window

[Russell King]

On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote:
> On Mon, 17 Jan 2011, Aaro Koskinen wrote:
> 
> > On Mon, 17 Jan 2011, Santosh Shilimkar wrote:
> > > > Amstrad E3 fails during the boot. Bisection points to:
> > > > 
> > > >  	commit 211baa7016894c02fc18693e21ca479cd08ac0c0
> > > >  	Author: Russell King <rmk+kernel@arm.linux.org.uk>
> > > >  	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.
> > > > 
> > > 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.

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: Open issues after 2.6.38 merge window

[Paul Walmsley]

On Mon, 17 Jan 2011, Russell King wrote:

> On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote:
> > 
> > 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.

Re: Open issues after 2.6.38 merge window

[Russell King]

On Mon, Jan 17, 2011 at 02:00:17PM -0700, Paul Walmsley wrote:
> On Mon, 17 Jan 2011, Russell King wrote:
> 
> > On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote:
> > > 
> > > 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].

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.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: Open issues after 2.6.38 merge window

[Paul Walmsley]

On Mon, 17 Jan 2011, Russell King wrote:

> On Mon, Jan 17, 2011 at 02:00:17PM -0700, Paul Walmsley wrote:
> > On Mon, 17 Jan 2011, Russell King wrote:
> > > On Mon, Jan 17, 2011 at 01:31:47PM -0700, Paul Walmsley wrote:
> > > > 
> > > > 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].
> 
> Yes I realise that.  That doesn't negate what I said though.  Let me
> show you how to do it:

...

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

Re: Open issues after 2.6.38 merge window

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [110117 02:14]:
> >
> > > - 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