On Friday 11 April 2008 09:29, Sylvain Munaut 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).
Only included
Anyone care to tell me why the parameters I type manually for the kernel
are
being ignored ?
Care to tell us which kernel you are using and what your .config for it
looks like?
Sure, sorry for not giving more details, I thought it was kind of a general
kernel question (and almost off topic
I think you need to figure out how to build u-boot for your board
outside buildroot, before you try to build it inside buildroot.
Working on it...
While I do that, I have a side question:
is it possible to boot off a first kernel on a local partition, but tell it
to tftp boot off another
Kumar Gala writes:
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
Hi Grant,
Grant Likely wrote:
On Fri, Apr 4, 2008 at 5:13 AM, Bartlomiej Sieka [EMAIL PROTECTED] wrote:
Bartlomiej Sieka wrote:
Hi Grant,
Grant Likely wrote:
I'm thinking 'optimized' defconfigs should go into a subdirectory.
This requires a change to the top-level Makefile and shepherding
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.
...
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/types.h
index 903fd19..d853cf0 100644
--- a/include/asm-powerpc/types.h
Ishizaki Kou writes:
Paul-san,
Could you apply my take 2 patchset?
There was some discussion about some of them -- did that end up with
Ben accepting that your patches didn't need any changes?
Ben - if so could you ack them for me please?
Paul.
___
Scott,
there has been a compatible=soc in my of_bus_id[] ...
It was taken from mpc834x_mds some weeks ago.
I changed to :
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
{},
};
now it works fine.
Thanks !
Andre
Scott Wood
I have just pushed the following patches to the master and
powerpc-next branches of the powerpc.git repository, and pulled in
Linus' tree as of 2.6.25-rc9.
Paul.
Dale Farnsworth (5):
[POWERPC] prpmc2800: Fix frequencies in prpmc2800.dts
[POWERPC] mv64x60: Remove device tree absolute
Hi everybody,
I'm implementing flow control and modem control lines support in the cpm_uart
driver.
The implementation is based on the GPIO lib. Modem control lines are described
in the device tree as GPIO resources and accessed through the OF GPIO
bindings. The I/O ports have to be
Hi everybody,
thanks to a bad hardware design decision, I'm faced with a software issue with
the cpm_uart driver.
My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port
with an external transceiver. The transceiver's data direction is controlled
by external logic that
On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
Hi everybody,
I'm implementing flow control and modem control lines support in the
cpm_uart driver.
The implementation is based on the GPIO lib. Modem control
On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
Hi everybody,
I'm implementing flow control and modem control lines support in the cpm_uart
driver.
The implementation is based on the GPIO lib. Modem control lines are
described
in the device tree as GPIO resources and
On Tue, Apr 15, 2008 at 01:53:56PM +0200, Andre Schwarz wrote:
Scott,
there has been a compatible=soc in my of_bus_id[] ...
It was taken from mpc834x_mds some weeks ago.
I changed to :
static struct of_device_id __initdata of_bus_ids[] = {
{ .compatible = fsl,pq2pro-localbus, },
On Apr 14, 2008, at 11:44 PM, Paul Mackerras wrote:
Kumar Gala writes:
global_dbcr0 needs to be a per cpu set of save areas instead of a
single
global on all processors.
Looks reasonable. At some point you might want to use a per-cpu
variable instead of an array in order to reduce
On Apr 15, 2008, at 5:12 AM, 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.
...
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/
types.h
index
On Apr 15, 2008, at 2:34 AM, Paul Mackerras wrote:
Kumar Gala writes:
+phys_addr_t memstart_addr;
+EXPORT_SYMBOL(memstart_addr);
Do you have a modular user of memstart_addr in mind?
I believe its needed for the CONFIG_RELOCATE build, but I can double
check that.
- k
On Apr 15, 2008, at 9:35 AM, Kumar Gala wrote:
On Apr 15, 2008, at 2:34 AM, Paul Mackerras wrote:
Kumar Gala writes:
+phys_addr_t memstart_addr;
+EXPORT_SYMBOL(memstart_addr);
Do you have a modular user of memstart_addr in mind?
I believe its needed for the CONFIG_RELOCATE build, but I
On Tue, Apr 15, 2008 at 03:47:41PM +0200, Laurent Pinchart wrote:
On Tuesday 15 April 2008 15:40, Anton Vorontsov wrote:
On Tue, Apr 15, 2008 at 03:22:33PM +0200, Laurent Pinchart wrote:
Hi everybody,
I'm implementing flow control and modem control lines support in the
cpm_uart
On Apr 15, 2008, at 5:57 AM, Paul Mackerras wrote:
Kumar Gala writes:
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
From: Sascha Hauer [EMAIL PROTECTED]
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): When this
occurs, software
On Apr 15, 2008, at 10:26 AM, Robert Schwebel wrote:
From: Sascha Hauer [EMAIL PROTECTED]
The error handling for the mpc5200 fec interrupt is broken. The
intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B
From: Sascha Hauer [EMAIL PROTECTED]
Add a set_type function for external (GPIO) interrupts.
Signed-off-by: Juergen Beisert [EMAIL PROTECTED]
Signed-off-by: Sascha Hauer [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 38 ++
1 file changed, 38
Hi Paul
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.26
to pick up some additional patches for 4xx. This contains the
defconfig reorg, some EMAC patches from Valentine that have been
outstanding for a while, and a new idle loop patch.
josh
On Tue, Apr 15, 2008 at 10:29:26AM -0500, Kumar Gala wrote:
You really need to also copy netdev and patches to drivers/net.
Hm? Sorry, don't understand what you mean.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Laurent Pinchart wrote:
thanks to a bad hardware design decision, I'm faced with a software issue with
the cpm_uart driver.
My hardware uses either SCC4 or SMC2 (production-time option) as an RS485 port
with an external transceiver. The transceiver's data direction is controlled
by external
From: Sascha Hauer [EMAIL PROTECTED]
The error handling for the mpc5200 fec interrupt is broken. The intended
behaviour is like this:
* If one of FEC_IEVENT_RFIFO_ERROR and FEC_IEVENT_XFIFO_ERROR happens,
the datasheet says (MPC5200B User's Guide R1.2, p. 14-13): When this
occurs, software
Hi Jocke,
On Mon, 2008-04-14 at 18:09 +0200, Detlev Zundel wrote:
Hi Jocke,
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.
Probably a dumb question, but doesn't backtrace(3)
Hi Scott,
On Tuesday 15 April 2008 17:34, Scott Wood wrote:
Laurent Pinchart wrote:
thanks to a bad hardware design decision, I'm faced with a software issue
with the cpm_uart driver.
My hardware uses either SCC4 or SMC2 (production-time option) as an RS485
port with an external
Laurent Pinchart wrote:
The clean solution would be to have an abstracted clock API, similar to
phylib, where the caller doesn't know details about BRGs and such.
Maybe the linux/clk.h API would be suitable; I haven't looked at it in
detail.
The clock API would have to be quite advanced to
1. Detect (and bail out on) more conditions that violate the
assumptions of the setup code -- we assume in such cases that the device
tree is correct and reflects what the firmware did.
2. The inbound memory mask calculation was wrong.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/configs/mpc8313_rdb_defconfig |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/configs/mpc8313_rdb_defconfig
b/arch/powerpc/configs/mpc8313_rdb_defconfig
index 7a862a6..7d18440 100644
---
On Tuesday 15 April 2008 17:59, Scott Wood wrote:
Laurent Pinchart wrote:
The clean solution would be to have an abstracted clock API, similar to
phylib, where the caller doesn't know details about BRGs and such.
Maybe the linux/clk.h API would be suitable; I haven't looked at it in
Paul Gortmaker wrote:
-void
+static void
mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
{
struct device_node *root;
@@ -190,13 +190,13 @@ static int __init mpc86xx_hpcn_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root,
Hi
I hereby take the liberty to contact you regarding an issue we
experience with the
MPC5200 BestComm/FEC in our system. I found that you are the writer of
the drivers
for these, so apparently with a lot of experience with these devices.
I hope you can find
the time and inspiration to look
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
We were already doing what amounts to a get_phy_id from within
get_phy_device, and rather than duplicate this for the TBIPA
probing, we might as well just factor it out and make it available
instead.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
Acked-by: Andy Fleming [EMAIL PROTECTED]
---
This is the resend of the two patches as per Andy's request for v2.6.26
that allow boards with a PHY at the end of the bus to function, by having
the TBIPA set dynamically. The 1st patch factors out some of the PHY
probe code so it can be recycled by the TBIPA probe, and the second patch
Paul Gortmaker wrote:
Valid point. Is there a precedent here -- like a printk indicating
that the old ID matched, to let the user know?
Not really, but a pr_warning() would be nice.
Actually on this one, we are OK, since the board support didn't exist
in the default kernel until I'd just
Hi,
Currently, I have problem of the UBoot MCC driver. I setup the
internal loopback on MPC8568. And here is the data of each channel:
Channel #Tx DataRx Data
0 0x010x9D
1
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 70 ++--
arch/powerpc/sysdev/fsl_soc.h |1 +
2 files changed, 33 insertions(+), 38 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
* Removed EXPORT_SYMBOL of memstart_addr
* Fixed phys_addr_t typedef so its not exported to user space
* Added new patch that splits out removal of KERNEL_PGD_PTRS USER_PGD_PTRS
and cleaning up pmd_page macro
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 1d4d19f..cb7406e
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]
---
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
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
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
* Removed defines KERNEL_PGD_PTRS USER_PGD_PTRS since they aren't used
anywhere
* Changed pmd_page macro to use pfn_to_page so we get proper behavior if
ARCH_PFN_OFFSET is set as well if we use a different memory model on ppc32.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
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 15, 2008, at 11:03 AM, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/configs/mpc8313_rdb_defconfig |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
Do we want similar updates to the mpc83xx_defconfig?
- k
Kumar Gala wrote:
On Apr 15, 2008, at 11:03 AM, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/configs/mpc8313_rdb_defconfig |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
Do we want similar updates to the mpc83xx_defconfig?
Sure.
-Scott
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 Tuesday 15 April 2008, Akira Iguchi wrote:
scc_pata has the different BAR configuration and using ide_setup_pci_device()
is inappropriate.
(ide_setup_pci_device() expects a normal PCI IDE controller with
BAR0..BAR3 either non-existant or being primary/secondary port bases
in I/O space.)
On Wednesday 09 April 2008, Bartlomiej Zolnierkiewicz wrote:
[ added Akira Kou to cc: ]
On Tuesday 08 April 2008, Sergei Shtylyov wrote:
Hi, I just wrote:
This function didn't actually check if a given BAR is in I/O space
because of
using the bogus PCI_BASE_ADDRESS_IO_MASK
On Tue, Apr 15, 2008 at 01:52:34PM -0500, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 70 ++--
arch/powerpc/sysdev/fsl_soc.h |1 +
2 files changed, 33 insertions(+), 38 deletions(-)
diff --git
Anton Vorontsov wrote:
+u32 fsl_get_sys_freq(void)
+{
+ struct device_node *soc;
+ const u32 *prop;
+ int size;
+
+ if (sysfreq != -1)
+ return sysfreq;
+
+ soc = of_find_node_by_type(NULL, soc);
+ if (!soc)
+ return -1;
Um.. can
On Monday 14 April 2008, Benjamin Herrenschmidt wrote:
2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both
phys have to be accessed through this one. This affectes the mdio
read/write functions.
The later can easily be described in the device-tree as it's a fairly
common
On Apr 15, 2008, at 4:35 PM, Scott Wood wrote:
Anton Vorontsov wrote:
+u32 fsl_get_sys_freq(void)
+{
+ struct device_node *soc;
+ const u32 *prop;
+ int size;
+
+ if (sysfreq != -1)
+ return sysfreq;
+
+ soc = of_find_node_by_type(NULL, soc);
+
I'm a big proponent of marking kernels with their characteristics during
development -- instead of trying to coordinate multiple pieces of
information and hope you get it right (I don't like to try)
I've been lobbying for /proc/config for a decade (that's one of the
first
things I enable when I'm
All the updates based on the feedback from folks (thanks!) are integrated
into this resend. This should be good to go for powerpc-next/2.6.26.
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
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
In message: Re: [PATCH] 86xx: mark functions static, other minor cleanups
on 15/04/2008 Timur Tabi wrote:
Paul Gortmaker wrote:
Valid point. Is there a precedent here -- like a printk indicating
that the old ID matched, to let the user know?
Not really, but a pr_warning() would be
What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
kernel is loaded at some address != CONFIG_PHYSICAL_START?
Assuming its not a CONFIG_RELOCATABLE kernel than bad things. Is
there some concern you have here?
Are we sure that ARCH_PFN_OFFSET only gets applied to normal
Paul,
The aim is to have more flex space for the kernel on machines with more
resources. Although the dump will be collected pretty fast and the memory
released really early on allowing the machine to have the full memory
available, this alleviates any issues that can be caused by having way
-void
+static void
mpc86xx_hpcn_show_cpuinfo(struct seq_file *m)
{
struct device_node *root;
@@ -190,13 +190,19 @@ static int __init mpc86xx_hpcn_probe(void)
{
unsigned long root = of_get_flat_dt_root();
- if (of_flat_dt_is_compatible(root, mpc86xx))
+ /* Delete this
On Mar 18, 2008, at 10:43 AM, Anton Vorontsov wrote:
This is needed to probe nor and nand flashes on the localbus.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
arch/powerpc/platforms/83xx/mpc837x_rdb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applied.
- k
On Apr 15, 2008, at 11:02 AM, Scott Wood wrote:
1. Detect (and bail out on) more conditions that violate the
assumptions of the setup code -- we assume in such cases that the
device
tree is correct and reflects what the firmware did.
2. The inbound memory mask calculation was wrong.
On Apr 15, 2008, at 11:03 AM, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/configs/mpc8313_rdb_defconfig |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
(Fixed and applied.. I moved defconfigs on you).
- k
On Apr 15, 2008, at 1:52 PM, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 70 +
+--
arch/powerpc/sysdev/fsl_soc.h |1 +
2 files changed, 33 insertions(+), 38 deletions(-)
applied.
- k
On Apr 15, 2008, at 5:41 PM, 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.
Signed-off-by: Paul Gortmaker [EMAIL PROTECTED]
---
On Apr 15, 2008, at 5:41 PM, Paul Gortmaker wrote:
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.
On Apr 15, 2008, at 5:41 PM, Paul Gortmaker wrote:
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
On Apr 15, 2008, at 5:46 PM, Paul Gortmaker wrote:
In message: Re: [PATCH] 86xx: mark functions static, other minor
cleanups
on 15/04/2008 Timur Tabi wrote:
Paul Gortmaker wrote:
Valid point. Is there a precedent here -- like a printk indicating
that the old ID matched, to let the user
Kumar Gala writes:
What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
kernel is loaded at some address != CONFIG_PHYSICAL_START?
Assuming its not a CONFIG_RELOCATABLE kernel than bad things. Is
there some concern you have here?
No, I meant if it is a CONFIG_RELOCATABLE
On Apr 15, 2008, at 7:03 PM, Paul Mackerras wrote:
Kumar Gala writes:
What happens if CONFIG_KERNEL_START != CONFIG_PAGE_OFFSET and the
kernel is loaded at some address != CONFIG_PHYSICAL_START?
Assuming its not a CONFIG_RELOCATABLE kernel than bad things. Is
there some concern you have
Paul Gortmaker writes:
This is the resend of the two patches as per Andy's request for v2.6.26
that allow boards with a PHY at the end of the bus to function, by having
the TBIPA set dynamically. The 1st patch factors out some of the PHY
probe code so it can be recycled by the TBIPA probe,
On Tue, 2008-04-15 at 23:51 +0200, Markus Brunner wrote:
On Monday 14 April 2008, Benjamin Herrenschmidt wrote:
2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both
phys have to be accessed through this one. This affectes the mdio
read/write functions.
The later can
On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras [EMAIL PROTECTED] wrote:
Paul Gortmaker writes:
This is the resend of the two patches as per Andy's request for v2.6.26
that allow boards with a PHY at the end of the bus to function, by having
the TBIPA set dynamically. The 1st patch
On Apr 15, 2008, at 8:57 PM, Paul Gortmaker wrote:
On Tue, Apr 15, 2008 at 8:25 PM, Paul Mackerras [EMAIL PROTECTED]
wrote:
Paul Gortmaker writes:
This is the resend of the two patches as per Andy's request for
v2.6.26
that allow boards with a PHY at the end of the bus to function, by
Paul,
Do you why we have the following:
* include/asm-powerpc/highmem.h - kunmap_atomic - comment about //FIXME?
* CONFIG_HIGHMEM_START -- what was the thinking here?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
Move the prototype for find_udbg_vterm() into pseries.h, removing
it from setup.c
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/lpar.c|1 +
arch/powerpc/platforms/pseries/pseries.h |2 ++
arch/powerpc/platforms/pseries/setup.c |3 ---
3
There is logic in platforms/peries/lpars.c which checks if the user has
specified a console on the command line, and refrains from adding a
preferred console entry for the hvc/hvsi console if they have.
This trips up if you use netconsole=foo on the command line, and has
the result that you get
90 matches
Mail list logo
