* [patch] ppc32: set smp_tb_synchronized on UP with SMP kernel
From: Johannes Berg @ 2005-12-10 23:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm, paulus
ppc32 kernel, when built with CONFIG_SMP and booted on a single CPU
machine, will not properly set smp_tb_synchronized, thus causing
gettimeofday() to not use the HW timebase and to be limited to jiffy
resolution. This, among others, causes unacceptable pauses when
launching X.org.
Signed-Off-By: Johannes Berg <johannes@sipsolutions.net>
---
With this patch, X.org startup time goes down from ~30 seconds to normal
(just a second or so). The know-how really comes from BenH who I
discussed with on IRC.
--- linux-2.6.15-rc5.orig/arch/ppc/kernel/smp.c 2005-12-10 23:56:23.026328000 +0100
+++ linux-2.6.15-rc5/arch/ppc/kernel/smp.c 2005-12-11 00:03:40.556328000 +0100
@@ -301,6 +301,11 @@
/* Probe platform for CPUs: always linear. */
num_cpus = smp_ops->probe();
+
+ if (num_cpus < 2) {
+ smp_tb_synchronized = 1;
+ }
+
for (i = 0; i < num_cpus; ++i)
cpu_set(i, cpu_possible_map);
^ permalink raw reply
* Re: [patch] ppc32: set smp_tb_synchronized on UP with SMP kernel
From: Benjamin Herrenschmidt @ 2005-12-10 23:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: akpm, linuxppc-dev, paulus
In-Reply-To: <1134256279.3810.8.camel@localhost>
On Sun, 2005-12-11 at 00:11 +0100, Johannes Berg wrote:
> ppc32 kernel, when built with CONFIG_SMP and booted on a single CPU
> machine, will not properly set smp_tb_synchronized, thus causing
> gettimeofday() to not use the HW timebase and to be limited to jiffy
> resolution. This, among others, causes unacceptable pauses when
> launching X.org.
>
> Signed-Off-By: Johannes Berg <johannes@sipsolutions.net>
Please, remove the useless { }
Ben.
> ---
>
> With this patch, X.org startup time goes down from ~30 seconds to normal
> (just a second or so). The know-how really comes from BenH who I
> discussed with on IRC.
>
> --- linux-2.6.15-rc5.orig/arch/ppc/kernel/smp.c 2005-12-10 23:56:23.026328000 +0100
> +++ linux-2.6.15-rc5/arch/ppc/kernel/smp.c 2005-12-11 00:03:40.556328000 +0100
> @@ -301,6 +301,11 @@
>
> /* Probe platform for CPUs: always linear. */
> num_cpus = smp_ops->probe();
> +
> + if (num_cpus < 2) {
> + smp_tb_synchronized = 1;
> + }
> +
> for (i = 0; i < num_cpus; ++i)
> cpu_set(i, cpu_possible_map);
>
>
^ permalink raw reply
* Re: [patch] ppc32: set smp_tb_synchronized on UP with SMP kernel
From: Johannes Berg @ 2005-12-11 0:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: akpm, linuxppc-dev
In-Reply-To: <1134258468.6989.36.camel@gaston>
ppc32 kernel, when built with CONFIG_SMP and booted on a single CPU
machine, will not properly set smp_tb_synchronized, thus causing
gettimeofday() to not use the HW timebase and to be limited to jiffy
resolution. This, among others, causes unacceptable pauses when
launching X.org.
Signed-Off-By: Johannes Berg <johannes@sipsolutions.net>
---
With this patch, X.org startup time goes down from ~30 seconds to normal
(just a second or so). The know-how really comes from BenH who I
discussed with on IRC.
--- linux-2.6.15-rc5.orig/arch/ppc/kernel/smp.c 2005-12-10 23:56:23.026328000 +0100
+++ linux-2.6.15-rc5/arch/ppc/kernel/smp.c 2005-12-11 00:56:53.756328000 +0100
@@ -301,6 +301,10 @@
/* Probe platform for CPUs: always linear. */
num_cpus = smp_ops->probe();
+
+ if (num_cpus < 2)
+ smp_tb_synchronized = 1;
+
for (i = 0; i < num_cpus; ++i)
cpu_set(i, cpu_possible_map);
^ permalink raw reply
* Re: [patch] ppc32: set smp_tb_synchronized on UP with SMP kernel
From: Benjamin Herrenschmidt @ 2005-12-11 0:25 UTC (permalink / raw)
To: Johannes Berg; +Cc: akpm, linuxppc-dev
In-Reply-To: <1134259249.4387.3.camel@localhost>
On Sun, 2005-12-11 at 01:00 +0100, Johannes Berg wrote:
> ppc32 kernel, when built with CONFIG_SMP and booted on a single CPU
> machine, will not properly set smp_tb_synchronized, thus causing
> gettimeofday() to not use the HW timebase and to be limited to jiffy
> resolution. This, among others, causes unacceptable pauses when
> launching X.org.
>
> Signed-Off-By: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> With this patch, X.org startup time goes down from ~30 seconds to normal
> (just a second or so). The know-how really comes from BenH who I
> discussed with on IRC.
>
> --- linux-2.6.15-rc5.orig/arch/ppc/kernel/smp.c 2005-12-10 23:56:23.026328000 +0100
> +++ linux-2.6.15-rc5/arch/ppc/kernel/smp.c 2005-12-11 00:56:53.756328000 +0100
> @@ -301,6 +301,10 @@
>
> /* Probe platform for CPUs: always linear. */
> num_cpus = smp_ops->probe();
> +
> + if (num_cpus < 2)
> + smp_tb_synchronized = 1;
> +
> for (i = 0; i < num_cpus; ++i)
> cpu_set(i, cpu_possible_map);
>
>
^ permalink raw reply
* RE: Linux process ABI broken in 2.6?
From: Joakim Tjernlund @ 2005-12-11 15:11 UTC (permalink / raw)
To: linuxppc-dev
>=20
> > On Fri, 2005-12-09 at 00:07 +0100, Tjernlund wrote:
> > > Seems like ppc32 kernel pass the application entry point address
> > > in r7 and MSR in r8 when starting the application. The=20
> source might be
> > > ret_from_syscall, in entry.S:=20
> > > ...
> > > lwz r7,_NIP(r1)
> > > lwz r8,_MSR(r1)
> > > FIX_SRR1(r8, r0)
> > > lwz r2,GPR2(r1)
> > > lwz r1,GPR1(r1)
> > > mtspr SPRN_SRR0,r7
> > > mtspr SPRN_SRR1,r8
> > > SYNC
> > > RFI
> > > I am not convinced this is the source, but a non zero r7
> > > breaks static apps in uClibc.
> > >=20
> > > Is this on purpose and why?
> > >=20
> > > Secion 8.4.1 in
> > >=20
> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-PPC32/LSB
> -Core-PPC32.html#PROCESSINITIALIZATION
> > >=20
> > > says:
> > > "Contrary to what is stated in the Registers part of=20
> chapter 3 of the System V Application Binary Interface=20
> PowerPC Processor
> > > Supplement there are no values set in registers r3, r4,=20
> r5, r6 and r7. Instead the values specified to appear in all of those
> > > registers except r7 are placed on the stack. The value to=20
> be placed into register r7, the termination function pointer=20
> is not passed
> > > to the process."
> > >=20
> > > How do one not pass a termination function in r7 other=20
> than setting
> > > r7 to zero?
> >
> > Just ignore those registers on entry. The semantics of a=20
> syscall are to
> > clobber all volatile registers and there is no point doing anything
> > else.
> >
> > Ben.
>=20
> [Sorry to break the thread, but I mailed from the wrong=20
> account which I can't reach ATM]
>=20
> Sure, but this syscall is a bit special as it has to prepare=20
> the runtime env. for the new process.
> Not having any defined value for register at process startup feels ..
>=20
> An undefined r7 register makes it hard to differ between=20
> dynamic and static apps in crt1.
> I now understand why glibc has its own non standard=20
> __libc_start function and I really don't
> want that in uClibc. Is it too much trouble to define r7 to=20
> always have a zero
> value at process startup?
>=20
> As far as I can tell 2.4 has all unused registers zeroed.
The only way to pass any info from ld.so to crt is to mess with the
stack, write a NULL word
before argc and set the stack ptr to point to it. Then let crt test for
a null word, if null
then crt will know that this is a dynamic app, if not then it is a
static app with no rtld_fini
function.
I feel the messing with the stack in this way not ideal, so I would like
to see a better
exec ABI where at least one register,r7, will be zero.
The fix is trivial, just swap r7 to r9 in the above assembler code.
Is that feasible?
Jocke
^ permalink raw reply
* [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-11 18:52 UTC (permalink / raw)
To: linux-kernel
Cc: linux-sh, tony.luck, linux-ia64, grundler, matthew, linuxppc-dev,
lethal, kkojima, rmk, parisc-linux
defconfig's shouldn't set CONFIG_BROKEN=y.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
arch/arm/configs/bast_defconfig | 3 +--
arch/arm/configs/collie_defconfig | 3 +--
arch/arm/configs/s3c2410_defconfig | 3 +--
arch/ia64/configs/sim_defconfig | 3 +--
arch/ia64/configs/zx1_defconfig | 3 +--
arch/m32r/mappi/defconfig.smp | 3 +--
arch/m32r/mappi/defconfig.up | 3 +--
arch/m32r/mappi3/defconfig.smp | 3 +--
arch/parisc/configs/712_defconfig | 3 +--
arch/parisc/configs/a500_defconfig | 3 +--
arch/parisc/configs/c3000_defconfig | 3 +--
arch/ppc/configs/mpc86x_ads_defconfig | 3 +--
arch/ppc/configs/mpc885ads_defconfig | 3 +--
arch/ppc/configs/rpxcllf_defconfig | 3 +--
arch/ppc/configs/rpxlite_defconfig | 3 +--
arch/sh/configs/hp680_defconfig | 3 +--
arch/sh/configs/sh03_defconfig | 3 +--
arch/sh/configs/systemh_defconfig | 3 +--
18 files changed, 18 insertions(+), 36 deletions(-)
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig.old 2005-12-11 19:37:15.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/bast_defconfig 2005-12-11 19:37:37.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig.old 2005-12-11 19:37:44.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/collie_defconfig 2005-12-11 19:37:52.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig.old 2005-12-11 19:38:01.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/arm/configs/s3c2410_defconfig 2005-12-11 19:38:08.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig.old 2005-12-11 19:38:17.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/sim_defconfig 2005-12-11 19:38:38.000000000 +0100
@@ -6,9 +6,8 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
+CONFIG_CLEAN_COMPILE=y
# CONFIG_STANDALONE is not set
-CONFIG_BROKEN=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig.old 2005-12-11 19:38:52.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ia64/configs/zx1_defconfig 2005-12-11 19:38:59.000000000 +0100
@@ -8,8 +8,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp.old 2005-12-11 19:39:08.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.smp 2005-12-11 19:39:15.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up.old 2005-12-11 19:39:25.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi/defconfig.up 2005-12-11 19:39:32.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp.old 2005-12-11 19:39:41.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/m32r/mappi3/defconfig.smp 2005-12-11 19:39:48.000000000 +0100
@@ -13,8 +13,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig.old 2005-12-11 19:40:00.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/712_defconfig 2005-12-11 19:40:08.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig.old 2005-12-11 19:40:32.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/a500_defconfig 2005-12-11 19:40:38.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig.old 2005-12-11 19:40:50.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/parisc/configs/c3000_defconfig 2005-12-11 19:40:57.000000000 +0100
@@ -16,8 +16,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig.old 2005-12-11 19:41:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc86x_ads_defconfig 2005-12-11 19:42:01.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig.old 2005-12-11 19:42:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/mpc885ads_defconfig 2005-12-11 19:42:30.000000000 +0100
@@ -17,8 +17,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig.old 2005-12-11 19:42:40.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxcllf_defconfig 2005-12-11 19:42:48.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig.old 2005-12-11 19:43:21.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/ppc/configs/rpxlite_defconfig 2005-12-11 19:43:27.000000000 +0100
@@ -15,8 +15,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig.old 2005-12-11 19:43:36.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/hp680_defconfig 2005-12-11 19:43:43.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
#
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig.old 2005-12-11 19:43:53.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/sh03_defconfig 2005-12-11 19:44:02.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
--- linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig.old 2005-12-11 19:44:19.000000000 +0100
+++ linux-2.6.15-rc5-mm2-full/arch/sh/configs/systemh_defconfig 2005-12-11 19:44:40.000000000 +0100
@@ -14,8 +14,7 @@
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
-# CONFIG_CLEAN_COMPILE is not set
-CONFIG_BROKEN=y
+CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Russell King @ 2005-12-11 19:21 UTC (permalink / raw)
To: Adrian Bunk
Cc: linux-sh, tony.luck, linux-ia64, grundler, matthew, linux-kernel,
linuxppc-dev, lethal, kkojima, parisc-linux
In-Reply-To: <20051211185212.GQ23349@stusta.de>
On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> defconfig's shouldn't set CONFIG_BROKEN=y.
NACK. This changes other configuration options in addition, for example
in collie_defconfig:
-CONFIG_MTD_OBSOLETE_CHIPS=y
-# CONFIG_MTD_AMDSTD is not set
-CONFIG_MTD_SHARP=y
-# CONFIG_MTD_JEDEC is not set
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Adrian Bunk @ 2005-12-11 19:31 UTC (permalink / raw)
To: linux-kernel, tony.luck, linux-ia64, matthew, grundler,
parisc-linux, paulus, linuxppc-dev, lethal, kkojima, dwmw2
Cc: linux-mtd
In-Reply-To: <20051211192109.GA22537@flint.arm.linux.org.uk>
On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > defconfig's shouldn't set CONFIG_BROKEN=y.
>
> NACK. This changes other configuration options in addition, for example
> in collie_defconfig:
>
> -CONFIG_MTD_OBSOLETE_CHIPS=y
> -# CONFIG_MTD_AMDSTD is not set
> -CONFIG_MTD_SHARP=y
> -# CONFIG_MTD_JEDEC is not set
That's not a problem introduced by my patch.
Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
dependency on BROKEN is not correct and should be corrected.
David, can you comment on this issue?
> Russell King
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: Russell King @ 2005-12-11 19:44 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel, linux-mtd,
linuxppc-dev, lethal, dwmw2, kkojima, parisc-linux
In-Reply-To: <20051211193118.GR23349@stusta.de>
On Sun, Dec 11, 2005 at 08:31:18PM +0100, Adrian Bunk wrote:
> On Sun, Dec 11, 2005 at 07:21:10PM +0000, Russell King wrote:
> > On Sun, Dec 11, 2005 at 07:52:12PM +0100, Adrian Bunk wrote:
> > > defconfig's shouldn't set CONFIG_BROKEN=y.
> >
> > NACK. This changes other configuration options in addition, for example
> > in collie_defconfig:
> >
> > -CONFIG_MTD_OBSOLETE_CHIPS=y
> > -# CONFIG_MTD_AMDSTD is not set
> > -CONFIG_MTD_SHARP=y
> > -# CONFIG_MTD_JEDEC is not set
>
> That's not a problem introduced by my patch.
It's a problem introduced by your patch because the resulting defconfig
file becomes _wrong_ by your change, and other changes in the defconfig
are thereby hidden.
If you change any options in a defconfig file, and they're obviously not
leaf options, you should check what impact they have on other options by
running it through an "oldconfig" cycle. That's what I just did with
this script:
#!/bin/sh -e
alias amake='make CROSS_COMPILE=arm-linux- ARCH=arm'
amake $1 O=../build/t >/dev/null 2>&1
mv ../build/t/.config ../build/t/.config.orig
sed '/CONFIG_BROKEN/d;s,^# CONFIG_CLEAN_COMPILE is not set,CONFIG_CLEAN_COMPILE=y,' < ../build/t/.config.orig > ../build/t/.config
amake oldconfig O=../build/t >/dev/null 2>&1
diff -u ../build/t/.config.orig ../build/t/.config
Hence I discovered that disabling CONFIG_BROKEN removes the above
options for the collie case.
BTW, it might be worth using something like the above script for all
the changes to the defconfig files in your patch so that it correctly
updates these files. It will also mean that any review of it is more
meaningful because we can see the full extent of your changes.
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in which
> case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything), or the
> dependency on BROKEN is not correct and should be corrected.
That's something which collie folk need to comment on. However, what
I can say is that the collie_defconfig builds successfully today:
http://armlinux.simtec.co.uk/kautobuild/2.6.15-rc5-git1/collie_defconfig/zimage.log
so it's quite possible that the Kconfig is out of sync with reality.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* Re: 82xx-HCI-USB & Webcams / PWC
From: Wolfgang Denk @ 2005-12-11 21:47 UTC (permalink / raw)
To: Absolut Hunter; +Cc: linuxppc-embedded
In-Reply-To: <003101c5fcf5$1ff05b80$6405a8c0@absolut>
Hello,
in message <003101c5fcf5$1ff05b80$6405a8c0@absolut> you wrote:
>
> Has anyone attempted to use the Phillips web cam driver, pwc.o, that is
> built into the standard 2.4.25 DENX kernel? I think its version 8.x
> something.
The current code uses version 10.0.7a of the driver. This driver has
been tested on several MPC5200 based systems (plain old IceCube,
TQM5200, and custom hardware). It works fine there.
> Anyone tried this?
We did, and it works fine. [Make sure to use current code, i. e. commit
e09474c3e0963b58470b447ab25188499e5c4af1 or later; see
http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=commit;h=e09474c3e0963b58470b447ab25188499e5c4af1
See also Documentation/README.webcam inthe source tree.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Genius doesn't work on an assembly line basis. You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3
^ permalink raw reply
* [PATCH] powerpc: Fix clock spreading setting on some powermacs
From: Benjamin Herrenschmidt @ 2005-12-12 2:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev list
The code that sets the clock spreading feature of the Intrepid ASIC
must not be run on some machine models or those won't boot. This
fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
This is 2.6.15 material.
Index: linux-work/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-19 10:56:07.000000000 +1100
+++ linux-work/arch/powerpc/platforms/powermac/feature.c 2005-12-12 12:17:02.000000000 +1100
@@ -1650,11 +1650,19 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ printk(KERN_INFO "%sabling clock spreading on Intrepid"
+ " ASIC\n", enable ? "En" : "Dis");
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
@@ -1724,6 +1732,9 @@
pmac_low_i2c_close(ui2c);
break;
}
+ printk(KERN_INFO "%sabling clock spreading on i2c clock chip\n",
+ enable ? "En" : "Dis");
+
pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_stdsub);
rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_write, 0x80, buffer, 9);
DBG("write result: %d,", rc);
Index: linux-work/arch/ppc/platforms/pmac_feature.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_feature.c 2005-11-14 20:32:16.000000000 +1100
+++ linux-work/arch/ppc/platforms/pmac_feature.c 2005-12-12 12:16:38.000000000 +1100
@@ -1606,11 +1606,19 @@
*/
if (macio->type == macio_intrepid) {
- if (enable)
- UN_OUT(UNI_N_CLOCK_SPREADING, 2);
- else
- UN_OUT(UNI_N_CLOCK_SPREADING, 0);
- mdelay(40);
+ struct device_node *clock =
+ of_find_node_by_path("/uni-n@f8000000/hw-clock");
+ if (clock && get_property(clock, "platform-do-clockspreading",
+ NULL)) {
+ printk(KERN_INFO "%sabling clock spreading on Intrepid"
+ " ASIC\n", enable ? "En" : "Dis");
+ if (enable)
+ UN_OUT(UNI_N_CLOCK_SPREADING, 2);
+ else
+ UN_OUT(UNI_N_CLOCK_SPREADING, 0);
+ mdelay(40);
+ }
+ of_node_put(clock);
}
while (machine_is_compatible("PowerBook5,2") ||
@@ -1680,6 +1688,8 @@
pmac_low_i2c_close(ui2c);
break;
}
+ printk(KERN_INFO "%sabling clock spreading on i2c clock chip\n",
+ enable ? "En" : "Dis");
pmac_low_i2c_setmode(ui2c, pmac_low_i2c_mode_stdsub);
rc = pmac_low_i2c_xfer(ui2c, 0xd2 | pmac_low_i2c_write, 0x80, buffer, 9);
DBG("write result: %d,", rc);
^ permalink raw reply
* Re: Linux process ABI broken in 2.6?
From: Paul Mackerras @ 2005-12-12 2:28 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev
In-Reply-To: <F6AD7E21CDF4E145A44F61F43EE6D939486E0C@tmnt04.transmode.se>
Joakim Tjernlund writes:
> Is it too much trouble to define r7 to always have
> a zero
> value at process startup?
That's not much trouble, but what will you do for existing kernels?
Won't you have to do something like testing *r1 anyway?
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix clock spreading setting on some powermacs
From: Andrew Morton @ 2005-12-12 2:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1134353605.6989.69.camel@gaston>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> The code that sets the clock spreading feature of the Intrepid ASIC
> must not be run on some machine models or those won't boot. This
> fixes it.
I have a bunch of powerpc fixes for 2.6.15, some of which are in Paul's
tree. I presently have:
powerpc-fix-a-huge-page-bug.patch
powerpc-remove-debug-code-in-hash-path.patch
fix-windfarm-model-id-table.patch
powerpc-set-cache-info-defaults.patch
powerpc-fix-slb-flushing-path-in-hugepage.patch
powerpc-add-missing-icache-flushes-for-hugepages.patch
ppc32-set-smp_tb_synchronized-on-up-with-smp-kernel.patch
Linus is back online now. Paul, do you intend to send a batch to Linus?
If so, please do so asap so I can merge up anything that's left over.
^ permalink raw reply
* Re: [PATCH] powerpc: Fix clock spreading setting on some powermacs
From: Paul Mackerras @ 2005-12-12 3:27 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20051211184520.7f565283.akpm@osdl.org>
Andrew Morton writes:
> Linus is back online now. Paul, do you intend to send a batch to Linus?
> If so, please do so asap so I can merge up anything that's left over.
Yes, I have all of those patches in my powerpc-merge tree and I'll
send him a "please pull" message once it's mirrored to kernel.org.
Paul.
^ permalink raw reply
* 82xx IRQ handling
From: Dmytro Bablinyuk @ 2005-12-12 2:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I am trying to setup an IRQ handler for IRQ4:
#define IRQ SIU_INT_IRQ4
volatile cpm2_map_t *immap;
int irq_flags = 0;
immap = (cpm2_map_t *)CPM_MAP_ADDR;
immap->im_intctl.ic_simrh &= ~(0x0800);
request_irq(IRQ,
&irq_handler, /* our handler */
irq_flags,
"interrupt_test",
NULL);
immap->im_intctl.ic_simrh |= 0x0800;
I can see on a scope that IRQ line pulls up/down but handler get never
called. I am sure I made some very stupid mistake here but I will really
appreciate if somebody can help me with this.
Thank you
Dmytro
^ permalink raw reply
* Re: 82xx IRQ handling
From: Dan Malek @ 2005-12-12 5:01 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <439CE3A2.8020603@rftechnology.com.au>
On Dec 11, 2005, at 9:42 PM, Dmytro Bablinyuk wrote:
> immap->im_intctl.ic_simrh &= ~(0x0800);
You should not be messing around with this register
in your code. The generic 82xx interrupt functions
will properly manage this for you.
> request_irq(IRQ,
> &irq_handler, /* our handler */
> irq_flags,
> "interrupt_test",
> NULL);
This is all you should do.
Thanks.
-- Dan
^ permalink raw reply
* Re: 82xx IRQ handling
From: Dmytro Bablinyuk @ 2005-12-12 6:00 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <dc0620490d9bef30d3a4b629483cd3f9@embeddededge.com>
>
>> immap->im_intctl.ic_simrh &= ~(0x0800);
>
>
> You should not be messing around with this register
> in your code. The generic 82xx interrupt functions
> will properly manage this for you.
Thank you Dan,
It's working now!
By the way question - shall I program somewhere an edge of the IRQ or it
always triggers on the rising edge?
Also does anybody knows any source code example of using 82xx General
Purpose Timer Unit so that it triggers interrupt handler after some period.
Thank you
^ permalink raw reply
* RE: Linux process ABI broken in 2.6?
From: Joakim Tjernlund @ 2005-12-12 8:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
=20
>=20
> Joakim Tjernlund writes:
>=20
> > Is it too much trouble to define r7 to always have
> > a zero
> > value at process startup?
>=20
> That's not much trouble, but what will you do for existing kernels?
> Won't you have to do something like testing *r1 anyway?
No, I don't plan to do anything. I just got the first report that static
uClibc apps dosen't work for 2.6, so if the current kernel is fixed I
will just
point to a newer kernel or they can patch their old kernel with the
required 2 line fix.
Thanks
Jocke
>=20
> Paul.
>=20
>=20
^ permalink raw reply
* Re: Re: 82xx IRQ handling
From: debora liu @ 2005-12-12 8:31 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2469 bytes --]
Hello, Dmytro Bablinyuk
In message <2005-12-12 14:00:46 dmytro.bablinyuk@rftechnology.com.au> you wrote:
>
>By the way question - shall I program somewhere an edge of the IRQ or it
>always triggers on the rising edge?
>
IRQ_POLARITY_POSITIVE /* high level or low->high edge */
IRQ_POLARITY_NEGATIVE /* low level or high->low edge */
you should modify OpenPIC_InitSenses, example my board:
static u_char sc82xx_openpic_initsenses[] __initdata = {
#if defined(CONFIG_SVM_GEMINI)
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 0,PCI0 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 1 ,PCI1*/
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 2 ,PCI2 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* DUART CH1 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* DUART CH2 */
(IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ3, PCI3 or DPRAM */
(IRQ_SENSE_EDGE | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ4, DPRAM */
#elif defined (CONFIG_SVM_IT6160A)
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 0 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 1 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ 2, xr16L788 chip1*/
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* DUART CH1 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* DUART CH2 */
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ3, xr16L788 chip2*/
(IRQ_SENSE_LEVEL | IRQ_POLARITY_NEGATIVE), /* EPIC IRQ4,spare */
#else
#error No board defined.!!!
#endif
};
static void __init
sc82xx_init_IRQ(void)
{
OpenPIC_InitSenses = sc82xx_openpic_initsenses;
OpenPIC_NumInitSenses = sizeof(sc82xx_openpic_initsenses);
/*
* We need to tell openpic_set_sources where things actually are.
* mpc10x_common will setup OpenPIC_Addr at ioremap(EUMB phys base +
* EPIC offset (0x40000)); The EPIC IRQ Register Address Map -
* Interrupt Source Configuration Registers gives these numbers
* as offsets starting at 0x50200, we need to adjust occordinly.
*/
openpic_set_sources(0, 3, OpenPIC_Addr + 0x10200); /* 0=IRQ0, 1=IRQ1, 2=IRQ2 *
openpic_set_sources(3, 2, OpenPIC_Addr + 0x11120); /* 3=UART0, 4=UART1 *
openpic_set_sources(5, 2, OpenPIC_Addr + 0x10260); /* 5=IRQ3, 6=IRQ4 *
openpic_init (0);
}
= = = = = = = = = = = = = = = = = = = =
debora liu
deboraliu@tom.com
2005-12-12
[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]
^ permalink raw reply
* eldk-3.1.1 mpc823 SCC3 CTS/CD
From: debora liu @ 2005-12-12 8:40 UTC (permalink / raw)
To: linuxppc-embedde
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]
Hello denx:
I found one bug when SCC3 as UART, my cpu is mpc823.
cts/cd config as:
CTS PC5
CD PC4
your ELDK-3.1.1 linux-2.4.25 uart.c set pcpar,pcso, pcdir:
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= iobits;
immap->im_ioport.iop_pcdir &= ~iobits;
but MPC823UM tell me CD3 and CTS3 is bit6 and bit7 on PCSO register, so I modify:
fix_pcso = iobits;
#if defined(CONFIG_UART_CTS_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CTS3_PIN));
fix_pcso |= 0x0100;
#endif
#if defined(CONFIG_UART_CD_CONTROL_SCC3)
fix_pcso &=~(1 << (15 - CONFIG_CD3_PIN));
fix_pcso |= 0x0200;
#endif
immap->im_ioport.iop_pcpar &= ~iobits;
immap->im_ioport.iop_pcso |= fix_pcso;
immap->im_ioport.iop_pcdir &= ~iobits;
My board have success communication to moderm with SCC3 hard flow control.
debora liu
deboraliu@tom.com
2005-12-12
[-- Attachment #2: fox.gif --]
[-- Type: image/gif, Size: 9519 bytes --]
^ permalink raw reply
* Re: [2.6 patch] defconfig's shouldn't set CONFIG_BROKEN=y
From: David Woodhouse @ 2005-12-12 9:38 UTC (permalink / raw)
To: Adrian Bunk
Cc: tony.luck, linux-ia64, grundler, matthew, linux-kernel, linux-mtd,
linuxppc-dev, lethal, kkojima, parisc-linux
In-Reply-To: <20051211193118.GR23349@stusta.de>
On Sun, 2005-12-11 at 20:31 +0100, Adrian Bunk wrote:
> Either the depency of MTD_OBSOLETE_CHIPS on BROKEN is correct (in
> which case CONFIG_MTD_OBSOLETE_CHIPS=y wouldn't bring you anything),
> or the dependency on BROKEN is not correct and should be corrected.
>
> David, can you comment on this issue?
I don't see any justification for MTD_OBSOLETE_CHIPS depending on
BROKEN. That option covers a few of the obsolete chip drivers which
people shouldn't be using any more -- and I'm perfectly willing to
believe that one or two of those don't work any more, but if that's the
case then those individual drivers ought to be marked BROKEN (or just
removed). We shouldn't mark MTD_OBSOLETE_CHIPS broken.
I'd like to see the collie_defconfig updated to use the appropriate CFI
driver back end.
--
dwmw2
^ permalink raw reply
* Can we compile them with eldk and debug them with BDI2000?
From: zengshuai @ 2005-12-12 12:25 UTC (permalink / raw)
To: ppc
There are some example C programs in freescale's web.
They don't work in linux but bareboard.
Can we compile them with eldk and debug them with BDI2000?
Thanks.
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: Can we compile them with eldk and debug them with BDI2000?
From: Wolfgang Denk @ 2005-12-12 13:26 UTC (permalink / raw)
To: zengshuai; +Cc: ppc
In-Reply-To: <4069241.1134390336250.JavaMail.postfix@mx3.mail.sohu.com>
In message <4069241.1134390336250.JavaMail.postfix@mx3.mail.sohu.com> you wrote:
> There are some example C programs in freescale's web.
> They don't work in linux but bareboard.
> Can we compile them with eldk and debug them with BDI2000?
Yes. You may have to set up your own linker script, though. It would
be probably much easier to run such code as standalone application in
U-Boot (and yes, this too can be compiled using the ELDK and debugged
using the BDI).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
We are all agreed that your theory is crazy. The question which
divides us is whether it is crazy enough to have a chance of being
correct. My own feeling is that it is not crazy enough. - Niels Bohr
^ permalink raw reply
* Re: 82xx IRQ handling
From: Kumar Gala @ 2005-12-12 14:28 UTC (permalink / raw)
To: Dmytro Bablinyuk; +Cc: linuxppc-embedded
In-Reply-To: <439D120E.9010606@rftechnology.com.au>
On Dec 12, 2005, at 12:00 AM, Dmytro Bablinyuk wrote:
>>> immap->im_intctl.ic_simrh &= ~(0x0800);
>> You should not be messing around with this register
>> in your code. The generic 82xx interrupt functions
>> will properly manage this for you.
> Thank you Dan,
> It's working now!
>
> By the way question - shall I program somewhere an edge of the IRQ
> or it always triggers on the rising edge?
>
> Also does anybody knows any source code example of using 82xx
> General Purpose Timer Unit so that it triggers interrupt handler
> after some period.
The IRQ pins are set to edge trigger by default.
- kumar
^ permalink raw reply
* chrdevs[] explained
From: Gabe.Johnson @ 2005-12-12 16:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 148 bytes --]
Could someone explain to me the chrdevs array found in fs/char_dev.c how
does that get populated and with what does it get populated?
Thanks,
Gabe
[-- Attachment #2: Type: text/html, Size: 278 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox