Andrew Morton wrote:
> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Hi Andrew,
>>
>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>
>> [0.00] [ cut here ]
>> [0.00] kernel BUG at arch/powerpc
On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi Andrew,
> >>
> >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>
> >> [0.00]
[Not to merge just yet ... almost]
This serie of patches adds lockdep support for 64 bits
powerpc. Dale's patch for 32 bits still need me to review
and test it which I'll try to do asap.
It needs the iSeries hardirq enable fix that I posted
earlier (which is probably 2.6.25 material).
Note that
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 c
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,
a
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,
> This serie of patches adds lockdep support for 64 bits
> powerpc. Dale's patch for 32 bits still need me to review
> and test it which I'll try to do asap.
Yay. I'll give it another try later today.
Thanks,
johannes
signature.asc
Description: This is a digitally signed message part
_
On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > > As you said, if read/write/in/out functions take device parameter,
> > > taking I/O function pointers into the dev_archdata structure should be
> > > the best solution. But they don't t
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> > As you said, if read/write/in/out functions take device parameter,
> > taking I/O function pointers into the dev_archdata structure should be
> > the best solution. But they don't take device parameter, and they must
> > search I/O function poin
On Wed, 2008-04-02 at 11:50 +0200, Johannes Berg wrote:
> > This serie of patches adds lockdep support for 64 bits
> > powerpc. Dale's patch for 32 bits still need me to review
> > and test it which I'll try to do asap.
>
> Yay. I'll give it another try later today.
Haven't tested this version o
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Jens Osterkamp wrote:
> >
> > Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5.
>
> Do you know which commit caused the change?
Yes, we bisected it to the following commit :
commit 5a622f2d0f86b316b07b55a4866ecb5518dd1cf7
Auth
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Nathan Lynch wrote:
> >
> > One could argue that the real problem is using the proc_dir_entry's
> > reference count to enforce exclusive open.
>
>
> I think this is better... the way these files are used is lame, but
> this should preserve the exis
Kumar Gala writes:
> Paul, any comments on sending this onto linus. I was hoping to avoid
> 2.6.25 coming up not support the proper device bindings for DMA and
> SATA.
I've pulled it and I'll send it on later (or Linus can pull it
directly if he wants). There is the iSeries fix from Ben H p
Nathan Lynch writes:
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
Looks OK -- can I have a proper patch description and a signed-off-by
line for this please?
Paul.
__
This is a quick hack to make ucc_geth handle a
ping -f -l 10 gracefully. Without it, the CPU will lockup during the ping flood.
I don't have time ATM to clean it up, but if anyone wants to he is welcome :)
Commenst on the geleral approach is wanted though, why do I need to move TX
processing to so
On Tue, 1 Apr 2008, Kumar Gala wrote:
> On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
> >Kumar Gala writes:
> > >Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in
> > >places that before would have caused recursive includes.
> > >
> > >For example to use phys_addr_t in
On Wed, 02 Apr 2008 18:52:10 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02
> 16:46:07.0 +1100
> @@ -0,0 +1,52 @@
> +
Copyight and license statement needed.
> +#include
> +#include
You should include for S
On Wed, 02 Apr 2008 18:52:09 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> This changes it so that all PACAs are statically initialized with
> __current pointing to the init task. For non-0 CPUs, this is fixed
> up before use.
You might want to see how this impacts on Tony Breed's 1
On Apr 2, 2008, at 6:53 AM, Geert Uytterhoeven wrote:
On Tue, 1 Apr 2008, Kumar Gala wrote:
On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote:
Kumar Gala writes:
Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can
use it in
places that before would have caused recursive include
On Apr 2, 2008, at 6:48 AM, Paul Mackerras wrote:
Kumar Gala writes:
Paul, any comments on sending this onto linus. I was hoping to avoid
2.6.25 coming up not support the proper device bindings for DMA and
SATA.
I've pulled it and I'll send it on later (or Linus can pull it
directly if he w
On Apr 1, 2008, at 7:58 PM, Paul Mackerras wrote:
Kumar Gala writes:
Hmm, need to think about that. But my initial reaction is two fold.
One I don't think this information would be around and two don't we
already have this problem with a kdump kernel?
I'm just concerned that we have two thi
Hello,
> On 1/15/08, S. Fricke <[EMAIL PROTECTED]> wrote:
> > Hello friends,
> >
> > I have on the psc3 the spi-interface of a fpga connected.
> >
> >psc3-0 - MOSI
> >psc3-1 - MISO
> >psc3-2 - CLK
> >psc3-3 - SlaveSelect
> >psc3-4 - CS-FPGA
> >psc3-5 - CS Another device
> >
On Tue, 2008-04-01 at 14:00 -0700, Andrew Morton wrote:
> On Mon, 31 Mar 2008 11:23:25 -0500
> York Sun <[EMAIL PROTECTED]> wrote:
>
> > Add platform code to support Freescale DIU. The platform code includes
> > framebuffer memory allocation, pixel format, monitor port, etc.
> >
> > Signed-off-by
Anyone care to comment on that:
$ make ARCH=ppc linux26-menuconfig
[ -f
/home/guinevere/buildroot/project_build_ppc/genepy/linux-2.6.24/.config ] |
| cp local/genepy/linux-2.6.24.config
/home/guinevere/buildroot/project_build_pp
c/genepy/linux-2.6.24/.config
/usr/bin/make -j1 HOSTCC="/usr/bin/
DTS updates that fix booting problems:
- change to ethernet reg property
- addition of mdio and phy nodes
- removal of pci node (Motion-Pro board)
Other DTS updates:
- update i2c device tree nodes
- add lpb bus node and flash device (without partitions defined)
- add rtc i2c nodes
Signed-off-by:
Paul Mackerras wrote:
Bartlomiej Sieka writes:
What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't
see it in the merge branch of your repository, and it would be nice to
get it upstream as it fixes boot problems on some MPC5200-based boards.
It needs a proper stand-alone
A missing break statement in a switch caused cpm2_clk_setup() to initialize
SCC2 instead of SCC1. This patch fixes the bug.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysd
Sorry, although it's related to linuxppc, I intended to post this question
to the buildroot mailing list.
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking whether the PCIe port is already configured as
root-complex or as endpoint. This has been done previously in U-Boot and
can be configured there dynamically by setting the "pcie_mode"
environment variable (reboo
On Wednesday 02 April 2008, Stefan Roese wrote:
> This patch adds basic endpoint support to the 4xx PCIe driver.
This should have been an RFC. Sorry I missed adding it to the subject.
Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlab
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> On Tuesday 25 March 2008, Carl Love wrote:
> > This patch fixes a bug in the code that records the SPU data and
> > context switches. The buffer_mutex lock must be held when the
> > kernel is adding data to the buffer between the kernel an
I am sending V2 series of patches that fix the OF serial driver and add
support to it and the boot for the Xilinx UART 16550.
The ePAPR, although not a formal spec yet, proposes allowing reg-shift
for ns16550. We believe this is a reasonable approach and have
implemented it in this patch series
From: Stephen Neuendorffer <[EMAIL PROTECTED]>
The of_serial driver queries the current-speed property and attempts
to use it to register the custom_divisor property of the uart_port.
However, if current-speed is not set, then this code will dereference
a bad pointer. The fix is to only set custo
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that th
Ideally we get set the phys address the PHDR, but I'm not sure how to
get the linker to do that.
I think you want to look at "AT" in the ld manual.
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linu
On Wed, 2008-04-02 at 09:42 -0700, Carl Love wrote:
> On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > On Tuesday 25 March 2008, Carl Love wrote:
> > > This patch fixes a bug in the code that records the SPU data and
> > > context switches. The buffer_mutex lock must be held when the
>
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
Please use a more descriptive name, if you can still change the binding.
"localplus" or something like that.
Maybe it's time to start an International Obfuscated Device Tree
Contest,
to serve as a warning
Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi Andrew,
The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
On Wed, 2008-04-02 at 22:39 +0530, Kamalesh Babulal wrote:
> Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> Hi Andrew,
>
>
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> From: Stephen Neuendorffer <[EMAIL PROTECTED]>
>
> The of_serial driver queries the current-speed property and attempts
> to use it to register the custom_divisor property of the uart_port.
> However, if current-speed is not
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible bindin
Sounds good, those are easy changes and make sense.
Since I'm a newbie, I don't know any better sometimes when I copy other
code that may not be as safe.
The same thing, of_get_property(np, "current-speed", NULL);, is done
right above my code I added.
Should the other code in the driver usin
On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> The 2.6.25-rc8-mm1 kern
>From c4923d80bbd40f91c7b402db37fabb4995632b7e Mon Sep 17 00:00:00 2001
From: Randy Vinson <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 17:19:06 -0700
Subject: [PATCH] E500 Make steal_context SMP-safe.
When steal_context is used on SMP systems, it can steal a context in
use by one of the other proces
Paul Mackerras wrote:
> Nathan Lynch writes:
>
> > I think this is better... the way these files are used is lame, but
> > this should preserve the existing behavior. I haven't yet tested
> > this, can you?
>
> Looks OK -- can I have a proper patch description and a signed-off-by
> line for this
Hello.
John Linn wrote:
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handl
Hi Guys'n'Gals,
We have a board with two Freescale MPC8641D chips (ie four cores, two in
each chip) on a single jtag chain, nothing else on the chain. We are
unable to get BDI and WindRiver jtag debuggers to work with both chips,
only the second (last) chip works. With the BDI we can configure to
On Wed, Apr 2, 2008 at 12:20 PM, John Linn <[EMAIL PROTECTED]> wrote:
> Sounds good, those are easy changes and make sense.
>
> Since I'm a newbie, I don't know any better sometimes when I copy other
> code that may not be as safe.
>
> The same thing, of_get_property(np, "current-speed", NULL);,
I don't think big-endian has the same context as reg-shift/reg-offset.
The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If
we were talking about a 32 bit device, then I'd probably agree with you,
but in this case, the reg-shift (and to some extent) reg-offset have
been used bef
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAI
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAI
On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> so try to allocate usemap at first altogether.
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 1006
On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> on powerpc,
>
> On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2008-04-02 at 18:17 +1100, Michael El
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
on powerpc,
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > An
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift
arch/powerpc/mm/init_32.c:102: error: conflicting types for
'__initial_memory_limit_addr'
arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of
'__initial_memory_limit_addr' was here
Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
---
arch/powerpc/mm/init_32.c |2 +-
1 files changed,
On Wednesday 02 April 2008, Grant Likely wrote:
> On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> > From: Stephen Neuendorffer <[EMAIL PROTECTED]>
> >
> > The of_serial driver queries the current-speed property and attempts
> > to use it to register the custom_divisor prop
On Thursday 03 April 2008, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the
On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This co
On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> >
> > on powerpc,
> >
> > On Wed, Apr 2, 2008 at 12:22 PM, Badari
On Wed, Apr 2, 2008 at 4:51 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> > so try to allocate usemap at first altogether.
> >
> > Signed-off-by: Yinghai Lu <[E
On Thu, 3 Apr 2008 01:39:04 +0200
Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Wednesday 02 April 2008, Grant Likely wrote:
> > On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> > > From: Stephen Neuendorffer <[EMAIL PROTECTED]>
> > >
> > > The of_serial driver queries the
On Wed, Apr 2, 2008 at 6:02 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based adressing. With
> > additional properties
On Thu, 27 Mar 2008 15:43:31 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/powerpc/platforms/44x/sequoia.c
> b/arch/powerpc/platforms/44x/sequoia.c
> index d279db4..1782d41 100644
> --- a/arch/powerpc/platforms/44x/sequoia.c
> +++ b/arch/powerpc/platforms/44x/sequoia.c
> @@ -2
vmemmap allocation current got
[e200-e21f] PMD ->81000140 on node 0
[e220-e23f] PMD ->81000180 on node 0
[e240-e25f] PMD ->810001c0 on node 0
[e260-e27f] PMD ->810002
On Wed, Apr 2, 2008 at 5:44 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote:
> >
> > > [PATCH] mm: allocate usemap at first instead of mem_map i
On Thursday 03 April 2008, Josh Boyer wrote:
> > > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]>
> > > > Signed-off-by: John Linn <[EMAIL PROTECTED]>
> > > Acked-by: Grant Likely <[EMAIL PROTECTED]>
> >
> > Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
>
> This is the second time all
On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote:
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
err, no.
>
> d
On Wed, Apr 2, 2008 at 5:34 PM, Arnd Bergmann <[EMAIL PROTECTED]> wrote:
> On Thursday 03 April 2008, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based addressing. With
> > additional properties it is compatib
Looks good to me. And ia64 boots up with this patch too.
Thanks.
Acked-by: Yasunori Goto <[EMAIL PROTECTED]>
>
> vmemmap allocation current got
> [e200-e21f] PMD ->81000140 on node 0
> [e220-e23f] PMD ->81000180 on node 0
> [ff
On Wed, Apr 2, 2008 at 7:22 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
> > v2 replace:
> > [PATCH] mm: make mem_map allocation continuous.
> > [PATCH] mm: allocate section_map for sparse_init
> > [PA
On Thursday 03 April 2008, Grant Likely wrote:
> >
> > Since it is not really compatible with ns16550, shouldn't you at least
> > specify
> > a different "compatible" property? That way, the driver won't do incorrect
> > accesses when you try to use an old driver with a device tree that
> > sp
On Thursday 03 April 2008, Josh Boyer wrote:
> On Thu, 27 Mar 2008 15:43:31 +0100
>
> Stefan Roese <[EMAIL PROTECTED]> wrote:
> > diff --git a/arch/powerpc/platforms/44x/sequoia.c
> > b/arch/powerpc/platforms/44x/sequoia.c index d279db4..1782d41 100644
> > --- a/arch/powerpc/platforms/44x/sequoia.c
On Apr 2, 2008, at 6:05 PM, Emil Medve wrote:
arch/powerpc/mm/init_32.c:102: error: conflicting types for
'__initial_memory_limit_addr'
arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of
'__initial_memory_limit_addr' was here
Signed-off-by: Emil Medve <[EMAIL PROTECTED]>
---
arch
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much st
Kumar Gala writes:
> > For a kdump kernel, at least for 64-bit, the physical address has to
> > be 32MB. There is no other choice, so there is no possibility of
> > confusion.
>
> But how do you know a vmlinux image is for kdump or not?
By looking at the ELF headers -- either the first PT_LOAD
On Apr 2, 2008, at 9:46 AM, Laurent Pinchart wrote:
A missing break statement in a switch caused cpm2_clk_setup() to
initialize
SCC2 instead of SCC1. This patch fixes the bug.
Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c |1 +
1 files changed, 1 insert
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
(Added trivial cpm2 fix from Laurent)
- k
arch/powerpc/boot/dts/mpc8377_mds.dts |4 ++--
arch/powerpc/boot/dts/mpc8377_rdb.dts
On Apr 3, 2008, at 1:34 AM, Paul Mackerras wrote:
Kumar Gala writes:
For a kdump kernel, at least for 64-bit, the physical address has to
be 32MB. There is no other choice, so there is no possibility of
confusion.
But how do you know a vmlinux image is for kdump or not?
By looking at the
Wanted to get any feedback on this initial port of the fixmap support over
from x86. There are a few TODOs:
* change HIGHMEM support to use fixmap
* fixup up VMALLOC config to respect fixmap
(after initial powerpc patch is in tree/accepted):
* rework a few bits of fixmap.h into an asm-generic/fi
83 matches
Mail list logo
