Re: [PATCH] Realtime preempt support for PPC

2005-02-17 Thread Matt Porter
On Thu, Feb 17, 2005 at 05:01:39AM -0800, Frank Rowand wrote:
> Ingo Molnar wrote:
> > * Frank Rowand <[EMAIL PROTECTED]> wrote:
> > - could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
> >   upstream as well?
> 
> Yes, I will do that.

This one is already mainline, was posted a week or so ago.

-Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Realtime preempt support for PPC

2005-02-17 Thread Frank Rowand
Ingo Molnar wrote:
* Frank Rowand <[EMAIL PROTECTED]> wrote:

I have attached a patch to add realtime support for PowerPC (32 bit
only). [...]

two comments:
- why is us_to_tb needed? It just seems to add alot of unnecessary
  clutter to the patch, while it's not used anywhere.
Sorry, the usage of us_to_tb got dropped from the patch when I moved
it from one of my development trees to another.  It gets used in
usecs_to_cycles().  The patch to add that is attached below.
Even with the usage of us_to_tb by usecs_to_cycles(), there is a lot
of added clutter for what is accomplished.  I considered a nasty hack
to try to derive the proper value from other sources, but adding
us_to_tb seemed a lot easier to understand.
This patch also adds the dreaded #ifdefs, so I suspect it will not be
the correct implementation long term.  I'm not sure if Manish's patch
included the ARM implementation of usecs_to_cycles() - it is a third
case in the #ifdef.
Performance instrumentation is also going to need mcount() and
_mcount(), which is currently a work in progress.
- could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
  upstream as well?
Yes, I will do that.

otherwise it looks pretty clean and straightforward.
	Ingo

Source: MontaVista Software, Inc.
Signed-off-by: Frank Rowand <[EMAIL PROTECTED]>
Index: linux-2.6.10/kernel/latency.c
===
--- linux-2.6.10.orig/kernel/latency.c
+++ linux-2.6.10/kernel/latency.c
@@ -192,7 +192,11 @@ static unsigned long notrace cycles_to_u
 static cycles_t notrace usecs_to_cycles(unsigned long delta)
 {
+#if defined CONFIG_X86
return (cycles_t) delta * (cycles_t) (cpu_khz/1000+1);
+#elif defined(CONFIG_PPC)
+   return delta * us_to_tb;
+#endif
 }
 #ifdef CONFIG_LATENCY_TRACE

Thanks,
-Frank (off to vacation for a couple days)
--
Frank Rowand <[EMAIL PROTECTED]>
MontaVista Software, Inc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Realtime preempt support for PPC

2005-02-17 Thread Ingo Molnar

* Frank Rowand <[EMAIL PROTECTED]> wrote:

> I have attached a patch to add realtime support for PowerPC (32 bit
> only). [...]

two comments:

- why is us_to_tb needed? It just seems to add alot of unnecessary
  clutter to the patch, while it's not used anywhere.

- could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
  upstream as well?

otherwise it looks pretty clean and straightforward.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Realtime preempt support for PPC

2005-02-16 Thread Frank Rowand

(Ingo, I apologize for the duplicate emails.  I did not have my email config
set up properly and was thus getting rejected by lkml.)

I have attached a patch to add realtime support for PowerPC (32 bit
only).  The patch applies over Ingo's real-time preempt patch:

http://people.redhat.com/mingo/realtime-preempt/realtime-preempt-2.6.11-rc4-V0.7.39-02


This patch has been tested on the IBM PPC 405GP eval board only.
You might notice that this board is not an SMP board.  A few small
changes were required to build an SMP kernel, even though only one cpu
is actually active.  I can supply a patch of the SMP related changes if
anyone desires it.

The testing has included a short (~ten minute) stress test for eight
configuration permutations.  The permutations are:

   SMP=nSMP=y
   ---  ---
 PREEMPT_NONE  pn   pn_smp
 PREEMPT_VOLUNTARY pv   pv_smp
 PREEMPT_DESKTOP   pd   pd_smp
 PREEMPT_RTpr   pr_smp


Any comments, suggestions, needed changes, etc are welcome.

Thanks,

-Frank

Frank Rowand <[EMAIL PROTECTED]>
MontaVista Software, Inc



Source: MontaVista Software, Inc.
Signed-off-by: Frank Rowand <[EMAIL PROTECTED]>

