The question about the QUICC ENGINE microcode for freescale
Couple of thoughts, is that according to Freescale specs, the QE can only support TWO 1000Mbit end points. And that is assuming RAW traffic, not protocol layer processing. Since the 8360E has two QUICC Engines, that is only 1000Mbits data per Engine. Are you intending to get 1000Mbits TX and RX on each engine? I think in reality you will be capped at 1000Mbit aggregate in the RX and TX. I could be wrong, but you might want to run that past a Freescale FAE, do you have the name of your contact for your area? This is assuming that you are running at the full speed of the MPC8360E, i.e both QUICC engines probably pushing 500Mhz. You'll also need to probably be running DDR2 RAM at MAX speed to achieve these rates, as each skbuf will have to be dma'd out to external memory. All the early dev boards by Freescale only used DDR1. As well you'll want to be sure your Coherent System Bus speed is as near max, i.e. 300-333Mhz. What clock speeds / Frequency of chip are you using to test this? As well which driver are you using with this test? As a HW designer for these boards and driver programmer I am just curious what your HW is looking / configured like? -Russ Hi,friends, I want to realize the high speed TCP package on GETH of MPC8360E,I would like the speed on both UCC1 and UCC2 for both send and receive TCP package(big package) up to 1000M bits/sec, so the total internet speed is 4000M bits/sec for MPC8360E. I tested the internet performance by IPERF test software with the condition that the core cpu deal with the TCP package,without microcode. I config the UCC2 down, config UCC1 to send package out to an server PC,no receive,the speed for UCC1 just only sending package is about 300M bits/sec, and CPU is 100% used. This speed is so slow, is too slow. If I send and recieve at the same time, the speed is much slower, if I make the UCC2 up, the speed is much slower and slower. I do not know how to incrase the internet speed for MPC8360E, somebody told me, we must use the microcode for QUICC ENGINE. My question is that where can I download the microcode for QUICC ENGINE and how to use it? Whether or not this microcode can help me to realize the 4000M bits/sec for TCP package? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [RFC/PATCH] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
On Mar 11, 2008, at 5:39 AM, Sebastian Siewior wrote:
The DT entry is copy / paste from the documentation.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 41 +
+
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 +
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts b/arch/powerpc/boot/
dts/mpc8544ds.dts
index 688af9d..fdaf793 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -116,6 +116,47 @@
};
};
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ cell-index = <0>;
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel",
+ "fsl,eloplus-dma-channel";
this should be mpc8544-dma everywhere.
- k
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
wait_event_interruptible does not wake_up
Can I ask you kernel gurus here for some advice? I am using Linux
2.4.25 on an Freescale MPC5200B IceCube development board.
I have some trouble waking a user process sent to sleep with
wait_event[_interruptible]. 99% of the time it works fine, but
sometimes when I call wake_up(), my user process does not wake up. I
can see whats happening by toggling LEDs on the board, and watching with
an oscilloscope.
<-- 50ms -->
__ _
|___| |___| LED1 (low active)
_ _ ___
|| || LED4 (low active)
^ user thread is finshed here, and goes back to sleep
^ user thread is woke up here
^ interrupt tasklet finishes here
^ interrupt tasklet starts here
With some testing and hair pulling, I have discovered exactly when (but
not why) this failure to wake_up happens. If I install a 10ms kernel
timer task, and the task occurs while my hardware interrupt service
tasklet is happening (I feel maybe exactly when it is calling wake_up
but not sure), that's when the wake_up always fails.
If I eliminate the asynchronous nature of the hardware interrupt, and
simulate the hardware interrupt by installing a 10ms kernel timer task,
using the task to toggling an I/O line that I jumper over to the
hardware interrupt input, then everything works great. The wake_up()
never fails with this synchronous configuration.
Anybody heard of such a thing? Any advice is very welcome. Here's more
details and code if you have a spare moment to read:
My very small user program is put to sleep by a driver with
wait_event_interruptable() when the user program calls device_write().
I want the user program to sleep until my hardware is ready. The
hardware will interrupt when ready, every 50ms or so. The hardware is a
64k word FIFO memory chip, and the interrupt is it's half-full flag
(latched with flip flop), but that doesn't matter.
When the driver recognizes the hardware interrupt, it should burst a
chunk of data out to the hardware FIFO, and then wake the user program.
The user program writes a new chunk of data to the driver, and gets
put to sleep again. The driver holds the data in kobuf, all ready in
preparation for the next hardware interrupt.
This all works perfectly well-- 99.99% of the time. But every once in a
while, the user process does not awake. My interrupt tasklet recognized
the interrupt, did call wake_up() for sure, but the process simply did
not wake up. Sometimes the process wakes up an arbitrary time later--
hundreds of milliseconds sometimes. The interrupt service tasklet
otherwise seems to be working reliably, as on the oscilloscope I can see
the effects of it clearing a hardware flip-flop perfectly every time,
and this is the call right before wake-up().
I copy below some of the code which may explain things better. Maybe my
error is obvious and dumb and if so, I am happy. Maybe my approach is
wrong?
Steve Kaiser
static u32 kobuf[FIFO_DEPTH][2];// output DAC buffer
static int wrq = 0; // user sleeps until hdw fifo is half empty
static DECLARE_WAIT_QUEUE_HEAD(WriteQ);
static void gpio_irq_handler (int, void*, struct pt_regs *);
static void gpio_tasklet_handler( unsigned long );
static DECLARE_TASKLET(gpio_tasklet,gpio_tasklet_handler,0);
/* --
device_open device_read device_ioctl
device_release device_writedevice_poll
-- */
static ssize_t device_write (struct file *filp,
const char *buff, // the user buffer to copy from
size_t count, // user requested nbytes
loff_t * f_pos) // offset in the file
{
size_t len = count;
// wait for interrupt to make room for data and wake us up
wrq = 1; wait_event_interruptible(WriteQ,!wrq);
// format of user buffer is uint[FIFO_DEPTH][2],
// where for MPC5200, sizeof(uint) = 4, or 8 bytes per element
if ( copy_from_user(kobuf,buff,len) )
return -EFAULT;
return len;
}
/* --
gpio_irq_handler: called on every gpio interrupt
-- */
static void gpio_irq_handler( int irq,
void *dev_id, struct pt_regs *regs )
{
struct mpc5xxx_gpio *pgpio = (struct mpc5xxx_gpio *)MPC5xxx_GPIO;
// check GPIO Simple Interrupt Status Register
if (pgpio->sint_istat & GSI2) {
// clear only GSI2 Status read-write-clear bit
// '=' instead oft '|=' to leave other bits unchanged
pgpio->sint_istat = GSI2;
// GSI2 Interrupt has occured. schedule some work
tasklet_schedule(&gpio_tasklet);
}
}
static void gpio_tasklet_handler( unsigned
RE: [PATCH] Ported Xilinx GPIO driver to OpenFirmware.
Thanks Magnus!
Generally speaking this looks reasonable. Some comments:
> struct xgpio_instance {
> struct list_head link;
> unsigned long base_phys;/* GPIO base address - physical
*/
> unsigned long remap_size;
> - u32 device_id;
> + u32 device_id; /* Dev ID for platform devices, 0 for OF
devices */
> + void *of_id;/* of_dev pointer for OF devices, NULL
for plat devices */
Why have separate ids? I don't think the of_dev needs to be kept around
here. This driver seems seems awkwardly written to have a local list of
all the devices, rather than simply attaching the xgpio_instance as the
private data of the file.
For instance, in drivers/char/xilinx_hwicap.c:
static ssize_t
hwicap_read(struct file *file, char __user *buf, size_t count, loff_t
*ppos)
{
struct hwicap_drvdata *drvdata = file->private_data;
and the drvdata is set in open:
static int hwicap_open(struct inode *inode, struct file *file)
{
struct hwicap_drvdata *drvdata;
int status;
drvdata = container_of(inode->i_cdev, struct hwicap_drvdata,
cdev);
...
file->private_data = drvdata;
Which would work if xgpio_instance directly contains the struct
miscdevice.
I think this is a much cleaner pattern (although it took me a while to
figure out the magic that makes it work... )
> +static struct of_device_id xgpio_of_match[] = {
> + {.compatible = "xlnx,xps-gpio-1.00.a"},
This should also probably contain the corresponding strings for the
following as well:
opb_gpio_v1_00_a
opb_gpio_v2_00_a
opb_gpio_v3_01_a
opb_gpio_v3_01_b
plb_gpio_v1_00_b
This would seem to be a relatively easy driver to clean up (by pulling
it all into one file and converting the other code to the kernel style)
and submit to mainline, if you're interested?
Steve
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[PATCH] Ported Xilinx GPIO driver to OpenFirmware.
From: Magnus Hjorth <[EMAIL PROTECTED]>
Added of_device structure and init code.
Basic functionality tested (LED:s on/off).
Added code to validate channel number in ioctl.
Signed-off-by: Magnus Hjorth <[EMAIL PROTECTED]>
---
Patch against Xilinx GIT tree (commit 7fb2b...)
Did this as a learning exercise. Hope it gets through Outlook in one piece :)
Cheers /Magnus
diff --git a/drivers/char/xilinx_gpio/adapter.c
b/drivers/char/xilinx_gpio/adapter.c
index ecd2897..6fdf7aa 100644
--- a/drivers/char/xilinx_gpio/adapter.c
+++ b/drivers/char/xilinx_gpio/adapter.c
@@ -43,15 +43,22 @@
#include
#include
+#ifdef CONFIG_OF
+// For open firmware.
+#include
+#include
+#endif
+
#define BUFSIZE200
#define MIN(x,y) (x < y ? x : y)
-
struct xgpio_instance {
struct list_head link;
unsigned long base_phys;/* GPIO base address - physical */
unsigned long remap_size;
- u32 device_id;
+ u32 device_id; /* Dev ID for platform devices, 0 for OF
devices */
+ void *of_id;/* of_dev pointer for OF devices, NULL for plat
devices */
+ int is_dual;
wait_queue_head_t wait;
unsigned int head, tail, count;
__u64 buf[BUFSIZE]; /* 32xChan1, 32xChan2 */
@@ -125,8 +132,7 @@ static struct xgpio_instance *xgpio_getinst(unsigned int
minor)
up_read(&inst_list_sem);
if (XGpio_IsReady(&inst->gpio)) {
return inst;
- }
- else {
+ } else {
return NULL;
}
}
@@ -147,6 +153,10 @@ static int xgpio_ioctl(struct inode *inode, struct file
*file,
if (copy_from_user(&ioctl_data, (void *) arg, sizeof(ioctl_data)))
return -EFAULT;
+ /* Validate channel number */
+ if (ioctl_data.chan != 1 && (ioctl_data.chan != 2 || !inst->is_dual))
+ return -EINVAL;
+
switch (cmd) {
case XGPIO_IN:
/*
@@ -216,6 +226,7 @@ static int xgpio_ioctl(struct inode *inode, struct file
*file,
return -ENOIOCTLCMD;
}
+
return 0;
}
@@ -237,7 +248,6 @@ static unsigned int prev(unsigned int ptr)
return ptr;
}
-
static ssize_t xgpio_read(struct file *file, char *buf,
size_t count, loff_t * ppos)
{
@@ -278,7 +288,6 @@ static ssize_t xgpio_read(struct file *file, char *buf,
return 0;
}
-
static irqreturn_t xgpio_interrupt(int irq, void *dev_id)
{
struct xgpio_instance *inst = dev_id;
@@ -287,7 +296,6 @@ static irqreturn_t xgpio_interrupt(int irq, void *dev_id)
inst->gpio.IsDual ? XIo_In32(inst->gpio.BaseAddress + 0x08) : 0;
__u32 int_status = XIo_In32(inst->gpio.BaseAddress + 0x120);
-
if (inst->buf[prev(inst->tail)] !=
(((__u64) val_1) | ((__u64) (val_2) << 32)))
if (next(inst->tail) != inst->head) {
@@ -303,7 +311,6 @@ static irqreturn_t xgpio_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
}
-
/*
* We get to all of the GPIOs through one minor number. Here's the
* miscdevice that gets registered for that minor number.
@@ -335,45 +342,33 @@ char *names[] = {
static int minor = XGPIO_MINOR;
-static int xgpio_probe(struct device *dev)
+static int xgpio_probe_main(struct device *dev, int dev_id, void *of_dev_id,
+ int is_dual,
+ struct resource *irq_res, struct resource *regs_res)
{
XGpio_Config xgpio_config;
struct xgpio_instance *xgpio_inst;
struct miscdevice *miscdev = 0;
- struct platform_device *pdev = to_platform_device(dev);
- struct resource *irq_res, *regs_res;
void *v_addr;
int retval;
- if (!dev)
- return -EINVAL;
-
memset(&xgpio_config, 0, sizeof(XGpio_Config));
xgpio_inst = kmalloc(sizeof(struct xgpio_instance), GFP_KERNEL);
if (!xgpio_inst) {
printk(KERN_ERR
"%s #%d: Couldn't allocate device private record\n",
- miscdev->name, pdev->id);
+ miscdev->name, dev_id);
return -ENOMEM;
}
memset(xgpio_inst, 0, sizeof(struct xgpio_instance));
- /* Map the control registers in */
- regs_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!regs_res || (regs_res->end - regs_res->start + 1 < 8)) {
- printk(KERN_ERR "%s #%d: Couldn't get registers resource\n",
- miscdev->name, pdev->id);
- retval = -EFAULT;
- goto failed1;
- }
-
xgpio_inst->remap_size = regs_res->end - regs_res->start + 1;
if (!request_mem_region(regs_res->start, xgpio_inst->remap_size,
DRIVER_NAME)) {
Re: issue about CONFIG_PPC_MMU and CONFIG_SMP define
On Mar 10, 2008, at 3:15 PM, jie han wrote: Hi guys, I want to simulate compile mutli-core using sequoia(IBM/AMCC 44x processor) source code under kernel arch/powerpc directory.I want to define CONFIG_SMP, I sould define CONFIG_STD_MMU at first,but AMCC 44x don't need to config CONFIG_STD_MMU.Is CONFIG_STD_MMU just for freescale chip? How can I do next? Thanks ahead for your help, STD_MMU is for all powerpc cpus with a non-BookE MMU. That includes all the 64-bit parts from IBM to date, pasemi's parts, and 32-bit parts from IBM & Freescale like the 6xx, 7xx, 7xxx, e600 e300, etc. You cannot set this for 44x, because it is a BookE part. BTW, there's no real relationship between STD_MMU and SMP. It was just a convenient way to restrict the SMP config option in the kernel, since all the Linux configs that currently support SMP are STD_MMU. We will have BookE configs in the future that do support SMP, at which point arch/powerpc/platforms/Kconfig.cputype will be changed to allow SMP to be set for those configs. You can't enable SMP on 44x right now. It's not supported. Cheers, B ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: bootstrap loader + gzip 1.3.5 --> huge image!?
I just recognized that gzip does his job right. But objcopy of all binutils > 2.16.1 has problems during binary copy: powerpc-linux-objcopy -O binary vmlinux arch/ppc/boot/images/vmlinux.bin The vmlinux file does look good (what i can see with vi) but the generated vmlinux.bin file is strange. Windows machines say that the vmlinux.bin file is > then 3GByte, but linux says 1,5Mbyte. But, I can't open it with vi... Anywhay i think binutils > 2.16.1 has some problems with ppc. Does anyone else use buildroot for ppc405 platform and solved the problems with actual binutils versions? cheers! robert Robert Zach wrote: hi list! I am using the xilinx git tree with the included bootstrap loader. Everthing works fine when i use binutils-2.16.1-gcc-3.4.6-uClibc-0.9.29. But when useing binutils-2.18.50-gcc-4.2.0-uClibc-0.9.29 (generated with buildroot) i get the following problem: At the end of the kernel build process the vmlinux image gets compressed (for the bootstrap loader). something like: gzip -f -9 < arch/ppc/boot/images/vmlinux.bin > arch/ppc/boot/images/vmlinux.gz.$$ when i compiled the kernel with binutils-2.16.1-gcc-3.4.6-uClibc-0.9.29 the resulting image size is smaller then the original and everything works (the bootstrap loader uncompresses, the kernel boots, ..) But when using the binutils-2.18.50-gcc-4.2.0-uClibc-0.9.29 cross-toolchain i get the following: du arch/ppc/boot/images/vmlinux.bin 1264arch/ppc/boot/images/vmlinux.bin gzip -f -9 < arch/ppc/boot/images/vmlinux.bin > arch/ppc/boot/images/vmlinux.gz.$$ du arch/ppc/boot/images/vmlinux.gz.$$ 3640arch/ppc/boot/images/vmlinux.gz The resulting huge zImage.elf file does not work (the bootstraploader stops somewhere early). Its the same for all other toolchains i tryed using binutils > 2.16. what does gzip do? I use the following version gzip --version gzip 1.3.5 (2002-09-30) Copyright 2002 Free Software Foundation Copyright 1992-1993 Jean-loup Gailly Does anybody know this problem? any suggestions for a solution. thanks in advanced! greets! robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
bootstrap loader + gzip 1.3.5 --> huge image!?
hi list! I am using the xilinx git tree with the included bootstrap loader. Everthing works fine when i use binutils-2.16.1-gcc-3.4.6-uClibc-0.9.29. But when useing binutils-2.18.50-gcc-4.2.0-uClibc-0.9.29 (generated with buildroot) i get the following problem: At the end of the kernel build process the vmlinux image gets compressed (for the bootstrap loader). something like: gzip -f -9 < arch/ppc/boot/images/vmlinux.bin > arch/ppc/boot/images/vmlinux.gz.$$ when i compiled the kernel with binutils-2.16.1-gcc-3.4.6-uClibc-0.9.29 the resulting image size is smaller then the original and everything works (the bootstrap loader uncompresses, the kernel boots, ..) But when using the binutils-2.18.50-gcc-4.2.0-uClibc-0.9.29 cross-toolchain i get the following: du arch/ppc/boot/images/vmlinux.bin 1264arch/ppc/boot/images/vmlinux.bin gzip -f -9 < arch/ppc/boot/images/vmlinux.bin > arch/ppc/boot/images/vmlinux.gz.$$ du arch/ppc/boot/images/vmlinux.gz.$$ 3640arch/ppc/boot/images/vmlinux.gz The resulting huge zImage.elf file does not work (the bootstraploader stops somewhere early). Its the same for all other toolchains i tryed using binutils > 2.16. what does gzip do? I use the following version gzip --version gzip 1.3.5 (2002-09-30) Copyright 2002 Free Software Foundation Copyright 1992-1993 Jean-loup Gailly Does anybody know this problem? any suggestions for a solution. thanks in advanced! greets! robert ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Interrupt routing ARCH=ppc
Hi All, I am working on porting Linux 2.6.16.60 on PowerPC based board with Tsi109 system controller. Our platform support is defined in arch/ppc Here is our hardware interrupt routing Tsi109 PCI BUS (BUS 0) | | V VME controller (BUS 0 IDSEL 16) IRQ 36 PMC Slot(BUS 0 IDSEL 17) IRQ 37 PCI-PCI Bridge (BUS 0 IDSEL 18) No IRQ required | (BUS 1)| |--->PMC Slot (BUS 1 IDSEL 19) IRQ 38 USB Contr(BUS 1 IDSEL 20) IRQ 39 I faced a problem at map_irq. Due to pci_swizzle, PCI probe is always returning p2p bridge IDSEL for all device on BUS 1. In our case, we routed independent interrupt lines for the devices on BUS 1. I made a quick workaround by assigning IRQ's based on dev->devfn. Is there any standard way of assigning independent interrupts for the devices connected below P2P bridge? I am facing problem with on-board USB controller. Even though /proc/interrupts shows correct assignment. USB is always returning the following message usb 2-1: new low speed USB device using ohci_hcd and address 2 ohci_hcd :01:04.0: Unlink after no-IRQ? Controller is probably using the wrong IRQ If the interrupts are not assigned properly, how the above message pop-up soon after inserting USB device? Here is the proc entry # cat /proc/interrupts CPU0 12:105 tsi108_pic Level serial 38: 4270 tsi108_PCI_int Level eth0 39: 1 tsi108_PCI_int Level ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd :usb3 Whereas USB PMC on BUS 0 works fine. I request you to provide some pointers on the same. Thanks a lot, Suresh ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
I2C device node on Sequoia (440EPx)
Hi I am using an AMCC 440EPx processor on "Sequoia" board with Linux 2.6.21 rc4. I am trying to use the i2c in the user-space In my Linux config file (Sequoia default) I have: CONFIG_I2C=y CONFIG_I2C_CHARDEV=y I than added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0) When I run a simple program to open the device (provided by the "dev-interface" file of i2c kernel documentation) it returns errno message: "No such device". I have tried to use the device number 1, 2, 3, 4 but with no luck. Any suggestions what I might be doing wrong? Best Regards Marko ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[RFC/PATCH] [POWER] mpc85xx_ds add DMA engine to the DT and parse it.
The DT entry is copy / paste from the documentation.
Signed-off-by: Sebastian Siewior <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8544ds.dts | 41 ++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 13 +
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index 688af9d..fdaf793 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -116,6 +116,47 @@
};
};
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
+ reg = <21300 4>;
+ ranges = <0 21100 200>;
+ cell-index = <0>;
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <0 80>;
+ cell-index = <0>;
+ interrupt-parent = <&mpic>;
+ interrupts = <14 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <80 80>;
+ cell-index = <1>;
+ interrupt-parent = <&mpic>;
+ interrupts = <15 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <100 80>;
+ cell-index = <2>;
+ interrupt-parent = <&mpic>;
+ interrupts = <16 2>;
+ };
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8540-dma-channel",
+ "fsl,eloplus-dma-channel";
+ reg = <180 80>;
+ cell-index = <3>;
+ interrupt-parent = <&mpic>;
+ interrupts = <17 2>;
+ };
+ };
+
enet0: [EMAIL PROTECTED] {
cell-index = <0>;
device_type = "network";
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
index bdb3d0b..b9a3094 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -183,6 +184,18 @@ static int __init mpc8544_ds_probe(void)
}
}
+static struct of_device_id mpc85xxds_ids[] = {
+ { .type = "soc", },
+ { .compatible = "soc", },
+ {},
+};
+
+static int __init mpc85xxds_publish_devices(void)
+{
+ return of_platform_bus_probe(NULL, mpc85xxds_ids, NULL);
+}
+machine_device_initcall(mpc8544_ds, mpc85xxds_publish_devices);
+
/*
* Called very early, device-tree isn't unflattened
*/
--
1.5.4.3
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
