[Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

Hi,
I'm trying to get xenomai-2.6.1 running on an ixp4xx board
with kernel 3.2.21.

The kernel boots with Xenomai and IPIPE disabled in the kernel configuration.

The kernel also boots with Xenmai disabled and IPIPE enabled.

But the kernel does not boot correctly with both, Xenomai and IPIPE enabled.

Using a JTAG debugger i found that the kernel always hits a breakpoint
On xnintr_clock_handler() with this backtrace:

 #1  0xc00516b8 in __ipipe_dispatch_irq_fast (irq=5) at kernel/ipipe/core.c:1272
#2  0xc00083b0 in __ipipe_grab_irq (irq=<optimized out>, regs=0xc381ff30) at arch/arm/kernel/ipipe.c:458
#3  0xc0008db0 in __irq_svc () at arch/arm/kernel/entry-armv.S:216

The last line is repeated very often, but i think this is just a gdb artefact.
The kernel seems to loop in __irq_svc->__ipipe_grab_irq->__irq_svc.
Maybe the timer interrupt is not cleared and therefore executed as soon as the
IRQ service function finishes?

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/19/2012 01:27 PM, Michael Lausch wrote:
> Hi,
> I'm trying to get xenomai-2.6.1 running on an ixp4xx board
> with kernel 3.2.21.
> 
> The kernel boots with Xenomai and IPIPE disabled in the kernel configuration.
> 
> The kernel also boots with Xenmai disabled and IPIPE enabled.
> 
> But the kernel does not boot correctly with both, Xenomai and IPIPE enabled.
> 
> Using a JTAG debugger i found that the kernel always hits a breakpoint
> On xnintr_clock_handler() with this backtrace:
> 
>  #1  0xc00516b8 in __ipipe_dispatch_irq_fast (irq=5) at kernel/ipipe/core.c:1272
> #2  0xc00083b0 in __ipipe_grab_irq (irq=<optimized out>, regs=0xc381ff30) at arch/arm/kernel/ipipe.c:458
> #3  0xc0008db0 in __irq_svc () at arch/arm/kernel/entry-armv.S:216
> 
> The last line is repeated very often, but i think this is just a gdb artefact.
> The kernel seems to loop in __irq_svc->__ipipe_grab_irq->__irq_svc.
> Maybe the timer interrupt is not cleared and therefore executed as soon as the
> IRQ service function finishes?

Please try the following patch:

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index f4b878e..cafa9fa 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -593,6 +593,7 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
 static struct ipipe_timer ixp4xx_itimer = {
        .irq = IRQ_IXP4XX_TIMER1,
        .min_delay_ticks = 333, /* 5 usec with the 66.66 MHz system clock */
+       .ack = ixp4xx_timer_ack,
 };
 #endif /* CONFIG_IPIPE */



-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

Hi,
Yep this fixes the boot error.

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Friday, July 20, 2012 7:07 PM
To: Michael Lausch
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

On 07/19/2012 01:27 PM, Michael Lausch wrote:
> Hi,
> I'm trying to get xenomai-2.6.1 running on an ixp4xx board
> with kernel 3.2.21.
> 
> The kernel boots with Xenomai and IPIPE disabled in the kernel configuration.
> 
> The kernel also boots with Xenmai disabled and IPIPE enabled.
> 
> But the kernel does not boot correctly with both, Xenomai and IPIPE enabled.
> 
> Using a JTAG debugger i found that the kernel always hits a breakpoint
> On xnintr_clock_handler() with this backtrace:
> 
>  #1  0xc00516b8 in __ipipe_dispatch_irq_fast (irq=5) at kernel/ipipe/core.c:1272
> #2  0xc00083b0 in __ipipe_grab_irq (irq=<optimized out>, regs=0xc381ff30) at arch/arm/kernel/ipipe.c:458
> #3  0xc0008db0 in __irq_svc () at arch/arm/kernel/entry-armv.S:216
> 
> The last line is repeated very often, but i think this is just a gdb artefact.
> The kernel seems to loop in __irq_svc->__ipipe_grab_irq->__irq_svc.
> Maybe the timer interrupt is not cleared and therefore executed as soon as the
> IRQ service function finishes?

Please try the following patch:

diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index f4b878e..cafa9fa 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -593,6 +593,7 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
 static struct ipipe_timer ixp4xx_itimer = {
        .irq = IRQ_IXP4XX_TIMER1,
        .min_delay_ticks = 333, /* 5 usec with the 66.66 MHz system clock */
+       .ack = ixp4xx_timer_ack,
 };
 #endif /* CONFIG_IPIPE */



-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/23/2012 12:28 PM, Michael Lausch wrote:

> Hi,
> Yep this fixes the boot error.


Good news. 

We have a pending issue on ixp4xx however: ixp4xx is the only arm SOC 
port not  using the "kuser" tsc emulation. It still works with xenomai 
2.6, but xenomai 3.x requires the arm SOC ports to use the kuser tsc.

I had done the necessary modifications at some point in the past:
http://git.denx.de/ipipe.git/?p=ipipe.git;a=commit;h=cbd591ed5797f105ff45e04cca3bc939388624ea

But it did not work, so we decided to revert it. Now, it would be nice 
if you could try it again and see if it still does not work.


-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

I'll be looking into this. 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Monday, July 23, 2012 12:38 PM
To: Michael Lausch
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

On 07/23/2012 12:28 PM, Michael Lausch wrote:

> Hi,
> Yep this fixes the boot error.


Good news. 

We have a pending issue on ixp4xx however: ixp4xx is the only arm SOC 
port not  using the "kuser" tsc emulation. It still works with xenomai 
2.6, but xenomai 3.x requires the arm SOC ports to use the kuser tsc.

I had done the necessary modifications at some point in the past:
http://git.denx.de/ipipe.git/?p=ipipe.git;a=commit;h=cbd591ed5797f105ff45e04cca3bc939388624ea

But it did not work, so we decided to revert it. Now, it would be nice 
if you could try it again and see if it still does not work.


-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

Hi,
I've some patches lying around against linux 3.0.x and xenomai 2.6 which compile and 
the "No kuser TSC emulation" (sp?)  message when starting a xenomai application is not printed any more.
I will merge them with the ipipe patch mentioned  in your post. (have i mentioned, i don't like outlook?). 

Can you point me to an acid test which i can use to verify if kuser TSC emulation is working correctly?

-----Original Message-----
From: xenomai-bounces@xenomai.org [mailto:xenomai-bounces@xenomai.org] On Behalf Of Michael Lausch
Sent: Monday, July 23, 2012 12:48 PM
To: Gilles Chanteperdrix
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

I'll be looking into this. 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Monday, July 23, 2012 12:38 PM
To: Michael Lausch
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

On 07/23/2012 12:28 PM, Michael Lausch wrote:

> Hi,
> Yep this fixes the boot error.


Good news. 

We have a pending issue on ixp4xx however: ixp4xx is the only arm SOC 
port not  using the "kuser" tsc emulation. It still works with xenomai 
2.6, but xenomai 3.x requires the arm SOC ports to use the kuser tsc.

I had done the necessary modifications at some point in the past:
http://git.denx.de/ipipe.git/?p=ipipe.git;a=commit;h=cbd591ed5797f105ff45e04cca3bc939388624ea

But it did not work, so we decided to revert it. Now, it would be nice 
if you could try it again and see if it still does not work.


-- 
                                                                Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/24/2012 08:49 AM, Michael Lausch wrote:

> Hi,
> I've some patches lying around against linux 3.0.x and xenomai 2.6 which compile and 
> the "No kuser TSC emulation" (sp?)  message when starting a xenomai application is not printed any more.
> I will merge them with the ipipe patch mentioned  in your post. (have i mentioned, i don't like outlook?). 
> 
> Can you point me to an acid test which i can use to verify if kuser TSC emulation is working correctly?


The "tsc" test in xenomai regression testsuite. Run it with "-w" and it
will try and read the tsc for as long as it takes for the hardware
counter to wrap.


-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/24/2012 08:51 AM, Gilles Chanteperdrix wrote:

> On 07/24/2012 08:49 AM, Michael Lausch wrote:
> 
>> Hi,
>> I've some patches lying around against linux 3.0.x and xenomai 2.6 which compile and 
>> the "No kuser TSC emulation" (sp?)  message when starting a xenomai application is not printed any more.
>> I will merge them with the ipipe patch mentioned  in your post. (have i mentioned, i don't like outlook?). 
>>
>> Can you point me to an acid test which i can use to verify if kuser TSC emulation is working correctly?
> 
> 
> The "tsc" test in xenomai regression testsuite. Run it with "-w" and it
> will try and read the tsc for as long as it takes for the hardware
> counter to wrap.


ping, any news about these patches?

-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

Sorry for the delay, but holiday season takes its toll (needed to cover a 2nd project as well). 
I've successfully booted a kernel with userspace tsc emulation enabled.
The output from the "tsc" testprogram looks like:
	
	min: 12, max: 21, avg: 12
	min: 12, max: 21, avg: 12
	min: 12, max: 18, avg: 12
	min: 12, max: 21, avg: 12
	min: 12, max: 21, avg: 12
	min: 12, max: 21, avg: 12
	......
	Min: 12, max: 26, avg: 12 ->0.180002 us

Does this look correct to you?

I have one question though:
What is the meaning of the min_delay_tick element of the ipipe_timer struct? i just
Used a random value here. 

If the result of the test program looks good to you, i'm going to clean up the patch and i can post it against a 
xenomai 2.6.1 patched 3.2.23 vanilla linux kernel.



-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Thursday, July 26, 2012 10:22 PM
To: Michael Lausch
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

On 07/24/2012 08:51 AM, Gilles Chanteperdrix wrote:

> On 07/24/2012 08:49 AM, Michael Lausch wrote:
> 
>> Hi,
>> I've some patches lying around against linux 3.0.x and xenomai 2.6 which compile and 
>> the "No kuser TSC emulation" (sp?)  message when starting a xenomai application is not printed any more.
>> I will merge them with the ipipe patch mentioned  in your post. (have i mentioned, i don't like outlook?). 
>>
>> Can you point me to an acid test which i can use to verify if kuser TSC emulation is working correctly?
> 
> 
> The "tsc" test in xenomai regression testsuite. Run it with "-w" and it
> will try and read the tsc for as long as it takes for the hardware
> counter to wrap.


ping, any news about these patches?

-- 
                                                                Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/30/2012 06:03 PM, Michael Lausch wrote:
> Sorry for the delay, but holiday season takes its toll (needed to cover a 2nd project as well). 
> I've successfully booted a kernel with userspace tsc emulation enabled.
> The output from the "tsc" testprogram looks like:
> 	
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 18, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	......
> 	Min: 12, max: 26, avg: 12 ->0.180002 us
> 
> Does this look correct to you?

Yes, it means that there were no problems when the counter wrapped (if
you ran the tsc program with the "-w" argument). A 180ns latency does
not look bad.

> 
> I have one question though:
> What is the meaning of the min_delay_tick element of the ipipe_timer struct? i just
> Used a random value here. 

It is not related with the tsc. It is the ipipe_timer implementation,
and it is normally already set. For ixp4xx, there is normally:

#ifdef CONFIG_IPIPE
static struct ipipe_timer ixp4xx_itimer = {
        .irq = IRQ_IXP4XX_TIMER1,
        .min_delay_ticks = 333, /* 5 usec with the 66.66 MHz system clock */
};
#endif /* CONFIG_IPIPE */

min_delay_ticks is explained here:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#The_general_case

It is the delay below which the timer can not be programmed successfully
(this happens for timers based on free-running counters and match
registers, but also as a documented limitation of some other hardware
timers).

> 
> If the result of the test program looks good to you, i'm going to clean up the patch and i can post it against a 
> xenomai 2.6.1 patched 3.2.23 vanilla linux kernel.

Please stay with 3.2.21, as the update to 3.2.23 may bring new conflicts.

-- 
					    Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Michael Lausch]

Ok.
Will prepare the patch for 3.2.21, but I'll be using 3.2.max until I have to freeze the kernel version.
As always I read your email with the pointer to the very nice ipipe porting guide *after* I pressed the
Send button. There's also the exaplanation of the ipipe_timer struct and I'll use the info in there to 
clean up my patch. 

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: Monday, July 30, 2012 6:28 PM
To: Michael Lausch
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

On 07/30/2012 06:03 PM, Michael Lausch wrote:
> Sorry for the delay, but holiday season takes its toll (needed to cover a 2nd project as well). 
> I've successfully booted a kernel with userspace tsc emulation enabled.
> The output from the "tsc" testprogram looks like:
> 	
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 18, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	min: 12, max: 21, avg: 12
> 	......
> 	Min: 12, max: 26, avg: 12 ->0.180002 us
> 
> Does this look correct to you?

Yes, it means that there were no problems when the counter wrapped (if
you ran the tsc program with the "-w" argument). A 180ns latency does
not look bad.

> 
> I have one question though:
> What is the meaning of the min_delay_tick element of the ipipe_timer struct? i just
> Used a random value here. 

It is not related with the tsc. It is the ipipe_timer implementation,
and it is normally already set. For ixp4xx, there is normally:

#ifdef CONFIG_IPIPE
static struct ipipe_timer ixp4xx_itimer = {
        .irq = IRQ_IXP4XX_TIMER1,
        .min_delay_ticks = 333, /* 5 usec with the 66.66 MHz system clock */
};
#endif /* CONFIG_IPIPE */

min_delay_ticks is explained here:
http://www.xenomai.org/index.php/I-pipe-core:ArmPorting#The_general_case

It is the delay below which the timer can not be programmed successfully
(this happens for timers based on free-running counters and match
registers, but also as a documented limitation of some other hardware
timers).

> 
> If the result of the test program looks good to you, i'm going to clean up the patch and i can post it against a 
> xenomai 2.6.1 patched 3.2.23 vanilla linux kernel.

Please stay with 3.2.21, as the update to 3.2.23 may bring new conflicts.

-- 
					    Gilles.

Re: [Xenomai] xenomai 2.6.1 on ixp4xx hangs on boot

[Gilles Chanteperdrix]

On 07/31/2012 08:15 AM, Michael Lausch wrote:

> Ok.
> Will prepare the patch for 3.2.21, but I'll be using 3.2.max until I have to freeze the kernel version.
> As always I read your email with the pointer to the very nice ipipe porting guide *after* I pressed the
> Send button. There's also the exaplanation of the ipipe_timer struct and I'll use the info in there to 
> clean up my patch. 


I do not understand what cleanup is needed: as far as I can tell, the 
conversion to ipipe_timer was already done in the I-pipe core patch. 
What is missing is the kuser based tsc emulation. It seems the 
following patch would be sufficient. Could you test it and tell us 
whether it works?

Regards.

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6e5da70..0ea9b7d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -528,6 +528,7 @@ config ARCH_IXP4XX
 	select HAVE_SCHED_CLOCK
 	select MIGHT_HAVE_PCI
 	select DMABOUNCE if PCI
+	select IPIPE_ARM_KUSER_TSC if IPIPE
 	help
 	  Support for Intel's IXP4XX (XScale) family of processors.
 
diff --git a/arch/arm/mach-ixp4xx/common.c b/arch/arm/mach-ixp4xx/common.c
index f4b878e..cbb1cd5 100644
--- a/arch/arm/mach-ixp4xx/common.c
+++ b/arch/arm/mach-ixp4xx/common.c
@@ -50,53 +50,6 @@ static void __init ixp4xx_clocksource_init(void);
 static void __init ixp4xx_clockevent_init(void);
 static struct clock_event_device clockevent_ixp4xx;
 
-#ifdef CONFIG_IPIPE
-static int ixp4xx_timer_initialized;
-
-#define ONE_SHOT_ENABLE (IXP4XX_OST_ENABLE|IXP4XX_OST_ONE_SHOT)
-
-union tsc_reg {
-#ifdef __BIG_ENDIAN
-	struct {
-		unsigned long high;
-		unsigned long low;
-	};
-#else /* __LITTLE_ENDIAN */
-	struct {
-		unsigned long low;
-		unsigned long high;
-	};
-#endif /* __LITTLE_ENDIAN */
-	unsigned long long full;
-};
-
-#ifdef CONFIG_SMP
-static union tsc_reg tsc[NR_CPUS];
-
-void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
-{
-	info->type = IPIPE_TSC_TYPE_NONE;
-}
-
-#else /* !CONFIG_SMP */
-static union tsc_reg *tsc;
-
-void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
-{
-	info->type = IPIPE_TSC_TYPE_FREERUNNING;
-	info->u.fr.counter =
-		(unsigned *)
-		(IXP4XX_TIMER_BASE_PHYS + IXP4XX_OSTS_OFFSET);
-	info->u.fr.mask = 0xffffffff;
-	info->u.fr.tsc = &tsc->full;
-}
-#endif /* !CONFIG_SMP */
-
-static void ipipe_mach_update_tsc(void);
-#else /* !CONFIG_IPIPE */
-#define ipipe_mach_update_tsc() do { } while (0)
-#endif /* !CONFIG_IPIPE */
-
 /*************************************************************************
  * IXP4xx chipset I/O mapping
  *************************************************************************/
@@ -328,7 +281,7 @@ static irqreturn_t ixp4xx_timer_interrupt(int irq, void *dev_id)
 	if (!clockevent_ipipe_stolen(evt))
 		ixp4xx_timer_ack();
 
-	ipipe_mach_update_tsc();
+	__ipipe_tsc_update();
 
 	evt->event_handler(evt);
 
@@ -353,14 +306,6 @@ void __init ixp4xx_timer_init(void)
 	/* Reset time-stamp counter */
 	*IXP4XX_OSTS = 0;
 
-#ifdef CONFIG_IPIPE
-#ifndef CONFIG_SMP
-	tsc = (union tsc_reg *) __ipipe_tsc_area;
-	barrier();
-#endif /* CONFIG_SMP */
-
-	ixp4xx_timer_initialized = 1;
-#endif
 	/* Connect the interrupt handler and enable the interrupt */
 	setup_irq(IRQ_IXP4XX_TIMER1, &ixp4xx_timer_irq);
 
@@ -537,12 +482,31 @@ static cycle_t ixp4xx_clocksource_read(struct clocksource *c)
 
 unsigned long ixp4xx_timer_freq = IXP4XX_TIMER_FREQ;
 EXPORT_SYMBOL(ixp4xx_timer_freq);
+
+#ifdef CONFIG_IPIPE
+static struct __ipipe_tscinfo tsc_info = {
+	.type = IPIPE_TSC_TYPE_FREERUNNING,
+	.freq = IXP4XX_TIMER_FREQ,
+	.counter_vaddr = (unsigned long)IXP4XX_OSTS,
+	.u = {
+		{
+			.mask = 0xffffffff,
+			.counter_paddr = IXP4XX_TIMER_BASE_PHYS,
+		},
+	},
+};
+#endif /* CONFIG_IPIPE */
+
 static void __init ixp4xx_clocksource_init(void)
 {
 	init_sched_clock(&cd, ixp4xx_update_sched_clock, 32, ixp4xx_timer_freq);
 
 	clocksource_mmio_init(NULL, "OSTS", ixp4xx_timer_freq, 200, 32,
 			ixp4xx_clocksource_read);
+
+#ifdef CONFIG_IPIPE
+	__ipipe_tsc_register(&tsc_info);
+#endif
 }
 
 /*
@@ -593,6 +557,7 @@ static void ixp4xx_set_mode(enum clock_event_mode mode,
 static struct ipipe_timer ixp4xx_itimer = {
 	.irq = IRQ_IXP4XX_TIMER1,
 	.min_delay_ticks = 333, /* 5 usec with the 66.66 MHz system clock */
+	.ack = ixp4xx_timer_ack,
 };
 #endif /* CONFIG_IPIPE */
 
@@ -620,44 +585,3 @@ static void __init ixp4xx_clockevent_init(void)
 
 	clockevents_register_device(&clockevent_ixp4xx);
 }
-
-#ifdef CONFIG_IPIPE
-static void ipipe_mach_update_tsc(void)
-{
-	union tsc_reg *local_tsc;
-	unsigned long stamp, flags;
-
-	flags = hard_local_irq_save();
-	local_tsc = &tsc[ipipe_processor_id()];
-	stamp = *IXP4XX_OSTS;
-	if (unlikely(stamp < local_tsc->low))
-		/* 32 bit counter wrapped, increment high word. */
-		local_tsc->high++;
-	local_tsc->low = stamp;
-	hard_local_irq_restore(flags);
-}
-
-notrace unsigned long long __ipipe_mach_get_tsc(void)
-{
-	if (likely(ixp4xx_timer_initialized)) {
-		union tsc_reg *local_tsc, result;
-		unsigned long stamp;
-
-		local_tsc = &tsc[ipipe_processor_id()];
-
-		__asm__ ("ldmia %1, %M0\n":
-			 "=r"(result.full): "r"(local_tsc), "m"(*local_tsc));
-		barrier();
-		stamp = *IXP4XX_OSTS;
-		if (unlikely(stamp < result.low))
-			/* 32 bit counter wrapped, increment high word. */
-			result.high++;
-		result.low = stamp;
-		return result.full;
-	}
-
-	return 0;
-}
-
-EXPORT_SYMBOL(__ipipe_mach_get_tsc);
-#endif /* CONFIG_IPIPE */


-- 
                                                                Gilles.