Index: linux-2.6.10/arch/ppc/Kconfig
===
--- linux-2.6.10.orig/arch/ppc/Kconfig
+++ linux-2.6.10/arch/ppc/Kconfig
@@ -17,9 +17,16 @@ config GENERIC_HARDIRQS
 
 config RWSEM_GENERIC_SPINLOCK
bool
+   depends on !PREEMPT_RT
+
+config ASM_SEMAPHORES
+   bool
+   depends on !PREEMPT_RT
+   default y
 
 config RWSEM_XCHGADD_ALGORITHM
bool
+   depends on !RWSEM_GENERIC_SPINLOCK && !PREEMPT_RT
default y
 
 config GENERIC_CALIBRATE_DELAY
@@ -862,15 +869,7 @@ config NR_CPUS
depends on SMP
default "4"
 
-config PREEMPT
-   bool "Preemptible Kernel"
-   help
- This option reduces the latency of the kernel when reacting to
- real-time or interactive events by allowing a low priority process to
- be preempted even if it is in kernel mode executing a system call.
-
- Say Y here if you are building a kernel for a desktop, embedded
- or real-time system.  Say N if you are unsure.
+source "lib/Kconfig.RT"
 
 config HIGHMEM
bool "High memory support"
Index: linux-2.6.10/arch/ppc/platforms/prpmc800.c
===
--- linux-2.6.10.orig/arch/ppc/platforms/prpmc800.c
+++ linux-2.6.10/arch/ppc/platforms/prpmc800.c
@@ -331,6 +331,7 @@ static void __init prpmc800_calibrate_de
tb_ticks_per_second = 1 / 4;
tb_ticks_per_jiffy = tb_ticks_per_second / HZ;
tb_to_us = mulhwu_scale_factor(tb_ticks_per_second, 100);
+   us_to_tb = tb_ticks_per_second / 100;
return;
}
 
@@ -371,6 +372,7 @@ static void __init prpmc800_calibrate_de
tb_ticks_per_second = (tbl_end - tbl_start) * 2;
tb_ticks_per_jiffy = tb_ticks_per_second / HZ;
tb_to_us = mulhwu_scale_factor(tb_ticks_per_second, 100);
+   us_to_tb = tb_ticks_per_second / 100;
 }
 
 static void prpmc800_restart(char *cmd)
Index: linux-2.6.10/arch/ppc/syslib/m8xx_setup.c
===
--- linux-2.6.10.orig/arch/ppc/syslib/m8xx_setup.c
+++ linux-2.6.10/arch/ppc/syslib/m8xx_setup.c
@@ -163,6 +163,7 @@ void __init m8xx_calibrate_decr(void)
 printk("Decrementer Frequency = %d/%d\n", freq, divisor);
 tb_ticks_per_jiffy = freq / HZ / divisor;
tb_to_us = mulhwu_scale_factor(freq / divisor, 100);
+   us_to_tb = (freq / divisor) / 100;
 
/* Perform some more timer/timebase initialization.  This used
 * to be done elsewhere, but other changes caused it to get
Index: linux-2.6.10/arch/ppc/platforms/chrp_time.c
===
--- linux-2.6.10.orig/arch/ppc/platforms/chrp_time.c
+++ linux-2.6.10/arch/ppc/platforms/chrp_time.c
@@ -191,4 +191,5 @@ void __init chrp_calibrate_decr(void)
   freq/100, freq%100);
tb_ticks_per_jiffy = freq / HZ;
tb_to_us = mulhwu_scale_factor(freq, 100);
+   us_to_tb = freq / 100;
 }
Index: linux-2.6.10/arch/ppc/platforms/gemini_setup.c
===
--- linux-2.6.10.orig/arch/ppc/platforms/gemini_setup.c
+++ linux-2.6.10/arch/ppc/platforms/gemini_setup.c
@@ -465,6 +465,7 @@ void __init gemini_calibrate_decr(void)
divisor = 4;
tb_ticks_per_jiffy = freq / HZ / divisor;
tb_to_us = mulhwu_scale_factor(freq/divisor, 100);
+   us_to_tb = (freq / divisor) / 100;
 }
 
 unsigned long __init gemini_find_end_of_memory(void)
Index: linux-2.6.10/include/asm-ppc/time.h
===