Our _GLOBAL macro does a .align 2 so the alignment is fine for 32
bit, but on 64 bit it is possible for it to end up only 4 byte aligned.
I don't know if it matters, but it can't hurt to 8 byte align it.
It also means that when we build with --emit_relocs, none of our 64 bit
relocations are to
Hello Scott,
On Mon, 8 Oct 2007 17:48:47 -0500
Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
ok, will give it a try shortly.
patch looks good after a quick glance.
--
Sincerely, Vitaly
___
Linuxppc-dev mailing list
All,
Thanks for the review, will process all the comments and resend
updated patches soon.
Marian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Mon, 8 Oct 2007, Ranulf Doswell wrote:
On 08/10/2007, Geoff Levand [EMAIL PROTECTED] wrote:
How do we go about claiming one of these OS_AREA_DB_OWNER_ keys? I'd
very much like to use this functionality in my python-ps3 games library.
It sounds like you should be storing your info in
Roland Dreier [EMAIL PROTECTED] wrote on 03.10.2007 20:05:44:
Replace struct ibmebus_dev and struct ibmebus_driver with
struct of_device
and struct of_platform_driver, respectively. Match the external
ibmebus
interface and drivers using it.
Signed-off-by: Joachim Fenkes
Hi Olof,
On Monday 08 October 2007, Olof Johansson wrote:
+config KILAUEA
+ bool Kilauea
+ depends on 40x
+ default y
+ select 405EX
+ help
+ This option enables support for the AMCC PPC405EX evaluation board.
+
#config REDWOOD_5
# bool Redwood-5
# depends
On Mon, 8 Oct 2007, Geoff Levand wrote:
o Add a KERN_WARNING message when flash driver is not available.
--- a/arch/powerpc/platforms/ps3/os-area.c
+++ b/arch/powerpc/platforms/ps3/os-area.c
+static void update_flash_db(void)
+{
+ int result;
+ int file;
+ off_t offset;
+
On 09/10/2007, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Mon, 8 Oct 2007, Ranulf Doswell wrote:
However, in this case the only data required is a single identifier used
to
identify one PS3 from another, and in fact this single 64-bit token can
be
shared amongst many other
I have just seen a crash at shutdown with 2.6.23-rc9 on an RS/6000
powerpc box (POWER3, 64-bit). It crashed immediately after printing
Disabling non-boot CPUs, so I tried reverting 4047727e and that
fixed it. It's unfortunate that that commit added the
disable_nonboot_cpus for all architectures,
On Oct 8, 2007, at 11:00 PM, Grant Likely wrote:
On 10/8/07, Timur Tabi [EMAIL PROTECTED] wrote:
Looks like the problem is back:
BOOTCC arch/powerpc/boot/treeboot-walnut.o
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at
On Oct 8, 2007, at 5:25 PM, Grant Likely wrote:
From: Grant Likely [EMAIL PROTECTED]
There is no good reason for board platform code to mess with the
ROOT_DEV.
Remove it from all in-tree platforms except powermac
Signed-off-by: Grant Likely [EMAIL PROTECTED]
---
On 10/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote:
All,
Thanks for the review, will process all the comments and resend
updated patches soon.
Make sure you take a look at the 6 patches I posted yesterday. They
will probably go in before your changes and will cause conflicts.
Kumar,
On Tue, 9 Oct 2007, Timur Tabi wrote:
Kumar Gala wrote:
What's the actual compile line? Want to see the flags to assembler of
-Wa to the compiler.
How do I modify the makefiles to spit out that command line?
make V=1
With kind regards,
Geert Uytterhoeven
Software Architect
Sony
On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
Add function qe_clock_source() which takes a string containing the
name of a
QE clock source (as is typically found in device trees) and returns
the
matching enum qe_clock value.
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
This
On Oct 9, 2007, at 9:38 AM, Grant Likely wrote:
On 10/9/07, Marian Balakowicz [EMAIL PROTECTED] wrote:
All,
Thanks for the review, will process all the comments and resend
updated patches soon.
Make sure you take a look at the 6 patches I posted yesterday. They
will probably go in
Kumar Gala wrote:
On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
Add function qe_clock_source() which takes a string containing the
name of a
QE clock source (as is typically found in device trees) and returns the
matching enum qe_clock value.
Signed-off-by: Timur Tabi [EMAIL
David Gibson wrote:
Policy. Compiling everything means build bugs - like this one - can
be found by everybody, not just those building for the specific
obscure platform.
Is this a new policy? Modules in the kernel are not built unless you want
them. Even in arch/powerpc/platforms, only
On Oct 9, 2007, at 11:01 AM, Timur Tabi wrote:
Kumar Gala wrote:
On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
Add function qe_clock_source() which takes a string containing
the name of a
QE clock source (as is typically found in device trees) and
returns the
matching enum qe_clock
Kumar Gala wrote:
Ok, I went and looked at how rx-clock tx-clock are spec'd in
booting-without-of.txt
Why dont we fix this so we have a property that says BRG or CLK and
another that has ID = [1.16] for BRG and [1..24] for CLK.
Because sometimes you can use both BRGs and CLKs. Some
Kumar Gala wrote:
Ok, I went and looked at how rx-clock tx-clock are spec'd in
booting-without-of.txt
Why dont we fix this so we have a property that says BRG or CLK
and another that has ID = [1.16] for BRG and [1..24] for CLK.
Or we could keep it as it is, check the beginning of the
Scott Wood wrote:
Or we could just stop putting CLK information in the device tree. :-)
If we had a BRG/CLK manager, we probably could do that. But we don't have
something like that now.
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
Scott Wood wrote:
In the absence of a BRG, the driver should just not support changing the
baud rate -- it shouldn't fail to function.
Since I don't have hardware that can test external clocks, I can't guarantee
that any such code will work.
I'm sure there are a dozen things I could do to
Timur Tabi wrote:
Scott Wood wrote:
Or we could just stop putting CLK information in the device tree. :-)
If we had a BRG/CLK manager, we probably could do that. But we don't
have something like that now.
I didn't say stop putting BRG information in there -- just CLKs, which
are static
Timur Tabi wrote:
UART, for instance, can use a CLK signal, but I wrote the driver to only
support BRGs because there are plenty of them and it's a lot simpler. But
someone, for instance, could wire up his board to want to use external clocks
for some UARTs, and so he'd need to modify the
On Mon, Oct 08, 2007 at 06:07:24PM -0700, Geoff Levand wrote:
Subject: PS3: Add os-area database routines
Add support for a simple tagged database in the PS3 flash rom
os-area. The database allows the flash rom os-area to be shared
between a bootloader and installed operating systems. The
On Oct 9, 2007, at 11:48 AM, Timur Tabi wrote:
Scott Wood wrote:
In the absence of a BRG, the driver should just not support
changing the baud rate -- it shouldn't fail to function.
Since I don't have hardware that can test external clocks, I can't
guarantee that any such code will
Kumar Gala wrote:
rx-clock-type = brg or clk
rx-clock-id = 3
I don't see how this doesn't cover what you need in the device tree.
That just looks more complicated than what my patch proposes. Why have two
properties when one will suffice? I still need to have a look-up table that
will
On Oct 9, 2007, at 1:12 PM, Timur Tabi wrote:
Kumar Gala wrote:
rx-clock-type = brg or clk
rx-clock-id = 3
I don't see how this doesn't cover what you need in the device tree.
That just looks more complicated than what my patch proposes. Why
have two properties when one will suffice?
On Oct 9, 2007, at 1:52 PM, Josh Boyer wrote:
On Tue, 09 Oct 2007 11:06:05 -0500
Timur Tabi [EMAIL PROTECTED] wrote:
David Gibson wrote:
Policy. Compiling everything means build bugs - like this one - can
be found by everybody, not just those building for the specific
obscure platform.
Kumar Gala wrote:
Ok. I guess I'm not in favor of changing the device tree to address
this issue. I think it would be solved if dtc had #define support.
Not really. The #defines would then need to match the enum, and that's dual
maintenance. This method is better because you can use the
On Oct 9, 2007, at 2:18 PM, Timur Tabi wrote:
Kumar Gala wrote:
Ok. I guess I'm not in favor of changing the device tree to
address this issue. I think it would be solved if dtc had
#define support.
Not really. The #defines would then need to match the enum, and
that's dual
Linas Vepstas wrote:
I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
for whatever reason, a spinlock locked up. The bizarre thing
was that the rest of system locked up as well: an ssh terminal,
and also an hvc console.
Breaking into the debugger showed 4 cpus, 1 of which
On Tue, Oct 09, 2007 at 04:18:19PM -0500, Nathan Lynch wrote:
Linas Vepstas wrote:
I was futzing with linux-2.6.23-rc8-mm1 in a power6 lpar when,
for whatever reason, a spinlock locked up. The bizarre thing
was that the rest of system locked up as well: an ssh terminal,
and also an
Signed-off-by: Wolfgang Denk [EMAIL PROTECTED]
---
arch/powerpc/kernel/vdso.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 213fa31..2322ba5 100644
--- a/arch/powerpc/kernel/vdso.c
+++
On Tue, Oct 09, 2007 at 04:28:10PM -0500, Linas Vepstas wrote:
Perhaps I should IRC this ...
yeah. I guess I'd forgotten how funky things can get. So never mind ...
--linas
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Tue, Oct 09, 2007 at 04:27:06PM -0700, Linus Torvalds wrote:
On Wed, 10 Oct 2007, Thomas Gleixner wrote:
Wrapping it into a #ifdef CONFIG_X86 would be sufficient.
Well, the ppc oops seems to be a ppc bug regardless.
If CPU_HOTPLUG isn't defined, the thing does nothing. And if it
Don't allow cpu hotplug on systems lacking XICS interrupt controller,
since current platform code is hardcoded for it.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index
Please Let me know the Status
Misbah
Misbah khan wrote:
Timur Tabi-3 wrote:
Kumar, this is what I get when I compile your 2.6.24 branch for the 8610:
CC arch/powerpc/sysdev/fsl_soc.o
In file included from arch/powerpc/sysdev/fsl_soc.c:40:
include/asm/cpm2.h:14:21:
38 matches
Mail list logo
