In message [EMAIL PROTECTED] you wrote:
This is why I've always had mixed feelings about merging device trees
into u-boot, rather than having them supplied by the wrapper.
On the other hand, we can now use the device tree to dynamically
configure U-Boot, thus allowing to run the
Josh Boyer writes:
I've not heard any objections. I'll be pushing my commit to my next
branch tomorrow morning.
I don't have any objections. I wonder if Sam Ravnborg responded to
Segher's patch to extend make help?
Paul.
___
Linuxppc-dev mailing
From: Christoph Hellwig [EMAIL PROTECTED]
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants
This fixes the handling of the preempt count when switching
interrupt stacks so that HW interrupt properly get the softirq
mask copied over from the previous stack.
It also initializes the softirq stack preempt_count to 0 instead
of SOFTIRQ_OFFSET, like x86, as __do_softirq() does the increment,
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
lockdep.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/net/iseries_veth.c |3 ++-
1
Lockdep found out that we can occasionally take the device-tree
lock for reading from softirq time (from rtas_token called
by the rtas real time clock code called by the NTP code),
while we take it occasionally for writing without masking
interrupts. The combination of those two can thus deadlock.
Currently, we initialize the current pointer in the PACA (which
is used by the current macro in the kernel) before calling
setup_system(). That means that early_setup() is called with
current still NULL which is -not- a good idea. It happens to
work so far but breaks with lockdep when early code
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly,
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Fri, 2008-04-04 at 15:42 +0900, Ishizaki Kou wrote:
As you pointed, spider I/O functions in Cell blades need 2 step
indirections by our patch. Shall I make another one for Cell blades
whose spider I/O functions need one step indirection?
On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
lockdep.
should probably go in ASAP
On Wed, 9 Apr 2008 16:22:17 +1000
Paul Mackerras [EMAIL PROTECTED] wrote:
Josh Boyer writes:
I've not heard any objections. I'll be pushing my commit to my next
branch tomorrow morning.
I don't have any objections. I wonder if Sam Ravnborg responded to
Segher's patch to extend make
On Wed, 09 Apr 2008 17:21:34 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK macro, causing problems with
lockdep.
Signed-off-by:
The architecture allows for Book-E style debug interrupts to either go
to critial interrupts of their own debug interrupt level. To allow for
a dynamic kernel to support machines of either type we want to be able to
compile in the interrupt handling code for both exception levels.
Towards this
On Wednesday 09 April 2008 14:16, Pandita, Vikram wrote:
What does QUICC stand for?
QUICC stands for QUad Integrated Communications Controller.
http://en.wikipedia.org/wiki/PowerQUICC
Am getting confused with SmartCard UICC. Is it anyway related?
They are not related.
--
Laurent Pinchart
On Tuesday 08 April 2008 14:16, Anton Vorontsov wrote:
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote:
[...]
I had a first go at hacking the FHCI driver to make it run on a CPM2
platform. Results so far are quite good. After getting rid of qe-specific
APIs as explained
What does QUICC stand for?
Am getting confused with SmartCard UICC. Is it anyway related?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Laurent
Pinchart
Sent: Wednesday, April 09, 2008 5:44 PM
To: [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org; [EMAIL
Scott Wood schrieb:
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote:
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during console_init() ...
Does your device tree have a /chosen node after u-boot is done with it?
Hi All,
This patch fixes a mixup in struct fs_platform_info. The struct has a field
dpram_offset which really is no offset but an io pointer to the dpram
(casted to u32).
It also has a field mem_offset which is used as the offset from the dpram
to the fcc RAM but then in turn filled into fcc.mem
Currently USB Host isn't functional on the MPC8315E boards, for two
reasons as described below.
MPC8315 Reference Manual says:
The USB DR unit must have the same clock ratio as the encryption core
unit, unless one of them has its clock disabled.
The encryption core also drives I2C clock, so it
This version fixes the clobbering of r12 by the call to
trace_hardirqs_off() that was pointed out by BenH.
Johannes, I'd appreciate your trying this version if/when
you get the chance.
Thanks Dale, this version seems to work. I'll stress it a bit more
later, but so far it has
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 83xx/85xx board specific defconfigs to individual directories under
arch/powerpc/configs.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
On Apr 9, 2008, at 10:26 AM, Grant Likely wrote:
On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala
[EMAIL PROTECTED] wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs
directory
Move the 83xx/85xx board
On Wed, Apr 9, 2008 at 9:18 AM, Kumar Gala [EMAIL PROTECTED] wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 83xx/85xx board specific defconfigs to individual directories under
I've not heard any objections. I'll be pushing my commit to my next
branch tomorrow morning.
I don't have any objections. I wonder if Sam Ravnborg responded to
Segher's patch to extend make help?
I haven't had a reply to that yet, from anyone. IIRC Sam send a
mail some time ago saying he
On Wed, Apr 09, 2008 at 10:27:04AM -0500, Kumar Gala wrote:
Scott is 8xx capable of having a generic defconfig such that we can
build a single kernel image that will run on the various boards?
It should be.
-Scott
___
Linuxppc-dev mailing list
On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
This patch fixes a mixup in struct fs_platform_info. The struct has a field
dpram_offset which really is no offset but an io pointer to the dpram
(casted to u32).
Right, I didn't want to touch that as the old-binding code should be
On Tue, Apr 8, 2008 at 10:51 PM, Segher Boessenkool
[EMAIL PROTECTED] wrote:
Let's flat out refuse any patch series that uses a non-documented
binding.
I would love this, it makes life easier, but let's make sure that the
documented binding is actually
fairly future proof, first, and not
On Wed, Apr 09, 2008 at 11:11:10AM -0500, Scott Wood wrote:
On Wed, Apr 09, 2008 at 03:06:10PM +0200, Sascha Hauer wrote:
This patch fixes a mixup in struct fs_platform_info. The struct has a field
dpram_offset which really is no offset but an io pointer to the dpram
(casted to u32).
Olof Johansson wrote:
These make for some really long variable names and lines. I know from
experience, since I've picked unneccessary long driver names in the past
myself. :)
How about just naming the new variables reserve_bootvar, etc? The name
of the struct they're in makes it obvious
Olof Johansson wrote:
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+unsigned long tmp;
+
+if (phyp_dump_info-phyp_dump_reserve_bootvar)
+return phyp_dump_info-phyp_dump_reserve_bootvar;
+
+/* divide by 20 to get 5% of value */
+tmp =
Sascha Hauer wrote:
Right, so it's probably not worth the effort. I stumbled on this while
porting my board to the new binding code. I was quite confused when
seeing this so I made this fix to understand what's going on here.
BTW have you tested the FCC driver with the new binding code?
Yes.
Hi Grant,
I have a question about your patch. It appears as if the cache setup code is in
a file that would be used only on Xilinx FPGA devices.
I understand that many people are using a bootloader that already sets up the
cache for the kernel, but I'm wondering if Xilinx boards are really a
Hi
I made my own backtrace function for printing
a trace from within a signal handler. Maybe it
can be useful for the kernel too? General
comments welcome.
Jocke
#include stdio.h
#include signal.h
#include execinfo.h
#include unistd.h
#define __USE_GNU
#include ucontext.h
/* This is the
On Wed, Apr 09, 2008 at 12:37:51PM -0500, Manish Ahuja wrote:
Olof Johansson wrote:
+static inline unsigned long phyp_dump_calculate_reserve_size(void)
+{
+ unsigned long tmp;
+
+ if (phyp_dump_info-phyp_dump_reserve_bootvar)
+ return
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Fix kernel oops due to machine check occuring in init_chipset_siimage() on
PPC
44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O
and
memory spaces are mapped beyond 4 GB; arch/ppc/
Hmmm,
You are possibly right.
Okay I can check and fix that.
-Manish
Olof Johansson wrote:
That's 512MB, isn't it?
My calculations in the example I gave in the last email were wrong.
In mentally did 10% instead of 5%. But the premise is same.
So assuming 5% of some memory is 400 MB, it
On Wed, Apr 09, 2008 at 01:43:51PM -0500, Manish Ahuja wrote:
Hmmm,
You are possibly right.
Okay I can check and fix that.
Well, fix the comments if you prefer, I just pointed out the
discreptancy.
-Olof
___
Linuxppc-dev mailing list
Andre Schwarz wrote:
- find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!
-
Scott Wood schrieb:
Andre Schwarz wrote:
- find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
!!
Andre Schwarz wrote:
Scott Wood schrieb:
Andre Schwarz wrote:
- find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
It looks like you have some memory corruption between here...
clocksource: timebase mult[3c1] shift[22] registered
On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio [EMAIL PROTECTED] wrote:
Hi Grant,
I have a question about your patch. It appears as if the cache setup code is
in a file that would be used only on Xilinx FPGA devices.
That is correct.
I understand that many people are using a bootloader
+ tmp = tmp ~0x1FFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fff - 32-bit -0x2000 -
64-bit -0x2000.
Please consider writing it with an L
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
ps3_gelic_net.c:1337: undefined
On Wed, 2008-04-09 at 10:36 +0200, Christoph Hellwig wrote:
On Wed, Apr 09, 2008 at 05:21:34PM +1000, Benjamin Herrenschmidt wrote:
The iSeries veth driver uses an on-stack struct completion that
it initializes using the COMPLETION_INITIALIZER instead of
COMPLETION_INITIALIZER_ONSTACK
global_dbcr0 needs to be a per cpu set of save areas instead of a single
global on all processors.
Also, we switch to using DBCR0_IDM to determine if the user space app is
being debugged as its a more consistent way. In the future we should
support features like hardware breakpoint and
Geoff Levand wrote:
The PS3 gelic network driver depends on the wake-on-lan support
provided by the PS3 sys manager driver. Add that dependency
to the GELIC_NET Kconfig option.
Prevents these build errors:
ps3_gelic_net.c:1277: undefined reference to `.ps3_sys_manager_get_wol'
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter [EMAIL PROTECTED]
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter [EMAIL PROTECTED]
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21 14:53:41.0 +
+++ b/arch/powerpc/sysdev/fsl_soc.c 2008-03-26 12:08:25.0
Hi,
On Thu, Apr 10, 2008 at 12:22:52AM +0200, Philippe De Muyter wrote:
Hello everybody,
Here is small patch allowing to use a m41t81 rtc chip on a FSL_SOC based
board.
Signed-off-by: Philippe De Muyter [EMAIL PROTECTED]
--- a/arch/powerpc/sysdev/fsl_soc.c 2008-03-21
On Wed, 2008-04-09 at 17:21 +1000, Benjamin Herrenschmidt wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on
On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by: Philippe De Muyter [EMAIL PROTECTED]
---
On Wed, Apr 09, 2008 at 05:51:40PM -0500, Kumar Gala wrote:
On Apr 9, 2008, at 5:12 PM, Philippe De Muyter wrote:
Hi everybody,
Previously, with the arch/ppc tree, mpc8540 boards could reboot.
Now with the arch/powerpc tree, they can not anymore.
Fix that.
Signed-off-by:
Hi Kumar,
On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala [EMAIL PROTECTED] wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs directory
Move the 83xx/85xx board specific defconfigs to individual
Kumar Gala writes:
[POWERPC] bootwrapper: Allow specifying of image physical offset
reworked to look at PHDR (needs linker script update patch). Still
open question on how best to do that (objdump, readelf, C program,
suggestions)
Just replied about that one.
[POWERPC] Remove
Segher Boessenkool writes:
+ tmp = tmp ~0x1FFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fff - 32-bit -0x2000 -
64-bit -0x2000.
Huh? It's not
Kumar Gala writes:
So now we can look at the vmlinux and determine the physical offset.
The question is how best to do that. Here are the options I see:
* readelf, grep and parse output
* objdump grep and parse output
* simple C program that read's the elf and reports back
Either
On Apr 9, 2008, at 7:31 PM, Stephen Rothwell wrote:
Hi Kumar,
On Wed, 9 Apr 2008 10:18:06 -0500 (CDT) Kumar Gala [EMAIL PROTECTED]
wrote:
Board specific defconfigs are useful, however with the ability to do
multi-board defconfigs they aren't needed in the top level configs
directory
+ tmp = tmp ~0x1FFF;
Note that this only works as you expect because the constant is
signed here -- the extra zeroes do not magically make it a 64-bit
number. So it goes 32-bit 0x1fff - 32-bit -0x2000 -
64-bit -0x2000.
Huh? It's not big enough to be negative
The powerpc kernel stacks need to be naturally aligned, as they
contain the thread info at the bottom, which is obtained by
clearing the low bits of the stack pointer.
However, when using 64K pages (the stack is smaller than a page),
we use kmalloc to allocate it, which doesn't provide that
Some architecture need to maintain a kmem cache for thread info
structures. (next patch adds that to powerpc to fix an alignment
problem).
There is no good arch callback to use to initialize that cache
that I can find, so this adds a new one and adds an empty macro
for when it's not implemented.
On Wed, Apr 9, 2008 at 10:24 PM, Stephen Rothwell [EMAIL PROTECTED] wrote:
On Wed, 9 Apr 2008 22:11:38 -0500 Kumar Gala [EMAIL PROTECTED] wrote:
Yeah the are mpc85xx_defconfig and mpc83xx_defconfig.
So should we add mpc83xx_defconfig to the kisskb builds and remove
mpc885_ads_defconfig
61 matches
Mail list logo
