* Re: [PATCH 2.6.14] mm: 8xx MM fix for
From: Dan Malek @ 2005-11-08 0:46 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded, Joakim Tjernlund, gtolstolytkin
In-Reply-To: <20051107182211.GI3839@smtp.west.cox.net>
On Nov 7, 2005, at 1:22 PM, Tom Rini wrote:
> Assuming Dan doesn't come up with a more simple & better fix, maybe we
> should go back to the original patch I made?
I'm working on it. It'll look more like 2.4.
Thanks.
-- Dan
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Dan Malek @ 2005-11-08 0:55 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-ppc-embedded
In-Reply-To: <20051107151011.GA17161@logos.cnet>
On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> The following is an attempt to fix swapping on 8xx by not touching
> _PAGE_ACCESSED bit if the page is not present.
Ugh .... I suppose. I hate assembler code macros .......
Somehow, "swapping" and "8xx" just don't belong together.
I'm tempted to add a configuration option that is the complete
opposite of this and assumes are really embedded system.
Mark pages as always accessed, data pages as always dirty,
and you can eliminate lots of TLB faults in systems that are
fairly static.
None of this should really be done in a TLB miss handler,
if there is anything that needs to be updated in a PTE, it should
be pushed out to an error function. A TLB miss handler
should fit in a cache line ......
-- Dan
^ permalink raw reply
* Re: [PATCH] Fix ppc32 smp build.
From: Mark Guertin @ 2005-11-08 1:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, David Woodhouse
In-Reply-To: <17263.58185.110462.536522@cargo.ozlabs.ibm.com>
On 7-Nov-05, at 6:29 PM, Paul Mackerras wrote:
> David Woodhouse writes:
>
>> We make no attempt to sync the timebases on quad powersurge, as
>> far as I
>> can tell -- and we never set smp_tb_synchronized there.
>
> Hmmm. Does anyone still have one of those? I have a dual but not a
> quad.
>
I have one that is collecting dust currently. I'd be willing to get
it to someone that can work with it for the cost of shipping (not
cheap, it's heavy). Even has an RJ45 jack on the CPU card -- most
I've seen don't. Or if there's someone in the Toronto area that
wants to pick it up is fine too, as long as it goes to a good home to
help kernel development :)
Mark
^ permalink raw reply
* Re: [PATCH] ppc32: fix perf_irq extern on e500
From: Andrew Morton @ 2005-11-08 3:01 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20051107124917.C1671@cox.net>
Matt Porter <mporter@kernel.crashing.org> wrote:
>
> Add an extern reference to perf_irq on e500.
>
> Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
>
> diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
> index 16adde6..ff1bdc2 100644
> --- a/arch/ppc/kernel/traps.c
> +++ b/arch/ppc/kernel/traps.c
> @@ -888,6 +888,8 @@ void altivec_assist_exception(struct pt_
> #endif /* CONFIG_ALTIVEC */
>
> #ifdef CONFIG_E500
> +extern perf_irq_t perf_irq;
> +
> void performance_monitor_exception(struct pt_regs *regs)
> {
> perf_irq(regs);
extern decls are placed in header files, please.
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2005-11-08 4:05 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev, linuxppc64-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
to get a powerpc update - various bug fixes (including Ben's fix for
the oops that Martin Bligh reported), some powermac and 8xx updates,
and a bit more merging. Diffstat and shortlog follow.
Thanks,
Paul.
arch/powerpc/Kconfig | 9
arch/powerpc/configs/g5_defconfig | 261 +++++--
arch/powerpc/kernel/misc_64.S | 70 ++
arch/powerpc/kernel/process.c | 4
arch/powerpc/kernel/prom.c | 21 -
arch/powerpc/kernel/prom_init.c | 11
arch/powerpc/kernel/rtas.c | 5
arch/powerpc/kernel/setup-common.c | 40 +
arch/powerpc/kernel/setup_32.c | 1
arch/powerpc/kernel/setup_64.c | 46 -
arch/powerpc/kernel/signal_32.c | 1
arch/powerpc/kernel/signal_64.c | 1
arch/powerpc/kernel/smp.c | 1
arch/powerpc/kernel/time.c | 5
arch/powerpc/kernel/traps.c | 11
arch/powerpc/lib/locks.c | 1
arch/powerpc/mm/fault.c | 17
arch/powerpc/mm/hash_utils_64.c | 10
arch/powerpc/mm/init_64.c | 1
arch/powerpc/mm/mem.c | 2
arch/powerpc/mm/numa.c | 1
arch/powerpc/mm/pgtable_64.c | 1
arch/powerpc/oprofile/op_model_power4.c | 24 +
arch/powerpc/platforms/iseries/irq.c | 5
arch/powerpc/platforms/iseries/pci.c | 37 -
arch/powerpc/platforms/iseries/setup.c | 4
arch/powerpc/platforms/iseries/smp.c | 1
arch/powerpc/platforms/powermac/Makefile | 3
arch/powerpc/platforms/powermac/cpufreq_32.c | 15
arch/powerpc/platforms/powermac/cpufreq_64.c | 323 ++++++++
arch/powerpc/platforms/powermac/setup.c | 13
arch/powerpc/platforms/pseries/iommu.c | 2
arch/powerpc/platforms/pseries/lpar.c | 3
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10
arch/powerpc/platforms/pseries/ras.c | 2
arch/powerpc/platforms/pseries/setup.c | 18
arch/powerpc/sysdev/i8259.c | 5
arch/powerpc/sysdev/u3_iommu.c | 1
arch/ppc/kernel/misc.S | 145 +++-
arch/ppc/kernel/traps.c | 12
arch/ppc/syslib/m8xx_wdt.c | 13
arch/ppc/syslib/prom.c | 4
arch/ppc/xmon/xmon.c | 5
arch/ppc64/Kconfig | 11
arch/ppc64/Kconfig.debug | 4
arch/ppc64/kernel/idle.c | 1
arch/ppc64/kernel/machine_kexec.c | 1
arch/ppc64/kernel/misc.S | 72 ++
arch/ppc64/kernel/pci.c | 17
arch/ppc64/kernel/prom.c | 25 +
arch/ppc64/kernel/prom_init.c | 3
arch/ppc64/kernel/rtas_pci.c | 6
arch/ppc64/kernel/udbg.c | 55 -
drivers/block/swim3.c | 20 -
drivers/ide/ppc/pmac.c | 9
drivers/macintosh/Kconfig | 19
drivers/macintosh/Makefile | 9
drivers/macintosh/smu.c | 174 ++++-
drivers/macintosh/via-pmu.c | 10
drivers/macintosh/windfarm.h | 131 +++
drivers/macintosh/windfarm_core.c | 426 +++++++++++
drivers/macintosh/windfarm_cpufreq_clamp.c | 105 +++
drivers/macintosh/windfarm_lm75_sensor.c | 263 +++++++
drivers/macintosh/windfarm_pid.c | 145 ++++
drivers/macintosh/windfarm_pid.h | 84 ++
drivers/macintosh/windfarm_pm81.c | 879 +++++++++++++++++++++++
drivers/macintosh/windfarm_pm91.c | 814 +++++++++++++++++++++
drivers/macintosh/windfarm_smu_controls.c | 282 +++++++
drivers/macintosh/windfarm_smu_sensors.c | 479 +++++++++++++
fs/proc/proc_devtree.c | 57 +
include/asm-powerpc/ide.h | 29 -
include/asm-powerpc/machdep.h | 4
include/asm-powerpc/ppc-pci.h | 1
include/asm-powerpc/prom.h | 2
include/asm-powerpc/reg.h | 9
include/asm-powerpc/smp.h | 4
include/asm-powerpc/smu.h | 199 +++++
include/asm-powerpc/xmon.h | 1
include/asm-ppc/btext.h | 22 -
include/asm-ppc/io.h | 12
include/asm-ppc/kgdb.h | 2
include/asm-ppc/prom.h | 2
include/asm-ppc64/ide.h | 30 -
include/asm-ppc64/pci.h | 8
include/asm-ppc64/ppcdebug.h | 108 ---
include/asm-ppc64/prom.h | 2
include/asm-ppc64/udbg.h | 3
include/linux/proc_fs.h | 9
88 files changed, 5134 insertions(+), 579 deletions(-)
rename arch/powerpc/platforms/powermac/{cpufreq.c => cpufreq_32.c} (99%)
create mode 100644 arch/powerpc/platforms/powermac/cpufreq_64.c
create mode 100644 drivers/macintosh/windfarm.h
create mode 100644 drivers/macintosh/windfarm_core.c
create mode 100644 drivers/macintosh/windfarm_cpufreq_clamp.c
create mode 100644 drivers/macintosh/windfarm_lm75_sensor.c
create mode 100644 drivers/macintosh/windfarm_pid.c
create mode 100644 drivers/macintosh/windfarm_pid.h
create mode 100644 drivers/macintosh/windfarm_pm81.c
create mode 100644 drivers/macintosh/windfarm_pm91.c
create mode 100644 drivers/macintosh/windfarm_smu_controls.c
create mode 100644 drivers/macintosh/windfarm_smu_sensors.c
rename include/{asm-ppc/ide.h => asm-powerpc/ide.h} (78%)
delete mode 100644 include/asm-ppc64/ide.h
delete mode 100644 include/asm-ppc64/ppcdebug.h
Anton Blanchard:
ppc64: fix Memory: summary line
ppc64: fix oprofile sample bit handling
ppc64: remove some direct xmon calls
Benjamin Herrenschmidt:
ppc64: SMU based macs cpufreq support
ppc64: SMU partition recovery
ppc64: Update g5_defconfig for ARCH=powerpc
ppc64: More U3 device-tree fixes
ppc64: Thermal control for SMU based machines
ppc: fix a bunch of warnings
ppc: Fix ARCH=ppc build with xmon
ppc: Fix PowerBook HD led on ARCH=powerpc
ppc64: Fix the lazy icache/dcache code for non-RAM pages
David Gibson:
powerpc: Kill ppcdebug
David Woodhouse:
powerpc: Fix i8259 cascade IRQ
powerpc: Fix ppc32 initrd
John Rose:
dlpar enable for OF pci probe
Marcelo Tosatti:
ppc32 8xx: fix m8xx_wdt accessor macro update
ppc32: handle access to non-present IO ports on 8xx
Michael Ellerman:
powerpc: Make ppc_md.set_dabr non 64-bit specific
Mike Kravetz:
Memory Add Fixes for ppc64
Olof Johansson:
powerpc: Nicer printing of address at oops
Paul Mackerras:
powerpc: Various UP build fixes
Merge ../linux-2.6
Merge ../linux-2.6
powerpc: Fix typo in pmac_cpufreq_resume
macintosh: Always export pmu_[un]register_sleep_notifier if CONFIG_PM set
powermac: Use a spinlock in swim3.c (floppy driver) instead of cli
Stephen Rothwell:
powerpc: merge ide.h
^ permalink raw reply
* Re: [PATCH] ppc32: fix perf_irq extern on e500
From: Matt Porter @ 2005-11-08 4:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
In-Reply-To: <20051107190128.68d41294.akpm@osdl.org>
On Mon, Nov 07, 2005 at 07:01:28PM -0800, Andrew Morton wrote:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > Add an extern reference to perf_irq on e500.
> >
> > Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
> >
> > diff --git a/arch/ppc/kernel/traps.c b/arch/ppc/kernel/traps.c
> > index 16adde6..ff1bdc2 100644
> > --- a/arch/ppc/kernel/traps.c
> > +++ b/arch/ppc/kernel/traps.c
> > @@ -888,6 +888,8 @@ void altivec_assist_exception(struct pt_
> > #endif /* CONFIG_ALTIVEC */
> >
> > #ifdef CONFIG_E500
> > +extern perf_irq_t perf_irq;
> > +
> > void performance_monitor_exception(struct pt_regs *regs)
> > {
> > perf_irq(regs);
>
> extern decls are placed in header files, please.
Ok, but we'll have to fix the equivalent code in arch/powerpc/.
The problem is that these rules are applied inconsistently at best. :)
-Matt
^ permalink raw reply
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 8:37 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hello Wolfgang,
Thanks for your answers.
I agree with you concerning the PPCBoot. In fact in other boards we are
using U-Boot.
We tried to use U-Boot for MPC859 but we had some problems we are =
trying to
solve.
As far as you know to change the boot or the kernel on cards in field =
is not
so easy :-(
Anyway, I would like to highlight I think the problem is more related =
to
the
kernel because when it starts I see the following error
init started: BusyBox v0.60.5 (2003.11.19-14:32+0000) multi-callmount:
Mounting devpts on /dev/pts failed: No su
ch file or directory
/opt/rc.project: /opt/bin/sinfo: No such file or directory
We check that slowing-down the UPM clock to 63 MHz (period=3D15.873ns) =
the
board showed a more stable behavior (no fault verified).
We start our investigation on the PPCBoot, but now we are moving on the
kernel.
No critical HW points have been found on the FLASH accesses, SDRAM =
accesses
and clocking circuitrty.
We found an unexpected beahviour regarding the Linux time tick.=20
Tracking with a HP16602 Bus Analyzer the bus activities of the faulty =
module
has been verified that the=20
interrupt service routine of the Decrementer timer, that I supposed to =
be
used to generate the OS time tick, it is not executed each 10ms.
Sometimes the period between 2 Decrementer interrupt service routines =
reach
hundreds of ms (but even as 10mS multiple)=20
such as some requests are missing.=20
Making the same tracking on a TQM866 module has been verified that the
interrupt service routines of the Decrementer timer are=20
all executed at the exact 10ms boundary.
Another interesting point is that the same kernel works well on other =
TQM8xx
modules, but not fot TQM859.
I will try to introduce the U-Boot, but I am not confident it will =
solve the
problem, what do you think about it?
Last question, which is the appropriate mailing list?
Thanks in advance for your support.
Best regards,
Agostino Sette
TechnoLabs
Department of Innovation Software3
S.S. 17 Localit=E0 Boschetto
67100 L' Aquila (Italy)
Tel: (+39) 0862 344.557
Fax: (+39) 0862 344.623
e-mail: Agostino.Sette@siemens.com =20
=20
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=20
Sent: luned=EC 7 novembre 2005 23.10
To: Sette Agostino
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPCBoot 2.0.0 Errors=20
In message =
<69DF49BE936F4441980EC1D59F0ADC2F0108C12C@aqlby02a.siemens.it>
you wrote:
>=20
> I have the following problem at the PPCBoot startup:
>=20
> PPCBoot 2.0.0 (Oct 20 2005 - 12:28:22)
PPCBoot is a dead project. It was discontinued more than 3 years ago.
It is definitely a bad idea to use it for current projects. Use
U-Boot instead.
Also, this is completely off topic on this mailing list.
> CPU: unknown MPC859 (0x08010004) at 133 MHz: 16 kB I-Cache 8 kB =
D-Cache
Use U-Boot instead.
> Board: Siemens CCM
And don't use a board configuration that does not match your hardware.
> ## Booting image at 40180000 ...
> Image Name: Linux-2.4.20-rthal5
Argh... Ancient stuff again. Forget it.
> Anybody experienced the same problem? Any suggestions about how to =
solve
it?
Use current software. Read the documentation. Post on the appropriate
mailing lists.
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
My challenge to the goto-less programmer is to recode tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens
^ permalink raw reply
* Re: PPCBoot 2.0.0 Errors
From: Wolfgang Denk @ 2005-11-08 9:08 UTC (permalink / raw)
To: Sette Agostino; +Cc: linuxppc-embedded
In-Reply-To: <69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it>
In message <69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it> you wrote:
>
> I agree with you concerning the PPCBoot. In fact in other boards we are using U-Boot.
> We tried to use U-Boot for MPC859 but we had some problems we are trying to
> solve.
You cannot solve these problems by downgrading to PPCBoot. The
852/859/866 processors are definitelu *not* supported by PPCBoot -
the required changes of the clock handling were added much later. You
*must* use U-Boot.
> As far as you know to change the boot or the kernel on cards in field is not
> so easy :-(
You mean you shipped boards to customers in the field in a state
where you did not even decide for a final version of the boot loader?
Gosh...
> We found an unexpected beahviour regarding the Linux time tick.
...whichis probablky cause by using PPCBoot which does not understand
to deal with a 859.
> Another interesting point is that the same kernel works well on other TQM8xx
> modules, but not fot TQM859.
U-Boot is running perfectly fine on the TQM859 - we have these boards
here in our virtual lab; they are tested on a regular base.
> I will try to introduce the U-Boot, but I am not confident it will solve the
> problem, what do you think about it?
I can *guarantee* you that PPCBoot is definitely worse on your hardware.
> Last question, which is the appropriate mailing list?
u-boot-users
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
Always leave room to add an explanation if it doesn't work out.
^ permalink raw reply
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 9:18 UTC (permalink / raw)
To: wd, Sette Agostino; +Cc: linuxppc-embedded
Wolfgang,
As I told you, I tried to produce the U-boot, but I am nont confident =
on the
version (1.0.0).
Could you suggest me the latest stale version I must get?
Thanks
Best Regards,
Agostino Sette
TechnoLabs
Department of Innovation Software3
S.S. 17 Localit=E0 Boschetto
67100 L' Aquila (Italy)
Tel: (+39) 0862 344.557
Fax: (+39) 0862 344.623
e-mail: Agostino.Sette@siemens.com =20
=20
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=20
Sent: marted=EC 8 novembre 2005 10.09
To: Sette Agostino
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPCBoot 2.0.0 Errors=20
In message =
<69DF49BE936F4441980EC1D59F0ADC2F0108C267@aqlby02a.siemens.it>
you wrote:
>=20
> I agree with you concerning the PPCBoot. In fact in other boards we =
are
using U-Boot.
> We tried to use U-Boot for MPC859 but we had some problems we are =
trying
to
> solve.
You cannot solve these problems by downgrading to PPCBoot. The
852/859/866 processors are definitelu *not* supported by PPCBoot -
the required changes of the clock handling were added much later. You
*must* use U-Boot.
> As far as you know to change the boot or the kernel on cards in field =
is
not
> so easy :-(
You mean you shipped boards to customers in the field in a state
where you did not even decide for a final version of the boot loader?
Gosh...
> We found an unexpected beahviour regarding the Linux time tick.=20
...whichis probablky cause by using PPCBoot which does not understand
to deal with a 859.
> Another interesting point is that the same kernel works well on other
TQM8xx
> modules, but not fot TQM859.
U-Boot is running perfectly fine on the TQM859 - we have these boards
here in our virtual lab; they are tested on a regular base.
> I will try to introduce the U-Boot, but I am not confident it will =
solve
the
> problem, what do you think about it?
I can *guarantee* you that PPCBoot is definitely worse on your =
hardware.
> Last question, which is the appropriate mailing list?
u-boot-users
Best regards,
Wolfgang Denk
--=20
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Always leave room to add an explanation if it doesn't work out.
^ permalink raw reply
* Re: fix swapping on 8xx?
From: David Jander @ 2005-11-08 11:59 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <b4fb08107c7bd17161f36e023035080a@embeddedalley.com>
On Tuesday 08 November 2005 01:55, Dan Malek wrote:
> On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> > The following is an attempt to fix swapping on 8xx by not touching
> > _PAGE_ACCESSED bit if the page is not present.
>
> Ugh .... I suppose. I hate assembler code macros .......
> Somehow, "swapping" and "8xx" just don't belong together.
Well, at least it sounds ugly together, but it is also at least conceiveable.
There seem to be people who use PCMCIA for an IDE interface, so swapping may
become desireable in some cases.
> I'm tempted to add a configuration option that is the complete
> opposite of this and assumes are really embedded system.
> Mark pages as always accessed, data pages as always dirty,
> and you can eliminate lots of TLB faults in systems that are
> fairly static.
It sounds tempting indeed, but should you really notice a performance increase
out of this?
Greetings,
--
David Jander
^ permalink raw reply
* Re: PPCBoot 2.0.0 Errors
From: Wolfgang Denk @ 2005-11-08 13:38 UTC (permalink / raw)
To: Sette Agostino; +Cc: linuxppc-embedded
In-Reply-To: <69DF49BE936F4441980EC1D59F0ADC2F0108C29F@aqlby02a.siemens.it>
In message <69DF49BE936F4441980EC1D59F0ADC2F0108C29F@aqlby02a.siemens.it> you wrote:
>
> As I told you, I tried to produce the U-boot, but I am nont confident on the
> version (1.0.0).
No, indeed. This is ancient stuff. Use top of tree from the GIT repo
(or CVS), or download the latest snapshot from our FTP server.
> Could you suggest me the latest stale version I must get?
May I suggest that you start reading the manual? See
http://www.denx.de/wiki/DULG/Manual
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
I will not say that women have no character; rather, they have a new
one every day. -- Heine
^ permalink raw reply
* RE: PPCBoot 2.0.0 Errors
From: Sette Agostino @ 2005-11-08 13:52 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>>
>> As I told you, I tried to produce the U-boot, but I am nont confident on
the
>> version (1.0.0).
>No, indeed. This is ancient stuff. Use top of tree from the GIT repo
>(or CVS), or download the latest snapshot from our FTP server.
Ok, I did it and I produced a new u-boot
>> Could you suggest me the latest stale version I must get?
>May I suggest that you start reading the manual? See
>http://www.denx.de/wiki/DULG/Manual
Ok, I alreay read it, but it is not so easy to convince my bosses to change
the boot :-(.
Anyway I am going to take a closer look to the doc.
Thanks once again
Best Regards
Agostino Sette
^ permalink raw reply
* Re: [PATCH] ppc32: fix perf_irq extern on e500
From: Matt Porter @ 2005-11-08 16:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, paulus, linuxppc-embedded
In-Reply-To: <20051107190128.68d41294.akpm@osdl.org>
On Mon, Nov 07, 2005 at 07:01:28PM -0800, Andrew Morton wrote:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > Add an extern reference to perf_irq on e500.
<snip>
> > #ifdef CONFIG_E500
> > +extern perf_irq_t perf_irq;
> > +
> > void performance_monitor_exception(struct pt_regs *regs)
> > {
> > perf_irq(regs);
>
> extern decls are placed in header files, please.
Here's the updated patch, addressing this for ppc64 as well. Paul,
would you prefer that this go through the powerpc-merge tree since
the updated version modifies arch/powerpc/?
-Matt
Fixes e500 build and cleans up traps.c by moving perf_irq extern to
pmc.h.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 07e5ee4..32cd797 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -898,10 +898,6 @@ void altivec_unavailable_exception(struc
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
}
-#ifdef CONFIG_PPC64
-extern perf_irq_t perf_irq;
-#endif
-
#if defined(CONFIG_PPC64) || defined(CONFIG_E500)
void performance_monitor_exception(struct pt_regs *regs)
{
diff --git a/include/asm-powerpc/pmc.h b/include/asm-powerpc/pmc.h
index 2f3c3fc..5f41f3a 100644
--- a/include/asm-powerpc/pmc.h
+++ b/include/asm-powerpc/pmc.h
@@ -22,6 +22,7 @@
#include <asm/ptrace.h>
typedef void (*perf_irq_t)(struct pt_regs *);
+extern perf_irq_t perf_irq;
int reserve_pmc_hardware(perf_irq_t new_perf_irq);
void release_pmc_hardware(void);
^ permalink raw reply related
* 440EP FPU support missing
From: Stefan Roese @ 2005-11-08 17:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc64-dev
In-Reply-To: <20051108093759.A26086@cox.net>
In the current linux version, Bamboo (440EP) won't compile anymore, because of
missing fpu support:
make uImage
...
LD init/built-in.o
LD .tmp_vmlinux1
arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
: undefined reference to `KernelFP'
make: *** [.tmp_vmlinux1] Error 1
Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
how to solve this problem (just restore the original file)?
Best regards,
Stefan
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Tom Rini @ 2005-11-08 17:56 UTC (permalink / raw)
To: David Jander; +Cc: linuxppc-embedded
In-Reply-To: <200511081259.26525.david.jander@protonic.nl>
On Tue, Nov 08, 2005 at 01:59:26PM +0200, David Jander wrote:
> On Tuesday 08 November 2005 01:55, Dan Malek wrote:
> > On Nov 7, 2005, at 10:10 AM, Marcelo Tosatti wrote:
> > > The following is an attempt to fix swapping on 8xx by not touching
> > > _PAGE_ACCESSED bit if the page is not present.
> >
> > Ugh .... I suppose. I hate assembler code macros .......
> > Somehow, "swapping" and "8xx" just don't belong together.
>
> Well, at least it sounds ugly together, but it is also at least conceiveable.
> There seem to be people who use PCMCIA for an IDE interface, so swapping may
> become desireable in some cases.
I think Dan might be in the camp that says a properly designed embedded
system won't need to swap. And when I hear about how people do try and
swap on systems like this, I really start agreeing. Maybe we could make
8xx just select SWAP=n? :)
> > I'm tempted to add a configuration option that is the complete
> > opposite of this and assumes are really embedded system.
> > Mark pages as always accessed, data pages as always dirty,
> > and you can eliminate lots of TLB faults in systems that are
> > fairly static.
>
> It sounds tempting indeed, but should you really notice a performance increase
> out of this?
Compared to 8xx in 2.6 today? Absolutely.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH] Remove arch/ppc/syslib/ppc4xx_pm.c
From: Alexey Dobriyan @ 2005-11-08 18:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, Domen Puncer
From: Domen Puncer <domen@coderock.org>
Remove nowhere referenced file ("grep ppc4xx_pm -r ." didn't find anything)
Signed-off-by: Domen Puncer <domen@coderock.org>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Index: linux-kj/arch/ppc/syslib/ppc4xx_pm.c
===================================================================
--- linux-kj.orig/arch/ppc/syslib/ppc4xx_pm.c 2005-11-08 20:46:23.000000000 +0300
+++ /dev/null 1970-01-01 00:00:00.000000000 +0000
@@ -1,47 +0,0 @@
-/*
- * Author: Armin Kuster <akuster@mvista.com>
- *
- * 2002 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- *
- * This an attempt to get Power Management going for the IBM 4xx processor.
- * This was derived from the ppc4xx._setup.c file
- */
-
-#include <linux/config.h>
-#include <linux/init.h>
-
-#include <asm/ibm4xx.h>
-
-void __init
-ppc4xx_pm_init(void)
-{
-
- unsigned int value = 0;
-
- /* turn off unused hardware to save power */
-#ifdef CONFIG_405GP
- value |= CPM_DCP; /* CodePack */
-#endif
-
-#if !defined(CONFIG_IBM_OCP_GPIO)
- value |= CPM_GPIO0;
-#endif
-
-#if !defined(CONFIG_PPC405_I2C_ADAP)
- value |= CPM_IIC0;
-#ifdef CONFIG_STB03xxx
- value |= CPM_IIC1;
-#endif
-#endif
-
-
-#if !defined(CONFIG_405_DMA)
- value |= CPM_DMA;
-#endif
-
- mtdcr(DCRN_CPMFR, value);
-
-}
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Dan Malek @ 2005-11-08 18:57 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108175658.GO3839@smtp.west.cox.net>
On Nov 8, 2005, at 12:56 PM, Tom Rini wrote:
> I think Dan might be in the camp that says a properly designed embedded
> system won't need to swap.
I'm actually in the camp that knows the majority of systems
running Linux aren't workstations and don't have disk drives.
It would be nice to have selectable features for such applications.
>> It sounds tempting indeed, but should you really notice a performance
>> increase
>> out of this?
Yes. Most importantly it adds some predictability which is quite
measurable on this class of processor. It was a coding mistake way
back in 2.2 that actually exposed this. I was taking some liberties by
updating more status in the PTE than I should have, and Paulus
made me fix it in 2.4 :-) It basically eliminates TLB faults associated
with system status tracking, since we aren't paging there isn't any
need to track page aging and such. If you are paging, it still
functions properly, you may just not pick the most suitable pages
to steal.
Thanks.
-- Dan
^ permalink raw reply
* Re: fix swapping on 8xx?
From: David Jander @ 2005-11-08 19:44 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <ae77b5dcfdaa24efebf92042907e2ce8@embeddededge.com>
>> I think Dan might be in the camp that says a properly designed embedded
>> system won't need to swap.
>
> I'm actually in the camp that knows the majority of systems
> running Linux aren't workstations and don't have disk drives.
> It would be nice to have selectable features for such applications.
Well, me too, but there are people out there trying to do strange stuff. I
remember myself even once trying to get swapping to work over nfs, because
I wanted to compile perl5 natively (overnight of course), since
cross-compiling perl is quite a bit of pain. Perl intends to
"include-together" enormous source files, that exhausted the whole 64Mbyte
RAM on my embedded board ;-)
Needless to say, swap over nfs did never work reliably enough to even
start compiling.
>>> It sounds tempting indeed, but should you really notice a performance
>>> increase out of this?
>
> Yes. Most importantly it adds some predictability which is quite
> measurable on this class of processor. It was a coding mistake way back
> in 2.2 that actually exposed this. I was taking some liberties by
> updating more status in the PTE than I should have, and Paulus
> made me fix it in 2.4 :-) It basically eliminates TLB faults associated
> with system status tracking, since we aren't paging there isn't any need
> to track page aging and such. If you are paging, it still
> functions properly, you may just not pick the most suitable pages to
> steal.
FYI, I have some benchmark results of yesterday's git of kernel-2.6 (with
_tlbie(address); just moved out of the two innermost if()'s in the
function update_mmu_cache()) compared to kernel 2.4.25 from denx, made
with "nbench". The results are quite interesting, and contradicting
(older) benchmark results, Wolfgang made a few months back:
kernel-2.6.14-git-20051107:
---------------------------
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 32.654 : 0.84 : 0.28
STRING SORT : 1.7408 : 0.78 : 0.12
BITFIELD : 8.3466e+06 : 1.43 : 0.30
FP EMULATION : 3.506 : 1.68 : 0.39
IDEA : 115.3 : 1.76 : 0.52
HUFFMAN : 27.855 : 0.77 : 0.25
LU DECOMPOSITION : 0.35932 : 0.02 : 0.01
kernel-2.4.25-devel-denx:
-------------------------
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 30.438 : 0.78 : 0.26
STRING SORT : 1.5842 : 0.71 : 0.11
BITFIELD : 7.9506e+06 : 1.36 : 0.28
FP EMULATION : 3.258 : 1.56 : 0.36
IDEA : 108.89 : 1.67 : 0.49
HUFFMAN : 26.281 : 0.73 : 0.23
LU DECOMPOSITION : 0.32765 : 0.02 : 0.01
This is all on the same hardware: MPC852T + 32Mbyte SDRAM running from
NFS. kernel 2.6 is faster all the way through!!
The results so far are pretty encouraging I'd say. Maybe something like
lmbench would help to shed more light on details important for kernel
testing, like context-switch overhead, mm, etc...
Nbench is quite useless here (a single task doing all sorts of nonsense,
almost no critical syscalls), but that's what makes the enormous
differences even more remarkable IMO. Maybe something is broken in 2.4?
Greetings,
--
David Jander
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Wolfgang Denk @ 2005-11-08 20:52 UTC (permalink / raw)
To: Tom Rini; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108175658.GO3839@smtp.west.cox.net>
In message <20051108175658.GO3839@smtp.west.cox.net> you wrote:
>
> > Well, at least it sounds ugly together, but it is also at least conceiveable.
> > There seem to be people who use PCMCIA for an IDE interface, so swapping may
> > become desireable in some cases.
>
> I think Dan might be in the camp that says a properly designed embedded
> system won't need to swap. And when I hear about how people do try and
> swap on systems like this, I really start agreeing. Maybe we could make
> 8xx just select SWAP=n? :)
No! David is right. There are systems out in the field running with
IDE harddisks attached (either through custom hardware interfaces or
through standard PCMCIA adapters), and some of these actually need
and use swap space.
Please do not remove stuff that is needed and used to work (in 2.4).
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
"Virtual" means never knowing where your next byte is coming from.
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Wolfgang Denk @ 2005-11-08 20:56 UTC (permalink / raw)
To: David Jander; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <27139.213.84.146.227.1131479070.squirrel@protonic.xs4all.nl>
In message <27139.213.84.146.227.1131479070.squirrel@protonic.xs4all.nl> you wrote:
>
> Needless to say, swap over nfs did never work reliably enough to even
> start compiling.
You can work around this. It's painfully slow, but it works. See
http://www.denx.de/wiki/view/DULG/SwappingOverNFS
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
Only a fool fights in a burning house.
-- Kank the Klingon, "Day of the Dove", stardate unknown
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Tom Rini @ 2005-11-08 21:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: David Jander, linuxppc-embedded
In-Reply-To: <20051108205259.A2870352B33@atlas.denx.de>
On Tue, Nov 08, 2005 at 09:52:59PM +0100, Wolfgang Denk wrote:
> In message <20051108175658.GO3839@smtp.west.cox.net> you wrote:
> >
> > > Well, at least it sounds ugly together, but it is also at least conceiveable.
> > > There seem to be people who use PCMCIA for an IDE interface, so swapping may
> > > become desireable in some cases.
> >
> > I think Dan might be in the camp that says a properly designed embedded
> > system won't need to swap. And when I hear about how people do try and
> > swap on systems like this, I really start agreeing. Maybe we could make
> > 8xx just select SWAP=n? :)
>
> No! David is right. There are systems out in the field running with
> IDE harddisks attached (either through custom hardware interfaces or
> through standard PCMCIA adapters), and some of these actually need
> and use swap space.
>
> Please do not remove stuff that is needed and used to work (in 2.4).
Note the bug in question exists in 2.4, and I think really even 2.2.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: fix swapping on 8xx?
From: Dan Malek @ 2005-11-08 22:30 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Tom Rini, David Jander, linuxppc-embedded
In-Reply-To: <20051108205259.A2870352B33@atlas.denx.de>
On Nov 8, 2005, at 3:52 PM, Wolfgang Denk wrote:
> Please do not remove stuff that is needed and used to work (in 2.4).
I'm not proposing we remove anything :-) It would just be nice
to eliminate the overhead of managing the PTEs if we don't
need such a feature. The complexity of the TLB miss handler
just keeps growing to add/fix this stuff, and it really shouldn't
be in that code path. All of this support should be pushed
into the error path, and if it was somewhat configurable we
wouldn't be in that path if not necessary.
Thanks.
-- Dan
^ permalink raw reply
* Re: 440EP FPU support missing
From: Matt Porter @ 2005-11-08 22:30 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200511081838.11236.sr@denx.de>
On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> In the current linux version, Bamboo (440EP) won't compile anymore, because of
> missing fpu support:
>
> make uImage
> ...
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> : undefined reference to `KernelFP'
> make: *** [.tmp_vmlinux1] Error 1
>
> Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> how to solve this problem (just restore the original file)?
arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
I don't know why the 44x fpu support wasn't using
kernel_fp_unavailable_exception() before but I must have missed that
reviewing it.
Try this patch.
-Matt
diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
index aeb349b..f3d274c 100644
--- a/arch/ppc/kernel/head_booke.h
+++ b/arch/ppc/kernel/head_booke.h
@@ -358,6 +358,6 @@ label:
NORMAL_EXCEPTION_PROLOG; \
bne load_up_fpu; /* if from user, just load it up */ \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_EE_LITE(0x800, KernelFP)
+ EXC_XFER_EE_LITE(0x800, kernel_fp_unavailable_exception)
#endif /* __HEAD_BOOKE_H__ */
^ permalink raw reply related
* Re: 440EP FPU support missing
From: David Gibson @ 2005-11-08 22:32 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <200511081838.11236.sr@denx.de>
On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> In the current linux version, Bamboo (440EP) won't compile anymore, because of
> missing fpu support:
>
> make uImage
> ...
> LD init/built-in.o
> LD .tmp_vmlinux1
> arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> : undefined reference to `KernelFP'
> make: *** [.tmp_vmlinux1] Error 1
>
> Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> how to solve this problem (just restore the original file)?
It's just moved to arch/powerpc/kernel/fpu.S. All you should need is
to tweak the Makefiles so that it's included in your build.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: 440EP FPU support missing
From: Josh Boyer @ 2005-11-08 22:32 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev, Stefan Roese, linuxppc64-dev
In-Reply-To: <20051108153036.F27232@cox.net>
On Tue, 2005-11-08 at 15:30 -0700, Matt Porter wrote:
> On Tue, Nov 08, 2005 at 06:38:11PM +0100, Stefan Roese wrote:
> > In the current linux version, Bamboo (440EP) won't compile anymore, because of
> > missing fpu support:
> >
> > make uImage
> > ...
> > LD init/built-in.o
> > LD .tmp_vmlinux1
> > arch/ppc/kernel/head_44x.o(.text+0x868): In function `_start':
> > : undefined reference to `KernelFP'
> > make: *** [.tmp_vmlinux1] Error 1
> >
> > Somehow arch/ppc/kernel/fpu.S has disappeared. :-( I assume, this happened in
> > the ppc/ppc64 -> powerpc merge. Any thoughts, why this file disappeared and
> > how to solve this problem (just restore the original file)?
>
> arch/powerpc/kernel/fpu.S is being used now which doesn't have KernelFP.
> I don't know why the 44x fpu support wasn't using
> kernel_fp_unavailable_exception() before but I must have missed that
> reviewing it.
>
> Try this patch.
Doesn't this render the 440EP's FPU useless?
josh
^ 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