* [RFC] xmon: setjmp / longjmp implementation problems
From: Florian Boelstler @ 2007-08-23 22:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
Hi,
I was hunting an ugly problem in the NuBus PowerMac port of Linux [1]
for a while now (that platform isn't included in mainline kernel and
still is based on 2.4 kernel series).
Linux was successfully built using gcc-3.3.5/binutils-2.15 so far.
Later toolchain versions (e.g. gcc-3.4.5/binutils-2.15) turned out to
break things during hardware detection on the NuBus.
Looking at the relevant code sections shows that the register probing
code is based on the setjmp/longjmp implementation [2] found in xmon.
Regarding the "ppc" platform that code almost matches at least up to
mainline kernel 2.6.20.1 [3].
On the "powerpc" platform the code did dramatically change [4].
I was extracting both implementations to a simple userspace application
to be able to easily try different compiler versions and optimization
levels.
Eventually I found out that the temporary solution is to build the
ppc-implementation using -O1 for gcc versions >3.3.5.
Since I found a comment by Paul in arch/ppc/xmon/setjmp.c: "NB this file
must be compiled with -O2.", I was wondering which toolchain versions
are/were used to compile xmon-enabled kernels for the ppc and powerpc
platform.
Since -O2 seems to be the default for 2.6 kernels as well, I am
wondering what gcc version is known to build a kernel with xmon support.
Are there are any known gcc versions, which are causing trouble with
xmon (actually its setjmp/longjmp implementation)?
Some details of toolchain tests follow:
"ppc" implementation:
When -O2 is used gcc-3.4.5 inlines static functions by default, which
turned out to be the first problem. Even when "static" is removed the
resulting program flow reflects an infinite loop (when longjumped
function returns).
I found out that -O1 with gcc-3.4.5 generates code, which resembles the
functionality of gcc-3.3.5 with -O2. I.e. a working version of
setjmp/longjmp. A segmentation fault occurs when no optimization level
is used.
With gcc-4.1.0 no successful working build was possible.
"powerpc" implementation:
The binary works with no optimization level, -O0 and -O1 with gcc-3.4.5.
Using -O2 turns the resulting code into an infinite loop again.
With gcc-4.1.0/binutils-2.16.1 only -O0 generated a useful binary.
Thanks for any suggestions!
Florian
[1] http://nubus-pmac.sf.net
[2]
http://nubus-pmac.cvs.sourceforge.net/nubus-pmac/linuxppc-2.4-nubus/arch/ppc/platforms/nbpmac_setup.c
Lines 162-194
[3] http://lxr.linux.no/source/arch/ppc/xmon/setjmp.c?a=ppc
[4] http://lxr.linux.no/source/arch/powerpc/xmon/setjmp.S?a=ppc
^ permalink raw reply
* [PATCH] powerpc: prom_init whitespace cleanup, typo fix.
From: Linas Vepstas @ 2007-08-23 23:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
Whitespace cleanup: badly indented lines.
Typo in comment.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
---
Yeah, OK, so the patch is lame. Stuff caught my eye while reading code.
arch/powerpc/kernel/prom_init.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c
===================================================================
--- linux-2.6.22-git2.orig/arch/powerpc/kernel/prom_init.c 2007-07-08 18:32:17.000000000 -0500
+++ linux-2.6.22-git2/arch/powerpc/kernel/prom_init.c 2007-08-23 17:27:37.000000000 -0500
@@ -1197,7 +1197,7 @@ static void __init prom_initialize_tce_t
if ((type[0] == 0) || (strstr(type, RELOC("pci")) == NULL))
continue;
- /* Keep the old logic in tack to avoid regression. */
+ /* Keep the old logic intact to avoid regression. */
if (compatible[0] != 0) {
if ((strstr(compatible, RELOC("python")) == NULL) &&
(strstr(compatible, RELOC("Speedwagon")) == NULL) &&
@@ -2224,7 +2224,7 @@ static void __init fixup_device_tree(voi
static void __init prom_find_boot_cpu(void)
{
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
u32 getprop_rval;
ihandle prom_cpu;
phandle cpu_pkg;
@@ -2244,7 +2244,7 @@ static void __init prom_find_boot_cpu(vo
static void __init prom_check_initrd(unsigned long r3, unsigned long r4)
{
#ifdef CONFIG_BLK_DEV_INITRD
- struct prom_t *_prom = &RELOC(prom);
+ struct prom_t *_prom = &RELOC(prom);
if (r3 && r4 && r4 != 0xdeadbeef) {
unsigned long val;
@@ -2277,7 +2277,7 @@ unsigned long __init prom_init(unsigned
unsigned long pp,
unsigned long r6, unsigned long r7)
{
- struct prom_t *_prom;
+ struct prom_t *_prom;
unsigned long hdr;
unsigned long offset = reloc_offset();
@@ -2336,8 +2336,8 @@ unsigned long __init prom_init(unsigned
/*
* Copy the CPU hold code
*/
- if (RELOC(of_platform) != PLATFORM_POWERMAC)
- copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
+ if (RELOC(of_platform) != PLATFORM_POWERMAC)
+ copy_and_flush(0, KERNELBASE + offset, 0x100, 0);
/*
* Do early parsing of command line
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Guennadi Liakhovetski @ 2007-08-23 23:21 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070823002637.GA24332@lixom.net>
On Wed, 22 Aug 2007, Olof Johansson wrote:
> With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> initcall is now called before I/O space is setup, but it's dependent on
> it being available.
>
> Since there's no way to make dependencies between initcalls, we'll just
> have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> aware of any better solution at this time.
Do I understand it right, that with this change all UARTs, controlled by
legacy_serial will be initialized later, and that for example console
output will be first possible later? Maybe, if there is really no other
possibility for I/O space devices, we could have both calls
arch_initcall(serial_mem_dev_init);
device_initcall(serial_io_dev_init);
so, that at least MEMIO based UARTs could still initialize as before?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: 2.6.23-rc3 broken on G5
From: Paul Mackerras @ 2007-08-23 23:33 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <jetzqvk9of.fsf@sykes.suse.de>
Andreas Schwab writes:
> That didn't change anything visibly.
OK, please try this one and let me know if it fixes it.
Paul.
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index a73d2d7..1ca87eb 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -89,7 +89,7 @@ void slb_flush_and_rebolt(void)
vflags = SLB_VSID_KERNEL | vmalloc_llp;
ksp_esid_data = mk_esid_data(get_paca()->kstack, 2);
- if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET) {
+ if ((ksp_esid_data & ESID_MASK) <= PAGE_OFFSET) {
ksp_esid_data &= ~SLB_ESID_V;
slb_shadow_clear(2);
} else {
^ permalink raw reply related
* Re: [PATCH 1/2] [POWERPC] Remove cmd_line from head*.S
From: Milton Miller @ 2007-08-23 23:17 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1A23DF12-65EB-4236-B78A-ADF1DDF0FFFD@kernel.crashing.org>
On Thu Aug 23 13:27:31 EST 2007, Kumar Gala wrote:
> On Aug 22, 2007, at 10:09 PM, Stephen Rothwell wrote:
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 0028fe6..dc85005 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -60,6 +60,8 @@
>> #endif
>>
>>
>> +char cmd_line[COMMAND_LINE_SIZE];
>> +
>
> would this be better in setup-common.c?
>
I strongly agree with Kumar. It doesn't belong in prom.c
milton
^ permalink raw reply
* [PATCH 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
From: Jesper Juhl @ 2007-08-23 23:45 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: linuxppc-dev, Heiko J Schick, Joachim Fenkes, Paul Mackerras,
Jesper Juhl
In-Reply-To: <1554af80879a7ef2f78a4d654f23c248203500d9.1187912217.git.jesper.juhl@gmail.com>
kmalloc() returns a void pointer so there is absolutely no need to
cast it in ibmebus_chomp().
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
arch/powerpc/kernel/ibmebus.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9a8c9af..9514e66 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -383,7 +383,8 @@ static int ibmebus_match_path(struct device *dev, void *data)
static char *ibmebus_chomp(const char *in, size_t count)
{
- char *out = (char*)kmalloc(count + 1, GFP_KERNEL);
+ char *out = kmalloc(count + 1, GFP_KERNEL);
+
if (!out)
return NULL;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Olof Johansson @ 2007-08-23 23:15 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0708240117460.3246@poirot.grange>
On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 22 Aug 2007, Olof Johansson wrote:
>
> > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > initcall is now called before I/O space is setup, but it's dependent on
> > it being available.
> >
> > Since there's no way to make dependencies between initcalls, we'll just
> > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > aware of any better solution at this time.
>
> Do I understand it right, that with this change all UARTs, controlled by
> legacy_serial will be initialized later, and that for example console
> output will be first possible later?
Yes, unfortunately. Unless they've got a udbg driver, since that
would give console output during early boot anyway (even without using
EARLY_DEBUG).
> Maybe, if there is really no other
> possibility for I/O space devices, we could have both calls
>
> arch_initcall(serial_mem_dev_init);
> device_initcall(serial_io_dev_init);
>
> so, that at least MEMIO based UARTs could still initialize as before?
That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
on how to get the IO setup earlier instead.
-Olof
^ permalink raw reply
* Re: [PATCH 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
From: Joachim Fenkes @ 2007-08-24 0:37 UTC (permalink / raw)
To: Jesper Juhl
Cc: linuxppc-dev, Heiko J Schick, Paul Mackerras, Jesper Juhl,
Linux Kernel Mailing List
In-Reply-To: <91dcfc2a1b0be436d04f9bc45bb6f8657a8d6ff4.1187912217.git.jesper.juhl@gmail.com>
> kmalloc() returns a void pointer so there is absolutely no need to
> cast it in ibmebus_chomp().
>
> Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Acked-By: Joachim Fenkes <fenkes@de.ibm.com>
^ permalink raw reply
* Re: [PATCH 05/20] bootwrapper: flatdevtree fixes
From: David Gibson @ 2007-08-24 1:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <46CDC86E.2070907@freescale.com>
On Thu, Aug 23, 2007 at 12:48:30PM -0500, Scott Wood wrote:
> David Gibson wrote:
> > Actually, no - sorry, that's the other problem with this, which I
> > forgot to mention. On real OF, the "name" property contains the
> > node's name *without the unit address*; that is, only the portion
> > before the '@'. So your getprop change does not match real OF
> > behaviour - and real OF behaviour will not do what you want for
> > dt_get_path().
>
> Ah, OK.
>
> > Actually, in any case, I don't think we want to implement get_path()
> > this way for real OF. Better to have get_path() itself as a callback:
> > on real OF I believe we can directly ask for the full path to a given
> > phandle, the get name based implementation can then be made specific
> > to the flat device tree.
> >
> > Or actually, I think we might be able to come up with a get_path()
> > implementation for flat tree that's less hideous than repeatedly
> > calling get_parent() which is an ugly, ugly operation on the flat tree
>
> It's likely to be ugly no matter what, though I'll try to come up with
> something slightly nicer. If I were doing this code from scratch, I'd
> probably liven the tree first and reflatten it to pass to the kernel.
Eh, probably not worth bothering doing an actual implementation at
this stage - I'll have to redo it for libfdt anyway.
> > (and will get worse with libfdt).
>
> Why is that?
flatdevtree uses some of the information it caches in the phandle
context stuff to remember who's the parent of a node. libfdt uses raw
offsets into the structure, so the *only* way to implement
get_parent() is to rescan the dt from the beginning, keeping track of
parents until reaching the given node.
> >>Plus, something might come along that needs to dynamically look for
> >>either name or something else. It's more flexible this way.
> >
> > Hrm... "something might come along" just seems contrived to me.
>
> Well, I generally prefer doing things the more flexible way in the
> absence of a good reason not to. OF returning the bare name is a good
> reason not to.
--
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: [patch 1/2] powerpc: rmb fix
From: Nick Piggin @ 2007-08-24 2:47 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <7dc0bb83644f4cd44b4810a99d0003a1@kernel.crashing.org>
On Thu, Aug 23, 2007 at 07:57:20PM +0200, Segher Boessenkool wrote:
> >>The powerpc kernel needs to have full sync insns in every I/O
> >>accessor in order to enforce all the ordering rules Linux demands.
> >>It's a bloody shame, but the alternative would be to make the
> >>barriers lots more expensive. A third alternative would be to
> >
> >Well lots more expensive compared to what you have now. But what
> >you have now is like having those expensive barriers between
> >*every* io access.
>
> Yeah. But I/O reads are very expensive anyway, and the barriers
> are used for more than just I/O ordering.
rmb() should only be used when IO ordering matters. smp_rmb() is
for regular ordering.
So doesn't the fact IO reads are very expensive anyway lend more
weight _to have_ the full IO ordering in rmb()?
> I/O writes are a different thing; ideally, they would use only
> eieio, if anything at all.
For IO to IO ordering, yes eieio would be ideal. I don't know that
there is really such a primitive for that in Linux. io_wmb().
> Maybe the tradeoff isn't optimal. The I/O primitives didn't have
> all those "sync"s in there before, they got added because some bad
> interaction with spinlocks was discovered, if my memory isn't failing
> me.
I think it may have been because IO ops are pretty strongly ordered
on x86, and it was thought that a fair amount of code was relying on
that. So the old primitives were made quite strongly ordered, and
new ones were added to avoid the overhead. Unfortunately, you can't
actually use the unordered ones unless you have working barrier
instructions. Hence why I think rmb() should be an IO barrier.
But I'm not pushing this too hard. You guys all know the gory ppc
details better than I, so I'll just leave it with you to work out
whether it is the right thing to do.
> >>have barrier ops that do not order everything, but just A vs. B
> >>for various choices of A and B (coherent accesses, MMIO accesses,
> >>etc.)
> >
> >The non-smp_ variant is supposed to order everything, AFAIK. Maybe
> >you could get more fancy and have PIO vs MMIO etc etc. but it looks
> >like this whole area is in a pretty sticky state anyway so let's
> >not think about that.
>
> *Thinking* about it is fun. Trying to get the code merged would be
> a different thing ;-)
;)
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 2:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708230915000.30176@woody.linux-foundation.org>
On Thu, Aug 23, 2007 at 09:16:42AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > until the point of unlock.
>
> And that is exactly what ppc64 does.
>
> But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
> total no-op. So when you talk about "advantages", you're not talking about
> any *real* advantage, are you?
You're in a feisty mood today ;)
I guess on the 0.1% of hradware where it is not a noop, there might be a
real advantage... but that was just handwaving anyway. My real point was
that I'd like things to be more easily understandable.
I think we are agreed at this point that mmiowb without some form of CPU
synchronisation is a bug, and it is also not of the same type of barrier
that we normally think about in the kernel (it could be like a MPI style
rendezvous barrier between the CPU and the IO fabric). Anyway, point is
that device drivers seem to have enough on their plate already.
Look at bcm43xx, for example. Most of this guy's mmiowb()s are completely
wrong and should be wmb(). mmiowb() is only a wmb() on ppc because as I
said, ppc's spin_unlock does not order IOs like most other architectures.
On alpha, for example, spin_unlock does order IOs, so mmiowb is a noop,
and this is broken (non-sn2 ia64 should also be a noop here, because
their unlock orders IOs, but it seems that mmiowb semantics are so non
obvious that they either got it wrong themselves, or assumed device
drivers surely would).
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 3:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jesse Barnes, linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <1187886462.5972.17.camel@localhost.localdomain>
On Thu, Aug 23, 2007 at 06:27:42PM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 09:16 -0700, Linus Torvalds wrote:
> >
> > On Thu, 23 Aug 2007, Nick Piggin wrote:
> > >
> > > Also, FWIW, there are some advantages of deferring the mmiowb thingy
> > > until the point of unlock.
> >
> > And that is exactly what ppc64 does.
> >
> > But you're missing a big point: for 99.9% of all hardware, mmiowb() is a
> > total no-op. So when you talk about "advantages", you're not talking about
> > any *real* advantage, are you?
>
> I wonder whether it might be worth removing mmiowb and having all archs
> that matter do like ppc64 though... It's just yet another confusing
> barrier that most driver writers get wrong..
Only sn2 and powerpc really matter, actually (for different reasons).
All smp architectures other than powerpc appear to have barrier
instructions that order all memory operations, so IOs never leak
out of locking primitives. This is why powerpc wants a wmb (not
mmiowb) before spin_unlock to order IOs (pity about other locking
primitives).
And all platforms other than sn2 don't appear to reorder IOs after
they leave the CPU, so only sn2 needs to do the mmiowb thing before
spin_unlock.
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-24 3:12 UTC (permalink / raw)
To: Jesse Barnes; +Cc: linux-ia64, Linus Torvalds, linuxppc-dev
In-Reply-To: <200708230956.17049.jesse.barnes@intel.com>
On Thu, Aug 23, 2007 at 09:56:16AM -0700, Jesse Barnes wrote:
> On Thursday, August 23, 2007 12:27 am Benjamin Herrenschmidt wrote:
> > > Of course, the normal memory barrier would usually be a
> > > "spin_unlock()" or something like that, not a "wmb()". In fact, I
> > > don't think the powerpc implementation (as an example of this) will
> > > actually synchronize with anything *but* a spin_unlock().
> >
> > We are even more sneaky in the sense that we set a per-cpu flag on
> > any MMIO write and do the sync automatically in spin_unlock() :-)
>
> Yeah, that's a reasonable thing to do, and in fact I think there's code
> to do something similar when a task is switched out (this keeps user
> level drivers from having do mmiowb() type things).
It might be worth doing that and removing mmiowb completely. Or, if
that's too expensive, I'd like to see an API that is more explicitly
for keeping IOs inside critical sections.
> FWIW, I think I had an earlier version of the patch that used the name
> pioflush() or something similar, the only confusing thing about that
> name is that the primitive doesn't actually force I/Os down to the
> device level, just to the closest bridge.
Yeah, that's what I found when trying to think of a name ;) It is
like an intermediate-level flush for the platform code, but from the
POV of the driver writer, it is nothing of the sort ;)
^ permalink raw reply
* Problems on porting linux 2.6 to xilinx ML410
From: woyuzhilei @ 2007-08-24 3:11 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]
Hey:
Recently I'm doing some project on Xilinx Ml410 evaluation board.The first step is porting linux 2.6 to ml410,but I got some problems on this,and my project cann't proceed,so I come to you for some help.
I use the linux kernel source tree download from http://git.secretlab.ca/git/linux-2.6-virtex.git (The latest one).Add the file the xparameters.h,xparameter_ml40x.h. Then add arch/ppc/platforms/4xx/xilinx_generic_ppc.c(Use the patch I get here),and change it's name to ml40x.c,then I make some necessay change of the configuration files to accept selecting a Ml40x type board.Then compile the kernel,and get the image file from arch/ppc/boot/images, (On kernel compiling,the only device driver I sellect is " 8250/16550 and compatible serial support ").After that I download the zImage.elf file to the target board,and run it.But there is no output from the serial port at all.Am I doing somthing wrong?I really don't know goes wrong.
Can anyone here help me with this?Any help from you is appreciated.Thank you very much!
woyuzhilei
2007-08-24
[-- Attachment #2: Type: text/html, Size: 3952 bytes --]
^ permalink raw reply
* Re: [PATCH v2] [02/10] pasemi_mac: Stop using the pci config space accessors for register read/writes
From: Stephen Rothwell @ 2007-08-24 4:05 UTC (permalink / raw)
To: Olof Johansson; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20070823181310.GB31882@lixom.net>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
On Thu, 23 Aug 2007 13:13:10 -0500 Olof Johansson <olof@lixom.net> wrote:
>
> out:
> - pci_dev_put(mac->iob_pdev);
> -out_put_dma_pdev:
> - pci_dev_put(mac->dma_pdev);
> -out_free_netdev:
> + if (mac->iob_pdev)
> + pci_dev_put(mac->iob_pdev);
> + if (mac->dma_pdev)
> + pci_dev_put(mac->dma_pdev);
It is not documented as such (as far as I can see), but pci_dev_put is
safe to call with NULL. And there are other places in the kernel that
explicitly use that fact.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Benjamin Herrenschmidt @ 2007-08-24 4:59 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <20070823231510.GA5619@lixom.net>
On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
> On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> > On Wed, 22 Aug 2007, Olof Johansson wrote:
> >
> > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > > initcall is now called before I/O space is setup, but it's dependent on
> > > it being available.
> > >
> > > Since there's no way to make dependencies between initcalls, we'll just
> > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > > aware of any better solution at this time.
> >
> > Do I understand it right, that with this change all UARTs, controlled by
> > legacy_serial will be initialized later, and that for example console
> > output will be first possible later?
>
> Yes, unfortunately. Unless they've got a udbg driver, since that
> would give console output during early boot anyway (even without using
> EARLY_DEBUG).
Legacy ports should get udbg first.
> > Maybe, if there is really no other
> > possibility for I/O space devices, we could have both calls
> >
> > arch_initcall(serial_mem_dev_init);
> > device_initcall(serial_io_dev_init);
> >
> > so, that at least MEMIO based UARTs could still initialize as before?
>
> That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
> on how to get the IO setup earlier instead.
IO space allocation now relies on get_vm_area() which can't be done too
early (not in setup_arch) which is why I allocate all PCI IO space at
PHB scanning time, which is a subsys initcall.
An option would be to do it from some other init call, but that's a bit
ugly. That means PCI would be split into setup_arch() setting up PHBs,
that initcall allocating the IO spaces, and later, the actual scan.
It would be tricky though as my current interface relies on pci_bus
structures. So you would also need to re-split that into a low-level
that works on the PHB and a high level version that works on the bus.
Is this really necessary ?
Ben.
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Olof Johansson @ 2007-08-24 4:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <1187931578.5972.25.camel@localhost.localdomain>
On Fri, Aug 24, 2007 at 06:59:38AM +0200, Benjamin Herrenschmidt wrote:
> On Thu, 2007-08-23 at 18:15 -0500, Olof Johansson wrote:
> > On Fri, Aug 24, 2007 at 01:21:57AM +0200, Guennadi Liakhovetski wrote:
> > > On Wed, 22 Aug 2007, Olof Johansson wrote:
> > >
> > > > With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> > > > initcall is now called before I/O space is setup, but it's dependent on
> > > > it being available.
> > > >
> > > > Since there's no way to make dependencies between initcalls, we'll just
> > > > have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> > > > aware of any better solution at this time.
> > >
> > > Do I understand it right, that with this change all UARTs, controlled by
> > > legacy_serial will be initialized later, and that for example console
> > > output will be first possible later?
> >
> > Yes, unfortunately. Unless they've got a udbg driver, since that
> > would give console output during early boot anyway (even without using
> > EARLY_DEBUG).
>
> Legacy ports should get udbg first.
>
> > > Maybe, if there is really no other
> > > possibility for I/O space devices, we could have both calls
> > >
> > > arch_initcall(serial_mem_dev_init);
> > > device_initcall(serial_io_dev_init);
> > >
> > > so, that at least MEMIO based UARTs could still initialize as before?
> >
> > That's quite a hack, I hope we can avoid it. Maybe Ben has some suggestion
> > on how to get the IO setup earlier instead.
>
> IO space allocation now relies on get_vm_area() which can't be done too
> early (not in setup_arch) which is why I allocate all PCI IO space at
> PHB scanning time, which is a subsys initcall.
>
> An option would be to do it from some other init call, but that's a bit
> ugly. That means PCI would be split into setup_arch() setting up PHBs,
> that initcall allocating the IO spaces, and later, the actual scan.
>
> It would be tricky though as my current interface relies on pci_bus
> structures. So you would also need to re-split that into a low-level
> that works on the PHB and a high level version that works on the bus.
>
> Is this really necessary ?
No, that's what I'm hoping won't be, i.e. that it'll be fine to just
init serial ports slightly later. If people care about early output they
should use udbg anyway.
It'd be useful if people could at least test the patch on their systems.
I have only a few 32-bit ones with proper uarts, and none of them are
currently in a state where I can just throw a new kernel on them for
testing. :(
-Olof
^ permalink raw reply
* [PATCH] Remove barriers from the SLB shadow buffer update
From: Michael Neuling @ 2007-08-24 6:58 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
After talking to an IBM POWER hypervisor design and development (PHYP)
guy, there seems to be no need for memory barriers when updating the SLB
shadow buffer provided we only update it from the current CPU, which we
do.
Also, these guys see no need in the future for these barriers.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Tested on PHYP and BML.
paulus: As you mentioned, this is 2.6.24 material.
arch/powerpc/kernel/entry_64.S | 8 ++++----
arch/powerpc/mm/slb.c | 6 ++----
2 files changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -385,15 +385,15 @@ BEGIN_FTR_SECTION
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
- /* Update the last bolted SLB */
+ /* Update the last bolted SLB. No write barriers are needed
+ * here, provided we only update the current CPU's SLB shadow
+ * buffer.
+ */
ld r9,PACA_SLBSHADOWPTR(r13)
li r12,0
std r12,SLBSHADOW_STACKESID(r9) /* Clear ESID */
- eieio
std r7,SLBSHADOW_STACKVSID(r9) /* Save VSID */
- eieio
std r0,SLBSHADOW_STACKESID(r9) /* Save ESID */
- eieio
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -59,14 +59,12 @@ static inline void slb_shadow_update(uns
{
/*
* Clear the ESID first so the entry is not valid while we are
- * updating it.
+ * updating it. No write barriers are needed here, provided
+ * we only update the current CPU's SLB shadow buffer.
*/
get_slb_shadow()->save_area[entry].esid = 0;
- smp_wmb();
get_slb_shadow()->save_area[entry].vsid = mk_vsid_data(ea, flags);
- smp_wmb();
get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, entry);
- smp_wmb();
}
static inline void slb_shadow_clear(unsigned long entry)
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-24 7:10 UTC (permalink / raw)
To: Brad Boyer; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <20070823185632.GA3571@cynthia.pants.nu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 904 bytes --]
On Thu, 23 Aug 2007, Brad Boyer wrote:
> Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
> so you should probably leave that alone as well. It probably doesn't need
> that header, but the change should really come from the 68k side of things.
Thanks, it's indeed not needed.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Kumar Gala @ 2007-08-24 7:24 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <Pine.LNX.4.62.0708240909370.19123@pademelon.sonytel.be>
On Aug 24, 2007, at 2:10 AM, Geert Uytterhoeven wrote:
> On Thu, 23 Aug 2007, Brad Boyer wrote:
>> Just as an extra note, the file drivers/macintosh/adb-iop.c is
>> m68k only,
>> so you should probably leave that alone as well. It probably
>> doesn't need
>> that header, but the change should really come from the 68k side
>> of things.
>
> Thanks, it's indeed not needed.
If its ok that the removal comes from my patchset that would be
great. I'm tired of re-spinning these patches at this point ;)
- k
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-24 7:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <9185AE94-7B04-4DC7-8B9D-C92D13AC6D6F@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1247 bytes --]
On Fri, 24 Aug 2007, Kumar Gala wrote:
> On Aug 24, 2007, at 2:10 AM, Geert Uytterhoeven wrote:
> > On Thu, 23 Aug 2007, Brad Boyer wrote:
> > > Just as an extra note, the file drivers/macintosh/adb-iop.c is m68k only,
> > > so you should probably leave that alone as well. It probably doesn't need
> > > that header, but the change should really come from the 68k side of
> > > things.
> >
> > Thanks, it's indeed not needed.
>
> If its ok that the removal comes from my patchset that would be great. I'm
> tired of re-spinning these patches at this point ;)
Sure, less work for me! ;-)
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* little endian page mapping on PQ3
From: Jose Almeida @ 2007-08-24 7:59 UTC (permalink / raw)
To: Linuxppc-embedded
Hi all,
Looking at PQ3 documentation, it looks like there is a way to select
on a page basis if we would like to map one particular page in BIG or
LITTLE endian.
This is a very nice feature when you need to exchange some data
between a PC and a PQ3 target.
I am wondering if someone have already tryed this PQ3 feature ?
I guess this would require some kind of hook in the kernel ...
Any clue ?
Thanks - Jose
^ permalink raw reply
* RE: little endian page mapping on PQ3
From: Joyeau Sylvain @ 2007-08-24 11:40 UTC (permalink / raw)
To: Jose Almeida, Linuxppc-embedded
Jose,
You are right, PQ3 supports endianess choice on a per page basis.=20
Without any hook in Linux, you can remap physical address range (but =
RAM), by calling __ioremap() with the "_PAGE_ENDIAN" bit set in the =
flags.
--
sj
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@ozlabs.or
> g=20
> [mailto:linuxppc-embedded-bounces+sylvain.joyeau=3Dthomson.net@o
> zlabs.org] On Behalf Of Jose Almeida
> Sent: vendredi 24 ao=FBt 2007 09:59
> To: Linuxppc-embedded@ozlabs.org
> Subject: little endian page mapping on PQ3
>=20
> Hi all,
>=20
> Looking at PQ3 documentation, it looks like there is a way to select
> on a page basis if we would like to map one particular page in BIG or
> LITTLE endian.
> This is a very nice feature when you need to exchange some data
> between a PC and a PQ3 target.
>=20
> I am wondering if someone have already tryed this PQ3 feature ?
> I guess this would require some kind of hook in the kernel ...
>=20
> Any clue ?
>=20
> Thanks - Jose
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: little endian page mapping on PQ3
From: Jose Almeida @ 2007-08-24 13:08 UTC (permalink / raw)
To: Joyeau Sylvain; +Cc: Linuxppc-embedded
In-Reply-To: <B00307ADBC68954AA8D6FB3AC8FD66F30141DE36@rennsmail05.eu.thmulti.com>
[-- Attachment #1: Type: text/html, Size: 3387 bytes --]
^ permalink raw reply
* Re: little endian page mapping on PQ3
From: Clemens Koller @ 2007-08-24 13:19 UTC (permalink / raw)
To: Jose Almeida; +Cc: Linuxppc-embedded
In-Reply-To: <46CE8FD5.2060609@sysgo.fr>
Hi, Jose!
Jose Almeida schrieb:
> Hi all,
>
> Looking at PQ3 documentation, it looks like there is a way to select
> on a page basis if we would like to map one particular page in BIG or
> LITTLE endian.
> This is a very nice feature when you need to exchange some data
> between a PC and a PQ3 target.
I would be interested, however cannot spend time right now to work
on that subject.
> I am wondering if someone have already tryed this PQ3 feature ?
> I guess this would require some kind of hook in the kernel ...
Just some random bits I found in the web:
http://developer.apple.com/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/PCI_BOOK.250.html
The Interesting part is:
"Thus, the address swizzle is completely transparent to software."
So, I would just try to setup some memory mapping and turn on little endian
mode to access that area... MMMV. Just a guess.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ 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