* Re: [RFC/PATCH 1/2] Basic generic time/clocksource code for PowerPC
From: Gabriel Paubert @ 2007-09-10 9:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18147.49943.182399.64990@cargo.ozlabs.ibm.com>
On Sun, Sep 09, 2007 at 07:55:35PM +1000, Paul Mackerras wrote:
> Gabriel Paubert writes:
>
> > The solution now used by i386/x86-64/sparc64 is
> > CONFIG_GENERIC_CMOS_UPDATE. Maybe powerpc should be switched
> > to use something similar, but the generic code has some
>
> Yes. I'll turn on CONFIG_GENERIC_CMOS_UPDATE. Do you think it needs
> to be a config option that can be turned on and off in the kernel
> config, or should it just be always on as on x86[-64]?
I believe that it can be turned on systematically. But
I only have 32 bit, non HV machines (basically 603e, 750,
and 74xx processors).
>
> > problems (it assumes that you have to set the clock
> > on a half-second, which is not the case of the RTC on
> > my boards to start with).
>
> Let's get the generic code fixed to do what we need then. Care to
> send a patch?
I'm unsure on how to implement it in a way acceptable
upstream, the problem is that the following lines:
if (abs(xtime.tv_nsec - (NSEC_PER_SEC / 2)) <= tick_nsec / 2)
fail = update_persistent_clock(now);
next.tv_nsec = (NSEC_PER_SEC / 2) - now.tv_nsec;
are hardwired to half a second. Can it be transformed into
a per arch static inline function defined in asm-${arch}?
There is also a possible problem in notify_cmos_timer, I believe
that the logic is wrong and the condition is reversed and should
be "if (!no_sync_cmos_clock)".
Otherwise the clock update timer will never be started! This boolean
really should be called disable_persistent_clock_updates or something
similar.
I'm really wondering how much testing all this code has had. The
more I look at the timekeeping code changes in the last months,
the less I understand them.
Gabriel
^ permalink raw reply
* Re: random panic and freezes on mpc8349 itx
From: Nicolas Schichan @ 2007-09-10 13:48 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2BDF@twx-exch01.twacs.local>
On Friday 07 September 2007 23:16:35 Benedict, Michael wrote:
> What version of U-boot are you using?
Until recently I was using the u-boot-1.2.0 available on the
ftp://ftp.denx.de/pub/u-boot/ apparently there since january 2007.
I now use the git tree of today, and everything seems to work fine. I dit not
notice any freeze or random panic. "stress --cpu 256" is running on the board
and after 10 minutes it is still alive.
Thank you for the hint :)
Regards,
--
Nicolas Schichan
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Scott Wood @ 2007-09-10 14:25 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, David Gibson
In-Reply-To: <d16e868937a1f77cbf080754f5742ad9@bga.com>
On Sun, Sep 09, 2007 at 06:29:11PM -0500, Milton Miller wrote:
> >>diff --git a/arch/powerpc/boot/io.h b/arch/powerpc/boot/io.h
> >>index ccaedae..ec57ec9 100644
> >>--- a/arch/powerpc/boot/io.h
> >>+++ b/arch/powerpc/boot/io.h
> >>@@ -99,4 +99,11 @@ static inline void barrier(void)
> >> asm volatile("" : : : "memory");
> >> }
> >>
> >>+static inline void disable_irq(void)
> >>+{
> >>+ int dummy;
> >>+ asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0"
> >>:
> >>+ "=r" (dummy) : : "memory");
> >>+}
>
> This will fail (mtmsr illegal instruction) on 64 bit processors that do
> not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
Ouch... And given the One wrapper.a To Rule Them All mandate, we can't
ifdef it here, but instead must make separate platform files. :-P
> >>+ timebase_period_ns = 1000000000 / timebase;
> >>+ simple_alloc_init(_end, memsize64 - (unsigned long)_end, 32,
> >>64);
> >>+ ft_init(_dtb_start, _dtb_end - _dtb_start, 32);
> >>
>
> only 64 malloc slots?
That was copied from other platforms; it should probably be higher.
> So the labels are linked against to find the memory size to allocate
> all above the load address to malloc ...
>
> We can eliminate the need for the labels by calling simple_alloc_init
> twice: the first time on a small bss region, read the properties, then
> call it again with the full memory, and then call ft_init again. That
> is the trick I used in the kexec series. When dtlib merges, we can
> read the tree without malloc and avoid the extra dance.
OK.
> >>+ serial_console_init();
>
> I'm not sure I consider serial_console firemware independent: our
> wrapper IO macros simply do normal loads and stores, and rely on
> firmware to setup either tlbs, virtural mappings, or other to make the
> IO cache inhibited ...
The intent wasn't to run without firmware (that's require memory
initialization and other fun stuff that isn't here, and certainly isn't
generic), but to run without caring what the firmware is. It's assumed
that whatever firmware is there has initialized the serial port to meet
the needs of whatever serial port the device tree points at.
> yea, i realize it doesn't have to find a console, and it all works
> without it. But this is why I pulled the call from my kexec patches.
That option is available, by not specifying linux,stdout-path at all.
> Just to clarify: this should go in the Kconfig help:
> This platform requires
> (1) device tree fully filled out, including memory size and timebase
> frequency
> (2) (currently) labels
> (3) firmware that jumps to start of image (this is like old kernels)
> (4) after its in ram (we must have writable data/bss)
> (5) space below load to decompress vmlinux (no vmlinux_alloc to
> fallback to malloc)
> (6) all space above load address available to hold malloc region
> (7) for console output (or input) from wrapper, on most cpus, some
> magic setup
For #5, I really need to get around to implementing setting the load
address at build-time based on the size of vmlinux...
> >>+if [ -n "$binary" ]; then
> >>+ mv "$ofile" "$ofile".elf
> >>+ ${CROSS}objcopy -O binary "$ofile".elf "$ofile"
> >>+fi
>
> I'm not sure how putting a binary flag test here will help other
> platforms. Even those that want a .elf left behind, if they need ohter
> processing they will done the move already. I'd say just make this
> part of the platform case just above, although I could accept it being
> moved ahead of that case.
Well, it's also used by planetcore platforms...
> Actually, looking at the current case, treeboot, cuboot, and ps3 all
> (could) start with this rename and objcopy, so lets put it above the
> final platform fixup case, and update those platforms to use this
> feature (adjusting the calls to nm, dd, gzip, etc accordingly).
...but moving it earlier and letting other platforms use the result in
this way would be better, yes.
> Bottom line: This looks like a very simple platform, but it has hidden
> assumptions in its environment (mtmsr, laod in the middle of memory,
> others?) and takes the wrapper script in directions i'd rather it not
> go. I'd like you to look at my kexec platform series, and see if
> reusing some of that code would give us a more robust "raw" image.
> (even if you don't need the detached kernel, initramfs parsing, and
> detached initrd; I was thinking more like memranges and the
> vmlinuz_alloc. The policy about not using memory to end can be
> relaxed, and find_end_of_ram made to search memory). It's on my short
> list to rediff and repost those anyways.
Where can I find the existing patches?
-Scott
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Scott Wood @ 2007-09-10 14:30 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910142513.GB21670@ld0162-tx32.am.freescale.net>
On Mon, Sep 10, 2007 at 09:25:13AM -0500, Scott Wood wrote:
> > (5) space below load to decompress vmlinux (no vmlinux_alloc to
> > fallback to malloc)
> > (6) all space above load address available to hold malloc region
> > (7) for console output (or input) from wrapper, on most cpus, some
> > magic setup
>
> For #5, I really need to get around to implementing setting the load
> address at build-time based on the size of vmlinux...
Actually, this isn't needed for raw images -- you can just load them
wherever you want (and thus yes, it should be documented). cuboot needs
it, though.
-Scott
^ permalink raw reply
* Re: [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Nathan Lynch @ 2007-09-10 15:44 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070905020945.GF25900@lixom.net>
Olof Johansson wrote:
> commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
> Author: Olof Johansson <olof@lixom.net>
> Date: Tue Sep 4 21:53:30 2007 -0500
>
> [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
>
> Move pasemi_idle_init() to be a late_initcall instead of being called from
> setup_arch(). This way the cpufreq driver has a chance to initialize and
> save away the boot time astate before we go to idle for the first time.
The patch looks fine, but while I was reviewing this I noticed that
the pasemi cpufreq code is bool in Kconfig, but it has stuff like
module_init() etc in it. It's not hurting anything, but it did
temporarily make me wonder "what happens if the cpufreq driver is
modular"?
^ permalink raw reply
* Re: [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Olof Johansson @ 2007-09-10 16:00 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070910154443.GK32388@localdomain>
On Mon, Sep 10, 2007 at 10:44:43AM -0500, Nathan Lynch wrote:
> Olof Johansson wrote:
> > commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
> > Author: Olof Johansson <olof@lixom.net>
> > Date: Tue Sep 4 21:53:30 2007 -0500
> >
> > [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
> >
> > Move pasemi_idle_init() to be a late_initcall instead of being called from
> > setup_arch(). This way the cpufreq driver has a chance to initialize and
> > save away the boot time astate before we go to idle for the first time.
>
> The patch looks fine, but while I was reviewing this I noticed that
> the pasemi cpufreq code is bool in Kconfig, but it has stuff like
> module_init() etc in it. It's not hurting anything, but it did
> temporarily make me wonder "what happens if the cpufreq driver is
> modular"?
Good point. I actually kept it from being modular for the very reason
that it's needed in the idle loop to restore the cpu frequency when
coming out of power savings modes.
The whole idle/cpufreq dependencies should be overhauled at some point,
to avoid this, or at least allow the cpufreq driver to be a module
(and make idle default to spin when it's not loaded).
-Olof
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-10 16:01 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910143006.GD21670@ld0162-tx32.am.freescale.net>
On Sep 10, 2007, at 9:30 AM, Scott Wood wrote:
> On Mon, Sep 10, 2007 at 09:25:13AM -0500, Scott Wood wrote:
>>> (5) space below load to decompress vmlinux (no vmlinux_alloc to
>>> fallback to malloc)
>>> (6) all space above load address available to hold malloc region
>>> (7) for console output (or input) from wrapper, on most cpus, some
>>> magic setup
>>
>> For #5, I really need to get around to implementing setting the load
>> address at build-time based on the size of vmlinux...
>
> Actually, this isn't needed for raw images -- you can just load them
> wherever you want (and thus yes, it should be documented). cuboot
> needs
> it, though.
Yea, raw doesn't really care about the linked address.
>>> It's on my short list to rediff and repost those anyways.
>>
>> Where can I find the existing patches?
The last rediff is patchwork id 12168-12181 posted Jul 11. They get
context rejects in the Makefile and ops.h, and I plan to change the
property name from boot-file in patch 12. Also, I need to make the
search for rmo_end be based on device_type "memory", looking for the
extent starting at 0.
milton
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Milton Miller @ 2007-09-10 16:09 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev, David Gibson
In-Reply-To: <20070910142513.GB21670@ld0162-tx32.am.freescale.net>
On Sep 10, 2007, at 9:25 AM, Scott Wood wrote:
>>>> +static inline void disable_irq(void)
>>>> +{
>>>> + int dummy;
>>>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr
>>>> %0"
>>>> :
>>>> + "=r" (dummy) : : "memory");
>>>> +}
>>
>> This will fail (mtmsr illegal instruction) on 64 bit processors that
>> do
>> not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
>
> Ouch... And given the One wrapper.a To Rule Them All mandate, we can't
> ifdef it here, but instead must make separate platform files. :-P
Rather than a seperate c file, I think this should go in your
_zimage_start, renaming fixed-head.S.
milton
^ permalink raw reply
* SPI driver?
From: Hesam Kohanteb @ 2007-09-10 16:16 UTC (permalink / raw)
To: linuxppc-embedded
We need a Linux based SPI driver for MPC885. Do you know where can I
possibly find the code.
Regards. --Hesam
--
Hesam Yehuda Kohanteb
(Netra Systems & Networking),
M/S USCA12-216 4120 Network Circle
Santa Clara, CA 95054
(W) 408-276-7329 X17329, Fax 408-276-4552
^ permalink raw reply
* Which 2.6 kernel for MPC5200
From: Babarovic Ivica @ 2007-09-10 17:10 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
What kernel should I get/pull for MPC5200 clone board.
I've been away from coding on mpc5200 for quite some time now.
I've read some archives from ML.
Git repo on Sylvain Munauts url:
http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.gitpage
isn't working. Nothing on http://*git*.secretlab.ca/cgi-bin/*gitweb*.cgi
<http://git.secretlab.ca/cgi-bin/gitweb.cgi> to.
I've pulled the sources from kernel.org git server.
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
linux-2.6-mpc52xx
How recent are these sources?
Regards,
I.
^ permalink raw reply
* Re: 2.6.23-rc4-mm1 -- powerpc per_cpu__cpu_sibling_map compile failure
From: Andy Whitcroft @ 2007-09-10 17:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: mel, linuxppc-dev, linux-kernel
In-Reply-To: <20070831215822.26e1432b.akpm@linux-foundation.org>
Am seeing the following compile error on all of my powerpc platforms:
CC kernel/sched.o
kernel/sched.c: In function `cpu_to_phys_group':
kernel/sched.c:5937: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)
kernel/sched.c:5937: error: (Each undeclared identifier is reported only once
kernel/sched.c:5937: error: for each function it appears in.)
kernel/sched.c:5937: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:5937: error: invalid type argument of `unary *'
kernel/sched.c: In function `build_sched_domains':
kernel/sched.c:6172: error: `per_cpu__cpu_sibling_map' undeclared (first use in this function)
kernel/sched.c:6172: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:6172: error: invalid type argument of `unary *'
kernel/sched.c:6183: warning: type defaults to `int' in declaration of `type name'
kernel/sched.c:6183: error: invalid type argument of `unary *'
make[1]: *** [kernel/sched.o] Error 1
make: *** [kernel] Error 2
-apw
^ permalink raw reply
* Re: Which 2.6 kernel for MPC5200
From: Grant Likely @ 2007-09-10 18:20 UTC (permalink / raw)
To: Babarovic Ivica; +Cc: linuxppc-embedded
In-Reply-To: <46E57A9D.2020506@asist.si>
On 9/10/07, Babarovic Ivica <ivica.babarovic@asist.si> wrote:
> Hi!
>
> What kernel should I get/pull for MPC5200 clone board.
> I've been away from coding on mpc5200 for quite some time now.
> I've read some archives from ML.
> Git repo on Sylvain Munauts url:
> http://gitbits.246tNt.com/gitbits/linux-2.6-mpc52xx.gitpage
> isn't working. Nothing on http://*git*.secretlab.ca/cgi-bin/*gitweb*.cgi
> <http://git.secretlab.ca/cgi-bin/gitweb.cgi> to.
>
> I've pulled the sources from kernel.org git server.
> git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> linux-2.6-mpc52xx
My 52xx git tree became way out of date, so I dropped it from the
server. Best bet is to use mainline which gives your everything
except the drivers that use the bestcomm DMA engine (like Ethernet).
Then you need to apply the bestcomm patches. You can get them here:
http://www.246tnt.com/mpc52xx/dev_full/
Have fun,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Need confirmation on MP8349 configuration problem
From: Grant Likely @ 2007-09-10 18:28 UTC (permalink / raw)
To: Timur Tabi, linuxppc-embedded
Hey Timur,
As we talked about on IRC, I'm having problems getting the BDI-2000 to
configure the MPC8349 when CFG_RESET_SOURCE is set to a hard coded
config (Like 100 or 111).
Can you please confirm what I'm seeing on one of your boards?
Steps to reproduce:
1. Set BDI config to override default RCW and initialize FLASH/RAM
2. Power up board and verify that BDI can read DDR and FLASH (using md commands)
3. Power down and remove jumpers A, B & C.
4. Power up and read DDR/FLASH again. At this point I get '# SAP:
read access failed' from the BDI-2000.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-10 18:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000e01c7f177$05ab1990$3a0d10ac@Radstone.Local>
Ilya Lipovsky wrote:
> Yes, I am uncertain. If it isn't a major headache, I think
> you can try the
> newest version (I think it's 2.6.1) and see if you get some
> resolution.=20
<snip>
> Please do share the outcome!!
>=20
> -Ilya
No luck with 2.6.1:
~ $ /lib/libc.so.6
GNU C Library stable release version 2.6.1, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.1.
Compiled on a Linux 2.6.12 system on 2007-09-10.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
~ $ ./bar
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!
I will continue investigating and follow up on this thread if I come
across anything.
-Michael
^ permalink raw reply
* Please pull powerpc.git merge branch
From: Paul Mackerras @ 2007-09-10 19:13 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There are four bug-fixes there. Three of them are to fix problems on
PS3 and the fourth is to fix a problem on POWER6 machines.
Thanks,
Paul.
arch/powerpc/kernel/ibmebus.c | 30 +++++++++---------------------
arch/powerpc/platforms/cell/spu_base.c | 24 +++++++++++++++---------
arch/powerpc/platforms/ps3/platform.h | 1 +
arch/powerpc/platforms/ps3/repository.c | 29 +++++++++++++++++++++++++++++
arch/powerpc/platforms/ps3/spu.c | 2 ++
include/asm-powerpc/spu.h | 2 +-
6 files changed, 57 insertions(+), 31 deletions(-)
commit d8612417b2f78767b96ca434b50d23e5cdfcde07
Author: Joachim Fenkes <fenkes@de.ibm.com>
Date: Wed Aug 29 18:15:17 2007 +0200
[POWERPC] ibmebus: Prevent bus_id collisions
Previously, ibmebus derived a device's bus_id from its location code.
The location code is not guaranteed to be unique, so we might get bus_id
collisions if two devices share the same location code. The OFDT
full_name, however, is unique, so we use that instead (truncating it
on the left if it is too long).
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit d51dd3de87026cb0ea1ea5f873f08e930053bfc5
Author: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Date: Thu Sep 6 18:14:57 2007 +0200
[POWERPC] cell/PS3: Ignore storage devices that are still being probed
On PS3, A storage device may show up in the repository before the hypervisor
has finished probing:
- If its type is not yet known, it shows up as PS3_DEV_TYPE_STOR_DUMMY,
- If its regions are being probed, it shows up as having zero regions.
If any of these happen, consider the device not yet present. The storage
probe thread will retry later.
This fixes the timing-dependent problem where a kernel booted from FLASH ROM
sometimes cannot find the hard disk.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Acked-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit ef8034d01a080e81488e9cf74052acf1e2a37bd0
Author: Jeremy Kerr <jk@ozlabs.org>
Date: Fri Sep 7 18:28:27 2007 +1000
[POWERPC] cell/PS3: Always set master run control bit in mfc_sr1_set
At present, running any SPE program on the ps3 will trigger a BUG_ON
when spufs_run_spu tries to clear the master run control bit, as lv1
does not make the master run control available to Linux.
This change makes SPE apps work again by disabling changes to the
master run control on PS3. Although we don't have the facility to
disable a SPE with supervisor-level privileges, it's better than
hitting the BUG_ON unconditionally.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
commit b7f90a406ff72d6698b619210c205e3375dd099a
Author: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Date: Fri Sep 7 18:28:27 2007 +1000
[POWERPC] cell/PS3: Fix a bug that causes the PS3 to hang on the SPU Class 0 interrupt.
The Cell BE Architecture spec states that the SPU MFC Class 0 interrupt
is edge-triggered. The current spu interrupt handler assumes this
behavior and does not clear the interrupt status.
The PS3 hypervisor visualizes all SPU interrupts as level, and on return
from the interrupt handler the hypervisor will deliver a new virtual
interrupt for any unmasked interrupts which for which the status has not
been cleared. This fix clears the interrupt status in the interrupt
handler.
Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Kumar Gala @ 2007-09-10 19:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192910.GA32462@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
> The hardware adds one to the BRG value to get the divider, so it must
> be subtracted by software. Without this patch, characters will
> occasionally
> be corrupted.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/cpm2_common.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
What was this patch against?
I ended up applying it by hand for 2.6.23 since its fixing a bug..
But, I'm wondering if there was a base set of changes this patchset
was against?
- k
> diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/
> sysdev/cpm2_common.c
> index dbef50c..99ad1ed 100644
> --- a/arch/powerpc/sysdev/cpm2_common.c
> +++ b/arch/powerpc/sysdev/cpm2_common.c
> @@ -102,7 +102,7 @@ cpm_setbrg(uint brg, uint rate)
> brg -= 4;
> }
> bp += brg;
> - out_be32(bp, ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN);
> + out_be32(bp, (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN);
>
> cpm2_unmap(bp);
> }
> --
> 1.5.3
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Scott Wood @ 2007-09-10 19:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EDF5D1CF-E423-449F-A435-9BD044206F4F@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>
>> The hardware adds one to the BRG value to get the divider, so it must
>> be subtracted by software. Without this patch, characters will
>> occasionally
>> be corrupted.
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> ---
>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> What was this patch against?
>
> I ended up applying it by hand for 2.6.23 since its fixing a bug.. But,
> I'm wondering if there was a base set of changes this patchset was against?
It was against head-of-your-tree as of the time I sent it.
-Scott
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: Jon Loeliger @ 2007-09-10 20:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <b976a70bd1942da7e31b9a409b2de569@kernel.crashing.org>
On Thu, 2007-09-06 at 09:09, Segher Boessenkool wrote:
> >> Either way, it's a bit late to change this, no?
> >
> > Sure, I was just whining due to having been bitten by this sort of bug
> > in
> > the past. :-)
>
> Write a song about it, it's therapeutical it seems!
One of these things is not like the others,
One of these things just doesn't belong,
Can you tell which thing is not like the others
By the time I finish my song?
Never mind.
jdl
^ permalink raw reply
* Re: [PATCH] powerpc: Don't use generic machine check parsing everywhere
From: Paul Mackerras @ 2007-09-10 20:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070905024159.GB27139@lixom.net>
Olof Johansson writes:
> If a platform provide it's own machine check handler, assume that code
> will handle the reason parsing and reporting the error. The current
> default fall-though only makes sense on a few 32-bit platforms that
> lack individual handlers.
Might be nice to put that code into a function of its own, called
print_6xx_machine_check or something similar.
Paul.
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Kumar Gala @ 2007-09-10 21:07 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <46E59E9E.30707@freescale.com>
On Sep 10, 2007, at 2:44 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>>> The hardware adds one to the BRG value to get the divider, so it
>>> must
>>> be subtracted by software. Without this patch, characters will
>>> occasionally
>>> be corrupted.
>>>
>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>> What was this patch against?
>> I ended up applying it by hand for 2.6.23 since its fixing a
>> bug.. But, I'm wondering if there was a base set of changes this
>> patchset was against?
>
> It was against head-of-your-tree as of the time I sent it.
Odd, my top of tree doesn't use out_be32() for cpm_setbrg().
- k
^ permalink raw reply
* Re: [PATCH 02/10] cpm2: Fix off-by-one error in setbrg().
From: Scott Wood @ 2007-09-10 21:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <5275D8E2-1DF2-4E2E-B9AC-7E085E69BF72@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 10, 2007, at 2:44 PM, Scott Wood wrote:
>
>> Kumar Gala wrote:
>>> On Sep 5, 2007, at 2:29 PM, Scott Wood wrote:
>>>> The hardware adds one to the BRG value to get the divider, so it must
>>>> be subtracted by software. Without this patch, characters will
>>>> occasionally
>>>> be corrupted.
>>>>
>>>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/cpm2_common.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>> What was this patch against?
>>> I ended up applying it by hand for 2.6.23 since its fixing a bug..
>>> But, I'm wondering if there was a base set of changes this patchset
>>> was against?
>>
>> It was against head-of-your-tree as of the time I sent it.
>
> Odd, my top of tree doesn't use out_be32() for cpm_setbrg().
That was done by patch 01/10. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 08/10] bootwrapper: Add a firmware-independent "raw" target.
From: Segher Boessenkool @ 2007-09-10 21:17 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev, David Gibson
In-Reply-To: <d16e868937a1f77cbf080754f5742ad9@bga.com>
>>> +static inline void disable_irq(void)
>>> +{
>>> + int dummy;
>>> + asm volatile("mfmsr %0; rlwinm %0, %0, 0, ~(1<<15); mtmsr %0"
>>> :
>>> + "=r" (dummy) : : "memory");
>>> +}
>
> This will fail (mtmsr illegal instruction) on 64 bit processors that do
> not implement the bridge facility (POWER4, 5, 6, PPC970, ...)
The latest ISA lists mtmsr as non-optional, not part of the bridge
facility. That suggests that all CPUs do in fact implement it.
970 does implement the 64-bit bridge facility, btw (well, "most of it").
Segher
^ permalink raw reply
* Please pull from 'for-2.6.23'
From: Kumar Gala @ 2007-09-10 21:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.23' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.23
to receive the following updates:
arch/powerpc/platforms/85xx/mpc8544_ds.c | 2 ++
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 2 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 2 ++
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 2 ++
arch/powerpc/platforms/Kconfig | 1 +
arch/powerpc/sysdev/cpm2_common.c | 2 +-
arch/ppc/kernel/head_8xx.S | 2 --
7 files changed, 9 insertions(+), 4 deletions(-)
Jochen Friedrich (1):
[PPC] 8xx: Fix r3 trashing due to 8MB TLB page instantiation
Kumar Gala (2):
[POWERPC] 8{5,6}xx: Fix build issue with !CONFIG_PCI
[POWERPC] Enable GENERIC_ISA_DMA if FSL_ULI1575
Scott Wood (1):
[POWERPC] cpm2: Fix off-by-one error in setbrg().
commit 8fb427e656e2379f295d18134ef1f2cc924e994c
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Sep 10 14:57:34 2007 -0500
[POWERPC] Enable GENERIC_ISA_DMA if FSL_ULI1575
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 83fcdb4b352f74a8a74737aedeaf622c37140c73
Author: Scott Wood <scottwood@freescale.com>
Date: Wed Sep 5 14:29:10 2007 -0500
[POWERPC] cpm2: Fix off-by-one error in setbrg().
The hardware adds one to the BRG value to get the divider, so it must
be subtracted by software. Without this patch, characters will occasionally
be corrupted.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 36c50f729b77144cae8d43457fefca66a4eeff6a
Author: Jochen Friedrich <jochen@scram.de>
Date: Tue Aug 28 13:20:48 2007 +0200
[PPC] 8xx: Fix r3 trashing due to 8MB TLB page instantiation
Instantiation of 8MB pages on the TLB cache for the kernel static
mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
This ensures r3 gets saved and restored.
This has been posted to linuxppc-embedded by Marcelo Tosatti
<marcelo@kvack.org>, but only an incomplete version of the patch
has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4.
This patch adds the rest of the fix.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 2af8569dc9f29c303bf4aa012d991afcfaeed0c3
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Mon Sep 10 14:30:33 2007 -0500
[POWERPC] 8{5,6}xx: Fix build issue with !CONFIG_PCI
We needed some ifdef CONFIG_PCI protection for pcibios_fixup so we
can build !CONFIG_PCI.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/arch/powerpc/platforms/85xx/mpc8544_ds.c b/arch/powerpc/platforms/85xx/mpc8544_ds.c
index 0f834d8..48983bc 100644
--- a/arch/powerpc/platforms/85xx/mpc8544_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc8544_ds.c
@@ -178,7 +178,9 @@ define_machine(mpc8544_ds) {
.probe = mpc8544_ds_probe,
.setup_arch = mpc8544_ds_setup_arch,
.init_IRQ = mpc8544_ds_pic_init,
+#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
.get_irq = mpic_get_irq,
.restart = mpc85xx_restart,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
index 6a171e9..2d4cb78 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -351,10 +351,10 @@ define_machine(mpc85xx_cds) {
.get_irq = mpic_get_irq,
#ifdef CONFIG_PCI
.restart = mpc85xx_cds_restart,
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#else
.restart = mpc85xx_restart,
#endif
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
- .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
};
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index be25ecd..7ca7e67 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -207,5 +207,7 @@ define_machine(mpc85xx_mds) {
.restart = mpc85xx_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
};
diff --git a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
index 56b27ca..47aafa7 100644
--- a/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
+++ b/arch/powerpc/platforms/86xx/mpc86xx_hpcn.c
@@ -250,5 +250,7 @@ define_machine(mpc86xx_hpcn) {
.time_init = mpc86xx_time_init,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
+#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
};
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index cfc2497..19d4628 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -285,6 +285,7 @@ config AXON_RAM
config FSL_ULI1575
bool
default n
+ select GENERIC_ISA_DMA
help
Supports for the ULI1575 PCIe south bridge that exists on some
Freescale reference boards. The boards all use the ULI in pretty
diff --git a/arch/powerpc/sysdev/cpm2_common.c b/arch/powerpc/sysdev/cpm2_common.c
index 9244129..c827715 100644
--- a/arch/powerpc/sysdev/cpm2_common.c
+++ b/arch/powerpc/sysdev/cpm2_common.c
@@ -102,7 +102,7 @@ cpm_setbrg(uint brg, uint rate)
brg -= 4;
}
bp += brg;
- *bp = ((BRG_UART_CLK / rate) << 1) | CPM_BRG_EN;
+ out_be32(bp, (((BRG_UART_CLK / rate) - 1) << 1) | CPM_BRG_EN);
cpm2_unmap(bp);
}
diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
index 944c35c..eb8d26f 100644
--- a/arch/ppc/kernel/head_8xx.S
+++ b/arch/ppc/kernel/head_8xx.S
@@ -495,9 +495,7 @@ LoadLargeDTLB:
lwz r11, 4(r0)
lwz r12, 16(r0)
-#ifdef CONFIG_8xx_CPU6
lwz r3, 8(r0)
-#endif
rfi
/* This is the data TLB error on the MPC8xx. This could be due to
^ permalink raw reply related
* Re: [PATCH] export new __io{re,un}map_at() symbols
From: Paul Mackerras @ 2007-09-10 21:57 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070831035851.GA24414@lixom.net>
Olof Johansson writes:
> Export new __io{re,un}map_at() symbols so modules can use them.
What module wants to use these? How is it going to work out what
effective address to use?
Paul.
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-10 21:41 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000e01c7f177$05ab1990$3a0d10ac@Radstone.Local>
Ilya Lipovsky wrote:
> Your code looks correct to me, so if the kernel developers
> did their job
> correctly, the only potentially weak link is glibc.
>=20
Well, either the kernel developers didn't do their job, or I am missing
something. The following also fails, and it should be bypassing glibc:
#define _XOPEN_SOURCE 600
#include <linux/futex.h>
#include <sys/time.h>
#include <asm/atomic.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <sched.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
int myfutex =3D 0;
void *important(void *ign)
{
sleep(1);
printf("important waiting for futex\n");
fflush(stdout);
if(syscall(SYS_futex, &myfutex, FUTEX_WAIT, 0, NULL)) {
perror("futex");
exit(1);
} else {
printf("important got futex!\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
}
return NULL;
}
void *unimportant(void *ign)
{
printf("unimportant waiting for futex\n");
fflush(stdout);
if(syscall(SYS_futex, &myfutex, FUTEX_WAIT, 0, NULL)) {
perror("futex");
exit(1);
} else {
printf("unimportant got futex!\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
}
return NULL;
}
int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;
p.__sched_priority =3D sched_get_priority_min(SCHED_FIFO);
if(-1 =3D=3D p.__sched_priority) {
perror("sched_get_priority_min");
return 1;
}
pthread_attr_init(&attr);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&u, &attr, unimportant, NULL);
p.__sched_priority =3D sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&i, &attr, important, NULL);
sleep(5);
printf("futex FUTEX_WAKE\n");
fflush(stdout);
syscall(SYS_futex, &myfutex, FUTEX_WAKE, 1, NULL);
pthread_join(u, NULL);
pthread_join(i, NULL);
return 0;
}
Which produces:
unimportant waiting for futex
important waiting for futex
futex FUTEX_WAKE
unimportant got futex!
important got futex!
Could someone with 2.6.22 please verify? =20
^ 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