* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-22 13:52 UTC (permalink / raw)
To: LinuxPPC-Embedded; +Cc: s.balamurugan
In-Reply-To: <47BD9FA9.1000904@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>> When I try to read some register from my FPGA (virtex5) I have this bus
>> error:
>
>
> Hmmm.... OK, so if we've eliminated PCI-E as a source
> for this issue, it really must be in the Virtex support
> somewhere then. Unfortunately, I know nothing about those,
> and am not going to be much direct help there.
>
> Sorry.
>
> jdl
>
>
>> Machine check in kernel mode.
>> Caused by (from SRR1=149030): Transfer error ack signal
>> Oops: Machine check, sig: 7 [#1]
>> PREEMPT SMP NR_CPUS=2
>> Modules linked in: virtex5
>> LTT NESTING LEVEL : 0
>> NIP: F108019C LR: F1080198 CTR: 00000001
>> REGS: c044dd60 TRAP: 0200 Not tainted (2.6.18-mpc8641d_hpcn)
>> MSR: 00149030 <EE,ME,IR,DR> CR: 22000222 XER: 00000000
>> TASK = c20e9990[568] 'insmod' THREAD: c044c000 CPU: 0
>> GPR00: F1080198 C044DE10 C20E9990 0000002E 80000000 FFFFFFFF 00008000
>> 00002EA3
>> GPR08: C20E9990 00000000 C04C0220 C044C000 22000222 1001956C 00000000
>> 00000000
>> GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>> 00000000
>> GPR24: 3000EAA0 7FD6FDC0 00000000 C045FCC0 F107E594 F10A0000 00000000
>> C2036000
>> NIP [F108019C] virtex5_probe+0x130/0x1c4 [virtex5]
>> LR [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5]
>> Call Trace:
>> [C044DE10] [F1080198] virtex5_probe+0x12c/0x1c4 [virtex5] (unreliable)
>> [C044DE30] [C01D2A58] pci_device_probe+0x84/0xbc
>> [C044DE50] [C0213754] driver_probe_device+0x60/0x118
>> [C044DE70] [C0213890] __driver_attach+0x84/0x88
>> [C044DE90] [C02130F4] bus_for_each_dev+0x58/0x94
>> [C044DEC0] [C02135D4] driver_attach+0x24/0x34
>> [C044DED0] [C0212AC8] bus_add_driver+0x88/0x164
>> [C044DEF0] [C021397C] driver_register+0x70/0xb8
>> [C044DF00] [C01D284C] __pci_register_driver+0x64/0x98
>> [C044DF10] [F1080030] init_module+0x30/0x6c [virtex5]
>> [C044DF20] [C004CBFC] sys_init_module+0xc8/0x25c
>> [C044DF40] [C0011358] ret_from_syscall+0x0/0x38
>> --- Exception: c00 at 0xff6de0c
>> LR = 0x10000de4
>> Instruction dump:
>> 40820060 3c60f108 3863cea0 48000311 807f0238 3c800001 48000395 7c7d1b78
>> 3c60f108 3863ced4 480002f5 809d0000 <3c60f108> 3863cf04 480002e5 3c60f108
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
I tried to use 2.6.24 but I have the same error. It looks like this
problem happens when I try to read something in my ML555 board (Virtex5
evaluation board), but if try to write everything works fine. I tried to
change the settings about inbound/outbound PCI-E windows but I have the
same problem. Have you got any suggestions?
Thanks.
Marco
^ permalink raw reply
* Doubt in Device tree entry for USB on Powerpc based board
From: mahendra varman @ 2008-02-22 13:33 UTC (permalink / raw)
To: linuxppc-embedded, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 6986 bytes --]
Hello All
Iam using Powerpc 7448 processor along with TSI 109 system controller.
On PCI interface of TSI 109 a PCI to PCI bridge(6520) is connected in which
an usb controller(Philips ISP1562) and PMC site is connected.
Iam following the Open Firmware Powerpc architecture and using Linux 2.6.23.
I have framed the device tree for the above architecture with usb entry. But
even though i enable the ohci ppc of in menuconfig the the functions
probe,etc inside ohci ppc of.c are not called when i insert the device in
usb port and hence it is not detecting ohci low/full speed devices.
Please help me in the device tree where to give the device type
compatibility address_cells size cells for the USB (since usb controller is
in pci bridge i have some confusion in where to give the entry for usb)
I have attached the device tree below
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
{ model = "CTP7448";
compatible = "mpc74xx";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells =<0>;
PowerPC,7448@0 {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <20>; // 32 bytes
i-cache-line-size = <20>; // 32 bytes
d-cache-size = <8000>; // L1, 32K bytes
i-cache-size = <8000>; // L1, 32K bytes
timebase-frequency = <0>; // 33 MHz, from uboot
clock-frequency = <0>; // From U-Boot
bus-frequency = <0>; // From U-Boot
32-bit;
};
};
memory{
device_type = "memory";
reg = <00000000 10000000>; // DDR2 512M at 0
};
tsi108@c0000000 {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
device_type = "tsi-bridge";
ranges = <00000000 c0000000 00010000
00000000 f0000000 00008000
00000000 f1000000 01000000
00000000 f8000000 01000000>;
reg = <c0000000 00010000>;
bus-frequency = <0>;
rtc@f0000000 {
device_type = "rtc";
compatible = "st,m48t59";
reg = <f0000000 8000>;
};
i2c@7000 {
interrupt-parent = <&mpic>;
interrupts = <E 0>;
reg = <7000 400>;
device_type = "i2c";
compatible = "tsi108-i2c";
};
MDIO: mdio@6000 {
device_type = "mdio";
compatible = "tsi108-mdio";
reg = <6000 50>;
#address-cells = <1>;
#size-cells = <0>;
phy1: ethernet-phy@1 {
interrupt-parent = <&mpic>;
interrupts = <0 0>;
reg = <1>;
device_type = "ethernet-phy";
};
phy8: ethernet-phy@8 {
interrupt-parent = <&mpic>;
interrupts = <1 0>;
reg = <8>;
device_type = "ethernet-phy";
};
};
ethernet@6200 {
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6000 200>;
address = [ 00 03 23 00 00 01 ];
interrupts = <10 0>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy1>;
};
ethernet@6600 {
#address-cells = <1>;
#size-cells = <0>;
device_type = "network";
compatible = "tsi108-ethernet";
reg = <6400 200>;
address = [ 00 03 23 00 00 02 ];
interrupts = <11 2>;
interrupt-parent = <&mpic>;
mdio-handle = <&MDIO>;
phy-handle = <&phy8>;
};
serial@7808 {
device_type = "serial";
compatible = "ns16550";
reg = <7808 200>;
clock-frequency = <3f6b5a00>;
interrupts = <c 0>;
interrupt-parent = <&mpic>;
};
serial@7c08 {
device_type = "serial";
compatible = "ns16550";
reg = <7c08 200>;
clock-frequency = <3f6b5a00>;
interrupts = <d 0>;
interrupt-parent = <&mpic>;
};
mpic: pic@7400 {
clock-frequency = <0>;
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <2>;
reg = <7400 400>;
built-in;
compatible = "chrp,open-pic";
device_type = "open-pic";
big-endian;
};
pci@1000 {
compatible = "tsi108-pci";
device_type = "pci";
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <1000 1000>;
bus-range = <0 0>;
ranges = <02000000 0 e0000000 e0000000 0 10000000
01000000 0 00000000 f2000000 0 01000000>;
clock-frequency = <3ef1480>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x10 */
00000 0 0 1 &RT0 24 0
/* IDSEL 0x11 */
00800 0 0 1 &RT0 25 0
/* IDSEL 0x12 */
1000 0 0 1 &RT0 24 0
1000 0 0 2 &RT0 25 0
1000 0 0 3 &RT0 26 0
1000 0 0 4 &RT0 27 0 >;
pci_bridge@12 {
interrupt-map-mask = <f800 0 0 7>;
interrupt-map = <
/* IDSEL 0x13 (PMC Site) */
1800 0 0 1 &RT0 24 0
1800 0 0 2 &RT0 25 0
1800 0 0 3 &RT0 26 0
1800 0 0 4 &RT0 27 0
/* IDSEL 0x14 (USB chip) */
2000 0 0 1 &RT0 27 0
2000 0 0 2 &RT0 27 0
2000 0 0 3 &RT0 27 0
2000 0 0 4 &RT0 27 0
>;
reg = <1000 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
ranges = <02000000 0 e0000000 e0000000 0 10000000 01000000 0
00000000 fa000000 0 00010000>;
clock-frequency = <1f78a40>;
RT0: router@1180 {
clock-frequency = <0>;
interrupt-controller;
device_type = "pic-router";
#address-cells = <0>;
#interrupt-cells = <2>;
built-in;
big-endian;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
};
};
};
};
[-- Attachment #2: Type: text/html, Size: 17996 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] 8xx: timebase frequency should not depend on bus-frequency
From: Bryan O'Donoghue @ 2008-02-22 13:01 UTC (permalink / raw)
To: cbouatmailru; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080221234136.GA3545@zarina>
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
> > Anton Vorontsov wrote:
> > > On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
> > >> Current u-boots don't support device trees at all on 8xx.
> > >
> > > Yes, vanilla u-boots. I assume many of us use some u-boot hacks to
> > > actually boot with the device tree (no, not cuboots)... ;-)
> >
> > Fine, but don't expect misbehavior from out-of-tree u-boots to be used
> > as justification for the kernel ignoring device tree content. :-)
>
> You got me wrong, maybe I wasn't clear enough: it wasn't justification of
> any kind. It's was just a remark regarding u-boot still not supporting
> fdt for 8xx (20 lines of code we're lazy to cleanup, write annotation
> to the patch and send it ;-).
Hey Anton.
I won't make any comment on what Linux should do with an older version of
u-boot.
However, just to let you know, there are a couple of patches to do a more modern
fdt on 8xx- sent to the u-boot list in the last <= ~ 10 days.
Using those patches - which incorporate the changes suggested by Scott re:
get_tbclk()- the timebase-frequency field is indeed stuffed with u-boot's
get_tbclk(); - see below.
u-boot/cpu/mpc8xx/fdt.c
void ft_cpu_setup(void *blob, bd_t *bd)
{
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"timebase-frequency", get_tbclk(), 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"bus-frequency", bd->bi_busfreq, 1);
do_fixup_by_prop_u32(blob, "device_type", "cpu", 4,
"clock-frequency", bd->bi_intfreq, 1);
do_fixup_by_compat_u32(blob, "fsl,cpm-brg", "clock-frequency",
gd->brg_clk, 1);
/* Fixup ethernet MAC addresses */
fdt_fixup_ethernet(blob, bd);
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
}
Adding fdt support to an 8xx board is then as simple as defining
/* pass open firmware flat tree */
#define CONFIG_OF_LIBFDT 1
#define CONFIG_OF_BOARD_SETUP 1
In your u-boot/include/configs/MySuperBoard.h
Best,
Bryan
^ permalink raw reply
* TQM5200 2.6-denx SM501 voyager enabling problem.
From: Pedro Luis D. L. @ 2008-02-22 11:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I'm working right now with a TQM5200 microcontroller on a STX5200 board.
I'm having problems to enable SM501 video output using 2.6-denx kernel. The=
system is working properly using 2.4 kernel and I can have graphical outpu=
t, so I can be sure that there's no hardware problem.
With 2.6 I have used the tqm5200_defconfig configuration file and then I ha=
ve enabled the following features in the kernel:
- Device Drivers -> Multifunction Device Drivers -> Support forSilicon Mot=
ion SM501.
- Device Drivers -> Graphic Support -> Support for frame buffer devices.
- Device Drivers -> Graphic Support -> Support for frame buffer devices -=
> Silicon Motion SM501 framebuffer support.
- Device Drivers -> Character devices -> Virtual Terminal.
- Device Drivers -> Character devices -> Support for console on virtual te=
rminal.
But I still can't make the SM501 driver initialized at booting time and the=
re's no framebuffer video device available. /dev/fb and /dev/fb0 nodes are =
already created.
I'm using 1.3.1 u-boot from denx repository compiled with CONFIG_STK52XX=
=3Dy and CONFIG_MINIFAP=3Dy options, and video=3Dvoyager:fp options is pass=
ed to the kernel at booting.
I'm sure there's something I'm missing to enable in the kernel. Maybe someo=
ne can sent me a hint. I would appreciate any!
Pedro L.
_________________________________________________________________
MSN Noticias
http://noticias.msn.es/comunidad.aspx=
^ permalink raw reply
* Re: [PATCHv4 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Jochen Friedrich @ 2008-02-22 11:16 UTC (permalink / raw)
To: Jean Delvare; +Cc: linux-kernel, linuxppc-dev list, i2c, Scott Wood
In-Reply-To: <20080221130520.12b01553@hyperion.delvare>
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your reasons.
Fortunately, I2c no longer uses numeric device IDs but names. So what are the alternatives?
1. modify the I2c subsystem to accept OF names additionally to I2c names (proposed by Jon smirl).
2. record the I2c name in the dts tree, either as seperate tag (like linux,i2c-name="<i2c-name>")
or as additional compatible entry (like compatible="...", "linux,<i2c-name>").
3. use a glue layer with a translation map.
What is the preferred way to do this?
Thanks,
Jochen
^ permalink raw reply
* MPC8540 : What's "SPE used in kernel" ?
From: Philippe De Muyter @ 2008-02-22 9:50 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080221123534.GA17716@ingate.macqel>
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of "SPE used in kernel" messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there something wrong in my setting and should I look further to
debug this problem or is this perfectly normal ?
I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
triggers this message. Is it invalid to use SPE instructions in the kernel
or do I misunderstand the message ?
Philippe
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Bartlomiej Sieka @ 2008-02-22 8:34 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
>> A property's data can be populated with a file's contents
>> as follows:
>>
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> A subset of a file can be included by passing start and size parameters.
>> For example, to include bytes 8 through 23:
>>
>> node {
>> prop = /incbin/("path/to/data", 8, 16);
>> };
>
>
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Binary includes are a critical feature of the new image format for
U-Boot. In short: we're describing image's content and other data
(architecture, os, image type, etc) in dts format, and then use dtc to
generate the file that is transferred to the target and booted by
U-Boot. Excerpt from an actual file describing an image:
/{
images {
kernel@1 {
data = /incbin/("./vmlinux.bin.gz");
type = "kernel";
arch = "ppc";
os = "linux";
compression = "gzip";
load = <00000000>;
entry = <00000000>;
};
};
};
As to the size of the final blob in our case, it depends. It seems that
in case of a powerpc Linux booting scenario, most of the times the size
will be roughly the size of a compressed kernel + the size of the FDT
blob, eventually plus the size of a ramdisk. Note however, that the new
image format has provisions for handling multiple components of the same
type in one image, so for example you could have three kernels, two
ramdisks and a couple of fdt blobs in one image, and the actual booting
configuration could be selected in U-Boot. In such a case, the final
blob can be arbitrarily large.
Regards,
Bartlomiej
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: David Woodhouse @ 2008-02-22 9:02 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev, jdl
In-Reply-To: <fa686aa40802212205p38c3793bg8793740955b1e91@mail.gmail.com>
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Device firmware?
--
dwmw2
^ permalink raw reply
* [PATCH] [POWERPC] AMCC Kilauea (405EX): Disable EMAC loopback mode
From: Stefan Roese @ 2008-02-22 8:32 UTC (permalink / raw)
To: linuxppc-dev
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese <sr@denx.de>
---
I'm not sure if this should be done here in the board platform code,
or in the newemac driver or perhaps in some code common for 405EX.
Any thoughts on this welcome.
Thanks.
arch/powerpc/platforms/40x/kilauea.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/40x/kilauea.c b/arch/powerpc/platforms/40x/kilauea.c
index f9206a7..b5456cc 100644
--- a/arch/powerpc/platforms/40x/kilauea.c
+++ b/arch/powerpc/platforms/40x/kilauea.c
@@ -1,7 +1,7 @@
/*
* Kilauea board specific routines
*
- * Copyright 2007 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ * Copyright 2007-2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
*
* Based on the Walnut code by
* Josh Boyer <jwboyer@linux.vnet.ibm.com>
@@ -20,6 +20,8 @@
#include <asm/time.h>
#include <asm/uic.h>
#include <asm/pci-bridge.h>
+#include <asm/dcr.h>
+#include <asm/dcr-regs.h>
static __initdata struct of_device_id kilauea_of_bus[] = {
{ .compatible = "ibm,plb4", },
@@ -45,6 +47,13 @@ static int __init kilauea_probe(void)
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+ /*
+ * 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
+ * the internal loopback mode. Clear these bits so that both EMACs
+ * don't use loopback mode as deafult.
+ */
+ mtdcri(SDR0, SDR0_MFR, mfdcri(SDR0, SDR0_MFR) & ~0x0c000000);
+
return 1;
}
--
1.5.4.2
^ permalink raw reply related
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Jens Axboe @ 2008-02-22 7:40 UTC (permalink / raw)
To: Andrew Morton
Cc: Dhaval Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, KAMEZAWA Hiroyuki,
Balbir Singh
In-Reply-To: <20080221232418.b93db8d9.akpm@linux-foundation.org>
On Thu, Feb 21 2008, Andrew Morton wrote:
> On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
>
> > But I think the radix 'scan over entire tree' is a bit fragile.
>
> eek, it had better not be. Was this an error in the caller? Hope so.
The cfq use of it, not the radix tree code! It juggled the keys and
wants to make sure that we see all users, modulo raced added ones (ok if
we see them, doesn't matter if we don't).
> > This
> > patch adds a parallel hlist for ease of properly browsing the members,
>
> Even though io_contexts are fairly uncommon, adding more stuff to a data
> structure was a pretty sad alternative to fixing a bug in
> radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
>
> IOW: what exactly went wrong here??
I could not convince myself that the current code would always do the
right thing. We should not have been seeing ->key == NULL entries in
there, it implied a double exit of that process. So I decided to fix it
by making the code a lot more readable (the patch in question deleted a
lot more than it added), at the cost of that hlist head + node.
--
Jens Axboe
^ permalink raw reply
* Re: [BUG] Linux 2.6.25-rc2 - Regression from 2.6.24-rc1-git1 softlockup while bootup on powerpc
From: Andrew Morton @ 2008-02-22 7:24 UTC (permalink / raw)
To: Jens Axboe
Cc: Giani, Srivatsa Vaddagiri, Linux Kernel Mailing List,
linuxppc-dev, Ingo Molnar, Kamalesh Babulal, Dhaval,
KAMEZAWA Hiroyuki, Balbir Singh
In-Reply-To: <20080219083633.GN23197@kernel.dk>
On Tue, 19 Feb 2008 09:36:34 +0100 Jens Axboe <jens.axboe@oracle.com> wrote:
> But I think the radix 'scan over entire tree' is a bit fragile.
eek, it had better not be. Was this an error in the caller? Hope so.
> This
> patch adds a parallel hlist for ease of properly browsing the members,
Even though io_contexts are fairly uncommon, adding more stuff to a data
structure was a pretty sad alternative to fixing a bug in
radix_tree_gang_lookup(), or to fixing a bug in a caller of it.
IOW: what exactly went wrong here??
^ permalink raw reply
* [PATCH] Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver
From: Satoru Takeuchi @ 2008-02-22 7:10 UTC (permalink / raw)
To: ebs, linuxppc-dev, netdev
Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===================================================================
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:35.000000000 +0900
+++ 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig 2008-02-22 15:13:54.000000000 +0900
@@ -43,7 +43,7 @@ config IBM_NEW_EMAC_DEBUG
depends on IBM_NEW_EMAC
default n
-# The options below has to be select'ed by the respective
+# The options below has to be selected by the respective
# processor types or platforms
config IBM_NEW_EMAC_ZMII
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix L1 cache size in katmai DTS
From: Benjamin Herrenschmidt @ 2008-02-22 6:24 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203607297-15732-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 16:21 +0100, Stefan Roese wrote:
> This patch changes the katmai (440SPe) L1 cache size to 32k. Some
> whitespace issues are cleaned up too.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/boot/dts/katmai.dts | 58 +++++++++++++++++++-------------------
> 1 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/katmai.dts b/arch/powerpc/boot/dts/katmai.dts
> index 9bdfc0f..abf7f3e 100644
> --- a/arch/powerpc/boot/dts/katmai.dts
> +++ b/arch/powerpc/boot/dts/katmai.dts
> @@ -38,8 +38,8 @@
> timebase-frequency = <0>; /* Filled in by zImage */
> i-cache-line-size = <20>;
> d-cache-line-size = <20>;
> - i-cache-size = <20000>;
> - d-cache-size = <20000>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> dcr-controller;
> dcr-access-method = "native";
> };
> @@ -136,11 +136,11 @@
> };
>
> POB0: opb {
> - compatible = "ibm,opb-440spe", "ibm,opb-440gp", "ibm,opb";
> + compatible = "ibm,opb-440spe", "ibm,opb-440gp", "ibm,opb";
> #address-cells = <1>;
> #size-cells = <1>;
> - ranges = <00000000 4 e0000000 20000000>;
> - clock-frequency = <0>; /* Filled in by zImage */
> + ranges = <00000000 4 e0000000 20000000>;
> + clock-frequency = <0>; /* Filled in by zImage */
>
> EBC0: ebc {
> compatible = "ibm,ebc-440spe", "ibm,ebc-440gp", "ibm,ebc";
> @@ -153,38 +153,38 @@
> };
>
> UART0: serial@10000200 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000200 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000200 8>;
> virtual-reg = <a0000200>;
> - clock-frequency = <0>; /* Filled in by zImage */
> - current-speed = <1c200>;
> - interrupt-parent = <&UIC0>;
> - interrupts = <0 4>;
> - };
> + clock-frequency = <0>; /* Filled in by zImage */
> + current-speed = <1c200>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <0 4>;
> + };
>
> UART1: serial@10000300 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000300 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000300 8>;
> virtual-reg = <a0000300>;
> - clock-frequency = <0>;
> - current-speed = <0>;
> - interrupt-parent = <&UIC0>;
> - interrupts = <1 4>;
> - };
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC0>;
> + interrupts = <1 4>;
> + };
>
>
> UART2: serial@10000600 {
> - device_type = "serial";
> - compatible = "ns16550";
> - reg = <10000600 8>;
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <10000600 8>;
> virtual-reg = <a0000600>;
> - clock-frequency = <0>;
> - current-speed = <0>;
> - interrupt-parent = <&UIC1>;
> - interrupts = <5 4>;
> - };
> + clock-frequency = <0>;
> + current-speed = <0>;
> + interrupt-parent = <&UIC1>;
> + interrupts = <5 4>;
> + };
>
> IIC0: i2c@10000400 {
> device_type = "i2c";
^ permalink raw reply
* Re: [PATCH 2/5] [POWERPC] Add AMCC Canyonlands 460EX eval board support to platforms/44x
From: Benjamin Herrenschmidt @ 2008-02-22 6:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602446-11330-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 15:00 +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/platforms/44x/Kconfig | 18 ++++++++
> arch/powerpc/platforms/44x/Makefile | 1 +
> arch/powerpc/platforms/44x/canyonlands.c | 64 ++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/platforms/44x/canyonlands.c
>
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> index c062c4c..b56690c 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -67,6 +67,16 @@ config WARP
> See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
> Telephony Developers" link for more information.
>
> +config CANYONLANDS
> + bool "Canyonlands"
> + depends on 44x
> + default n
> + select 460EX
> + select PCI
> + select PPC4xx_PCI_EXPRESS
> + help
> + This option enables support for the AMCC PPC460EX evaluation board.
> +
> #config LUAN
> # bool "Luan"
> # depends on 44x
> @@ -122,6 +132,14 @@ config 440SPe
> select IBM_NEW_EMAC_EMAC4
> bool
>
> +config 460EX
> + bool
> + select PPC_FPU
> + select IBM_NEW_EMAC_EMAC4
> + select IBM_NEW_EMAC_RGMII
> + select IBM_NEW_EMAC_ZMII
> + select IBM_NEW_EMAC_TAH
> +
> # 44x errata/workaround config symbols, selected by the CPU models above
> config IBM440EP_ERR42
> bool
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> index 0864d4f..d70eb03 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_KATMAI) += katmai.o
> obj-$(CONFIG_RAINIER) += rainier.o
> obj-$(CONFIG_WARP) += warp.o
> obj-$(CONFIG_WARP) += warp-nand.o
> +obj-$(CONFIG_CANYONLANDS) += canyonlands.o
> diff --git a/arch/powerpc/platforms/44x/canyonlands.c b/arch/powerpc/platforms/44x/canyonlands.c
> new file mode 100644
> index 0000000..dac5b32
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/canyonlands.c
> @@ -0,0 +1,64 @@
> +/*
> + * Canyonlands board specific routines
> + *
> + * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
> + *
> + * Based on the Katmai code by
> + * Benjamin Herrenschmidt <benh@kernel.crashing.org>
> + * Copyright 2007 IBM Corp.
> + * Josh Boyer <jwboyer@linux.vnet.ibm.com>
> + * Copyright 2007 IBM Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/time.h>
> +#include <asm/uic.h>
> +#include <asm/pci-bridge.h>
> +
> +#include "44x.h"
> +
> +static __initdata struct of_device_id canyonlands_of_bus[] = {
> + { .compatible = "ibm,plb4", },
> + { .compatible = "ibm,opb", },
> + { .compatible = "ibm,ebc", },
> + {},
> +};
> +
> +static int __init canyonlands_device_probe(void)
> +{
> + of_platform_bus_probe(NULL, canyonlands_of_bus, NULL);
> +
> + return 0;
> +}
> +machine_device_initcall(canyonlands, canyonlands_device_probe);
> +
> +static int __init canyonlands_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (!of_flat_dt_is_compatible(root, "amcc,canyonlands"))
> + return 0;
> +
> + ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
> +
> + return 1;
> +}
> +
> +define_machine(canyonlands) {
> + .name = "Canyonlands",
> + .probe = canyonlands_probe,
> + .progress = udbg_progress,
> + .init_IRQ = uic_init_tree,
> + .get_irq = uic_get_irq,
> + .restart = ppc44x_reset_system,
> + .calibrate_decr = generic_calibrate_decr,
> +};
^ permalink raw reply
* Re: [PATCH 1/5] [POWERPC] Add AMCC 460EX/460GT support to cputable.c & cpu_setup_44x.S
From: Benjamin Herrenschmidt @ 2008-02-22 6:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203602435-11302-1-git-send-email-sr@denx.de>
On Thu, 2008-02-21 at 15:00 +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
Ack.
> ---
> arch/powerpc/kernel/cpu_setup_44x.S | 5 ++++-
> arch/powerpc/kernel/cputable.c | 28 +++++++++++++++++++++++++++-
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/cpu_setup_44x.S b/arch/powerpc/kernel/cpu_setup_44x.S
> index 6250443..5465e8d 100644
> --- a/arch/powerpc/kernel/cpu_setup_44x.S
> +++ b/arch/powerpc/kernel/cpu_setup_44x.S
> @@ -3,7 +3,7 @@
> * Valentine Barshak <vbarshak@ru.mvista.com>
> * MontaVista Software, Inc (c) 2007
> *
> - * Based on cpu_setup_6xx code by
> + * Based on cpu_setup_6xx code by
> * Benjamin Herrenschmidt <benh@kernel.crashing.org>
> *
> * This program is free software; you can redistribute it and/or
> @@ -32,6 +32,9 @@ _GLOBAL(__setup_cpu_440grx)
> bl __fixup_440A_mcheck
> mtlr r4
> blr
> +_GLOBAL(__setup_cpu_460ex)
> +_GLOBAL(__setup_cpu_460gt)
> + b __init_fpu_44x
> _GLOBAL(__setup_cpu_440gx)
> _GLOBAL(__setup_cpu_440spe)
> b __fixup_440A_mcheck
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 2a8f5cc..26ffb44 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -36,6 +36,8 @@ extern void __setup_cpu_440epx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440gx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440grx(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_440spe(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
> extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
> @@ -1397,6 +1399,30 @@ static struct cpu_spec __initdata cpu_specs[] = {
> .machine_check = machine_check_440A,
> .platform = "ppc440",
> },
> + { /* 460EX */
> + .pvr_mask = 0xffff0002,
> + .pvr_value = 0x13020002,
> + .cpu_name = "460EX",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + .cpu_setup = __setup_cpu_460ex,
> + .machine_check = machine_check_440A,
> + .platform = "ppc440",
> + },
> + { /* 460GT */
> + .pvr_mask = 0xffff0002,
> + .pvr_value = 0x13020000,
> + .cpu_name = "460GT",
> + .cpu_features = CPU_FTRS_44X,
> + .cpu_user_features = COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU,
> + .icache_bsize = 32,
> + .dcache_bsize = 32,
> + .cpu_setup = __setup_cpu_460gt,
> + .machine_check = machine_check_440A,
> + .platform = "ppc440",
> + },
> #endif /* CONFIG_44x */
> #ifdef CONFIG_FSL_BOOKE
> #ifdef CONFIG_E200
> @@ -1512,7 +1538,7 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
> *t = *s;
> *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
> #if defined(CONFIG_PPC64) || defined(CONFIG_BOOKE)
> - /* ppc64 and booke expect identify_cpu to also call
> + /* ppc64 and booke expect identify_cpu to also call
> * setup_cpu for that processor. I will consolidate
> * that at a later time, for now, just use #ifdef.
> * we also don't need to PTRRELOC the function pointer
^ permalink raw reply
* Re: [PATCH] Add support for binary includes.
From: Grant Likely @ 2008-02-22 6:05 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080220191941.GA2062@ld0162-tx32.am.freescale.net>
On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <scottwood@freescale.com> wrote:
> A property's data can be populated with a file's contents
> as follows:
>
> node {
> prop = /incbin/("path/to/data");
> };
>
> A subset of a file can be included by passing start and size parameters.
> For example, to include bytes 8 through 23:
>
> node {
> prop = /incbin/("path/to/data", 8, 16);
> };
Can I ask; what is the intended usage of such a thing? How large
would a typical binary blob be?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 3/5 v5] [POWERPC] Add Canyonlands DTS
From: Stefan Roese @ 2008-02-22 5:58 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
And now the I2C device-types are removed. Sorry for the mail-flood.
arch/powerpc/boot/dts/canyonlands.dts | 393 +++++++++++++++++++++++++++++++++
1 files changed, 393 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
new file mode 100644
index 0000000..2aee74c
--- /dev/null
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -0,0 +1,393 @@
+/*
+ * Device Tree Source for AMCC Canyonlands (460EX)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,canyonlands";
+ compatible = "amcc,canyonlands";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460EX";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460ex";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460ex";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460ex", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460ex", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <10>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460ex", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460ex", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@4ef60700 {
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460ex", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460ex", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-460ex", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-460ex", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <1>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460ex", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-2 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 2 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.2
^ permalink raw reply related
* [PATCH 3/5 v4] [POWERPC] Add Canyonlands DTS
From: Stefan Roese @ 2008-02-22 5:50 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Stefan Roese <sr@denx.de>
---
Changed MAL interrupt description as suggested by David Gibson.
arch/powerpc/boot/dts/canyonlands.dts | 395 +++++++++++++++++++++++++++++++++
1 files changed, 395 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/canyonlands.dts
diff --git a/arch/powerpc/boot/dts/canyonlands.dts b/arch/powerpc/boot/dts/canyonlands.dts
new file mode 100644
index 0000000..2aee74c
--- /dev/null
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -0,0 +1,395 @@
+/*
+ * Device Tree Source for AMCC Canyonlands (460EX)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,canyonlands";
+ compatible = "amcc,canyonlands";
+ dcr-parent = <&/cpus/cpu@0>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ ethernet1 = &EMAC1;
+ serial0 = &UART0;
+ serial1 = &UART1;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "PowerPC,460EX";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0e0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <a 4 b 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460ex","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0f0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <10 4 11 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460ex";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460ex";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460ex", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460ex", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
+ dcr-reg = <180 62>;
+ num-tx-chans = <2>;
+ num-rx-chans = <10>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-parent = <&UIC2>;
+ interrupts = < /*TXEOB*/ 6 4
+ /*RXEOB*/ 7 4
+ /*SERR*/ 3 4
+ /*TXDE*/ 4 4
+ /*RXDE*/ 5 4>;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-460ex", "ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <b0000000 4 b0000000 50000000>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-460ex", "ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ interrupts = <6 4>;
+ interrupt-parent = <&UIC1>;
+ };
+
+ UART0: serial@ef600300 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600300 8>;
+ virtual-reg = <ef600300>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1 4>;
+ };
+
+ UART1: serial@ef600400 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600400 8>;
+ virtual-reg = <ef600400>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC0>;
+ interrupts = <1 4>;
+ };
+
+ UART2: serial@ef600500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600500 8>;
+ virtual-reg = <ef600500>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1d 4>;
+ };
+
+ UART3: serial@ef600600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <ef600600 8>;
+ virtual-reg = <ef600600>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ current-speed = <0>; /* Filled in by U-Boot */
+ interrupt-parent = <&UIC1>;
+ interrupts = <1e 4>;
+ };
+
+ IIC0: i2c@4ef60700 {
+ device_type = "i2c";
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <ef600700 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <2 4>;
+ };
+
+ IIC1: i2c@ef600800 {
+ device_type = "i2c";
+ compatible = "ibm,iic-460ex", "ibm,iic";
+ reg = <ef600800 14>;
+ interrupt-parent = <&UIC0>;
+ interrupts = <3 4>;
+ };
+
+ ZMII0: emac-zmii@ef600d00 {
+ compatible = "ibm,zmii-460ex", "ibm,zmii";
+ reg = <ef600d00 c>;
+ };
+
+ RGMII0: emac-rgmii@ef601500 {
+ compatible = "ibm,rgmii-460ex", "ibm,rgmii";
+ reg = <ef601500 8>;
+ has-mdio;
+ };
+
+ EMAC0: ethernet@ef600e00 {
+ linux,network-index = <0>;
+ device_type = "network";
+ compatible = "ibm,emac-460ex", "ibm,emac4";
+ interrupt-parent = <&EMAC0>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 10 4
+ /*Wake*/ 1 &UIC2 14 4>;
+ reg = <ef600e00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+
+ EMAC1: ethernet@ef600f00 {
+ linux,network-index = <1>;
+ device_type = "network";
+ compatible = "ibm,emac-460ex", "ibm,emac4";
+ interrupt-parent = <&EMAC1>;
+ interrupts = <0 1>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = </*Status*/ 0 &UIC2 11 4
+ /*Wake*/ 1 &UIC2 15 4>;
+ reg = <ef600f00 70>;
+ local-mac-address = [000000000000]; /* Filled in by U-Boot */
+ mal-device = <&MAL0>;
+ mal-tx-channel = <1>;
+ mal-rx-channel = <8>;
+ cell-index = <1>;
+ max-frame-size = <2328>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rgmii";
+ phy-map = <00000000>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <1>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
+ has-inverted-stacr-oc;
+ has-new-stacr-staopc;
+ };
+ };
+
+ PCIX0: pci@c0ec00000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pcix-460ex", "ibm,plb-pcix";
+ primary;
+ large-inbound-windows;
+ enable-msi-hole;
+ reg = <c 0ec00000 8 /* Config space access */
+ 0 0 0 /* no IACK cycles */
+ c 0ed00000 4 /* Special cycles */
+ c 0ec80000 100 /* Internal registers */
+ c 0ec80100 fc>; /* Internal messaging registers */
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+ 01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 0 to 0x3f */
+ bus-range = <0 3f>;
+
+ /* All PCI interrupts are routed to ext IRQ 2 -> UIC1-2 */
+ interrupt-map-mask = <0000 0 0 0>;
+ interrupt-map = < 0000 0 0 0 &UIC1 2 8 >;
+ };
+
+ PCIE0: pciex@d00000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <0>; /* port number */
+ reg = <d 00000000 20000000 /* Config space access */
+ c 08010000 00001000>; /* Registers */
+ dcr-reg = <100 020>;
+ sdr-base = <300>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+ 01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 40 to 0x7f */
+ bus-range = <40 7f>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+ };
+
+ PCIE1: pciex@d20000000 {
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+ primary;
+ port = <1>; /* port number */
+ reg = <d 20000000 20000000 /* Config space access */
+ c 08011000 00001000>; /* Registers */
+ dcr-reg = <120 020>;
+ sdr-base = <340>;
+
+ /* Outbound ranges, one memory and one IO,
+ * later cannot be changed
+ */
+ ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+ 01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+ /* Inbound 2GB range starting at 0 */
+ dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+ /* This drives busses 80 to 0xbf */
+ bus-range = <80 bf>;
+
+ /* Legacy interrupts (note the weird polarity, the bridge seems
+ * to invert PCIe legacy interrupts).
+ * We are de-swizzling here because the numbers are actually for
+ * port of the root complex virtual P2P bridge. But I want
+ * to avoid putting a node for it in the tree, so the numbers
+ * below are basically de-swizzled numbers.
+ * The real slot is on idsel 0, so the swizzling is 1:1
+ */
+ interrupt-map-mask = <0000 0 0 7>;
+ interrupt-map = <
+ 0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+ 0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+ 0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+ 0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+ };
+ };
+};
--
1.5.4.2
^ permalink raw reply related
* Re: [PATCH] Add support for binary includes.
From: David Gibson @ 2008-02-22 5:34 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, jdl
In-Reply-To: <20080220191941.GA2062@ld0162-tx32.am.freescale.net>
On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote:
> A property's data can be populated with a file's contents
> as follows:
>
> node {
> prop = /incbin/("path/to/data");
> };
>
> A subset of a file can be included by passing start and size parameters.
> For example, to include bytes 8 through 23:
>
> node {
> prop = /incbin/("path/to/data", 8, 16);
> };
>
> As with /include/, non-absolute paths are looked for in the directory
> of the source file that includes them.
I still dislike the syntax, but haven't thought of a better one yet.
There are some issues with the implementation too, but I've been a bit
too busy with ePAPR stuff to review properly.
Soon, I hope.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
From: Benjamin Herrenschmidt @ 2008-02-22 3:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20080222032708.689FFDDE08@ozlabs.org>
On Fri, 2008-02-22 at 14:26 +1100, Benjamin Herrenschmidt wrote:
> The function cpu_thread_mask_to_cores() which returns a cpumask
> of one and only one thread enabled for a given core has a bug
> as it's shifting things in the wrong direction.
>
> Note: The implementation is still sub-optimal in the sense that
> for a given core, the thread set in the result may not be any of
> the threads set in the input, which can lead to more IPIs then
> strictly necessary, but it isn't incorrect per-se. I'll improve
> that later.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
Note that this function is, afaik, not used by anything in-tree at the
moment, so the bug isn't hurting anybody, but I'd rather have it
fixed anyway.
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] Fix thinko in cpu_thread_mask_to_cores()
From: Benjamin Herrenschmidt @ 2008-02-22 3:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
The function cpu_thread_mask_to_cores() which returns a cpumask
of one and only one thread enabled for a given core has a bug
as it's shifting things in the wrong direction.
Note: The implementation is still sub-optimal in the sense that
for a given core, the thread set in the result may not be any of
the threads set in the input, which can lead to more IPIs then
strictly necessary, but it isn't incorrect per-se. I'll improve
that later.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
include/asm-powerpc/cputhreads.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-work.orig/include/asm-powerpc/cputhreads.h 2008-02-22 14:22:34.000000000 +1100
+++ linux-work/include/asm-powerpc/cputhreads.h 2008-02-22 14:22:39.000000000 +1100
@@ -35,7 +35,7 @@ static inline cpumask_t cpu_thread_mask_
res = CPU_MASK_NONE;
for (i = 0; i < NR_CPUS; i += threads_per_core) {
- cpus_shift_right(tmp, threads_core_mask, i);
+ cpus_shift_left(tmp, threads_core_mask, i);
if (cpus_intersects(threads, tmp))
cpu_set(i, res);
}
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Peter Korsgaard @ 2008-02-22 1:52 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <87bq6993hg.fsf@macbook.be.48ers.dk>
On Fri, Feb 22, 2008 at 2:36 AM, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> Notice that I have a patch in the USB queue which fixes up the MPC834x
> symbol (PPC_MPC834x instead of MPC834x) so this patch won't apply.
Never mind, Greg fixed it.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 3/5 v3] [POWERPC] Add Canyonlands DTS
From: David Gibson @ 2008-02-22 1:48 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1203603768-13880-1-git-send-email-sr@denx.de>
On Thu, Feb 21, 2008 at 03:22:48PM +0100, Stefan Roese wrote:
> Signed-off-by: Stefan Roese <sr@denx.de>
[snip]
> + MAL0: mcmal {
> + compatible = "ibm,mcmal-460ex", "ibm,mcmal2";
> + dcr-reg = <180 62>;
> + num-tx-chans = <2>;
> + num-rx-chans = <10>;
> + interrupt-parent = <&MAL0>;
> + interrupts = <0 1 2 3 4>;
> + #interrupt-cells = <1>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + interrupt-map = </*TXEOB*/ 0 &UIC2 6 4
> + /*RXEOB*/ 1 &UIC2 7 4
> + /*SERR*/ 2 &UIC2 3 4
> + /*TXDE*/ 3 &UIC2 4 4
> + /*RXDE*/ 4 &UIC2 5 4>;
> + interrupt-map-mask = <ffffffff>;
Because all the MAL interrupts are on the same UIC, you don't need
this interrupt-map nonsense here - that's just a workaround for the
chips that have the MAL interrupts spread across different UICs. You
can just use:
interrupt-parent = <&UIC2>;
interrupts = <6 4 7 4 3 4 4 4 5 4>;
[snip]
> + IIC0: i2c@4ef60700 {
> + device_type = "i2c";
No device_type here.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [USB POWERPC] ehci-fsl: add PPC_MPC837x to default y
From: Peter Korsgaard @ 2008-02-22 1:36 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, linux-usb
In-Reply-To: <20080221203058.GA18624@localhost.localdomain>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Hi,
Anton> config USB_EHCI_FSL
Anton> - bool
Anton> - depends on USB_EHCI_HCD
Anton> + bool "Support for Freescale on-chip EHCI USB controller"
Anton> + depends on USB_EHCI_HCD && FSL_SOC
Anton> select USB_EHCI_ROOT_HUB_TT
Anton> - default y if MPC834x || PPC_MPC831x
Notice that I have a patch in the USB queue which fixes up the MPC834x
symbol (PPC_MPC834x instead of MPC834x) so this patch won't apply.
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
From: Michael Ellerman @ 2008-02-22 0:53 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev, Linas Vepstas, paulus
In-Reply-To: <47B90F55.2080606@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]
On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote:
> The following series of patches implement a basic framework
> for hypervisor-assisted dump. The very first patch provides
> documentation explaining what this is :-) . Yes, its supposed
> to be an improvement over kdump.
>
> A list of open issues / todo list is included in the documentation.
> It also appears that the not-yet-released firmware versions this was tested
> on are still, ahem, incomplete; this work is also pending.
>
> I have included most of the changes requested. Although, I did find
> one or two, fixed in a later patch file rather than the first location
> they appeared at.
This series still doesn't build on !CONFIG_RTAS configs:
http://kisskb.ellerman.id.au/kisskb/head/629/
This solution is to move early_init_dt_scan_phyp_dump() into
arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy
implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP
case.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox