* Re: [PATCH] PowerPC: Fix find_legacy_serial_ports on OPB.
From: Valentine Barshak @ 2007-10-11 18:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200710111750.41852.arnd@arndb.de>
Arnd Bergmann wrote:
> On Thursday 11 October 2007, Valentine Barshak wrote:
>> Currently find_legacy_serial_ports() can find no serial ports on the OPB.
>> Thus no legacy boot console can be initialized. Just the early udbg console
>> works, which is initialized with udbg_init_44x_as1() on the UART's physical
>> address specified in kernel config. This happens because we look for ns16750
>> and higher serial devices only and expect opb node to have a device type
>> property. This patch makes it look for ns16550 compatible devices and use
>> of_device_is_compatible() for opb instead of checking device type.
>> Lack of legacy serial ports found causes problems for KGDB over serial.
>>
>> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> The patch would make sense if we were only dealing with flattened device
> tree systems at this point. Unfortunately, IBM is shipping hardware that
> encodes the serial port in exactly the way that find_legacy_serial_ports
> is looking for (parent->type == "opb", compatible = "ns16750" "ns16550"
> "ns16450" i8250").
>
> Changing the search for ns16750 to ns16550 should be fine, but unnecessary
> because AFAIK, all OPB serial imlpementations are actually ns16750 and
> should have that in the device tree as well.
This is a bit odd. The docs say that uart chips on the ppc44x processors
are registry-compatible to 16750, but have 16-byte FIFO's.
This is OK for legacy serial stuff (since it really needs the chip to be
16550-compatible), but the 8250 driver expects 64-byte FIFO size for 16750.
I guess that's why 44x uart dts entries don't have 16750 compatible
property.
>
> For the device type of the bus, please check for both compatible and
> type, so that it still works on machines that are missing the compatible
> property.
>
> Arnd <><
^ permalink raw reply
* [PATCH] PowerPC: Add legacy serial support for OPB with flattened device tree.
From: Valentine Barshak @ 2007-10-11 19:09 UTC (permalink / raw)
To: linuxppc-dev; +Cc: arnd
In-Reply-To: <200710111909.39927.arnd@arndb.de>
Currently find_legacy_serial_ports() can find no serial ports on the OPB
with flattened device. Thus no legacy boot console can be initialized.
Just the early udbg console works, which is initialized with udbg_init_44x_as1
on the UART's physical address specified in kernel config. This happens
because we look for ns16750 serial devices only and expect opb node to have
a device type property. This patch makes it look for ns16550-compatible
devices and use of_device_is_compatible() for opb in case device type is not
specified.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/kernel/legacy_serial.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c linux-2.6/arch/powerpc/kernel/legacy_serial.c
--- linux-2.6.orig/arch/powerpc/kernel/legacy_serial.c 2007-10-11 17:12:09.000000000 +0400
+++ linux-2.6/arch/powerpc/kernel/legacy_serial.c 2007-10-11 23:01:25.000000000 +0400
@@ -340,9 +340,10 @@ void __init find_legacy_serial_ports(voi
}
/* First fill our array with opb bus ports */
- for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16750")) != NULL;) {
+ for (np = NULL; (np = of_find_compatible_node(np, "serial", "ns16550")) != NULL;) {
struct device_node *opb = of_get_parent(np);
- if (opb && !strcmp(opb->type, "opb")) {
+ if (opb && (!strcmp(opb->type, "opb") ||
+ of_device_is_compatible(opb, "ibm,opb"))) {
index = add_legacy_soc_port(np, np);
if (index >= 0 && np == stdout)
legacy_serial_console = index;
^ permalink raw reply
* Re: mpc860T linux2.6.23 boot problem
From: Scott Wood @ 2007-10-11 19:14 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <470E4DFF.2050800@scram.de>
Jochen Friedrich wrote:
> Hi keng_629,
>> i have ported linux2.6.23 to mpc860t board use cpm smc1 as serial port.
>> when i boot my kernel with ramdisk i find it stop after print"Loading
>> Ramdisk to 07e20000, end 07fa4100 ... OK"
> Could you try the patches from git://git.bocc.de/dbox2.git ppc-fixes i
> submitted recently?
> You might as well download the series (the patches starting with
> PATCH#2) from
> http://patchwork.ozlabs.org/linuxppc-embedded/list?person=1023
Or better yet, use paulus's git tree which has most of the above
patches, as well as several other patches relevant to 8xx. Note that
there are some device tree changes you'll need to make -- look at the
mpc885ads dts.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
From: Scott Wood @ 2007-10-11 19:55 UTC (permalink / raw)
To: Olof Johansson; +Cc: grundler, linux-kernel, kyle, linuxppc-dev, lethal, akpm
In-Reply-To: <20071011171413.GC10877@lixom.net>
On Thu, Oct 11, 2007 at 12:14:13PM -0500, Olof Johansson wrote:
> Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
> 4K text on a ppc64_defconfig. The main reason seems to be that prepping
> the arguments to the conditional trap instructions is more work than
> just doing a compare and branch.
It'd be nice if we could get GCC to generate bug table entries for
__builtin_trap(); that way we could use GCC's ability to put arbitrary
conditions in the trap instruction.
-Scott
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: Scott Wood @ 2007-10-11 20:02 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Timur Tabi, David Gibson
In-Reply-To: <18189.27251.48582.614106@cargo.ozlabs.ibm.com>
On Thu, Oct 11, 2007 at 10:12:35AM +1000, Paul Mackerras wrote:
> Timur Tabi writes:
>
> > Is this a new policy? Modules in the kernel are not built unless you want
> > them. Even in arch/powerpc/platforms, only the specific platform file I'm
> > targeting is built. So I don't really understand why you claim it's normal
> > for platform-specific files to be built, regardless of the actual platform.
>
> The wrapper script is intended to be a standalone tool which is
> independent of the kernel configuration, and can be used separately
> from the kernel build process.
Is it ever actually used that way? I wonder if this "intent" is worth the
pain...
-Scott
^ permalink raw reply
* Re: [PATCH 3/9 v2] add Freescale SerDes PHY support
From: Scott Wood @ 2007-10-11 20:09 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, paulus
In-Reply-To: <1192096425-30192-1-git-send-email-leoli@freescale.com>
On Thu, Oct 11, 2007 at 05:53:45PM +0800, Li Yang wrote:
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index 19d4628..e89f803 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -291,4 +291,8 @@ config FSL_ULI1575
> Freescale reference boards. The boards all use the ULI in pretty
> much the same way.
>
> +config FSL_SERDES
> + bool
> + default n
"default n" is the default -- no need to specify it explicitly.
> + /* Configure SRDSCR1 */
> + tmp = in_be32(regs + FSL_SRDSCR1_OFFS);
> + tmp &= ~FSL_SRDSCR1_PLLBW;
> + out_be32(regs + FSL_SRDSCR1_OFFS, tmp);
clrbits32?
> + /* Configure SRDSCR2 */
> + tmp = in_be32(regs + FSL_SRDSCR2_OFFS);
> + tmp &= ~FSL_SRDSCR2_SEIC_MASK;
> + tmp |= FSL_SRDSCR2_SEIC_SATA;
> + out_be32(regs + FSL_SRDSCR2_OFFS, tmp);
clrsetbits_be32?
-Scott
^ permalink raw reply
* Re: [PATCH 4/4 v2] [POWERPC] Kilauea defconfig file
From: Scott Wood @ 2007-10-11 20:12 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200710111531.13022.sr@denx.de>
On Thu, Oct 11, 2007 at 03:31:12PM +0200, Stefan Roese wrote:
> Yes, good catch. Since I'm not using the bootwrapper, I should be able to get
> rid of WANT_DEVICE_TREE too. But it seems to be autoselected in
> arch/powerpc/platforms/Kconfig.cputype for 40x and most other "embedded"
> CPU's. Any idea why this is the case?
Probably copying from 83xx, 85xx, etc, which set it on the entire CPU family
because there's a wrapper platform that covers the entire family. AFAICT,
there are only board wrappers for 4xx, so individual boards should be
selecting WANT_DEVICE_TREE.
In any case, you can just set DEVICE_TREE to an empty string if you only
want the regular uImage.
-Scott
^ permalink raw reply
* Re: Hard hang in hypervisor!?
From: Linas Vepstas @ 2007-10-11 20:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <18189.26776.326248.278431@cargo.ozlabs.ibm.com>
On Thu, Oct 11, 2007 at 10:04:40AM +1000, Paul Mackerras wrote:
> Linas Vepstas writes:
>
> > Err .. it was cpu 0 that was spinlocked. Are interrupts not
> > distributed?
>
> We have some bogosities in the xics code that I noticed a couple of
> days ago. Basically we only set the xics to distribute interrupts to
> all cpus if (a) the affinity mask is equal to CPU_MASK_ALL (which has
> ones in every bit position from 0 to NR_CPUS-1) and (b) all present
> cpus are online (cpu_online_map == cpu_present_map). Otherwise we
> direct interrupts to the first cpu in the affinity map. So you can
> easily have the affinity mask containing all the online cpus and still
> not get distributed interrupts.
>
> So in your case it's quite possible that all interrupts were directed
> to cpu 0.
Thanks,
I'll give this a whirl if I don't get distracted by other tasks.
A simple cat /proc/interrupts shows them evenly distributed on
my "usual" box, and all glommed up on cpu 0 on the one thats
giving me fits.
Also, I noticed years ago that "BAD" was non-zero and large.
Vowed to look into it someday ...
--linas
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Benjamin Herrenschmidt @ 2007-10-11 20:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <91E54A0A-EFD6-46C8-A703-7892731FA3F8@kernel.crashing.org>
On Thu, 2007-10-11 at 07:52 -0500, Kumar Gala wrote:
> > Benjamin Herrenschmidt (3):
> > [POWERPC] Fix platinumfb framebuffer
> > [POWERPC] cell: Move cbe_regs.h to include/asm-powerpc/cell-
> > regs.h
> > [POWERPC] cell: Add Cell memory controller register defs and
> > expose it
>
> Ben, your slacking :)
?
Ben.
^ permalink raw reply
* Re: [PATCH] Make clockevents work on PPC601 processors
From: Benjamin Herrenschmidt @ 2007-10-11 20:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <96C1AFB8-784F-445E-A3F2-5D68494541CD@kernel.crashing.org>
On Thu, 2007-10-11 at 09:12 -0500, Kumar Gala wrote:
> On Oct 11, 2007, at 6:46 AM, Paul Mackerras wrote:
>
> > In testing the new clocksource and clockevent code on a PPC601
> > processor, I discovered that the clockevent multiplier value for the
> > decrementer clockevent was overflowing. Because the RTCL register in
> > the 601 effectively counts at 1GHz (it doesn't actually, but it
> > increases by 128 every 128ns), and the shift value was 32, that meant
> > the multiplier value had to be 2^32, which won't fit in an unsigned
> > long on 32-bit. The same problem would arise on any platform where
> > the timebase frequency was 1GHz or more (not that we actually have any
> > such machines today).
>
> do you still have a 601 running somewhere?
On my desk :-) (and he also has a 601 card for the 7500 iirc)
/me remembers to revive his dual 604 8500 one of these days.
Ben.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Kumar Gala @ 2007-10-11 21:06 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <1192136106.8476.56.camel@pasglop>
On Oct 11, 2007, at 3:55 PM, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-10-11 at 07:52 -0500, Kumar Gala wrote:
>>> Benjamin Herrenschmidt (3):
>>> [POWERPC] Fix platinumfb framebuffer
>>> [POWERPC] cell: Move cbe_regs.h to include/asm-powerpc/cell-
>>> regs.h
>>> [POWERPC] cell: Add Cell memory controller register defs and
>>> expose it
>>
>> Ben, your slacking :)
>
> ?
Just three patches for 2.6.24... :)
- k
^ permalink raw reply
* Re: [PATCH] PowerPC: Add legacy serial support for OPB with flattened device tree.
From: Arnd Bergmann @ 2007-10-11 21:10 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071011190925.GA22704@ru.mvista.com>
On Thursday 11 October 2007, Valentine Barshak wrote:
> Currently find_legacy_serial_ports() can find no serial ports on the OPB
> with flattened device. Thus no legacy boot console can be initialized.
> Just the early udbg console works, which is initialized with udbg_init_44x_as1
> on the UART's physical address specified in kernel config. This happens
> because we look for ns16750 serial devices only and expect opb node to have
> a device type property. This patch makes it look for ns16550-compatible
> devices and use of_device_is_compatible() for opb in case device type is not
> specified.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Looks correct for QS21 now.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH 4/4 v2] [POWERPC] Kilauea defconfig file
From: Josh Boyer @ 2007-10-11 21:13 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20071011201232.GD4247@loki.buserror.net>
On Thu, 2007-10-11 at 15:12 -0500, Scott Wood wrote:
> On Thu, Oct 11, 2007 at 03:31:12PM +0200, Stefan Roese wrote:
> > Yes, good catch. Since I'm not using the bootwrapper, I should be able to get
> > rid of WANT_DEVICE_TREE too. But it seems to be autoselected in
> > arch/powerpc/platforms/Kconfig.cputype for 40x and most other "embedded"
> > CPU's. Any idea why this is the case?
>
> Probably copying from 83xx, 85xx, etc, which set it on the entire CPU family
> because there's a wrapper platform that covers the entire family. AFAICT,
> there are only board wrappers for 4xx, so individual boards should be
> selecting WANT_DEVICE_TREE.
Probably. Seems somewhat redundant at this point to move it into the
individual board options though.
> In any case, you can just set DEVICE_TREE to an empty string if you only
> want the regular uImage.
Well, he wants the raw uImage, and a separate DTB to be spit out as far
as I can tell. So we don't want an empty string here, but what's there
currently doesn't do the latter part either.
josh
^ permalink raw reply
* Re: Hard hang in hypervisor!?
From: Milton Miller @ 2007-10-11 21:35 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18189.26776.326248.278431@cargo.ozlabs.ibm.com>
On Thu Oct 11 10:04:40 EST 2007, Paul Mackerras wrote:
> Linas Vepstas writes:
>> Err .. it was cpu 0 that was spinlocked. Are interrupts not
>> distributed?
>
> We have some bogosities in the xics code that I noticed a couple of
> days ago. Basically we only set the xics to distribute interrupts to
> all cpus if (a) the affinity mask is equal to CPU_MASK_ALL (which has
> ones in every bit position from 0 to NR_CPUS-1) and (b) all present
> cpus are online (cpu_online_map == cpu_present_map). Otherwise we
> direct interrupts to the first cpu in the affinity map. So you can
> easily have the affinity mask containing all the online cpus and still
> not get distributed interrupts.
The second condition was just added to try fix some issues where a
vendor wants to always run the kdump kernel with maxcpus=1 on all
architectures, and the emulated xics on js20 was not working.
For a true xics, this should work because we (1) remove all but 1
cpu from the global server list and (2) raise the prioirity of the
cpu to disabled and the hardware will deliver to another cpu in the
parition.
http://ozlabs.org/pipermail/linuxppc-dev/2006-December/028941.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-January/029607.html
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/032621.html
However, my experience the other day on a js21 was that firmware
delivered either to all cpus (if we bound to the global server) or
the first online cpu in the partition, regardless of to which cpu
we bound the interrupt, so I don't know that the change will fix
the original problem.
It does mean that taking a cpu offline but not dlpar removing it from the
kernel will result in the inability to actually distribute interrupts
to all cpus.
I'd be happy to say remove the extra check and work with firmware to
property distribute the interrupts.
milton
^ permalink raw reply
* Re: [PATCH v2] powerpc: don't enable cpu hotplug on mpic-based pseries
From: Milton Miller @ 2007-10-11 21:42 UTC (permalink / raw)
Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <18189.47620.466515.645055@cargo.ozlabs.ibm.com>
Paul Mackerras writes:
> Olof Johansson writes:
>> Don't allow cpu hotplug on systems lacking XICS interrupt controller,
>> since current code is hardcoded for it.
> ...
>> + for (np = NULL; (np = of_find_node_by_name(np,
>> + "interrupt-controller"));) {
>
> Looks like for_each_node_by_name would be nicer here.
>
> If you agree, I'll hand-edit your patch to do that and apply it. Of
> course, ultimately we should implement the necessary mpic bits to
> support cpu hotplug.
>
While you are editing, can you please change the condition to finding
ppc-xicp instead of not finding open-pic?
thanks.
milton
^ permalink raw reply
* Re: [PATCH v4 or so] Use 1TB segments
From: Paul Mackerras @ 2007-10-11 21:52 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <20071011163358.GA4258@austin.ibm.com>
Linas Vepstas writes:
> Gack. A system dump might take a while on these machines ...
Why? Using 1TB segments doesn't mean they have 1TB of RAM ...
Paul.
^ permalink raw reply
* [RFC] Fixup stfiwx decode bug
From: Kumar Gala @ 2007-10-11 21:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Paul,
Can you look over this fix and see if you have any style issues with it.
Its legal for stfiwx to have RA = 0, however we treated it as illegal
since it was in class "XE".
- k
diff --git a/arch/powerpc/math-emu/math.c b/arch/powerpc/math-emu/math.c
index 69058b2..381306b 100644
--- a/arch/powerpc/math-emu/math.c
+++ b/arch/powerpc/math-emu/math.c
@@ -407,11 +407,16 @@ do_mathemu(struct pt_regs *regs)
case XE:
idx = (insn >> 16) & 0x1f;
- if (!idx)
- goto illegal;
-
op0 = (void *)¤t->thread.fpr[(insn >> 21) & 0x1f];
- op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ if (!idx) {
+ if (((insn >> 1) & 0x3ff) == STFIWX)
+ op1 = (void *)(regs->gpr[(insn >> 11) & 0x1f]);
+ else
+ goto illegal;
+ } else {
+ op1 = (void *)(regs->gpr[idx] + regs->gpr[(insn >> 11) & 0x1f]);
+ }
+
break;
case XEU:
^ permalink raw reply related
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Paul Mackerras @ 2007-10-11 21:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <DFC6881D-E917-4EC5-B19C-8CE04E040B06@kernel.crashing.org>
Kumar Gala writes:
> > #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
> > there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
> to the x86 specific name?
How is "extended floating point registers" x86-specific?
ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
conjunction with a function called elf_core_copy_task_xfpregs().
Paul.
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Kumar Gala @ 2007-10-11 22:01 UTC (permalink / raw)
To: Paul Mackerras; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <18190.39864.4562.852292@cargo.ozlabs.ibm.com>
On Oct 11, 2007, at 4:55 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>>> #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current
>>> users so
>>> there's are no change in behaviour.
>>
>> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
>> to the x86 specific name?
>
> How is "extended floating point registers" x86-specific?
we'll I don't consider the altivec register file as 'extended fp'.
I'm assuming the name XFP came from IA32 land when MMX/SSE came into
existence.
> ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
> conjunction with a function called elf_core_copy_task_xfpregs().
agreed, I think the function name should change as well.
- k
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Josh Boyer @ 2007-10-11 22:07 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1192106826.5534.114.camel@localhost.localdomain>
On Thu, 2007-10-11 at 07:47 -0500, Josh Boyer wrote:
> On Thu, 2007-10-11 at 22:30 +1000, Paul Mackerras wrote:
> > Below is the list of commits that I plan to ask Linus to pull
> > tomorrow. This is the last call for anything else or for objections
> > to any of these commits going in. These commits are in powerpc.git on
> > the master and for-2.6.24 branches.
>
> Hi Paul,
>
> Could you pull from:
>
> master.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.24
>
> to pick up some Xilinx changes from Grant? I'm also hoping to get
> Stefan's 405EX changes in soon.
I added Stefan's latest patch set to my tree as well. They look good.
josh
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Paul Mackerras @ 2007-10-11 22:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <2C31F1C3-3337-483B-A463-767459305F1E@kernel.crashing.org>
Kumar Gala writes:
> > ELF_CORE_XFPREG_TYPE is a suitable name for something that's used in
> > conjunction with a function called elf_core_copy_task_xfpregs().
>
> agreed, I think the function name should change as well.
Maybe. Let's do one step at a time...
Paul.
^ permalink raw reply
* Re: [PATCH] Make clockevents work on PPC601 processors
From: Paul Mackerras @ 2007-10-11 22:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <96C1AFB8-784F-445E-A3F2-5D68494541CD@kernel.crashing.org>
Kumar Gala writes:
> do you still have a 601 running somewhere?
Yes, I still have the original 601 cpu card for my PowerMac 7500. :)
Paul.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Paul Mackerras @ 2007-10-11 22:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3A203D25-2CC1-4450-ADA1-752A99504108@kernel.crashing.org>
Kumar Gala writes:
> I'm debugging one issue with MPC8560 that should get fixed today with
> a new pull request after I find the issue.
There's no particular hurry for bug fixes.
> Just to clarify, are we closing 2.6.24 for new code after you send
> Linus a pull request or are we still taking things during the two
> week merge window?
Basically, yes. We got a lecture at kernel summit from Linus and
Andrew where we got told to get everything merged early in the merge
window. I might make an exception for stuff that has already been
posted for review but still needs some minor changes, but other than
that, the window for new code has closed.
Paul.
^ permalink raw reply
* Re: powerpc commits for 2.6.24
From: Kumar Gala @ 2007-10-11 22:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18190.42074.495464.74585@cargo.ozlabs.ibm.com>
On Oct 11, 2007, at 5:31 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> I'm debugging one issue with MPC8560 that should get fixed today with
>> a new pull request after I find the issue.
>
> There's no particular hurry for bug fixes.
Already dealt with, mainly I was being stupid.
>> Just to clarify, are we closing 2.6.24 for new code after you send
>> Linus a pull request or are we still taking things during the two
>> week merge window?
>
> Basically, yes. We got a lecture at kernel summit from Linus and
> Andrew where we got told to get everything merged early in the merge
> window. I might make an exception for stuff that has already been
> posted for review but still needs some minor changes, but other than
> that, the window for new code has closed.
I was wondering about this case. I'll follow your lead here.
- k
^ permalink raw reply
* Re: [patch 1/2] Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE #define
From: Michael Ellerman @ 2007-10-11 23:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Linux Kernel Mailing List
In-Reply-To: <DFC6881D-E917-4EC5-B19C-8CE04E040B06@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 3498 bytes --]
On Thu, 2007-10-11 at 08:04 -0500, Kumar Gala wrote:
> On Oct 11, 2007, at 2:15 AM, markn@au1.ibm.com wrote:
>
> > Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump code
> > which
> > allows for more flexibility in the note type for the state of
> > 'extended
> > floating point' implementations in coredumps. New note types can
> > now be
> > added with an appropriate #define.
> >
> > #define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
> > there's are no change in behaviour.
>
> Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled
> to the x86 specific name?
>
> >
> > Signed-off-by: Mark Nelson <markn@au1.ibm.com>
> > ---
> > arch/ia64/ia32/elfcore32.h | 1 +
> > arch/x86_64/ia32/ia32_binfmt.c | 1 +
> > fs/binfmt_elf.c | 4 ++--
> > include/asm-i386/elf.h | 1 +
> > 4 files changed, 5 insertions(+), 2 deletions(-)
> >
> > Index: linux/arch/ia64/ia32/elfcore32.h
> > ===================================================================
> > --- linux.orig/arch/ia64/ia32/elfcore32.h
> > +++ linux/arch/ia64/ia32/elfcore32.h
> > @@ -117,6 +117,7 @@ elf_core_copy_task_fpregs(struct task_st
> > }
> >
> > #define ELF_CORE_COPY_XFPREGS 1
> > +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> > static inline int
> > elf_core_copy_task_xfpregs(struct task_struct *tsk,
> > elf_fpxregset_t *xfpu)
> > {
> > Index: linux/arch/x86_64/ia32/ia32_binfmt.c
> > ===================================================================
> > --- linux.orig/arch/x86_64/ia32/ia32_binfmt.c
> > +++ linux/arch/x86_64/ia32/ia32_binfmt.c
> > @@ -188,6 +188,7 @@ elf_core_copy_task_fpregs(struct task_st
> > }
> >
> > #define ELF_CORE_COPY_XFPREGS 1
> > +#define ELF_CORE_XFPREG_TYPE NT_PRXFPREG
> > static inline int
> > elf_core_copy_task_xfpregs(struct task_struct *t, elf_fpxregset_t
> > *xfpu)
> > {
> > Index: linux/fs/binfmt_elf.c
> > ===================================================================
> > --- linux.orig/fs/binfmt_elf.c
> > +++ linux/fs/binfmt_elf.c
> > @@ -1446,8 +1446,8 @@ static int elf_dump_thread_status(long s
> >
> > #ifdef ELF_CORE_COPY_XFPREGS
> > if (elf_core_copy_task_xfpregs(p, &t->xfpu)) {
> > - fill_note(&t->notes[2], "LINUX", NT_PRXFPREG, sizeof(t->xfpu),
> > - &t->xfpu);
> > + fill_note(&t->notes[2], "LINUX", ELF_CORE_XFPREG_TYPE,
> > + sizeof(t->xfpu), &t->xfpu);
> > t->num_notes++;
> > sz += notesize(&t->notes[2]);
> > }
>
> You've only fixed up one of 4 NT_PRXFPREG uses in the kernel.
>
> Also, I'm not a fan of your proposed mechanism to "overload" the
> elf_fpxregset_t. I'd rather see us introduce a new elf_vecregset_t
> and have it typedef'd to be elf_fpxregset_t on i386, x86_64, ia64
He's not overloading it, there is no such thing as an elf_fpxregset_t,
unless it's typedef'd to something else by the arch code, eg:
include/asm-i386/elf.h:typedef struct user_fxsr_struct elf_fpxregset_t;
include/asm-ia64/elf.h:typedef unsigned long elf_fpxregset_t;
Introducing another typedef would just be another layer of obfuscation
IMO, and the elf code doesn't need any more of that.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox