Grant Likely wrote:
On 1/13/08, Matt Sealey [EMAIL PROTECTED] wrote:
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I want to update the firmware tree to add these but, am basically
On Sun, 13 Jan 2008 23:55:21 -0500
Sean MacLennan [EMAIL PROTECTED] wrote:
Stefan Roese wrote:
+#ifdef CONFIG_TACO
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the taco!
+ */
We definitely don't want to see such board specific stuff in the common
On Sun, 13 Jan 2008, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 10:14:14 -0500, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL
On 1/14/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On 1/13/08, Matt Sealey [EMAIL PROTECTED] wrote:
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device trees.
I
On 1/14/08, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 11:26:07 -0500, Jon Smirl wrote:
On 1/13/08, Jean Delvare [EMAIL PROTECTED] wrote:
On Sun, 13 Jan 2008 10:14:14 -0500,
On 13/01/2008, Olof Johansson [EMAIL PROTECTED] wrote:
How do you expect to have it in full production if you don't have all
resources available for it? It's not until the dump has finished that you
can return all memory to the production environment and use it.
With the PHYP dump, each chunk
On Sun, Jan 13, 2008 at 02:26:12PM +, Bryan O'Donoghue wrote:
I've applied your code against Linus' git v2.6.26-rc7 as at today.
I have to apply
It should apply against paulus's tree.
make adder87x-uboot_defconfig
make uImage
make zImage, not uImage.
cp arch/powerpc/boot/uImage
mike zheng wrote:
Is there any BSP on Linux Kernel 2.4 support Quick Engine of MPC8568?
If not, which BSP shall I start the porting? The BSP(on Kernel2.6) of
MPC8568MDS from Freescale supports CPM2, but not QE. What the
difference between CPM2 and QE?
Think of the QE as CPM3.
Supporting the
Hi Geert,
On Mon, 14 Jan 2008 11:57:52 +0100 (CET), Geert Uytterhoeven wrote:
On Sun, 13 Jan 2008, Jon Smirl wrote:
I don't know exactly what those modules tables are used for. I just
copied what the other subsystems do. Maybe they are used when you make
an initrd to know which drivers to
ft_get_next_node() enumerates children of a given node.
ft_get_next_prop() enumerates propreties of a given node.
ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
than a node offset and property name; it is primarily intended for use
with ft_get_next_prop().
The reg property in fsl soc nodes should be removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index
On Mon, 14 Jan 2008, Jean Delvare wrote:
On Mon, 14 Jan 2008 11:57:52 +0100 (CET), Geert Uytterhoeven wrote:
On Sun, 13 Jan 2008, Jon Smirl wrote:
I don't know exactly what those modules tables are used for. I just
copied what the other subsystems do. Maybe they are used when you make
This should have all of Stephen Rothwell's recommended changes.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@
Josh Boyer wrote:
But did you go back and verify the EBC settings were correct on your
board? This shouldn't be needed at all if the EBC bank settings and
timings are correct.
josh
In the EBC0_CFG register we set the RTC (Ready Timeout Count) to 0 and
the sequoia uses 7. Also we set
On Mon, 14 Jan 2008 18:08:16 +0100 (CET), Geert Uytterhoeven wrote:
On Mon, 14 Jan 2008, Jean Delvare wrote:
I thought that the module aliases were generated by
scripts/mod/modpost? As a matter of fact, I did not apply Jon's patch
Sorry, you're right. Too early in the morning :-)
to
On Sun, Jan 13, 2008 at 10:42:16PM -0600, Olof Johansson wrote:
I think simple devices might have been agreed upon (but it's been a
while since it was covered). Muxed busses probably hasn't. Either that
or I completely missed the emails.
I posted something in one of the i2c device tree threads
On Jan 14, 2008 6:50 PM, Jean Delvare [EMAIL PROTECTED] wrote:
On Mon, 14 Jan 2008 18:08:16 +0100 (CET), Geert Uytterhoeven wrote:
On Mon, 14 Jan 2008, Jean Delvare wrote:
I thought that the module aliases were generated by
scripts/mod/modpost? As a matter of fact, I did not apply Jon's
On Monday 14 January 2008, Sean MacLennan wrote:
Josh Boyer wrote:
But did you go back and verify the EBC settings were correct on your
board? This shouldn't be needed at all if the EBC bank settings and
timings are correct.
josh
In the EBC0_CFG register we set the RTC (Ready Timeout
On Mon, 14 Jan 2008 20:38:28 +0100, Kay Sievers wrote:
On Jan 14, 2008 6:50 PM, Jean Delvare [EMAIL PROTECTED] wrote:
I am under the impression that modules.*map are the old way to get
automatic driver loading and aliases are the new way to do the same.
But maybe that's just me.
Right,
Stefan Roese wrote:
And the EBC0_BxCR EBC0BxAP registers for the CS where the NAND is
connected?
How are they configured?
EBC0_B1CR d001c000
EBC0_B1AP 18003c0
Which matches the defines in include/configs/warp.h:
#define CFG_EBC_PB1AP0x018003c0
#define CFG_EBC_PB1CR
On Mon, 10 Dec 2007 17:34:44 +0530 (IST)
Poonam_Aggrwal-b10812 [EMAIL PROTECTED] wrote:
From: Poonam Aggrwal [EMAIL PROTECTED]
The UCC TDM driver basically multiplexes and demultiplexes data from
different channels. It can interface with for example SLIC kind of devices
to receive TDM
Hi Scott,
On Mon, 14 Jan 2008 10:30:04 -0600 Scott Wood [EMAIL PROTECTED] wrote:
ft_get_next_node() enumerates children of a given node.
ft_get_next_prop() enumerates propreties of a given node.
^^
typo.
ft_getprop_offset() is like ft_getprop(), but
Stephen Rothwell wrote:
+++ b/libfdt/libfdt.h
+#define FDT_ERR_BADDEPTH8
Wouldn't it have been less intrusive to just use the next error number
rather than inserting this here?
Yes, but then either the order in errtable[] wouldn't match the order in
the header file, or the error type
From: Mark A. Greer [EMAIL PROTECTED]
The mv64x60 Hotswap register is on the first hose of the mv64x60
hostbridge. To access it, manually find the hose structure and
use the early_* PCI accessor routines because the hostbridge is
normally hidden.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
On Mon, 14 Jan 2008 16:44:33 -0600 Scott Wood [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
+++ b/libfdt/libfdt.h
+#define FDT_ERR_BADDEPTH 8
Wouldn't it have been less intrusive to just use the next error number
rather than inserting this here?
Yes, but then either the
Bryan O'Donoghue wrote:
Ah.
This explains eveything then.. there _is_ a magic image and I haven't
been booting it !
Typical.
I'll give the 8xx-centric ucImage a go.
It is not 8xx centric; it is a compatibility layer for old,
non-device-tree aware u-boots (regardless of what chip
On Mon, 2008-01-14 at 09:28 -0600, Scott Wood wrote:
On Sun, Jan 13, 2008 at 02:26:12PM +, Bryan O'Donoghue wrote:
I've applied your code against Linus' git v2.6.26-rc7 as at today.
I have to apply
It should apply against paulus's tree.
make adder87x-uboot_defconfig
make
On Mon, Jan 14, 2008 at 09:10:01AM +0100, Wolfgang Grandegger wrote:
Grant Likely wrote:
On 1/13/08, Matt Sealey [EMAIL PROTECTED] wrote:
Hi guys,
I know the I2C stuff is up in the air (I cannot pinpoint the documentation
for it) and have not found any CAN bus documentation for device
Hi Mark,
On Mon, 14 Jan 2008 15:51:50 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/sysdev/mv64x60.h
@@ -3,10 +3,32 @@
#include linux/init.h
+#include asm/prom.h
You probably meant to include linux/of.h here
--
Cheers,
Stephen Rothwell[EMAIL
From: Mark A. Greer [EMAIL PROTECTED]
Add support for the Emerson Katana 750i 752i platforms.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
This patch depends on 2 other patch series. This is the list of all the
patches in the two series (not all of them are actually required):
From: Mark A. Greer [EMAIL PROTECTED]
Add DTS file for the Emerson Katana 750i 752i platforms.
Signed-off-by: Mark A. Greer [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/katana750i.dts | 372 +
1 file changed, 372 insertions(+)
diff --git
Hi Mark,
On Mon, 14 Jan 2008 15:51:50 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+static inline struct pci_controller *mv64x60_find_hose(u32 idx)
+{
+ struct device_node *phb;
+ struct pci_controller *hose;
+ const u32 *prop;
+ int len;
+
+
Hi Mark,
On Mon, 14 Jan 2008 16:00:57 -0700 Mark A. Greer [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/embedded6xx/katana750i.c
@@ -0,0 +1,314 @@
+/*
+ * Board setup routines for the Emerson Katana-750i/752i
+ *
+ * Author: Mark A. Greer [EMAIL PROTECTED]
+ *
+ * Based on code
On Mon, Jan 14, 2008 at 03:59:26PM -0700, Mark A. Greer wrote:
From: Mark A. Greer [EMAIL PROTECTED]
Add DTS file for the Emerson Katana 750i 752i platforms.
[snip]
+/dts-v1/;
+
+/ {
+ #address-cells = 1;
+ #size-cells = 1;
+ model = Katana-75xi; /* Default */
+
On Mon, Jan 14, 2008 at 10:30:04AM -0600, Scott Wood wrote:
ft_get_next_node() enumerates children of a given node.
ft_get_next_prop() enumerates propreties of a given node.
ft_getprop_offset() is like ft_getprop(), but takes a property offset rather
than a node offset and property name; it
On Jan 14, 2008, at 10:29 AM, Scott Wood wrote:
The reg property in fsl soc nodes should be removed.
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git
For transparent P2P bridges the first 3 resources may get set from based on
BAR registers and need to get fixed up. Where as the remainder come from the
parent bus and have already been fixed up.
---
in my git tree.
arch/powerpc/kernel/pci-common.c |5 +++--
1 files changed, 3
The fixup code that handles the case for PowerMac's that leave bridge
windows open over an inaccessible region should only be applied to
memory resources (IORESOURCE_MEM). If not we can get it trying to fixup
IORESOURCE_IO on some systems since the other conditions that are used to
detect the
The current PCI code for Freescale 85xx/86xx was treating the virtual
P2P PCIe bridge as a transparent bridge. Rather than doing that fixup
the virtual P2P bridge by copying the resources from the PHB.
Also, fixup a bit of the code for dealing with resource_size_t being
64-bits and how we set
The 85xx/86xx pci code no longer uses update_bridge_resource and it was the
only caller.
---
in my git tree.
arch/powerpc/kernel/pci_32.c | 58 --
include/asm-powerpc/pci-bridge.h |3 --
2 files changed, 0 insertions(+), 61 deletions(-)
diff --git
From: Becky Bruce [EMAIL PROTECTED]
The mpic_map() and __mpic_map_mmio() need to use phys_addr_t for the
physical address they are passed.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mpic.c |4 ++--
1 files changed, 2
I keep getting these link(?) warnings:
WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to
.init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and
'emac_phy_map_lock')
WARNING: vmlinux.o(.init.text+0x16ba8): Section mismatch: reference to
.exit.text:zmii_detach (between
On Mon, 2008-01-14 at 20:44 -0600, Kumar Gala wrote:
The fixup code that handles the case for PowerMac's that leave bridge
windows open over an inaccessible region should only be applied to
memory resources (IORESOURCE_MEM). If not we can get it trying to fixup
IORESOURCE_IO on some systems
On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
I keep getting these link(?) warnings:
WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to
.init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and
'emac_phy_map_lock')
emac_of_bus_notify is
On Mon, 2008-01-14 at 20:58 -0600, Kumar Gala wrote:
From: Becky Bruce [EMAIL PROTECTED]
The mpic_map() and __mpic_map_mmio() need to use phys_addr_t for the
physical address they are passed.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
Ack.
On Mon, 2008-01-14 at 20:45 -0600, Kumar Gala wrote:
For transparent P2P bridges the first 3 resources may get set from based on
BAR registers and need to get fixed up. Where as the remainder come from the
parent bus and have already been fixed up.
Ack.
---
in my git tree.
On Mon, 2008-01-14 at 20:46 -0600, Kumar Gala wrote:
The 85xx/86xx pci code no longer uses update_bridge_resource and it was the
only caller.
Ack.
---
in my git tree.
arch/powerpc/kernel/pci_32.c | 58
--
include/asm-powerpc/pci-bridge.h |
Stephen Rothwell wrote:
On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
I keep getting these link(?) warnings:
WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to
.init.text:emac_of_bus_notify (between 'emac_of_bus_notifier' and
On Monday 14 January 2008, Sean MacLennan wrote:
Stefan Roese wrote:
And the EBC0_BxCR EBC0BxAP registers for the CS where the NAND is
connected? How are they configured?
EBC0_B1CR d001c000
EBC0_B1AP 18003c0
Which matches the defines in include/configs/warp.h:
#define
On Mon, 14 Jan 2008 23:45:17 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
Stephen Rothwell wrote:
On Mon, 14 Jan 2008 23:15:41 -0500 Sean MacLennan [EMAIL PROTECTED] wrote:
I keep getting these link(?) warnings:
WARNING: vmlinux.o(.data+0x16178): Section mismatch: reference to
On Jan 13, 2008, at 6:01 PM, David Gibson wrote:
On Fri, Jan 11, 2008 at 02:07:05PM -0600, Scott Wood wrote:
Signed-off-by: Scott Wood [EMAIL PROTECTED]
[snip]
+aliases {
+console = console;
+enet0 = eth0;
+enet1 = eth1;
I think most other boards
Stefan Roese wrote:
Right. One thing I noticed though is, that you map the NAND to 0xd000,
which is reserved for PCI in the 440EP address space. I suggest you map it to
0x9000 as done on Bamboo. Please give it a try and let me know if this
changes the 32bit access behavior.
I
On Tuesday 15 January 2008, Sean MacLennan wrote:
Stefan Roese wrote:
Right. One thing I noticed though is, that you map the NAND to
0xd000, which is reserved for PCI in the 440EP address space. I
suggest you map it to 0x9000 as done on Bamboo. Please give it a try
and let me know
The patch adds the Haleakala dts. The Haleakala is a stripped down
version of the Kilauea (405EX) with only one EMAC and only one PCIe
interface.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/haleakala.dts | 277 +++
1 files changed, 277
This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
is a 405EX with only one EMAC and only one PCIe interface.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/kernel/cputable.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff
55 matches
Mail list logo
