Hi Grant,
On Tue, Apr 08, 2008 at 03:26:11PM -0600, Grant Likely wrote:
I disagree and that is not my point.
Well, having something like a device tree that describes the hardware is
definitely a good thing, in general.
Now, if out-of-tree ports continue to break then we've got a problem
that
Now that we have the alpaca, the reg_save_ptr is no longer needed in the
paca. Eradicate all global uses of it and make it static in the iSeries
lpardata.c
Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
arch/powerpc/kernel/paca.c | 33 +++
On Thu, 3 Apr 2008 14:08:42 -0700 (PDT) Roland McGrath [EMAIL PROTECTED]
wrote:
This requires the earlier HAVE_SET_RESTORE_SIGMASK patch series.
This does the same for powerpc that I posted the x86 change for.
---
Replace TIF_RESTORE_SIGMASK with TLF_RESTORE_SIGMASK and define
our own
The iSeries HV only needs the first two fields of the paca statically
initialised, so create an alternate paca that contains only those and
switch to our real paca immediately after boot.
This is in order to make the 1024 cpu patches easier since they will no
longer have to statically initialise
Hi Jon,
On Saturday 12 January 2008 03:47, Jon Smirl wrote:
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
The patch breaks the pfc8563 driver.
The old style driver allocated memory for a
Scott Wood schrieb:
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
[POWERPC] Clean up some linker and symbol usage
No comments. Straight forward patch.
Well, it is changing behaviour. In particular, klimit is not
necessarily the same as _end. It starts out initialized to _end but
then gets advanced by some allocations very early in the boot IIRC.
It might
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
../..
Overall looks good, just a few things:
Ben, thanks for the review.
In general, while I have nothing against the idea of reading the HW
setup left by uboot, I wonder if
Hi,
I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
already working in the kernel and Uboot with UART and ethernet is also
working.
But I can't get the emac driver (ibm_newemac) working under Linux.
On boot emac_init get's called and exits normally, but no probe or
open will
On Wed, Apr 09, 2008 at 12:39:48PM -0500, Scott Wood wrote:
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
* Updated the phys_addr_t patch to be a bit cleaner
* reworked order of patches a bit (bootwrapper now second to last)
* added patch to properly set physical address of PHDR
* reverted change in prom.c to use PHYSICAL_START klimit for lmb_reserve
These patches exist in the following git tree:
Nothing appears to use BOOT_LOAD so remove it as a configurable option.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/Kconfig | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 625342e..c12111d
There does not appear to be any reason that we shouldn't just have
-Iarch/$(ARCH) on both ppc32 and ppc64 builds.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/Makefile | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/Makefile
A number of users of PPC_MEMSTART (40x, ppc_mmu_32) can just always use
0 as we don't support booting these kernels at non-zero physical addresses
since their exception vectors must be at 0 (or 0xfffx_).
For the sub-arches that support relocatable interrupt vectors (book-e) its
reasonable to
total_lowmem represents the amount of low memory not the physical address
that low memory ends at. If the start of memory is at 0 it happends that
total_lowmem can be used as both the size and the address that lowmem
ends at. (technical its one byte beyond the end)
To make the code a bit more
* Determine the RPN we are running the kernel at runtime rather
than using compile time constant for initial TLB
* Cleanup adjust_total_lowmem() to respect memstart_addr and
be a bit more clear on variables that are sizes vs addresses.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Now that we have a proper variable that is the address of the top
of low memory we can use it to limit the lmb allocations.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
include/asm-powerpc/lmb.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git
We always use __initial_memory_limit as an address so rename it
to be clear.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/mm/fsl_booke_mmu.c |2 +-
arch/powerpc/mm/init_32.c | 10 +-
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/ppc_mmu_32.c|
* PAGE_OFFSET is not always the start of code, use _stext instead.
* grab PAGE_SIZE and KERNELBASE from asm/page.h like ppc64 does. Makes the
code a bit more common and provide a single place to manipulate the
defines for things like kdump.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
On Wed, 2008-04-02 at 17:12 +0200, Stefan Roese wrote:
../..
Overall looks good, just a few things:
In general, while I have nothing against the idea of reading the HW
setup left by uboot, I wonder if it wouldn't be best to have this file
capable of fully configuring it in either mode based
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
---
include/asm-powerpc/cpm.h | 14 ++
include/asm-powerpc/cpm1.h | 13 -
include/asm-powerpc/cpm2.h | 11 +--
3 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/include/asm-powerpc/cpm.h
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 asm/page.h we would have included
asm/mmu.h which would have possibly included asm/mmu-hash64.h which
includes asm/page.h. Wh
Now that we properly set the physical address in the program header of the
vmlinux ELF we can extract it to properly set the load and entry point for
u-boot uImages. Before we always hard coded the laod entry point to 0.
However there are situations that the kernel may be built with a non-zero
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
Added support to allow an 85xx kernel to be run from a non-zero physical
address (useful for cooperative asymmetric multiprocessing situations) and
kdump. The support can either be at compile time or runtime
(CONFIG_RELOCATABLE).
Currently we are limited to running at a physical address that is
On Apr 9, 2008, at 9:25 PM, Paul Mackerras wrote:
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
On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
I don't think there's any difference between the _ONSTACK variant
and the normal one without lockdep, is there ?
No there's not. Thus it's a guaranteed no-op and can easily go in.
Paul Mackerras [EMAIL PROTECTED] wrote:
The following patches have been added to the master and powerpc-next
branches of the powerpc.git repository. There is a bunch that I
Paul-san,
Could you apply my take 2 patchset?
[PATCH 0/11] celleb: patchset for 2.6.26 (take 2)
Hi Kumar,
On Thu, 10 Apr 2008 03:51:42 -0500 Kumar Gala [EMAIL PROTECTED] wrote:
We should probably add mpc83xx_defconfig to kisskb. However,
mpc885_ads_defconfig is an 8xx (extreme low end) and mpc85xx_defconfig
(higher end) cover two different processor families so we shouldn't
drop
On Thursday 10 April 2008, M B wrote:
I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
already working in the kernel and Uboot with UART and ethernet is also
working.
But I can't get the emac driver (ibm_newemac) working under Linux.
On boot emac_init get's called and
On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
Sure, this would be optimal. But frankly, I currently have no need for
this
non U-Boot mode, and therefore I didn't implement it. This can be
added later
when really needed don't you think?
It can... but on the other hand, it's not
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-based
platforms.
http://ozlabs.org/pipermail/linuxppc-dev/2008-April/053858.html
[PATCHv4 2/5] powerpc: Add bootwrapper function to get virtual reg from the
device tree.
On Thu, 10 Apr 2008 12:37:45 +0200
M B [EMAIL PROTECTED] wrote:
Hi,
I'm porting vanilla 2.6.25-rc8 (arch=powerpc) to a new board. UART is
already working in the kernel and Uboot with UART and ethernet is also
working.
But I can't get the emac driver (ibm_newemac) working under Linux.
On
On Tue, 08 Apr 2008 11:49:14 -0500
Jerone Young [EMAIL PROTECTED] wrote:
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2
arch/powerpc/platforms/44x/idle.c | 76 +++
Updates: Now setting MSR_WE is now default
On Mon, 07 Apr 2008 15:53:31 -0500
Hollis Blanchard [EMAIL PROTECTED] wrote:
Implement initial support for KVM for PowerPC 440. There are just two small
prerequisite patches, and then the bulk of the code can't be split easily.
Please review; I would like to submit these for 2.6.26. There is
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
On Thu, 2008-04-10 at 12:21 +0200, Stefan Roese wrote:
Sure, this would be optimal. But frankly, I currently have no need for
this
non U-Boot mode, and therefore I didn't implement it. This can be
added later
when really needed
On Thu, 2008-04-10 at 12:56 +0200, Christoph Hellwig wrote:
On Thu, Apr 10, 2008 at 07:03:22AM +1000, Benjamin Herrenschmidt wrote:
I don't think there's any difference between the _ONSTACK variant
and the normal one without lockdep, is there ?
No there's not. Thus it's a guaranteed
On Thu, 2008-04-10 at 13:59 +0200, Stefan Roese wrote:
Understood. But for this dynamic root-complex/endpoint configuration as
implemented with the current version of the patch, I can't change the PCIe
node in the dts from root-complex mode to endpoint mode, since I would loose
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or Kumar can put them in his tree.
Paul.
On Thu, Apr 10, 2008 at 1:52 PM, Josh Boyer [EMAIL PROTECTED] wrote:
You have to call of_platform_bus_probe with the various bus types for
your board. See the top few functions of:
arch/powerpc/platforms/40x/walnut.c
Well I did this, but I made a typo (plb4 instead of plb3).
So thanks a
On Thursday 10 April 2008, Benjamin Herrenschmidt wrote:
Understood. But for this dynamic root-complex/endpoint configuration as
implemented with the current version of the patch, I can't change the
PCIe node in the dts from root-complex mode to endpoint mode, since I
would loose
On Thu, Apr 10, 2008 at 12:44:43PM +0200, Marian Balakowicz wrote:
Last year you have posted a MPC5200 PSC AC97 driver patch
[PATCH 9/9] sound: Add support for Freescale MPC5200 AC97 interface.
with the following comment:
Not quite a clean driver, but it get things done (well, mostly).
On Tuesday 08 April 2008, Jerone Young wrote:
+static struct sleep_mode modes[] = {
+ { .name = wait, .entry = ppc44x_idle },
+ { .name = spin, .entry = NULL },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+
Laurent,
The cpm/82xx ones should go via me.
- k
On Apr 10, 2008, at 6:46 AM, Laurent Pinchart wrote:
Hi Paul,
could you please add the following patches ?
[PATCHv4 1/5] cpm_uart: Allocate DPRAM memory for SMC ports on CPM2-
based
platforms.
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part of 2/5 that adds the new
dt_get_virtual_reg function). Or
Hi Kumar,
On Thursday 10 April 2008 16:10, Kumar Gala wrote:
Laurent,
The cpm/82xx ones should go via me.
Sorry, I didn't know that. I'll e-mail you directly next time.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2)
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in http://patchwork.ozlabs.org/linuxppc/
thanks
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Thursday 10 April 2008 16:11, Kumar Gala wrote:
On Apr 10, 2008, at 7:32 AM, Paul Mackerras wrote:
Laurent Pinchart writes:
could you please add the following patches ?
Sure, if Kumar acks them, since they are all 8xxx-related as far as I
can see (with the exception of the part
On Mon, 07 Apr 2008 15:53:32 -0500
Hollis Blanchard [EMAIL PROTECTED] wrote:
1 file changed, 2 insertions(+)
include/asm-powerpc/mmu-44x.h |2 ++
PowerPC 440 KVM needs to know how many TLB entries are used for the host
kernel
linear mapping (it does not modify these mappings when
On Thursday 10 April 2008 06:55:18 Josh Boyer wrote:
On Mon, 07 Apr 2008 15:53:31 -0500
Hollis Blanchard [EMAIL PROTECTED] wrote:
Implement initial support for KVM for PowerPC 440. There are just two
small prerequisite patches, and then the bulk of the code can't be split
easily.
anyone looking into this?
http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
Its really a Kconfig issue.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Apr 1, 2008, at 7:33 AM, Laurent Pinchart wrote:
Hi everybody,
these 5 patches reset the CPM in cpm2_reset() and fix the cpm_uart
driver to
initialise SMC ports correctly without relying on any initialisation
performed by the boot loader/wrapper. They update the boot wrapper
code and
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in
http://patchwork.ozlabs.org/linuxppc/
Could you please add this one ?
fs_enet: Don't call NAPI functions
I have a copy of the driver I hacked to work with the new PSC framework
but it doesn't work anymore - I have no idea why.
Mail me privately if you want it, I have no time to make patches or
look for a good reason for the breakages, but it compiles at least.
The Efika hack should be gone now
On Apr 3, 2008, at 11:46 AM, Randy Vinson wrote:
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking
to
prevent this as suggested by BenH.
Can we be more descriptive in the problem/bug symptom in the
On Apr 10, 2008, at 10:20 AM, Laurent Pinchart wrote:
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in
http://patchwork.ozlabs.org/linuxppc/
Could you please
Hi everybody,
I need to pass a limited amount of information from the boot loader to the
Linux kernel, such as the boot mode chosen by the user or the last boot
reason (power up, reset, watchdog, ...).
What is the best way to pass that kind of information from the boot loader to
the kernel ?
On Thu, Apr 10, 2008 at 9:50 AM, Laurent Pinchart
[EMAIL PROTECTED] wrote:
Hi everybody,
I need to pass a limited amount of information from the boot loader to the
Linux kernel, such as the boot mode chosen by the user or the last boot
reason (power up, reset, watchdog, ...).
What is
Sascha Hauer wrote:
See bottom of this mail. The board really is a 8260 based board. Our
bootloader does not fill in the clock values, so they are hardcoded. I'm
not very sure about the muram entries because the dpram is organized
slightly different on the 8260. It has some dedicated FCC space
On Tue, 8 Apr 2008 13:54:41 +1000
David Gibson [EMAIL PROTECTED] wrote:
On Mon, Apr 07, 2008 at 10:25:32PM -0500, Hollis Blanchard wrote:
On Monday 07 April 2008 20:11:28 David Gibson wrote:
On Mon, Apr 07, 2008 at 03:53:33PM -0500, Hollis Blanchard wrote:
1 file changed, 7
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums which
had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC
44x). You should have used resource_size_t for the 'offset'
parameter. As this
On Apr 10, 2008, at 10:50 AM, Laurent Pinchart wrote:
Hi everybody,
I need to pass a limited amount of information from the boot loader
to the
Linux kernel, such as the boot mode chosen by the user or the last
boot
reason (power up, reset, watchdog, ...).
What is the best way to pass
On Apr 10, 2008, at 11:56 AM, Sergei Shtylyov wrote:
Hello, I wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have
On Wed, 9 Apr 2008 13:50:43 -0600
Grant Likely [EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio [EMAIL PROTECTED] wrote:
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
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should have used resource_size_t for the
'offset' parameter. As
On Apr 10, 2008, at 1:24 PM, Sergei Shtylyov wrote:
Kumar Gala wrote:
Those functions are going to break on 32-bit platforms with
extended physical address (well, that's starting with Pentiums
which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g.
PowerPC 44x). You should
On Thu, 2008-04-10 at 15:44 +0200, Arnd Bergmann wrote:
On Tuesday 08 April 2008, Jerone Young wrote:
+static struct sleep_mode modes[] = {
+ { .name = wait, .entry = ppc44x_idle },
+ { .name = spin, .entry = NULL },
+};
+
+int __init ppc44x_idle_init(void)
+{
+
The kconfig entry can go away once arch/ppc and references to the config in
drivers are removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/platforms/82xx/Kconfig |3 -
arch/powerpc/platforms/85xx/Kconfig |8 -
arch/powerpc/platforms/8xx/Kconfig |4 -
+#ifndef thread_info_cache_init
+#define thread_info_cache_init do { } while(0)
+#endif
+
Blah ! Missing a pair of () here. Ooops. I'll send a fixed patch.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Thu, 2008-04-10 at 15:37 +0200, Stefan Roese wrote:
Now I have to re-check to see what you really have in mind. Do you think
about
creating two different PCIe nodes, one for root-complex and one for endpoint
functionality? Or is your idea to add a property to the existing PCIe
From: Laurent Pinchart [EMAIL PROTECTED]
Date: Thu, 10 Apr 2008 17:20:36 +0200
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally you can provide links to the patches in
Please use [EMAIL PROTECTED] for patch and development
discussion, linux-net is for user discussions only.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Thu, 2008-04-10 at 15:16 -0700, David Miller wrote:
From: Laurent Pinchart [EMAIL PROTECTED]
Date: Thu, 10 Apr 2008 17:20:36 +0200
On Thursday 10 April 2008 16:21, Kumar Gala wrote:
Guy's
if you have work you want in 2.6.26 related to Freescale PPC's let me
know. Ideally
The following patches add support for the Wind River SBC8641D board.
I've done it by starting with the current mpc8641_hpcn support and
then making the changes from there, so it should be 1:1 comparable
with the HPCN platform, which aids in tracking/applying future changes.
The SBC8641D support
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
arch/powerpc/platforms/86xx/Kconfig|8 ++-
This adds in the device tree source for the SBC8641D, based
largely on the mpc8641_hpcn.dts. The biggest differences are
the lack of a complex IRQ mapping (since no Uli/i8259 cascade)
and the different layout of devices on the localbus node.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
This adds a sample defconfig for the Wind River SBC8641D
board, with SMP, PCI and NFS root enabled.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
arch/powerpc/configs/sbc8641d_defconfig | 1342 +++
1 files changed, 1342 insertions(+), 0 deletions(-)
create mode
The gianfar priv struct has an entry for the mii_bus, but it
isn't being populated. Assign a value for it at the same time
as we assign the phydev, so that it can be used in calls like
gianfar_mdio_read/write.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
drivers/net/gianfar.c |1 +
1
I've tested on 8360, 8540 and 8641D and in all cases, the PHY
ID returned for bus addr 0x1f is all zeros, and not all 0xf.
This means we've been allocating a phydev for this ghost.
In addition to marking 0x0 as an invalid PHY ID, I've also
changed the existing somewhat useless printk to actually
The gfar was previously using the mii_bus-priv to directly
store the gfar_mii regs, which leaves no room/flexibility to
store anything else there. I believe it makes more sense to
have mii_bus-priv point at a struct gianfar_mdio_data and
then have the regs stored as a field within that. It makes
The gfar_local_mdio_read/write functions were brought in via
extern since they go right at the regs vs. going via the normal
gfar_mdio_read/write functions. With the priv-mii_bus properly
set, we can get rid of the externs, the casts etc. and use the
normal gfar_mdio_read/write. We just need to
Currently the MDIO address for the gianfar Ten Bit
Interface is hard coded to be 0x1f, which can conflit
with some boards if they happen to put a PHY there.
Previous discussions indicated that the proper approach
here would be to dynamically allocate it, based on
picking the highest MDIO address
On Apr 10, 2008, at 12:51, Paul Gortmaker wrote:
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this
TBIPA needs to be set to a value (on connected MDIO buses) that doesn't
conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing
boards with PHYs at 0x1f from working properly. Instead, scan the bus when
it comes up, and find an address that doesn't have a PHY on it. The TBI
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.
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
This patch series consists of some minor cleanups that eventually
allow us to implement a dynamic assignment of the gianfar TBIPA.
This was the implementation that Andy and Scott indicated was
the most desireable solution at the bottom of this discussion:
On Apr 10, 2008, at 3:45 PM, Scott Wood wrote:
The kconfig entry can go away once arch/ppc and references to the
config in
drivers are removed.
just to be clear. arch/powerpc will always just use the new binding
and arch/ppc uses the old (or has the option)?
- k
Hi Paul,
Just a couple of comments.
On Thu, 10 Apr 2008 19:22:17 -0400 Paul Gortmaker [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/86xx/sbc8641d.c
+#undef DEBUG
+
+#ifdef DEBUG
+#define DBG(fmt...) do { printk(KERN_ERR fmt); } while(0)
On Thursday 10 April 2008, Jerone Young wrote:
Well it could be this simple. But the current code leaves a lot more
room to add different type waits or spins if need be (if they are ever
needed ... though none off the top of my head at the moment)...but it
does allow you to create another wait
On Fri, 2008-04-11 at 02:18 +0200, Arnd Bergmann wrote:
static int __init idle_param(char *p)
{
if (!strcmp(modes[i].name, spin))
ppc_md.power_save = NULL;
}
early_param(idle, idle_param);
if you statically initialize the ppc_md.power_save function to
The allyesconfig (among others) build was giving this:
In file included from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from include/linux/percpu.h:5,
from include2/asm/time.h:18,
from include2/asm/cputime.h:26,
Hi Kumar,
On Thu, 10 Apr 2008 10:01:27 -0500 Kumar Gala [EMAIL PROTECTED] wrote:
anyone looking into this?
http://kisskb.ellerman.id.au/kisskb/buildresult/23299/
Its really a Kconfig issue.
Just posted a patch.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
This crashes my powerpc mac g5.
It worked fine on mine.
It happens after the boot, during the first login-over-ssh.
Mine did lots of stuff fine.
This is with most of the rest of the -mm poopile applied. i386 and x86_64
seem OK.
I had only tested with Linus's tree plus the small handful
On Thu, Apr 10, 2008 at 07:22:17PM -0400, Paul Gortmaker wrote:
This adds support for the Wind River SBC8641D board, based
largely on the mpc86xx_hpcn support. The biggest difference is
the lack of the Uli and the i8259 cascade, which simplifies things.
Hi Paul,
A couple issues. (These
On Thu, 10 Apr 2008 18:36:35 -0700 (PDT) Roland McGrath [EMAIL PROTECTED]
wrote:
This crashes my powerpc mac g5.
It worked fine on mine.
It happens after the boot, during the first login-over-ssh.
Mine did lots of stuff fine.
This is with most of the rest of the -mm poopile
Kumar Gala wrote:
but there is no reason not to make it work properly. For example I
believe libata uses devm_* and the fsl SATA driver (non-PCI) will
need to work in cases similar to the 44x.
Well, as for sata_fsl, it calls of_iomap() which does The Right Thing.
Fair, but I don't see
In message: Re: [PATCH 0/5] dynamic detection of gianfar TPIPA
on 10/04/2008 Andy Fleming wrote:
I may be missing something, but I don't think this quite right.
If you have a PHY at 0x1f, this patchset will cause no PHY device to be
allocated for that address, and you'll actually end up
98 matches
Mail list logo
