* Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
From: Sachin Sant @ 2009-06-20 7:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel
In-Reply-To: <1245450580.16880.12.camel@pasglop>
Benjamin Herrenschmidt wrote:
> That is strange. If I revert that commit, I get breakages on machines
> here. It would be interesting to understand what the problem is here,
> as we -do- use that kmem cache for allocating page tables, so we do
> need it initialized that early. (IE, we can't allow vmalloc for example
> to be called before the page table caches are initialized).
>
> This will need more debugging and understanding as to why it hangs.
>
Hi Ben,
Looks like the control enters pgtable_cache_init but rever returns. The
machine just hangs. I triggered a system reset via HMC to see what's
happening on the cpu. Here is the xmon o/p after a system reset.
The code that was executed was __mutex_lock_slowpath..
cpu 0x0: Vector: 100 (System Reset) at [c000000000b138e0]
pc: c00000000060a4b8: .__mutex_lock_slowpath+0x9c/0x1f4
lr: c00000000060abc8: .mutex_lock+0x50/0x70
sp: c000000000b13b60
msr: 8000000000081032
current = 0xc000000000a3ab70
paca = 0xc000000000be2400
pid = 0, comm = swapper
enter ? for help
[c000000000b13c30] c00000000060abc8 .mutex_lock+0x50/0x70
[c000000000b13cb0] c00000000008c7f0 .get_online_cpus+0x4c/0x84
[c000000000b13d40] c00000000014a120 .kmem_cache_create+0xcc/0x5f4
[c000000000b13e50] c000000000033f38 .pgtable_cache_init+0x28/0x78
[c000000000b13ee0] c0000000008809a4 .start_kernel+0x1f8/0x568
[c000000000b13f90] c0000000000083d8 .start_here_common+0x1c/0x44
0:mon>
0:mon> di $.__mutex_lock_slowpath
c00000000060a41c fba1ffe8 std r29,-24(r1)
c00000000060a420 7c0802a6 mflr r0
.... SNIP .....
c00000000060a46c 7fe4fb78 mr r4,r31
c00000000060a470 419e0014 beq cr7,c00000000060a484 # .__mutex_lock_slowpath+0x68/0x1f4
c00000000060a474 4ba6859d bl c000000000072a10 # .mutex_spin_on_owner+0x0/0xbc
c00000000060a478 60000000 nop
c00000000060a47c 2fa30000 cmpdi cr7,r3,0
c00000000060a480 419e0078 beq cr7,c00000000060a4f8 # .__mutex_lock_slowpath+0xdc/0x1f4
c00000000060a484 93010070 stw r24,112(r1)
c00000000060a488 93210074 stw r25,116(r1)
c00000000060a48c 81210070 lwz r9,112(r1)
c00000000060a490 80010074 lwz r0,116(r1)
c00000000060a494 7d2907b4 extsw r9,r9
c00000000060a498 7c0007b4 extsw r0,r0
0:mon>
c00000000060a49c 7c2004ac lwsync
c00000000060a4a0 7d60e828 lwarx r11,0,r29
c00000000060a4a4 7c0b4800 cmpw r11,r9
c00000000060a4a8 40c20010 bne- c00000000060a4b8 # .__mutex_lock_slowpath+0x9c/0x1f4
c00000000060a4ac 7c00e92d stwcx. r0,0,r29
c00000000060a4b0 40c2fff0 bne- c00000000060a4a0 # .__mutex_lock_slowpath+0x84/0x1f4
c00000000060a4b4 4c00012c isync
c00000000060a4b8 2f8b0001 cmpwi cr7,r11,1
^^^^^ PC points to this instruction ^^^^^^^^
c00000000060a4bc 2f3f0000 cmpdi cr6,r31,0
c00000000060a4c0 409e0010 bne cr7,c00000000060a4d0 # .__mutex_lock_slowpath+0xb4/0x1f4
c00000000060a4c4 78200464 rldicr r0,r1,0,49
c00000000060a4c8 f81d0030 std r0,48(r29)
c00000000060a4cc 48000118 b c00000000060a5e4 # .__mutex_lock_slowpath+0x1c8/0x1f4
c00000000060a4d0 409a001c bne cr6,c00000000060a4ec # .__mutex_lock_slowpath+0xd0/0x1f4
c00000000060a4d4 e81b0000 ld r0,0(r27)
c00000000060a4d8 7809f7e3 rldicl. r9,r0,62,63
0:mon> r
R00 = 0000000000000000 R16 = 0000000002bc4b68
R01 = c000000000b13b60 R17 = 0000000000000000
R02 = c000000000b0bca0 R18 = c0000000008c4b68
R03 = c000000000d07fd0 R19 = 0000000001b1fc90
R04 = 0000000000000000 R20 = 00000000000000b8
R05 = 000000000000005e R21 = c0000000007ec008
R06 = 0000000000040000 R22 = 00000000007c28bb
R07 = c000000000a95288 R23 = c0000000007cbdd5
R08 = 0000000000000000 R24 = 0000000000000001
R09 = 0000000000000001 R25 = 0000000000000000
R10 = 0000000000000000 R26 = c000000000d08000
R11 = 00000000ffffffff R27 = c000000000b10080
R12 = 0000000024000082 R28 = c000000000a3ab70
R13 = c000000000be2400 R29 = c000000000d07fd0
R14 = c0000000008c4c30 R30 = c000000000a75be8
R15 = c000000000a95288 R31 = 0000000000000000
pc = c00000000060a4b8 .__mutex_lock_slowpath+0x9c/0x1f4
lr = c00000000060abc8 .mutex_lock+0x50/0x70
msr = 8000000000081032 cr = 84000022
ctr = 0000000000136f8c xer = 0000000000000001 trap = 100
0:mon>
Let me know if i can provide more information.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH] powerpc: warp platform fix for i2c change
From: Sean MacLennan @ 2009-06-20 5:43 UTC (permalink / raw)
To: linuxppc-dev, ben-linux, Josh Boyer
A change to the i2c subsystem breaks the warp platform code. The patch
is cleaner anyway, the old way was a bit crufty.
For those with keen eyes, the gratuitous change in the string from
PIKA to Warp is just so the logs look a bit nicer. The following two
lines tend to be printed one after another.
Warp POST OK
Warp DTM thread running.
Yeah, this will be the third patch to warp.c submitted in this
release....
Cheers,
Sean
The i2c_client struct changed, breaking the code that looked for the ad7414
chip. Use the new of_find_i2c_device_by_node function added in 2.6.29.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 42e09a9..0362c88 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -16,6 +16,7 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/of_gpio.h>
+#include <linux/of_i2c.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -65,7 +66,6 @@ define_machine(warp) {
static u32 post_info;
-/* I am not sure this is the best place for this... */
static int __init warp_post_info(void)
{
struct device_node *np;
@@ -194,9 +194,9 @@ static int pika_setup_leds(void)
return 0;
}
-static void pika_setup_critical_temp(struct i2c_client *client)
+static void pika_setup_critical_temp(struct device_node *np,
+ struct i2c_client *client)
{
- struct device_node *np;
int irq, rc;
/* Do this before enabling critical temp interrupt since we
@@ -208,14 +208,7 @@ static void pika_setup_critical_temp(struct i2c_client *client)
i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
i2c_smbus_write_byte_data(client, 3, 0); /* Tlow */
- np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
- if (np == NULL) {
- printk(KERN_ERR __FILE__ ": Unable to find ad7414\n");
- return;
- }
-
irq = irq_of_parse_and_map(np, 0);
- of_node_put(np);
if (irq == NO_IRQ) {
printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
return;
@@ -244,32 +237,24 @@ static inline void pika_dtm_check_fan(void __iomem *fpga)
static int pika_dtm_thread(void __iomem *fpga)
{
- struct i2c_adapter *adap;
+ struct device_node *np;
struct i2c_client *client;
- /* We loop in case either driver was compiled as a module and
- * has not been insmoded yet.
- */
- while (!(adap = i2c_get_adapter(0))) {
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(HZ);
- }
-
- while (1) {
- list_for_each_entry(client, &adap->clients, list)
- if (client->addr == 0x4a)
- goto found_it;
+ np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
+ if (np == NULL)
+ return -ENOENT;
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(HZ);
+ client = of_find_i2c_device_by_node(np);
+ if (client == NULL) {
+ of_node_put(np);
+ return -ENOENT;
}
-found_it:
- pika_setup_critical_temp(client);
+ pika_setup_critical_temp(np, client);
- i2c_put_adapter(adap);
+ of_node_put(np);
- printk(KERN_INFO "PIKA DTM thread running.\n");
+ printk(KERN_INFO "Warp DTM thread running.\n");
while (!kthread_should_stop()) {
int val;
@@ -291,7 +276,6 @@ found_it:
return 0;
}
-
static int __init pika_dtm_start(void)
{
struct task_struct *dtm_thread;
^ permalink raw reply related
* Re: [PATCH] of_serial: Add UPF_FIXED_TYPE flag
From: Benjamin Herrenschmidt @ 2009-06-19 22:59 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Dave Mitchell, arnd
In-Reply-To: <1245399861.10629.194.camel@concordia>
On Fri, 2009-06-19 at 18:24 +1000, Michael Ellerman wrote:
> I think we /probably/ want a similar change in legacy_serial.c, for
> soc
> ports at least.
>
> Or do people have things that are compatible "ns16550" but aren't?
>
Do we really want to keep of_serial.c ?
I fail to see the point in keeping -both- the of_serial (of_device
variant) and the legacy serial stuff which shims the device-tree into
platform devices.
They tend to clash with each other too, which is annoying.
Cheers,
Ben
^ permalink raw reply
* Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
From: Benjamin Herrenschmidt @ 2009-06-19 22:29 UTC (permalink / raw)
To: Sachin Sant; +Cc: linuxppc-dev, Pekka Enberg, linux-kernel
In-Reply-To: <4A3BC57B.8000408@in.ibm.com>
On Fri, 2009-06-19 at 22:36 +0530, Sachin Sant wrote:
> The offending commit seems to be
> c868d550115b9ccc0027c67265b9520790f05601.
> mm: Move pgtable_cache_init() earlier
>
> If i revert this commit, the machine boots fine.
That is strange. If I revert that commit, I get breakages on machines
here. It would be interesting to understand what the problem is here,
as we -do- use that kmem cache for allocating page tables, so we do
need it initialized that early. (IE, we can't allow vmalloc for example
to be called before the page table caches are initialized).
This will need more debugging and understanding as to why it hangs.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/amigaone: Limit ISA I/O range to 4k in the device tree
From: Gerhard Pircher @ 2009-06-19 21:42 UTC (permalink / raw)
To: linuxppc-dev list
The kernel reserves the I/O address space from 0x0 to 0xfff for legacy
ISA devices. Change the ranges property for the PCI2ISA bridge to match
the kernels behavior, even if the ranges property isn't used for now.
Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
---
arch/powerpc/boot/dts/amigaone.dts | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/amigaone.dts b/arch/powerpc/boot/dts/amigaone.dts
index 26549fc..49ac36b 100644
--- a/arch/powerpc/boot/dts/amigaone.dts
+++ b/arch/powerpc/boot/dts/amigaone.dts
@@ -70,8 +70,8 @@
devsel-speed = <0x00000001>;
min-grant = <0>;
max-latency = <0>;
- /* First 64k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
- ranges = <0x00000001 0 0x01000000 0 0x00000000 0x00010000>;
+ /* First 4k for I/O at 0x0 on PCI mapped to 0x0 on ISA. */
+ ranges = <0x00000001 0 0x01000000 0 0x00000000 0x00001000>;
interrupt-parent = <&i8259>;
#interrupt-cells = <2>;
#address-cells = <2>;
--
1.5.6.5
--
GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss
für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
^ permalink raw reply related
* [PATCH] powerpc/amigaone: Convert amigaone_init() to a machine_device_initcall()
From: Gerhard Pircher @ 2009-06-19 21:40 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev
This allows to remove the ppc_md.init() hook in the setup code.
Signed-off-by: Gerhard Pircher <gerhard_pircher@gmx.net>
---
arch/powerpc/platforms/amigaone/setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/amigaone/setup.c b/arch/powerpc/platforms/amigaone/setup.c
index e8bea5e..ca65d86 100644
--- a/arch/powerpc/platforms/amigaone/setup.c
+++ b/arch/powerpc/platforms/amigaone/setup.c
@@ -111,13 +111,16 @@ void __init amigaone_init_IRQ(void)
irq_set_default_host(i8259_get_host());
}
-void __init amigaone_init(void)
+static int __init request_isa_regions(void)
{
request_region(0x00, 0x20, "dma1");
request_region(0x40, 0x20, "timer");
request_region(0x80, 0x10, "dma page reg");
request_region(0xc0, 0x20, "dma2");
+
+ return 0;
}
+machine_device_initcall(amigaone, request_isa_regions);
void amigaone_restart(char *cmd)
{
@@ -162,7 +165,6 @@ define_machine(amigaone) {
.name = "AmigaOne",
.probe = amigaone_probe,
.setup_arch = amigaone_setup_arch,
- .init = amigaone_init,
.show_cpuinfo = amigaone_show_cpuinfo,
.init_IRQ = amigaone_init_IRQ,
.restart = amigaone_restart,
--
1.5.6.5
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply related
* [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Ira Snyder @ 2009-06-19 19:31 UTC (permalink / raw)
To: linuxppc-dev, Dan Williams, Li Yang, Kumar Gala
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some controller-specific features such as
external start and external pause for a DMA transaction.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
This patch depends on the "fsldma: split apart external pause and
request count features" patch.
After discussion with Dan Williams, this is the third version of the
DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
with both drivers I have written against this API, an FPGA programmer
and an FPGA data grabber.
Kumar, Dan asked me to add you to the CC list, so you can have a look at
this patch before he adds it to his tree.
The other two small patches I posted earlier are very helpful in testing
this functionality. They make the fsldma driver leave the BWC (bandwidth
control) bits alone on the 83xx controller, as well as making the
external start feature available on 83xx.
v2 -> v3:
* add support for setting DMA request count
v1 -> v2:
* move fsldma.h from include/linux to arch/powerpc/include/asm
* add kerneldoc documentation
arch/powerpc/include/asm/fsldma.h | 136 ++++++++++++++++++++++
drivers/dma/fsldma.c | 227 +++++++++++++++++++++++++++++++++++++
2 files changed, 363 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
diff --git a/arch/powerpc/include/asm/fsldma.h b/arch/powerpc/include/asm/fsldma.h
new file mode 100644
index 0000000..a67aeed
--- /dev/null
+++ b/arch/powerpc/include/asm/fsldma.h
@@ -0,0 +1,136 @@
+/*
+ * Freescale MPC83XX / MPC85XX DMA Controller
+ *
+ * Copyright (c) 2009 Ira W. Snyder <iws@ovro.caltech.edu>
+ *
+ * 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.
+ */
+
+#ifndef __ARCH_POWERPC_ASM_FSLDMA_H__
+#define __ARCH_POWERPC_ASM_FSLDMA_H__
+
+#include <linux/dmaengine.h>
+
+/*
+ * Definitions for the Freescale DMA controller's DMA_SLAVE implemention
+ *
+ * The Freescale DMA_SLAVE implementation was designed to handle many-to-many
+ * transfers. An example usage would be an accelerated copy between two
+ * scatterlists. Another example use would be an accelerated copy from
+ * multiple non-contiguous device buffers into a single scatterlist.
+ *
+ * A DMA_SLAVE transaction is defined by a struct fsl_dma_slave. This
+ * structure contains a list of hardware addresses that should be copied
+ * to/from the scatterlist passed into device_prep_slave_sg(). The structure
+ * also has some fields to enable hardware-specific features.
+ */
+
+/**
+ * struct fsl_dma_hw_addr
+ * @entry: linked list entry
+ * @address: the hardware address
+ * @length: length to transfer
+ *
+ * Holds a single physical hardware address / length pair for use
+ * with the DMAEngine DMA_SLAVE API.
+ */
+struct fsl_dma_hw_addr {
+ struct list_head entry;
+
+ dma_addr_t address;
+ size_t length;
+};
+
+/**
+ * struct fsl_dma_slave
+ * @addresses: a linked list of struct fsl_dma_hw_addr structures
+ * @request_count: value for DMA request count
+ * @src_loop_size: setup and enable constant source-address DMA transfers
+ * @dst_loop_size: setup and enable constant destination address DMA transfers
+ * @external_start: enable externally started DMA transfers
+ * @external_pause: enable externally paused DMA transfers
+ *
+ * Holds a list of address / length pairs for use with the DMAEngine
+ * DMA_SLAVE API implementation for the Freescale DMA controller.
+ */
+struct fsl_dma_slave {
+
+ /* List of hardware address/length pairs */
+ struct list_head addresses;
+
+ /* Support for extra controller features */
+ unsigned int request_count;
+ unsigned int src_loop_size;
+ unsigned int dst_loop_size;
+ bool external_start;
+ bool external_pause;
+};
+
+/**
+ * fsl_dma_slave_append - add an address/length pair to a struct fsl_dma_slave
+ * @slave: the &struct fsl_dma_slave to add to
+ * @address: the hardware address to add
+ * @length: the length of bytes to transfer from @address
+ *
+ * Add a hardware address/length pair to a struct fsl_dma_slave. Returns 0 on
+ * success, -ERRNO otherwise.
+ */
+static inline int fsl_dma_slave_append(struct fsl_dma_slave *slave,
+ dma_addr_t address, size_t length)
+{
+ struct fsl_dma_hw_addr *addr;
+
+ addr = kzalloc(sizeof(*addr), GFP_ATOMIC);
+ if (!addr)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&addr->entry);
+ addr->address = address;
+ addr->length = length;
+
+ list_add_tail(&addr->entry, &slave->addresses);
+ return 0;
+}
+
+/**
+ * fsl_dma_slave_free - free a struct fsl_dma_slave
+ * @slave: the struct fsl_dma_slave to free
+ *
+ * Free a struct fsl_dma_slave and all associated address/length pairs
+ */
+static inline void fsl_dma_slave_free(struct fsl_dma_slave *slave)
+{
+ struct fsl_dma_hw_addr *addr, *tmp;
+
+ if (slave) {
+ list_for_each_entry_safe(addr, tmp, &slave->addresses, entry) {
+ list_del(&addr->entry);
+ kfree(addr);
+ }
+
+ kfree(slave);
+ }
+}
+
+/**
+ * fsl_dma_slave_alloc - allocate a struct fsl_dma_slave
+ * @gfp: the flags to pass to kmalloc when allocating this structure
+ *
+ * Allocate a struct fsl_dma_slave for use by the DMA_SLAVE API. Returns a new
+ * struct fsl_dma_slave on success, or NULL on failure.
+ */
+static inline struct fsl_dma_slave *fsl_dma_slave_alloc(gfp_t gfp)
+{
+ struct fsl_dma_slave *slave;
+
+ slave = kzalloc(sizeof(*slave), gfp);
+ if (!slave)
+ return NULL;
+
+ INIT_LIST_HEAD(&slave->addresses);
+ return slave;
+}
+
+#endif /* __ARCH_POWERPC_ASM_FSLDMA_H__ */
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index dd9d4d6..6f769a7 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -34,6 +34,7 @@
#include <linux/dmapool.h>
#include <linux/of_platform.h>
+#include <asm/fsldma.h>
#include "fsldma.h"
static void dma_init(struct fsl_dma_chan *fsl_chan)
@@ -550,6 +551,229 @@ fail:
}
/**
+ * fsl_dma_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
+ * @chan: DMA channel
+ * @sgl: scatterlist to transfer to/from
+ * @sg_len: number of entries in @scatterlist
+ * @direction: DMA direction
+ * @flags: DMAEngine flags
+ *
+ * Prepare a set of descriptors for a DMA_SLAVE transaction. Following the
+ * DMA_SLAVE API, this gets the device-specific information from the
+ * chan->private variable.
+ */
+static struct dma_async_tx_descriptor *fsl_dma_prep_slave_sg(
+ struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
+ enum dma_data_direction direction, unsigned long flags)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *first = NULL, *prev = NULL, *new = NULL;
+ struct fsl_dma_slave *slave;
+ struct list_head *tx_list;
+ size_t copy;
+
+ int i;
+ struct scatterlist *sg;
+ size_t sg_used;
+ size_t hw_used;
+ struct fsl_dma_hw_addr *hw;
+ dma_addr_t dma_dst, dma_src;
+
+ if (!chan)
+ return NULL;
+
+ if (!chan->private)
+ return NULL;
+
+ fsl_chan = to_fsl_chan(chan);
+ slave = chan->private;
+
+ if (list_empty(&slave->addresses))
+ return NULL;
+
+ hw = list_first_entry(&slave->addresses, struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+
+ /*
+ * Build the hardware transaction to copy from the scatterlist to
+ * the hardware, or from the hardware to the scatterlist
+ *
+ * If you are copying from the hardware to the scatterlist and it
+ * takes two hardware entries to fill an entire page, then both
+ * hardware entries will be coalesced into the same page
+ *
+ * If you are copying from the scatterlist to the hardware and a
+ * single page can fill two hardware entries, then the data will
+ * be read out of the page into the first hardware entry, and so on
+ */
+ for_each_sg(sgl, sg, sg_len, i) {
+ sg_used = 0;
+
+ /* Loop until the entire scatterlist entry is used */
+ while (sg_used < sg_dma_len(sg)) {
+
+ /*
+ * If we've used up the current hardware address/length
+ * pair, we need to load a new one
+ *
+ * This is done in a while loop so that descriptors with
+ * length == 0 will be skipped
+ */
+ while (hw_used >= hw->length) {
+
+ /*
+ * If the current hardware entry is the last
+ * entry in the list, we're finished
+ */
+ if (list_is_last(&hw->entry, &slave->addresses))
+ goto finished;
+
+ /* Get the next hardware address/length pair */
+ hw = list_entry(hw->entry.next,
+ struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+ }
+
+ /* Allocate the link descriptor from DMA pool */
+ new = fsl_dma_alloc_descriptor(fsl_chan);
+ if (!new) {
+ dev_err(fsl_chan->dev, "No free memory for "
+ "link descriptor\n");
+ goto fail;
+ }
+#ifdef FSL_DMA_LD_DEBUG
+ dev_dbg(fsl_chan->dev, "new link desc alloc %p\n", new);
+#endif
+
+ /*
+ * Calculate the maximum number of bytes to transfer,
+ * making sure it is less than the DMA controller limit
+ */
+ copy = min_t(size_t, sg_dma_len(sg) - sg_used,
+ hw->length - hw_used);
+ copy = min_t(size_t, copy, FSL_DMA_BCR_MAX_CNT);
+
+ /*
+ * DMA_FROM_DEVICE
+ * from the hardware to the scatterlist
+ *
+ * DMA_TO_DEVICE
+ * from the scatterlist to the hardware
+ */
+ if (direction == DMA_FROM_DEVICE) {
+ dma_src = hw->address + hw_used;
+ dma_dst = sg_dma_address(sg) + sg_used;
+ } else {
+ dma_src = sg_dma_address(sg) + sg_used;
+ dma_dst = hw->address + hw_used;
+ }
+
+ /* Fill in the descriptor */
+ set_desc_cnt(fsl_chan, &new->hw, copy);
+ set_desc_src(fsl_chan, &new->hw, dma_src);
+ set_desc_dest(fsl_chan, &new->hw, dma_dst);
+
+ /*
+ * If this is not the first descriptor, chain the
+ * current descriptor after the previous descriptor
+ */
+ if (!first) {
+ first = new;
+ } else {
+ set_desc_next(fsl_chan, &prev->hw,
+ new->async_tx.phys);
+ }
+
+ new->async_tx.cookie = 0;
+ async_tx_ack(&new->async_tx);
+
+ prev = new;
+ sg_used += copy;
+ hw_used += copy;
+
+ /* Insert the link descriptor into the LD ring */
+ list_add_tail(&new->node, &first->async_tx.tx_list);
+ }
+ }
+
+finished:
+
+ /* All of the hardware address/length pairs had length == 0 */
+ if (!first || !new)
+ return NULL;
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ /* Set End-of-link to the last link descriptor of new list */
+ set_ld_eol(fsl_chan, new);
+
+ /* Enable extra controller features */
+ if (fsl_chan->set_src_loop_size)
+ fsl_chan->set_src_loop_size(fsl_chan, slave->src_loop_size);
+
+ if (fsl_chan->set_dest_loop_size)
+ fsl_chan->set_dest_loop_size(fsl_chan, slave->dst_loop_size);
+
+ if (fsl_chan->toggle_ext_start)
+ fsl_chan->toggle_ext_start(fsl_chan, slave->external_start);
+
+ if (fsl_chan->toggle_ext_pause)
+ fsl_chan->toggle_ext_pause(fsl_chan, slave->external_pause);
+
+ if (fsl_chan->set_request_count)
+ fsl_chan->set_request_count(fsl_chan, slave->request_count);
+
+ return &first->async_tx;
+
+fail:
+ /* If first was not set, then we failed to allocate the very first
+ * descriptor, and we're done */
+ if (!first)
+ return NULL;
+
+ /*
+ * First is set, so all of the descriptors we allocated have been added
+ * to first->async_tx.tx_list, INCLUDING "first" itself. Therefore we
+ * must traverse the list backwards freeing each descriptor in turn
+ *
+ * We're re-using variables for the loop, oh well
+ */
+ tx_list = &first->async_tx.tx_list;
+ list_for_each_entry_safe_reverse(new, prev, tx_list, node) {
+ list_del_init(&new->node);
+ dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
+ }
+
+ return NULL;
+}
+
+static void fsl_dma_device_terminate_all(struct dma_chan *chan)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *desc, *tmp;
+ unsigned long flags;
+
+ if (!chan)
+ return;
+
+ fsl_chan = to_fsl_chan(chan);
+
+ /* Halt the DMA engine */
+ dma_halt(fsl_chan);
+
+ spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
+ /* Remove and free all of the descriptors in the LD queue */
+ list_for_each_entry_safe(desc, tmp, &fsl_chan->ld_queue, node) {
+ list_del(&desc->node);
+ dma_pool_free(fsl_chan->desc_pool, desc, desc->async_tx.phys);
+ }
+
+ spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
+}
+
+/**
* fsl_dma_update_completed_cookie - Update the completed cookie.
* @fsl_chan : Freescale DMA channel
*/
@@ -975,12 +1199,15 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
+ dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
+ fdev->common.device_prep_slave_sg = fsl_dma_prep_slave_sg;
+ fdev->common.device_terminate_all = fsl_dma_device_terminate_all;
fdev->common.dev = &dev->dev;
fdev->irq = irq_of_parse_and_map(dev->node, 0);
--
1.5.4.3
^ permalink raw reply related
* [PATCH 1/2] fsldma: split apart external pause and request count features
From: Ira Snyder @ 2009-06-19 19:26 UTC (permalink / raw)
To: linuxppc-dev, Li Yang, Dan Williams, Kumar Gala
When using the Freescale DMA controller in external control mode, both the
request count and external pause bits need to be setup correctly. This was
being done with the same function.
The 83xx controller lacks the external pause feature, but has a similar
feature called external start. This feature requires that the request count
bits be setup correctly.
Split the function into two parts, to make it possible to use the external
start feature on the 83xx controller.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
This patch splits apart the external pause feature from the request
count feature, to make it possible to use the external start feature on
the 83xx controller without writing the register directly after the
driver has been initialized.
The DMA_SLAVE patch depends on this patch.
drivers/dma/fsldma.c | 45 +++++++++++++++++++++++++++++----------------
drivers/dma/fsldma.h | 3 ++-
2 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 6e60c77..dd9d4d6 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -280,28 +280,40 @@ static void fsl_chan_set_dest_loop_size(struct fsl_dma_chan *fsl_chan, int size)
}
/**
- * fsl_chan_toggle_ext_pause - Toggle channel external pause status
+ * fsl_chan_set_request_count - Set DMA Request Count for external control
* @fsl_chan : Freescale DMA channel
- * @size : Pause control size, 0 for disable external pause control.
- * The maximum is 1024.
+ * @size : Number of bytes to transfer in a single request
+ *
+ * The Freescale DMA channel can be controlled by the external signal DREQ#.
+ * The DMA request count is how many bytes are allowed to transfer before
+ * pausing the channel, after which a new assertion of DREQ# resumes channel
+ * operation.
*
- * The Freescale DMA channel can be controlled by the external
- * signal DREQ#. The pause control size is how many bytes are allowed
- * to transfer before pausing the channel, after which a new assertion
- * of DREQ# resumes channel operation.
+ * A size of 0 disables external pause control. The maximum size is 1024.
*/
-static void fsl_chan_toggle_ext_pause(struct fsl_dma_chan *fsl_chan, int size)
+static void fsl_chan_set_request_count(struct fsl_dma_chan *fsl_chan, int size)
{
- if (size > 1024)
- return;
+ BUG_ON(size > 1024);
+ DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr,
+ DMA_IN(fsl_chan, &fsl_chan->reg_base->mr, 32)
+ | ((__ilog2(size) << 24) & 0x0f000000),
+ 32);
+}
- if (size) {
- DMA_OUT(fsl_chan, &fsl_chan->reg_base->mr,
- DMA_IN(fsl_chan, &fsl_chan->reg_base->mr, 32)
- | ((__ilog2(size) << 24) & 0x0f000000),
- 32);
+/**
+ * fsl_chan_toggle_ext_pause - Toggle channel external pause status
+ * @fsl_chan : Freescale DMA channel
+ * @enable : 0 is disabled, 1 is enabled.
+ *
+ * The Freescale DMA channel can be controlled by the external signal DREQ#.
+ * The DMA Request Count feature should be used in addition to this feature
+ * to set the number of bytes to transfer before pausing the channel.
+ */
+static void fsl_chan_toggle_ext_pause(struct fsl_dma_chan *fsl_chan, int enable)
+{
+ if (enable)
fsl_chan->feature |= FSL_DMA_CHAN_PAUSE_EXT;
- } else
+ else
fsl_chan->feature &= ~FSL_DMA_CHAN_PAUSE_EXT;
}
@@ -883,6 +895,7 @@ static int __devinit fsl_dma_chan_probe(struct fsl_dma_device *fdev,
new_fsl_chan->toggle_ext_start = fsl_chan_toggle_ext_start;
new_fsl_chan->set_src_loop_size = fsl_chan_set_src_loop_size;
new_fsl_chan->set_dest_loop_size = fsl_chan_set_dest_loop_size;
+ new_fsl_chan->set_request_count = fsl_chan_set_request_count;
}
spin_lock_init(&new_fsl_chan->desc_lock);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index dc7f268..462208d 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -143,10 +143,11 @@ struct fsl_dma_chan {
struct tasklet_struct tasklet;
u32 feature;
- void (*toggle_ext_pause)(struct fsl_dma_chan *fsl_chan, int size);
+ void (*toggle_ext_pause)(struct fsl_dma_chan *fsl_chan, int enable);
void (*toggle_ext_start)(struct fsl_dma_chan *fsl_chan, int enable);
void (*set_src_loop_size)(struct fsl_dma_chan *fsl_chan, int size);
void (*set_dest_loop_size)(struct fsl_dma_chan *fsl_chan, int size);
+ void (*set_request_count)(struct fsl_dma_chan *fsl_chan, int size);
};
#define to_fsl_chan(chan) container_of(chan, struct fsl_dma_chan, common)
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH v2] sdhci: Add support for hosts that are only capable of 1-bit transfers
From: Pierre Ossman @ 2009-06-19 19:21 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev, devicetree-discuss, sdhci-devel
In-Reply-To: <20090617201408.GA17909@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
On Thu, 18 Jun 2009 00:14:08 +0400
Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> Some hosts (hardware configurations, or particular SD/MMC slots) may
> not support 4-bit bus. For example, on MPC8569E-MDS boards we can
> switch between serial (1-bit only) and nibble (4-bit) modes, thought
> we have to disable more peripherals to work in 4-bit mode.
>
> Along with some small core changes, this patch modifies sdhci-of
> driver, so that now it looks for "sdhci,1-bit-only" property in the
> device-tree, and if specified we enable a proper quirk.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
Patch merged.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: kilauea/405ex external interrupts
From: Tirumala Reddy Marri @ 2009-06-19 18:51 UTC (permalink / raw)
To: Lada Podivin, linuxppc-dev
In-Reply-To: <e35801cc0906190100i1a0429eahade975319b5246df@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1825 bytes --]
You will have to program GPIO's to select appropriate external IRQ as
they are shared .
From: linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org] On Behalf
Of Lada Podivin
Sent: Friday, June 19, 2009 1:01 AM
To: linuxppc-dev@lists.ozlabs.org
Subject: kilauea/405ex external interrupts
Hi,
I'm writing a linux driver that uses an external interrupt (ppc 405ex).
I'm using GPIO pin 30 (external IRQ 1) connected to UIC1. I'm aware of
the virtual interrupt stuff, so I added a new node to my device tree in
order to get proper virtual IRQ number. This node describes an external
event and its connection to UIC via the mentioned ext. int. Here is a
sample of the divce-tree:
..
UIC1: interrupt-controller1 {
compatible = "ibm,uic-405ex","ibm,uic";
interrupt-controller;
cell-index = <1>;
dcr-reg = <0x0d0 0x009>;
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
interrupt-parent = <&UIC0>;
};
EXTEVENT: external_event {
device_type = "external";
#address-cells = <0>;
#size-cells = <0>;
#interrupt-cells = <2>;
interrupts = <0x1e 0x1>;
interrupt-parent = <&UIC1>;
};
...
Then I use function "irq_of_parse_and_map()" which returns the virtual
IRQ number 22. So, "request_irq()" seems to be satisfied with this
number. I can see this interrupt in the /proc/interrupts. But! When I
connect a signal source to the pin 30, nothing happens - the interrupt
service routine isn't called.
Am I suppose to configure anything else? (e. g. pin multiplexing,
further device-tree tuning...) Thank you!
Best regards,
Ladi
[-- Attachment #2: Type: text/html, Size: 7379 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation
From: Lorenz Kolb @ 2009-06-19 18:42 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: Linux PPC Development
In-Reply-To: <1243454441.3489.1@antares>
Albrecht Dreß wrote:
> This trivial patch changes memcpy_(to|from)io as to transfer as many
> 32-bit words as possible in 32-bit accesses (in the current solution,
> the last 32-bit word was transferred as 4 byte accesses).
>
> Signed-off-by: Albrecht Dreß <albrecht.dress@arcor.de>
> ---
>
> diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff
> linux-2.6.29.1.orig/arch/powerpc/kernel/io.c
> linux-2.6.29.1/arch/powerpc/kernel/io.c
> --- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c 2009-04-02
> 22:55:27.000000000 +0200
> +++ linux-2.6.29.1/arch/powerpc/kernel/io.c 2009-05-27
> 11:36:09.000000000 +0200
> @@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
> dest++;
> n--;
> }
> - while(n > 4) {
> + while(n >= 4) {
> *((u32 *)dest) = *((volatile u32 *)vsrc);
> eieio();
> vsrc += 4;
> @@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
> vdest++;
> n--;
> }
> - while(n > 4) {
> + while(n >= 4) {
> *((volatile u32 *)vdest) = *((volatile u32 *)src);
> src += 4;
> vdest += 4;
>
>
> ------------------------------------------------------------------------
Works for me (and some custom hardware I created [quite a while ago,
when I was young ;-)] that is not very tolerant to Byte-by-Byte-Transfers).
Thus:
Acked
^ permalink raw reply
* Re: [PATCH v2] fsldma: Add DMA_SLAVE support
From: Ira Snyder @ 2009-06-19 18:26 UTC (permalink / raw)
To: linuxppc-dev, Kumar Gala, Dan Williams, Li Yang
In-Reply-To: <20090618225345.GB16741@ovro.caltech.edu>
On Thu, Jun 18, 2009 at 03:53:45PM -0700, Ira Snyder wrote:
> Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
> scatterlist into an arbitrary list of hardware address/length pairs.
>
> This allows a single DMA transaction to copy data from several different
> devices into a scatterlist at the same time.
>
> This also adds support to enable some controller-specific features such as
> external start and external pause for a DMA transaction.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
>
> After discussion with Dan Williams, this is the second version of the
> DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
> with both drivers I have written against this API, an FPGA programmer
> and an FPGA data grabber.
>
> Kumar, Dan asked me to add you to the CC list, so you can have a look at
> this patch before he adds it to his tree.
>
> The other two small patches I posted earlier are very helpful in testing
> this functionality. They make the fsldma driver leave the BWC (bandwidth
> control) bits alone on the 83xx controller, as well as making the
> external start feature available on 83xx.
>
> In order for the external start/pause features to be useful, the
> bandwidth control bits (in the mode register) need to be set before
> attempting to use the controller. I could spin a v3 of this patch that
> adds a field to struct fsl_dma_slave to set the bits appropriately. Or I
> could send another patch for that. Thoughts?
>
> Many thanks to all that have participated in the discussion about this
> patch.
>
> v1 -> v2:
> * move fsldma.h from include/linux to arch/powerpc/include/asm
> * add kerneldoc documentation
>
[snip]
> +
> + /* Enable extra controller features */
> + if (fsl_chan->set_src_loop_size)
> + fsl_chan->set_src_loop_size(fsl_chan, slave->src_loop_size);
> +
> + if (fsl_chan->set_dest_loop_size)
> + fsl_chan->set_dest_loop_size(fsl_chan, slave->dst_loop_size);
> +
> + if (fsl_chan->toggle_ext_start)
> + fsl_chan->toggle_ext_start(fsl_chan, slave->external_start);
> +
> + if (fsl_chan->toggle_ext_pause)
> + fsl_chan->toggle_ext_pause(fsl_chan, slave->external_pause);
I just noticed that I got this wrong for external pause. It takes a
size, not a boolean enable/disable. I'll split the size out from the
external pause feature, and send another patch.
> +
> + return &first->async_tx;
> +
^ permalink raw reply
* Re: Problem with memcpy on ppc8536
From: Albrecht Dreß @ 2009-06-19 17:28 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A3BC58A.7050408@missinglinkelectronics.com>
[-- Attachment #1: Type: text/plain, Size: 717 bytes --]
Am 19.06.09 19:06 schrieb(en) Lorenz Kolb:
> Could you please try the following patch, I am quite sure that
> checking for > 4 was accidentially done within io.c instead of >= 4
> as if it's 4 we still can copy a 32-bit word. Some hardware might not
> be happy about 8-bit accesses...
I submitted the same patch a while ago, see
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html>
and
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073065.html>,
maybe you can add a tested/revied for it?
If it is a problem with *byte* accesses, you might want to have a look
at
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072903.html>.
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problem with memcpy on ppc8536
From: Wolfram Sang @ 2009-06-19 17:51 UTC (permalink / raw)
To: Lorenz Kolb; +Cc: linuxppc-dev, Fahd Abidi
In-Reply-To: <4A3BC58A.7050408@missinglinkelectronics.com>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Fri, Jun 19, 2009 at 07:06:18PM +0200, Lorenz Kolb wrote:
> Could you please try the following patch, I am quite sure that checking
> for > 4 was accidentially done within io.c instead of >= 4 as if it's 4
> we still can copy a 32-bit word. Some hardware might not be happy about
> 8-bit accesses...
There seems to be desire for this fix:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/072582.html
If it works here, too, then you could maybe also ack it?
BTW, I can't find the original patch in patchwork, maybe the patch was missed
because of that?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Problem with memcpy on ppc8536
From: Lorenz Kolb @ 2009-06-19 17:04 UTC (permalink / raw)
To: Fahd Abidi; +Cc: linuxppc-dev
In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local>
Could you please try the following patch, I am quite sure that checking
for > 4 was accidentially done within io.c instead of >= 4 as if it's 4
we still can copy a 32-bit word. Some hardware might not be happy about
8-bit accesses...
Index: 2.6.30-source/arch/powerpc/kernel/io.c
===================================================================
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c
@@ -162,5 +162,5 @@
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
@@ -191,5 +191,5 @@
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
Fahd Abidi wrote:
> Hello,
>
> I am trying to debug a crash during memcpy while copying data from the
> FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
> through my BDI3000 to see that the entire contents of the fcm buffer I
> want moved are actually moved off to memory location I specify. The
> crash comes after it memcpy finishes copying and performs the
> instruction "2: cmplwi 0,r5,4":
>
> memcpy:
> rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */
> addi r6,r3,-4
> addi r4,r4,-4
> beq 2f /* if less than 8 bytes to do */
> andi. r0,r6,3 /* get dest word aligned */
> mtctr r7
> bne 5f
> 1: lwz r7,4(r4)
> lwzu r8,8(r4)
> stw r7,4(r6)
> stwu r8,8(r6)
> bdnz 1b
> andi. r5,r5,7
> 2: cmplwi 0,r5,4
>
> contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
> specified correctly finished. At this point I can check the memory
> contents through my BDI and verify all the data is in the ddr as I
> expect. Now the strange thing happens, if I execute the "cmplwi 0,r5,4"
> the program takes an exception and eventually gets struck at exception
> vector 0x700 which I saw from start.S is an "Alignment" exception. I am
> not sure what this exception means, can someone help me understand what
> is happening?
>
> Does this exception somehow mean that memcpy did not move all the data?
> Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
> cmplwi instruction?
>
>
> Fahd Abidi
> Product Manager - Technical Tools and Development
> Ultimate Solutions, Inc.
> ================================================================
> Your Single Source for Professional Development Tools and Embedded
> Solutions
> Ph: 978-455-3383 x255
> Fx: 978-926-3091
> Email: fabidi@ultsol.com
> Visit: http://www.ultsol.com <http://www.ultsol.com/>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Problem with memcpy on ppc8536
From: Lorenz Kolb @ 2009-06-19 17:06 UTC (permalink / raw)
To: Fahd Abidi; +Cc: linuxppc-dev
In-Reply-To: <71DEA556544D7A4F9C6848402D8184340C4A13__24467.8549039692$1245370891$gmane$org@usi01.ultsol.local>
Could you please try the following patch, I am quite sure that checking
for > 4 was accidentially done within io.c instead of >= 4 as if it's 4
we still can copy a 32-bit word. Some hardware might not be happy about
8-bit accesses...
Index: 2.6.30-source/arch/powerpc/kernel/io.c
===================================================================
--- a/2.6.30-source/arch/powerpc/kernel/io.c
+++ b/2.6.30-source/arch/powerpc/kernel/io.c
@@ -162,5 +162,5 @@
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
@@ -191,5 +191,5 @@
n--;
}
- while(n > 4) {
+ while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
Fahd Abidi wrote:
> Hello,
>
> I am trying to debug a crash during memcpy while copying data from the
> FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough
> through my BDI3000 to see that the entire contents of the fcm buffer I
> want moved are actually moved off to memory location I specify. The
> crash comes after it memcpy finishes copying and performs the
> instruction "2: cmplwi 0,r5,4":
>
> memcpy:
> rlwinm. r7,r5,32-3,3,31 /* r0 = r5 >> 3 */
> addi r6,r3,-4
> addi r4,r4,-4
> beq 2f /* if less than 8 bytes to do */
> andi. r0,r6,3 /* get dest word aligned */
> mtctr r7
> bne 5f
> 1: lwz r7,4(r4)
> lwzu r8,8(r4)
> stw r7,4(r6)
> stwu r8,8(r6)
> bdnz 1b
> andi. r5,r5,7
> 2: cmplwi 0,r5,4
>
> contents of r5 are 0x0 showing that the entire 0x1000 size transfer I
> specified correctly finished. At this point I can check the memory
> contents through my BDI and verify all the data is in the ddr as I
> expect. Now the strange thing happens, if I execute the "cmplwi 0,r5,4"
> the program takes an exception and eventually gets struck at exception
> vector 0x700 which I saw from start.S is an "Alignment" exception. I am
> not sure what this exception means, can someone help me understand what
> is happening?
>
> Does this exception somehow mean that memcpy did not move all the data?
> Does memcpy expect contents of r5 to be 4 and not 0 when it hits the
> cmplwi instruction?
>
>
> Fahd Abidi
> Product Manager - Technical Tools and Development
> Ultimate Solutions, Inc.
> ================================================================
> Your Single Source for Professional Development Tools and Embedded
> Solutions
> Ph: 978-455-3383 x255
> Fx: 978-926-3091
> Email: fabidi@ultsol.com
> Visit: http://www.ultsol.com <http://www.ultsol.com/>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PowerPC] 2.6.30-git14 boot failure with SLAB
From: Sachin Sant @ 2009-06-19 17:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Pekka Enberg, linux-kernel
In-Reply-To: <4A3B615F.8090504@in.ibm.com>
Sachin Sant wrote:
> 2.6.30-git14 (0732f87761dbe417cb6e084b712d07e879e876ef) fails to boot
> on various PowerPC machines. Here are last few boot messages from a
> Power6
> box.
<SNIP>
>
> I will go back and check what changes between git10 and git11
> could have caused this boot failure.
>
The offending commit seems to be c868d550115b9ccc0027c67265b9520790f05601.
mm: Move pgtable_cache_init() earlier
If i revert this commit, the machine boots fine.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
From: Ingo Molnar @ 2009-06-19 16:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Peter Zijlstra, linux-kernel
In-Reply-To: <19003.18793.605755.277949@cargo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Ingo Molnar writes:
>
> > Note, i left out this bit from the commit - we need to find a
> > better solution than to allow ugly warnings on PowerPC.
> >
> > Could we use the kernel's u64 type directly perhaps? That would
> > allow us to change all __u64 to u64 in all of tools/perf/ which
> > is a nice clean-up in any case.
>
> This is userspace, we can use "u64" however we like. :) I'll cook
> up a patch to add "typedef unsigned long long u64" and change
> __u64 to u64.
Thanks, i've applied the patch. Note, it crossed with a few changes
from Peter - i fixed up the conflicts - please double check whether
it's still fine on PowerPC too.
Ingo
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
From: Kumar Gala @ 2009-06-19 15:39 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20090619153113.GA6267@oksana.dev.rtsoft.ru>
On Jun 19, 2009, at 10:31 AM, Anton Vorontsov wrote:
> On Thu, Jun 18, 2009 at 09:25:46PM -0500, Kumar Gala wrote:
>>
>> On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote:
>>
>>> For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS
>>> boards,
>>> so make 1-bit mode default. When we resolve the issue, u-boot will
>>> remove sdhci,1-bit-only property from the device tree, while SDHCI
>>> will still work with older u-boots.
>>>
>>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>>> ---
>>> arch/powerpc/boot/dts/mpc8569mds.dts | 1 +
>>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> Did I miss the patch that adds this property defn. to our docs?
>
> Yep. ;-)
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073394.html
Ok. I'll wait for Pierre to ack or pick up that patch before pulling
in the .dts change.
- k
^ permalink raw reply
* [PATCH] powerpc: Refactor device tree binding
From: Kumar Gala @ 2009-06-19 15:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
Split device tree binding out of booting-without-of.txt and put them
into their own files per binding.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Documentation/powerpc/booting-without-of.txt | 1168 +---------------------
Documentation/powerpc/dts-bindings/4xx/emac.txt | 148 +++
Documentation/powerpc/dts-bindings/gpio/gpio.txt | 50 +
Documentation/powerpc/dts-bindings/gpio/mdio.txt | 19 +
Documentation/powerpc/dts-bindings/marvell.txt | 521 ++++++++++
Documentation/powerpc/dts-bindings/phy.txt | 25 +
Documentation/powerpc/dts-bindings/spi-bus.txt | 57 ++
Documentation/powerpc/dts-bindings/usb-ehci.txt | 25 +
Documentation/powerpc/dts-bindings/xilinx.txt | 295 ++++++
9 files changed, 1142 insertions(+), 1166 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/4xx/emac.txt
create mode 100644 Documentation/powerpc/dts-bindings/gpio/gpio.txt
create mode 100644 Documentation/powerpc/dts-bindings/gpio/mdio.txt
create mode 100644 Documentation/powerpc/dts-bindings/marvell.txt
create mode 100644 Documentation/powerpc/dts-bindings/phy.txt
create mode 100644 Documentation/powerpc/dts-bindings/spi-bus.txt
create mode 100644 Documentation/powerpc/dts-bindings/usb-ehci.txt
create mode 100644 Documentation/powerpc/dts-bindings/xilinx.txt
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index 8d999d8..79f533f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1238,1122 +1238,7 @@ descriptions for the SOC devices for which new nodes have been
defined; this list will expand as more and more SOC-containing
platforms are moved over to use the flattened-device-tree model.
- a) PHY nodes
-
- Required properties:
-
- - device_type : Should be "ethernet-phy"
- - interrupts : <a b> where a is the interrupt number and b is a
- field that represents an encoding of the sense and level
- information for the interrupt. This should be encoded based on
- the information in section 2) depending on the type of interrupt
- controller you have.
- - interrupt-parent : the phandle for the interrupt controller that
- services interrupts for this device.
- - reg : The ID number for the phy, usually a small integer
- - linux,phandle : phandle for this node; likely referenced by an
- ethernet controller node.
-
-
- Example:
-
- ethernet-phy@0 {
- linux,phandle = <2452000>
- interrupt-parent = <40000>;
- interrupts = <35 1>;
- reg = <0>;
- device_type = "ethernet-phy";
- };
-
-
- b) Interrupt controllers
-
- Some SOC devices contain interrupt controllers that are different
- from the standard Open PIC specification. The SOC device nodes for
- these types of controllers should be specified just like a standard
- OpenPIC controller. Sense and level information should be encoded
- as specified in section 2) of this chapter for each device that
- specifies an interrupt.
-
- Example :
-
- pic@40000 {
- linux,phandle = <40000>;
- interrupt-controller;
- #address-cells = <0>;
- reg = <40000 40000>;
- compatible = "chrp,open-pic";
- device_type = "open-pic";
- };
-
- c) 4xx/Axon EMAC ethernet nodes
-
- The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
- the Axon bridge. To operate this needs to interact with a ths
- special McMAL DMA controller, and sometimes an RGMII or ZMII
- interface. In addition to the nodes and properties described
- below, the node for the OPB bus on which the EMAC sits must have a
- correct clock-frequency property.
-
- i) The EMAC node itself
-
- Required properties:
- - device_type : "network"
-
- - compatible : compatible list, contains 2 entries, first is
- "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
- 405gp, Axon) and second is either "ibm,emac" or
- "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
- "ibm,emac4"
- - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
- - interrupt-parent : optional, if needed for interrupt mapping
- - reg : <registers mapping>
- - local-mac-address : 6 bytes, MAC address
- - mal-device : phandle of the associated McMAL node
- - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
- with this EMAC
- - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
- with this EMAC
- - cell-index : 1 cell, hardware index of the EMAC cell on a given
- ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
- each Axon chip)
- - max-frame-size : 1 cell, maximum frame size supported in bytes
- - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
- operations.
- For Axon, 2048
- - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
- operations.
- For Axon, 2048.
- - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
- thresholds).
- For Axon, 0x00000010
- - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
- in bytes.
- For Axon, 0x00000100 (I think ...)
- - phy-mode : string, mode of operations of the PHY interface.
- Supported values are: "mii", "rmii", "smii", "rgmii",
- "tbi", "gmii", rtbi", "sgmii".
- For Axon on CAB, it is "rgmii"
- - mdio-device : 1 cell, required iff using shared MDIO registers
- (440EP). phandle of the EMAC to use to drive the
- MDIO lines for the PHY used by this EMAC.
- - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
- the ZMII device node
- - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
- channel or 0xffffffff if ZMII is only used for MDIO.
- - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
- of the RGMII device node.
- For Axon: phandle of plb5/plb4/opb/rgmii
- - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
- RGMII channel is used by this EMAC.
- Fox Axon: present, whatever value is appropriate for each
- EMAC, that is the content of the current (bogus) "phy-port"
- property.
-
- Optional properties:
- - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
- a search is performed.
- - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
- for, used if phy-address is absent. bit 0x00000001 is
- MDIO address 0.
- For Axon it can be absent, though my current driver
- doesn't handle phy-address yet so for now, keep
- 0x00ffffff in it.
- - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
- operations (if absent the value is the same as
- rx-fifo-size). For Axon, either absent or 2048.
- - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
- operations (if absent the value is the same as
- tx-fifo-size). For Axon, either absent or 2048.
- - tah-device : 1 cell, optional. If connected to a TAH engine for
- offload, phandle of the TAH device node.
- - tah-channel : 1 cell, optional. If appropriate, channel used on the
- TAH engine.
-
- Example:
-
- EMAC0: ethernet@40000800 {
- device_type = "network";
- compatible = "ibm,emac-440gp", "ibm,emac";
- interrupt-parent = <&UIC1>;
- interrupts = <1c 4 1d 4>;
- reg = <40000800 70>;
- local-mac-address = [00 04 AC E3 1B 1E];
- mal-device = <&MAL0>;
- mal-tx-channel = <0 1>;
- mal-rx-channel = <0>;
- cell-index = <0>;
- max-frame-size = <5dc>;
- rx-fifo-size = <1000>;
- tx-fifo-size = <800>;
- phy-mode = "rmii";
- phy-map = <00000001>;
- zmii-device = <&ZMII0>;
- zmii-channel = <0>;
- };
-
- ii) McMAL node
-
- Required properties:
- - device_type : "dma-controller"
- - compatible : compatible list, containing 2 entries, first is
- "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
- emac) and the second is either "ibm,mcmal" or
- "ibm,mcmal2".
- For Axon, "ibm,mcmal-axon","ibm,mcmal2"
- - interrupts : <interrupt mapping for the MAL interrupts sources:
- 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
- For Axon: This is _different_ from the current
- firmware. We use the "delayed" interrupts for txeob
- and rxeob. Thus we end up with mapping those 5 MPIC
- interrupts, all level positive sensitive: 10, 11, 32,
- 33, 34 (in decimal)
- - dcr-reg : < DCR registers range >
- - dcr-parent : if needed for dcr-reg
- - num-tx-chans : 1 cell, number of Tx channels
- - num-rx-chans : 1 cell, number of Rx channels
-
- iii) ZMII node
-
- Required properties:
- - compatible : compatible list, containing 2 entries, first is
- "ibm,zmii-CHIP" where CHIP is the host ASIC (like
- EMAC) and the second is "ibm,zmii".
- For Axon, there is no ZMII node.
- - reg : <registers mapping>
-
- iv) RGMII node
-
- Required properties:
- - compatible : compatible list, containing 2 entries, first is
- "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
- EMAC) and the second is "ibm,rgmii".
- For Axon, "ibm,rgmii-axon","ibm,rgmii"
- - reg : <registers mapping>
- - revision : as provided by the RGMII new version register if
- available.
- For Axon: 0x0000012a
-
- d) Xilinx IP cores
-
- The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
- in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
- of standard device types (network, serial, etc.) and miscellaneous
- devices (gpio, LCD, spi, etc). Also, since these devices are
- implemented within the fpga fabric every instance of the device can be
- synthesised with different options that change the behaviour.
-
- Each IP-core has a set of parameters which the FPGA designer can use to
- control how the core is synthesized. Historically, the EDK tool would
- extract the device parameters relevant to device drivers and copy them
- into an 'xparameters.h' in the form of #define symbols. This tells the
- device drivers how the IP cores are configured, but it requres the kernel
- to be recompiled every time the FPGA bitstream is resynthesized.
-
- The new approach is to export the parameters into the device tree and
- generate a new device tree each time the FPGA bitstream changes. The
- parameters which used to be exported as #defines will now become
- properties of the device node. In general, device nodes for IP-cores
- will take the following form:
-
- (name): (generic-name)@(base-address) {
- compatible = "xlnx,(ip-core-name)-(HW_VER)"
- [, (list of compatible devices), ...];
- reg = <(baseaddr) (size)>;
- interrupt-parent = <&interrupt-controller-phandle>;
- interrupts = < ... >;
- xlnx,(parameter1) = "(string-value)";
- xlnx,(parameter2) = <(int-value)>;
- };
-
- (generic-name): an open firmware-style name that describes the
- generic class of device. Preferably, this is one word, such
- as 'serial' or 'ethernet'.
- (ip-core-name): the name of the ip block (given after the BEGIN
- directive in system.mhs). Should be in lowercase
- and all underscores '_' converted to dashes '-'.
- (name): is derived from the "PARAMETER INSTANCE" value.
- (parameter#): C_* parameters from system.mhs. The C_ prefix is
- dropped from the parameter name, the name is converted
- to lowercase and all underscore '_' characters are
- converted to dashes '-'.
- (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
- (HW_VER): from the HW_VER parameter.
- (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
-
- Typically, the compatible list will include the exact IP core version
- followed by an older IP core version which implements the same
- interface or any other device with the same interface.
-
- 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
-
- For example, the following block from system.mhs:
-
- BEGIN opb_uartlite
- PARAMETER INSTANCE = opb_uartlite_0
- PARAMETER HW_VER = 1.00.b
- PARAMETER C_BAUDRATE = 115200
- PARAMETER C_DATA_BITS = 8
- PARAMETER C_ODD_PARITY = 0
- PARAMETER C_USE_PARITY = 0
- PARAMETER C_CLK_FREQ = 50000000
- PARAMETER C_BASEADDR = 0xEC100000
- PARAMETER C_HIGHADDR = 0xEC10FFFF
- BUS_INTERFACE SOPB = opb_7
- PORT OPB_Clk = CLK_50MHz
- PORT Interrupt = opb_uartlite_0_Interrupt
- PORT RX = opb_uartlite_0_RX
- PORT TX = opb_uartlite_0_TX
- PORT OPB_Rst = sys_bus_reset_0
- END
-
- becomes the following device tree node:
-
- opb_uartlite_0: serial@ec100000 {
- device_type = "serial";
- compatible = "xlnx,opb-uartlite-1.00.b";
- reg = <ec100000 10000>;
- interrupt-parent = <&opb_intc_0>;
- interrupts = <1 0>; // got this from the opb_intc parameters
- current-speed = <d#115200>; // standard serial device prop
- clock-frequency = <d#50000000>; // standard serial device prop
- xlnx,data-bits = <8>;
- xlnx,odd-parity = <0>;
- xlnx,use-parity = <0>;
- };
-
- Some IP cores actually implement 2 or more logical devices. In
- this case, the device should still describe the whole IP core with
- a single node and add a child node for each logical device. The
- ranges property can be used to translate from parent IP-core to the
- registers of each device. In addition, the parent node should be
- compatible with the bus type 'xlnx,compound', and should contain
- #address-cells and #size-cells, as with any other bus. (Note: this
- makes the assumption that both logical devices have the same bus
- binding. If this is not true, then separate nodes should be used
- for each logical device). The 'cell-index' property can be used to
- enumerate logical devices within an IP core. For example, the
- following is the system.mhs entry for the dual ps2 controller found
- on the ml403 reference design.
-
- BEGIN opb_ps2_dual_ref
- PARAMETER INSTANCE = opb_ps2_dual_ref_0
- PARAMETER HW_VER = 1.00.a
- PARAMETER C_BASEADDR = 0xA9000000
- PARAMETER C_HIGHADDR = 0xA9001FFF
- BUS_INTERFACE SOPB = opb_v20_0
- PORT Sys_Intr1 = ps2_1_intr
- PORT Sys_Intr2 = ps2_2_intr
- PORT Clkin1 = ps2_clk_rx_1
- PORT Clkin2 = ps2_clk_rx_2
- PORT Clkpd1 = ps2_clk_tx_1
- PORT Clkpd2 = ps2_clk_tx_2
- PORT Rx1 = ps2_d_rx_1
- PORT Rx2 = ps2_d_rx_2
- PORT Txpd1 = ps2_d_tx_1
- PORT Txpd2 = ps2_d_tx_2
- END
-
- It would result in the following device tree nodes:
-
- opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "xlnx,compound";
- ranges = <0 a9000000 2000>;
- // If this device had extra parameters, then they would
- // go here.
- ps2@0 {
- compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
- reg = <0 40>;
- interrupt-parent = <&opb_intc_0>;
- interrupts = <3 0>;
- cell-index = <0>;
- };
- ps2@1000 {
- compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
- reg = <1000 40>;
- interrupt-parent = <&opb_intc_0>;
- interrupts = <3 0>;
- cell-index = <0>;
- };
- };
-
- Also, the system.mhs file defines bus attachments from the processor
- to the devices. The device tree structure should reflect the bus
- attachments. Again an example; this system.mhs fragment:
-
- BEGIN ppc405_virtex4
- PARAMETER INSTANCE = ppc405_0
- PARAMETER HW_VER = 1.01.a
- BUS_INTERFACE DPLB = plb_v34_0
- BUS_INTERFACE IPLB = plb_v34_0
- END
-
- BEGIN opb_intc
- PARAMETER INSTANCE = opb_intc_0
- PARAMETER HW_VER = 1.00.c
- PARAMETER C_BASEADDR = 0xD1000FC0
- PARAMETER C_HIGHADDR = 0xD1000FDF
- BUS_INTERFACE SOPB = opb_v20_0
- END
-
- BEGIN opb_uart16550
- PARAMETER INSTANCE = opb_uart16550_0
- PARAMETER HW_VER = 1.00.d
- PARAMETER C_BASEADDR = 0xa0000000
- PARAMETER C_HIGHADDR = 0xa0001FFF
- BUS_INTERFACE SOPB = opb_v20_0
- END
-
- BEGIN plb_v34
- PARAMETER INSTANCE = plb_v34_0
- PARAMETER HW_VER = 1.02.a
- END
-
- BEGIN plb_bram_if_cntlr
- PARAMETER INSTANCE = plb_bram_if_cntlr_0
- PARAMETER HW_VER = 1.00.b
- PARAMETER C_BASEADDR = 0xFFFF0000
- PARAMETER C_HIGHADDR = 0xFFFFFFFF
- BUS_INTERFACE SPLB = plb_v34_0
- END
-
- BEGIN plb2opb_bridge
- PARAMETER INSTANCE = plb2opb_bridge_0
- PARAMETER HW_VER = 1.01.a
- PARAMETER C_RNG0_BASEADDR = 0x20000000
- PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
- PARAMETER C_RNG1_BASEADDR = 0x60000000
- PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
- PARAMETER C_RNG2_BASEADDR = 0x80000000
- PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
- PARAMETER C_RNG3_BASEADDR = 0xC0000000
- PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
- BUS_INTERFACE SPLB = plb_v34_0
- BUS_INTERFACE MOPB = opb_v20_0
- END
-
- Gives this device tree (some properties removed for clarity):
-
- plb@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "xlnx,plb-v34-1.02.a";
- device_type = "ibm,plb";
- ranges; // 1:1 translation
-
- plb_bram_if_cntrl_0: bram@ffff0000 {
- reg = <ffff0000 10000>;
- }
-
- opb@20000000 {
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <20000000 20000000 20000000
- 60000000 60000000 20000000
- 80000000 80000000 40000000
- c0000000 c0000000 20000000>;
-
- opb_uart16550_0: serial@a0000000 {
- reg = <a00000000 2000>;
- };
-
- opb_intc_0: interrupt-controller@d1000fc0 {
- reg = <d1000fc0 20>;
- };
- };
- };
-
- That covers the general approach to binding xilinx IP cores into the
- device tree. The following are bindings for specific devices:
-
- i) Xilinx ML300 Framebuffer
-
- Simple framebuffer device from the ML300 reference design (also on the
- ML403 reference design as well as others).
-
- Optional properties:
- - resolution = <xres yres> : pixel resolution of framebuffer. Some
- implementations use a different resolution.
- Default is <d#640 d#480>
- - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
- Default is <d#1024 d#480>.
- - rotate-display (empty) : rotate display 180 degrees.
-
- ii) Xilinx SystemACE
-
- The Xilinx SystemACE device is used to program FPGAs from an FPGA
- bitstream stored on a CF card. It can also be used as a generic CF
- interface device.
-
- Optional properties:
- - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
-
- iii) Xilinx EMAC and Xilinx TEMAC
-
- Xilinx Ethernet devices. In addition to general xilinx properties
- listed above, nodes for these devices should include a phy-handle
- property, and may include other common network device properties
- like local-mac-address.
-
- iv) Xilinx Uartlite
-
- Xilinx uartlite devices are simple fixed speed serial ports.
-
- Required properties:
- - current-speed : Baud rate of uartlite
-
- v) Xilinx hwicap
-
- Xilinx hwicap devices provide access to the configuration logic
- of the FPGA through the Internal Configuration Access Port
- (ICAP). The ICAP enables partial reconfiguration of the FPGA,
- readback of the configuration information, and some control over
- 'warm boots' of the FPGA fabric.
-
- Required properties:
- - xlnx,family : The family of the FPGA, necessary since the
- capabilities of the underlying ICAP hardware
- differ between different families. May be
- 'virtex2p', 'virtex4', or 'virtex5'.
-
- vi) Xilinx Uart 16550
-
- Xilinx UART 16550 devices are very similar to the NS16550 but with
- different register spacing and an offset from the base address.
-
- Required properties:
- - clock-frequency : Frequency of the clock input
- - reg-offset : A value of 3 is required
- - reg-shift : A value of 2 is required
-
- e) USB EHCI controllers
-
- Required properties:
- - compatible : should be "usb-ehci".
- - reg : should contain at least address and length of the standard EHCI
- register set for the device. Optional platform-dependent registers
- (debug-port or other) can be also specified here, but only after
- definition of standard EHCI registers.
- - interrupts : one EHCI interrupt should be described here.
- If device registers are implemented in big endian mode, the device
- node should have "big-endian-regs" property.
- If controller implementation operates with big endian descriptors,
- "big-endian-desc" property should be specified.
- If both big endian registers and descriptors are used by the controller
- implementation, "big-endian" property can be specified instead of having
- both "big-endian-regs" and "big-endian-desc".
-
- Example (Sequoia 440EPx):
- ehci@e0000300 {
- compatible = "ibm,usb-ehci-440epx", "usb-ehci";
- interrupt-parent = <&UIC0>;
- interrupts = <1a 4>;
- reg = <0 e0000300 90 0 e0000390 70>;
- big-endian;
- };
-
- f) MDIO on GPIOs
-
- Currently defined compatibles:
- - virtual,gpio-mdio
-
- MDC and MDIO lines connected to GPIO controllers are listed in the
- gpios property as described in section VIII.1 in the following order:
-
- MDC, MDIO.
-
- Example:
-
- mdio {
- compatible = "virtual,mdio-gpio";
- #address-cells = <1>;
- #size-cells = <0>;
- gpios = <&qe_pio_a 11
- &qe_pio_c 6>;
- };
-
- g) SPI (Serial Peripheral Interface) busses
-
- SPI busses can be described with a node for the SPI master device
- and a set of child nodes for each SPI slave on the bus. For this
- discussion, it is assumed that the system's SPI controller is in
- SPI master mode. This binding does not describe SPI controllers
- in slave mode.
-
- The SPI master node requires the following properties:
- - #address-cells - number of cells required to define a chip select
- address on the SPI bus.
- - #size-cells - should be zero.
- - compatible - name of SPI bus controller following generic names
- recommended practice.
- No other properties are required in the SPI bus node. It is assumed
- that a driver for an SPI bus device will understand that it is an SPI bus.
- However, the binding does not attempt to define the specific method for
- assigning chip select numbers. Since SPI chip select configuration is
- flexible and non-standardized, it is left out of this binding with the
- assumption that board specific platform code will be used to manage
- chip selects. Individual drivers can define additional properties to
- support describing the chip select layout.
-
- SPI slave nodes must be children of the SPI master node and can
- contain the following properties.
- - reg - (required) chip select address of device.
- - compatible - (required) name of SPI device following generic names
- recommended practice
- - spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
- - spi-cpol - (optional) Empty property indicating device requires
- inverse clock polarity (CPOL) mode
- - spi-cpha - (optional) Empty property indicating device requires
- shifted clock phase (CPHA) mode
- - spi-cs-high - (optional) Empty property indicating device requires
- chip select active high
-
- SPI example for an MPC5200 SPI bus:
- spi@f00 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
- reg = <0xf00 0x20>;
- interrupts = <2 13 0 2 14 0>;
- interrupt-parent = <&mpc5200_pic>;
-
- ethernet-switch@0 {
- compatible = "micrel,ks8995m";
- spi-max-frequency = <1000000>;
- reg = <0>;
- };
-
- codec@1 {
- compatible = "ti,tlv320aic26";
- spi-max-frequency = <100000>;
- reg = <1>;
- };
- };
-
-VII - Marvell Discovery mv64[345]6x System Controller chips
-===========================================================
-
-The Marvell mv64[345]60 series of system controller chips contain
-many of the peripherals needed to implement a complete computer
-system. In this section, we define device tree nodes to describe
-the system controller chip itself and each of the peripherals
-which it contains. Compatible string values for each node are
-prefixed with the string "marvell,", for Marvell Technology Group Ltd.
-
-1) The /system-controller node
-
- This node is used to represent the system-controller and must be
- present when the system uses a system controller chip. The top-level
- system-controller node contains information that is global to all
- devices within the system controller chip. The node name begins
- with "system-controller" followed by the unit address, which is
- the base address of the memory-mapped register set for the system
- controller chip.
-
- Required properties:
-
- - ranges : Describes the translation of system controller addresses
- for memory mapped registers.
- - clock-frequency: Contains the main clock frequency for the system
- controller chip.
- - reg : This property defines the address and size of the
- memory-mapped registers contained within the system controller
- chip. The address specified in the "reg" property should match
- the unit address of the system-controller node.
- - #address-cells : Address representation for system controller
- devices. This field represents the number of cells needed to
- represent the address of the memory-mapped registers of devices
- within the system controller chip.
- - #size-cells : Size representation for for the memory-mapped
- registers within the system controller chip.
- - #interrupt-cells : Defines the width of cells used to represent
- interrupts.
-
- Optional properties:
-
- - model : The specific model of the system controller chip. Such
- as, "mv64360", "mv64460", or "mv64560".
- - compatible : A string identifying the compatibility identifiers
- of the system controller chip.
-
- The system-controller node contains child nodes for each system
- controller device that the platform uses. Nodes should not be created
- for devices which exist on the system controller chip but are not used
-
- Example Marvell Discovery mv64360 system-controller node:
-
- system-controller@f1000000 { /* Marvell Discovery mv64360 */
- #address-cells = <1>;
- #size-cells = <1>;
- model = "mv64360"; /* Default */
- compatible = "marvell,mv64360";
- clock-frequency = <133333333>;
- reg = <0xf1000000 0x10000>;
- virtual-reg = <0xf1000000>;
- ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
- 0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
- 0xa0000000 0xa0000000 0x4000000 /* User FLASH */
- 0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
- 0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
-
- [ child node definitions... ]
- }
-
-2) Child nodes of /system-controller
-
- a) Marvell Discovery MDIO bus
-
- The MDIO is a bus to which the PHY devices are connected. For each
- device that exists on this bus, a child node should be created. See
- the definition of the PHY node below for an example of how to define
- a PHY.
-
- Required properties:
- - #address-cells : Should be <1>
- - #size-cells : Should be <0>
- - device_type : Should be "mdio"
- - compatible : Should be "marvell,mv64360-mdio"
-
- Example:
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
- device_type = "mdio";
- compatible = "marvell,mv64360-mdio";
-
- ethernet-phy@0 {
- ......
- };
- };
-
-
- b) Marvell Discovery ethernet controller
-
- The Discover ethernet controller is described with two levels
- of nodes. The first level describes an ethernet silicon block
- and the second level describes up to 3 ethernet nodes within
- that block. The reason for the multiple levels is that the
- registers for the node are interleaved within a single set
- of registers. The "ethernet-block" level describes the
- shared register set, and the "ethernet" nodes describe ethernet
- port-specific properties.
-
- Ethernet block node
-
- Required properties:
- - #address-cells : <1>
- - #size-cells : <0>
- - compatible : "marvell,mv64360-eth-block"
- - reg : Offset and length of the register set for this block
-
- Example Discovery Ethernet block node:
- ethernet-block@2000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "marvell,mv64360-eth-block";
- reg = <0x2000 0x2000>;
- ethernet@0 {
- .......
- };
- };
-
- Ethernet port node
-
- Required properties:
- - device_type : Should be "network".
- - compatible : Should be "marvell,mv64360-eth".
- - reg : Should be <0>, <1>, or <2>, according to which registers
- within the silicon block the device uses.
- - interrupts : <a> where a is the interrupt number for the port.
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
- - phy : the phandle for the PHY connected to this ethernet
- controller.
- - local-mac-address : 6 bytes, MAC address
-
- Example Discovery Ethernet port node:
- ethernet@0 {
- device_type = "network";
- compatible = "marvell,mv64360-eth";
- reg = <0>;
- interrupts = <32>;
- interrupt-parent = <&PIC>;
- phy = <&PHY0>;
- local-mac-address = [ 00 00 00 00 00 00 ];
- };
-
-
-
- c) Marvell Discovery PHY nodes
-
- Required properties:
- - device_type : Should be "ethernet-phy"
- - interrupts : <a> where a is the interrupt number for this phy.
- - interrupt-parent : the phandle for the interrupt controller that
- services interrupts for this device.
- - reg : The ID number for the phy, usually a small integer
-
- Example Discovery PHY node:
- ethernet-phy@1 {
- device_type = "ethernet-phy";
- compatible = "broadcom,bcm5421";
- interrupts = <76>; /* GPP 12 */
- interrupt-parent = <&PIC>;
- reg = <1>;
- };
-
-
- d) Marvell Discovery SDMA nodes
-
- Represent DMA hardware associated with the MPSC (multiprotocol
- serial controllers).
-
- Required properties:
- - compatible : "marvell,mv64360-sdma"
- - reg : Offset and length of the register set for this device
- - interrupts : <a> where a is the interrupt number for the DMA
- device.
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery SDMA node:
- sdma@4000 {
- compatible = "marvell,mv64360-sdma";
- reg = <0x4000 0xc18>;
- virtual-reg = <0xf1004000>;
- interrupts = <36>;
- interrupt-parent = <&PIC>;
- };
-
-
- e) Marvell Discovery BRG nodes
-
- Represent baud rate generator hardware associated with the MPSC
- (multiprotocol serial controllers).
-
- Required properties:
- - compatible : "marvell,mv64360-brg"
- - reg : Offset and length of the register set for this device
- - clock-src : A value from 0 to 15 which selects the clock
- source for the baud rate generator. This value corresponds
- to the CLKS value in the BRGx configuration register. See
- the mv64x60 User's Manual.
- - clock-frequence : The frequency (in Hz) of the baud rate
- generator's input clock.
- - current-speed : The current speed setting (presumably by
- firmware) of the baud rate generator.
-
- Example Discovery BRG node:
- brg@b200 {
- compatible = "marvell,mv64360-brg";
- reg = <0xb200 0x8>;
- clock-src = <8>;
- clock-frequency = <133333333>;
- current-speed = <9600>;
- };
-
-
- f) Marvell Discovery CUNIT nodes
-
- Represent the Serial Communications Unit device hardware.
-
- Required properties:
- - reg : Offset and length of the register set for this device
-
- Example Discovery CUNIT node:
- cunit@f200 {
- reg = <0xf200 0x200>;
- };
-
-
- g) Marvell Discovery MPSCROUTING nodes
-
- Represent the Discovery's MPSC routing hardware
-
- Required properties:
- - reg : Offset and length of the register set for this device
-
- Example Discovery CUNIT node:
- mpscrouting@b500 {
- reg = <0xb400 0xc>;
- };
-
-
- h) Marvell Discovery MPSCINTR nodes
-
- Represent the Discovery's MPSC DMA interrupt hardware registers
- (SDMA cause and mask registers).
-
- Required properties:
- - reg : Offset and length of the register set for this device
-
- Example Discovery MPSCINTR node:
- mpsintr@b800 {
- reg = <0xb800 0x100>;
- };
-
-
- i) Marvell Discovery MPSC nodes
-
- Represent the Discovery's MPSC (Multiprotocol Serial Controller)
- serial port.
-
- Required properties:
- - device_type : "serial"
- - compatible : "marvell,mv64360-mpsc"
- - reg : Offset and length of the register set for this device
- - sdma : the phandle for the SDMA node used by this port
- - brg : the phandle for the BRG node used by this port
- - cunit : the phandle for the CUNIT node used by this port
- - mpscrouting : the phandle for the MPSCROUTING node used by this port
- - mpscintr : the phandle for the MPSCINTR node used by this port
- - cell-index : the hardware index of this cell in the MPSC core
- - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
- register
- - interrupts : <a> where a is the interrupt number for the MPSC.
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery MPSCINTR node:
- mpsc@8000 {
- device_type = "serial";
- compatible = "marvell,mv64360-mpsc";
- reg = <0x8000 0x38>;
- virtual-reg = <0xf1008000>;
- sdma = <&SDMA0>;
- brg = <&BRG0>;
- cunit = <&CUNIT>;
- mpscrouting = <&MPSCROUTING>;
- mpscintr = <&MPSCINTR>;
- cell-index = <0>;
- max_idle = <40>;
- interrupts = <40>;
- interrupt-parent = <&PIC>;
- };
-
-
- j) Marvell Discovery Watch Dog Timer nodes
-
- Represent the Discovery's watchdog timer hardware
-
- Required properties:
- - compatible : "marvell,mv64360-wdt"
- - reg : Offset and length of the register set for this device
-
- Example Discovery Watch Dog Timer node:
- wdt@b410 {
- compatible = "marvell,mv64360-wdt";
- reg = <0xb410 0x8>;
- };
-
-
- k) Marvell Discovery I2C nodes
-
- Represent the Discovery's I2C hardware
-
- Required properties:
- - device_type : "i2c"
- - compatible : "marvell,mv64360-i2c"
- - reg : Offset and length of the register set for this device
- - interrupts : <a> where a is the interrupt number for the I2C.
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery I2C node:
- compatible = "marvell,mv64360-i2c";
- reg = <0xc000 0x20>;
- virtual-reg = <0xf100c000>;
- interrupts = <37>;
- interrupt-parent = <&PIC>;
- };
-
-
- l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
-
- Represent the Discovery's PIC hardware
-
- Required properties:
- - #interrupt-cells : <1>
- - #address-cells : <0>
- - compatible : "marvell,mv64360-pic"
- - reg : Offset and length of the register set for this device
- - interrupt-controller
-
- Example Discovery PIC node:
- pic {
- #interrupt-cells = <1>;
- #address-cells = <0>;
- compatible = "marvell,mv64360-pic";
- reg = <0x0 0x88>;
- interrupt-controller;
- };
-
-
- m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
-
- Represent the Discovery's MPP hardware
-
- Required properties:
- - compatible : "marvell,mv64360-mpp"
- - reg : Offset and length of the register set for this device
-
- Example Discovery MPP node:
- mpp@f000 {
- compatible = "marvell,mv64360-mpp";
- reg = <0xf000 0x10>;
- };
-
-
- n) Marvell Discovery GPP (General Purpose Pins) nodes
-
- Represent the Discovery's GPP hardware
-
- Required properties:
- - compatible : "marvell,mv64360-gpp"
- - reg : Offset and length of the register set for this device
-
- Example Discovery GPP node:
- gpp@f000 {
- compatible = "marvell,mv64360-gpp";
- reg = <0xf100 0x20>;
- };
-
-
- o) Marvell Discovery PCI host bridge node
-
- Represents the Discovery's PCI host bridge device. The properties
- for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
- 1275-1994. A typical value for the compatible property is
- "marvell,mv64360-pci".
-
- Example Discovery PCI host bridge node
- pci@80000000 {
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
- device_type = "pci";
- compatible = "marvell,mv64360-pci";
- reg = <0xcf8 0x8>;
- ranges = <0x01000000 0x0 0x0
- 0x88000000 0x0 0x01000000
- 0x02000000 0x0 0x80000000
- 0x80000000 0x0 0x08000000>;
- bus-range = <0 255>;
- clock-frequency = <66000000>;
- interrupt-parent = <&PIC>;
- interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
- interrupt-map = <
- /* IDSEL 0x0a */
- 0x5000 0 0 1 &PIC 80
- 0x5000 0 0 2 &PIC 81
- 0x5000 0 0 3 &PIC 91
- 0x5000 0 0 4 &PIC 93
-
- /* IDSEL 0x0b */
- 0x5800 0 0 1 &PIC 91
- 0x5800 0 0 2 &PIC 93
- 0x5800 0 0 3 &PIC 80
- 0x5800 0 0 4 &PIC 81
-
- /* IDSEL 0x0c */
- 0x6000 0 0 1 &PIC 91
- 0x6000 0 0 2 &PIC 93
- 0x6000 0 0 3 &PIC 80
- 0x6000 0 0 4 &PIC 81
-
- /* IDSEL 0x0d */
- 0x6800 0 0 1 &PIC 93
- 0x6800 0 0 2 &PIC 80
- 0x6800 0 0 3 &PIC 81
- 0x6800 0 0 4 &PIC 91
- >;
- };
-
-
- p) Marvell Discovery CPU Error nodes
-
- Represent the Discovery's CPU error handler device.
-
- Required properties:
- - compatible : "marvell,mv64360-cpu-error"
- - reg : Offset and length of the register set for this device
- - interrupts : the interrupt number for this device
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery CPU Error node:
- cpu-error@0070 {
- compatible = "marvell,mv64360-cpu-error";
- reg = <0x70 0x10 0x128 0x28>;
- interrupts = <3>;
- interrupt-parent = <&PIC>;
- };
-
-
- q) Marvell Discovery SRAM Controller nodes
-
- Represent the Discovery's SRAM controller device.
-
- Required properties:
- - compatible : "marvell,mv64360-sram-ctrl"
- - reg : Offset and length of the register set for this device
- - interrupts : the interrupt number for this device
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery SRAM Controller node:
- sram-ctrl@0380 {
- compatible = "marvell,mv64360-sram-ctrl";
- reg = <0x380 0x80>;
- interrupts = <13>;
- interrupt-parent = <&PIC>;
- };
-
-
- r) Marvell Discovery PCI Error Handler nodes
-
- Represent the Discovery's PCI error handler device.
-
- Required properties:
- - compatible : "marvell,mv64360-pci-error"
- - reg : Offset and length of the register set for this device
- - interrupts : the interrupt number for this device
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery PCI Error Handler node:
- pci-error@1d40 {
- compatible = "marvell,mv64360-pci-error";
- reg = <0x1d40 0x40 0xc28 0x4>;
- interrupts = <12>;
- interrupt-parent = <&PIC>;
- };
-
-
- s) Marvell Discovery Memory Controller nodes
-
- Represent the Discovery's memory controller device.
-
- Required properties:
- - compatible : "marvell,mv64360-mem-ctrl"
- - reg : Offset and length of the register set for this device
- - interrupts : the interrupt number for this device
- - interrupt-parent : the phandle for the interrupt controller
- that services interrupts for this device.
-
- Example Discovery Memory Controller node:
- mem-ctrl@1400 {
- compatible = "marvell,mv64360-mem-ctrl";
- reg = <0x1400 0x60>;
- interrupts = <17>;
- interrupt-parent = <&PIC>;
- };
-
-
-VIII - Specifying interrupt information for devices
+VII - Specifying interrupt information for devices
===================================================
The device tree represents the busses and devices of a hardware
@@ -2439,56 +1324,7 @@ encodings listed below:
2 = high to low edge sensitive type enabled
3 = low to high edge sensitive type enabled
-IX - Specifying GPIO information for devices
-============================================
-
-1) gpios property
------------------
-
-Nodes that makes use of GPIOs should define them using `gpios' property,
-format of which is: <&gpio-controller1-phandle gpio1-specifier
- &gpio-controller2-phandle gpio2-specifier
- 0 /* holes are permitted, means no GPIO 3 */
- &gpio-controller4-phandle gpio4-specifier
- ...>;
-
-Note that gpio-specifier length is controller dependent.
-
-gpio-specifier may encode: bank, pin position inside the bank,
-whether pin is open-drain and whether pin is logically inverted.
-
-Example of the node using GPIOs:
-
- node {
- gpios = <&qe_pio_e 18 0>;
- };
-
-In this example gpio-specifier is "18 0" and encodes GPIO pin number,
-and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
-
-2) gpio-controller nodes
-------------------------
-
-Every GPIO controller node must have #gpio-cells property defined,
-this information will be used to translate gpio-specifiers.
-
-Example of two SOC GPIO banks defined as gpio-controller nodes:
-
- qe_pio_a: gpio-controller@1400 {
- #gpio-cells = <2>;
- compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
- reg = <0x1400 0x18>;
- gpio-controller;
- };
-
- qe_pio_e: gpio-controller@1460 {
- #gpio-cells = <2>;
- compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
- reg = <0x1460 0x18>;
- gpio-controller;
- };
-
-X - Specifying Device Power Management Information (sleep property)
+VIII - Specifying Device Power Management Information (sleep property)
===================================================================
Devices on SOCs often have mechanisms for placing devices into low-power
diff --git a/Documentation/powerpc/dts-bindings/4xx/emac.txt b/Documentation/powerpc/dts-bindings/4xx/emac.txt
new file mode 100644
index 0000000..2161334
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/4xx/emac.txt
@@ -0,0 +1,148 @@
+ 4xx/Axon EMAC ethernet nodes
+
+ The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
+ the Axon bridge. To operate this needs to interact with a ths
+ special McMAL DMA controller, and sometimes an RGMII or ZMII
+ interface. In addition to the nodes and properties described
+ below, the node for the OPB bus on which the EMAC sits must have a
+ correct clock-frequency property.
+
+ i) The EMAC node itself
+
+ Required properties:
+ - device_type : "network"
+
+ - compatible : compatible list, contains 2 entries, first is
+ "ibm,emac-CHIP" where CHIP is the host ASIC (440gx,
+ 405gp, Axon) and second is either "ibm,emac" or
+ "ibm,emac4". For Axon, thus, we have: "ibm,emac-axon",
+ "ibm,emac4"
+ - interrupts : <interrupt mapping for EMAC IRQ and WOL IRQ>
+ - interrupt-parent : optional, if needed for interrupt mapping
+ - reg : <registers mapping>
+ - local-mac-address : 6 bytes, MAC address
+ - mal-device : phandle of the associated McMAL node
+ - mal-tx-channel : 1 cell, index of the tx channel on McMAL associated
+ with this EMAC
+ - mal-rx-channel : 1 cell, index of the rx channel on McMAL associated
+ with this EMAC
+ - cell-index : 1 cell, hardware index of the EMAC cell on a given
+ ASIC (typically 0x0 and 0x1 for EMAC0 and EMAC1 on
+ each Axon chip)
+ - max-frame-size : 1 cell, maximum frame size supported in bytes
+ - rx-fifo-size : 1 cell, Rx fifo size in bytes for 10 and 100 Mb/sec
+ operations.
+ For Axon, 2048
+ - tx-fifo-size : 1 cell, Tx fifo size in bytes for 10 and 100 Mb/sec
+ operations.
+ For Axon, 2048.
+ - fifo-entry-size : 1 cell, size of a fifo entry (used to calculate
+ thresholds).
+ For Axon, 0x00000010
+ - mal-burst-size : 1 cell, MAL burst size (used to calculate thresholds)
+ in bytes.
+ For Axon, 0x00000100 (I think ...)
+ - phy-mode : string, mode of operations of the PHY interface.
+ Supported values are: "mii", "rmii", "smii", "rgmii",
+ "tbi", "gmii", rtbi", "sgmii".
+ For Axon on CAB, it is "rgmii"
+ - mdio-device : 1 cell, required iff using shared MDIO registers
+ (440EP). phandle of the EMAC to use to drive the
+ MDIO lines for the PHY used by this EMAC.
+ - zmii-device : 1 cell, required iff connected to a ZMII. phandle of
+ the ZMII device node
+ - zmii-channel : 1 cell, required iff connected to a ZMII. Which ZMII
+ channel or 0xffffffff if ZMII is only used for MDIO.
+ - rgmii-device : 1 cell, required iff connected to an RGMII. phandle
+ of the RGMII device node.
+ For Axon: phandle of plb5/plb4/opb/rgmii
+ - rgmii-channel : 1 cell, required iff connected to an RGMII. Which
+ RGMII channel is used by this EMAC.
+ Fox Axon: present, whatever value is appropriate for each
+ EMAC, that is the content of the current (bogus) "phy-port"
+ property.
+
+ Optional properties:
+ - phy-address : 1 cell, optional, MDIO address of the PHY. If absent,
+ a search is performed.
+ - phy-map : 1 cell, optional, bitmap of addresses to probe the PHY
+ for, used if phy-address is absent. bit 0x00000001 is
+ MDIO address 0.
+ For Axon it can be absent, though my current driver
+ doesn't handle phy-address yet so for now, keep
+ 0x00ffffff in it.
+ - rx-fifo-size-gige : 1 cell, Rx fifo size in bytes for 1000 Mb/sec
+ operations (if absent the value is the same as
+ rx-fifo-size). For Axon, either absent or 2048.
+ - tx-fifo-size-gige : 1 cell, Tx fifo size in bytes for 1000 Mb/sec
+ operations (if absent the value is the same as
+ tx-fifo-size). For Axon, either absent or 2048.
+ - tah-device : 1 cell, optional. If connected to a TAH engine for
+ offload, phandle of the TAH device node.
+ - tah-channel : 1 cell, optional. If appropriate, channel used on the
+ TAH engine.
+
+ Example:
+
+ EMAC0: ethernet@40000800 {
+ device_type = "network";
+ compatible = "ibm,emac-440gp", "ibm,emac";
+ interrupt-parent = <&UIC1>;
+ interrupts = <1c 4 1d 4>;
+ reg = <40000800 70>;
+ local-mac-address = [00 04 AC E3 1B 1E];
+ mal-device = <&MAL0>;
+ mal-tx-channel = <0 1>;
+ mal-rx-channel = <0>;
+ cell-index = <0>;
+ max-frame-size = <5dc>;
+ rx-fifo-size = <1000>;
+ tx-fifo-size = <800>;
+ phy-mode = "rmii";
+ phy-map = <00000001>;
+ zmii-device = <&ZMII0>;
+ zmii-channel = <0>;
+ };
+
+ ii) McMAL node
+
+ Required properties:
+ - device_type : "dma-controller"
+ - compatible : compatible list, containing 2 entries, first is
+ "ibm,mcmal-CHIP" where CHIP is the host ASIC (like
+ emac) and the second is either "ibm,mcmal" or
+ "ibm,mcmal2".
+ For Axon, "ibm,mcmal-axon","ibm,mcmal2"
+ - interrupts : <interrupt mapping for the MAL interrupts sources:
+ 5 sources: tx_eob, rx_eob, serr, txde, rxde>.
+ For Axon: This is _different_ from the current
+ firmware. We use the "delayed" interrupts for txeob
+ and rxeob. Thus we end up with mapping those 5 MPIC
+ interrupts, all level positive sensitive: 10, 11, 32,
+ 33, 34 (in decimal)
+ - dcr-reg : < DCR registers range >
+ - dcr-parent : if needed for dcr-reg
+ - num-tx-chans : 1 cell, number of Tx channels
+ - num-rx-chans : 1 cell, number of Rx channels
+
+ iii) ZMII node
+
+ Required properties:
+ - compatible : compatible list, containing 2 entries, first is
+ "ibm,zmii-CHIP" where CHIP is the host ASIC (like
+ EMAC) and the second is "ibm,zmii".
+ For Axon, there is no ZMII node.
+ - reg : <registers mapping>
+
+ iv) RGMII node
+
+ Required properties:
+ - compatible : compatible list, containing 2 entries, first is
+ "ibm,rgmii-CHIP" where CHIP is the host ASIC (like
+ EMAC) and the second is "ibm,rgmii".
+ For Axon, "ibm,rgmii-axon","ibm,rgmii"
+ - reg : <registers mapping>
+ - revision : as provided by the RGMII new version register if
+ available.
+ For Axon: 0x0000012a
+
diff --git a/Documentation/powerpc/dts-bindings/gpio/gpio.txt b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
new file mode 100644
index 0000000..edaa84d
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/gpio.txt
@@ -0,0 +1,50 @@
+Specifying GPIO information for devices
+============================================
+
+1) gpios property
+-----------------
+
+Nodes that makes use of GPIOs should define them using `gpios' property,
+format of which is: <&gpio-controller1-phandle gpio1-specifier
+ &gpio-controller2-phandle gpio2-specifier
+ 0 /* holes are permitted, means no GPIO 3 */
+ &gpio-controller4-phandle gpio4-specifier
+ ...>;
+
+Note that gpio-specifier length is controller dependent.
+
+gpio-specifier may encode: bank, pin position inside the bank,
+whether pin is open-drain and whether pin is logically inverted.
+
+Example of the node using GPIOs:
+
+ node {
+ gpios = <&qe_pio_e 18 0>;
+ };
+
+In this example gpio-specifier is "18 0" and encodes GPIO pin number,
+and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+
+2) gpio-controller nodes
+------------------------
+
+Every GPIO controller node must have #gpio-cells property defined,
+this information will be used to translate gpio-specifiers.
+
+Example of two SOC GPIO banks defined as gpio-controller nodes:
+
+ qe_pio_a: gpio-controller@1400 {
+ #gpio-cells = <2>;
+ compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
+ reg = <0x1400 0x18>;
+ gpio-controller;
+ };
+
+ qe_pio_e: gpio-controller@1460 {
+ #gpio-cells = <2>;
+ compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ };
+
+
diff --git a/Documentation/powerpc/dts-bindings/gpio/mdio.txt b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
new file mode 100644
index 0000000..bc95495
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/gpio/mdio.txt
@@ -0,0 +1,19 @@
+MDIO on GPIOs
+
+Currently defined compatibles:
+- virtual,gpio-mdio
+
+MDC and MDIO lines connected to GPIO controllers are listed in the
+gpios property as described in section VIII.1 in the following order:
+
+MDC, MDIO.
+
+Example:
+
+mdio {
+ compatible = "virtual,mdio-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpios = <&qe_pio_a 11
+ &qe_pio_c 6>;
+};
diff --git a/Documentation/powerpc/dts-bindings/marvell.txt b/Documentation/powerpc/dts-bindings/marvell.txt
new file mode 100644
index 0000000..3708a2f
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/marvell.txt
@@ -0,0 +1,521 @@
+Marvell Discovery mv64[345]6x System Controller chips
+===========================================================
+
+The Marvell mv64[345]60 series of system controller chips contain
+many of the peripherals needed to implement a complete computer
+system. In this section, we define device tree nodes to describe
+the system controller chip itself and each of the peripherals
+which it contains. Compatible string values for each node are
+prefixed with the string "marvell,", for Marvell Technology Group Ltd.
+
+1) The /system-controller node
+
+ This node is used to represent the system-controller and must be
+ present when the system uses a system controller chip. The top-level
+ system-controller node contains information that is global to all
+ devices within the system controller chip. The node name begins
+ with "system-controller" followed by the unit address, which is
+ the base address of the memory-mapped register set for the system
+ controller chip.
+
+ Required properties:
+
+ - ranges : Describes the translation of system controller addresses
+ for memory mapped registers.
+ - clock-frequency: Contains the main clock frequency for the system
+ controller chip.
+ - reg : This property defines the address and size of the
+ memory-mapped registers contained within the system controller
+ chip. The address specified in the "reg" property should match
+ the unit address of the system-controller node.
+ - #address-cells : Address representation for system controller
+ devices. This field represents the number of cells needed to
+ represent the address of the memory-mapped registers of devices
+ within the system controller chip.
+ - #size-cells : Size representation for for the memory-mapped
+ registers within the system controller chip.
+ - #interrupt-cells : Defines the width of cells used to represent
+ interrupts.
+
+ Optional properties:
+
+ - model : The specific model of the system controller chip. Such
+ as, "mv64360", "mv64460", or "mv64560".
+ - compatible : A string identifying the compatibility identifiers
+ of the system controller chip.
+
+ The system-controller node contains child nodes for each system
+ controller device that the platform uses. Nodes should not be created
+ for devices which exist on the system controller chip but are not used
+
+ Example Marvell Discovery mv64360 system-controller node:
+
+ system-controller@f1000000 { /* Marvell Discovery mv64360 */
+ #address-cells = <1>;
+ #size-cells = <1>;
+ model = "mv64360"; /* Default */
+ compatible = "marvell,mv64360";
+ clock-frequency = <133333333>;
+ reg = <0xf1000000 0x10000>;
+ virtual-reg = <0xf1000000>;
+ ranges = <0x88000000 0x88000000 0x1000000 /* PCI 0 I/O Space */
+ 0x80000000 0x80000000 0x8000000 /* PCI 0 MEM Space */
+ 0xa0000000 0xa0000000 0x4000000 /* User FLASH */
+ 0x00000000 0xf1000000 0x0010000 /* Bridge's regs */
+ 0xf2000000 0xf2000000 0x0040000>;/* Integrated SRAM */
+
+ [ child node definitions... ]
+ }
+
+2) Child nodes of /system-controller
+
+ a) Marvell Discovery MDIO bus
+
+ The MDIO is a bus to which the PHY devices are connected. For each
+ device that exists on this bus, a child node should be created. See
+ the definition of the PHY node below for an example of how to define
+ a PHY.
+
+ Required properties:
+ - #address-cells : Should be <1>
+ - #size-cells : Should be <0>
+ - device_type : Should be "mdio"
+ - compatible : Should be "marvell,mv64360-mdio"
+
+ Example:
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "marvell,mv64360-mdio";
+
+ ethernet-phy@0 {
+ ......
+ };
+ };
+
+
+ b) Marvell Discovery ethernet controller
+
+ The Discover ethernet controller is described with two levels
+ of nodes. The first level describes an ethernet silicon block
+ and the second level describes up to 3 ethernet nodes within
+ that block. The reason for the multiple levels is that the
+ registers for the node are interleaved within a single set
+ of registers. The "ethernet-block" level describes the
+ shared register set, and the "ethernet" nodes describe ethernet
+ port-specific properties.
+
+ Ethernet block node
+
+ Required properties:
+ - #address-cells : <1>
+ - #size-cells : <0>
+ - compatible : "marvell,mv64360-eth-block"
+ - reg : Offset and length of the register set for this block
+
+ Example Discovery Ethernet block node:
+ ethernet-block@2000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "marvell,mv64360-eth-block";
+ reg = <0x2000 0x2000>;
+ ethernet@0 {
+ .......
+ };
+ };
+
+ Ethernet port node
+
+ Required properties:
+ - device_type : Should be "network".
+ - compatible : Should be "marvell,mv64360-eth".
+ - reg : Should be <0>, <1>, or <2>, according to which registers
+ within the silicon block the device uses.
+ - interrupts : <a> where a is the interrupt number for the port.
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+ - phy : the phandle for the PHY connected to this ethernet
+ controller.
+ - local-mac-address : 6 bytes, MAC address
+
+ Example Discovery Ethernet port node:
+ ethernet@0 {
+ device_type = "network";
+ compatible = "marvell,mv64360-eth";
+ reg = <0>;
+ interrupts = <32>;
+ interrupt-parent = <&PIC>;
+ phy = <&PHY0>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+
+
+ c) Marvell Discovery PHY nodes
+
+ Required properties:
+ - device_type : Should be "ethernet-phy"
+ - interrupts : <a> where a is the interrupt number for this phy.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - reg : The ID number for the phy, usually a small integer
+
+ Example Discovery PHY node:
+ ethernet-phy@1 {
+ device_type = "ethernet-phy";
+ compatible = "broadcom,bcm5421";
+ interrupts = <76>; /* GPP 12 */
+ interrupt-parent = <&PIC>;
+ reg = <1>;
+ };
+
+
+ d) Marvell Discovery SDMA nodes
+
+ Represent DMA hardware associated with the MPSC (multiprotocol
+ serial controllers).
+
+ Required properties:
+ - compatible : "marvell,mv64360-sdma"
+ - reg : Offset and length of the register set for this device
+ - interrupts : <a> where a is the interrupt number for the DMA
+ device.
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery SDMA node:
+ sdma@4000 {
+ compatible = "marvell,mv64360-sdma";
+ reg = <0x4000 0xc18>;
+ virtual-reg = <0xf1004000>;
+ interrupts = <36>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ e) Marvell Discovery BRG nodes
+
+ Represent baud rate generator hardware associated with the MPSC
+ (multiprotocol serial controllers).
+
+ Required properties:
+ - compatible : "marvell,mv64360-brg"
+ - reg : Offset and length of the register set for this device
+ - clock-src : A value from 0 to 15 which selects the clock
+ source for the baud rate generator. This value corresponds
+ to the CLKS value in the BRGx configuration register. See
+ the mv64x60 User's Manual.
+ - clock-frequence : The frequency (in Hz) of the baud rate
+ generator's input clock.
+ - current-speed : The current speed setting (presumably by
+ firmware) of the baud rate generator.
+
+ Example Discovery BRG node:
+ brg@b200 {
+ compatible = "marvell,mv64360-brg";
+ reg = <0xb200 0x8>;
+ clock-src = <8>;
+ clock-frequency = <133333333>;
+ current-speed = <9600>;
+ };
+
+
+ f) Marvell Discovery CUNIT nodes
+
+ Represent the Serial Communications Unit device hardware.
+
+ Required properties:
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery CUNIT node:
+ cunit@f200 {
+ reg = <0xf200 0x200>;
+ };
+
+
+ g) Marvell Discovery MPSCROUTING nodes
+
+ Represent the Discovery's MPSC routing hardware
+
+ Required properties:
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery CUNIT node:
+ mpscrouting@b500 {
+ reg = <0xb400 0xc>;
+ };
+
+
+ h) Marvell Discovery MPSCINTR nodes
+
+ Represent the Discovery's MPSC DMA interrupt hardware registers
+ (SDMA cause and mask registers).
+
+ Required properties:
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery MPSCINTR node:
+ mpsintr@b800 {
+ reg = <0xb800 0x100>;
+ };
+
+
+ i) Marvell Discovery MPSC nodes
+
+ Represent the Discovery's MPSC (Multiprotocol Serial Controller)
+ serial port.
+
+ Required properties:
+ - device_type : "serial"
+ - compatible : "marvell,mv64360-mpsc"
+ - reg : Offset and length of the register set for this device
+ - sdma : the phandle for the SDMA node used by this port
+ - brg : the phandle for the BRG node used by this port
+ - cunit : the phandle for the CUNIT node used by this port
+ - mpscrouting : the phandle for the MPSCROUTING node used by this port
+ - mpscintr : the phandle for the MPSCINTR node used by this port
+ - cell-index : the hardware index of this cell in the MPSC core
+ - max_idle : value needed for MPSC CHR3 (Maximum Frame Length)
+ register
+ - interrupts : <a> where a is the interrupt number for the MPSC.
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery MPSCINTR node:
+ mpsc@8000 {
+ device_type = "serial";
+ compatible = "marvell,mv64360-mpsc";
+ reg = <0x8000 0x38>;
+ virtual-reg = <0xf1008000>;
+ sdma = <&SDMA0>;
+ brg = <&BRG0>;
+ cunit = <&CUNIT>;
+ mpscrouting = <&MPSCROUTING>;
+ mpscintr = <&MPSCINTR>;
+ cell-index = <0>;
+ max_idle = <40>;
+ interrupts = <40>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ j) Marvell Discovery Watch Dog Timer nodes
+
+ Represent the Discovery's watchdog timer hardware
+
+ Required properties:
+ - compatible : "marvell,mv64360-wdt"
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery Watch Dog Timer node:
+ wdt@b410 {
+ compatible = "marvell,mv64360-wdt";
+ reg = <0xb410 0x8>;
+ };
+
+
+ k) Marvell Discovery I2C nodes
+
+ Represent the Discovery's I2C hardware
+
+ Required properties:
+ - device_type : "i2c"
+ - compatible : "marvell,mv64360-i2c"
+ - reg : Offset and length of the register set for this device
+ - interrupts : <a> where a is the interrupt number for the I2C.
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery I2C node:
+ compatible = "marvell,mv64360-i2c";
+ reg = <0xc000 0x20>;
+ virtual-reg = <0xf100c000>;
+ interrupts = <37>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes
+
+ Represent the Discovery's PIC hardware
+
+ Required properties:
+ - #interrupt-cells : <1>
+ - #address-cells : <0>
+ - compatible : "marvell,mv64360-pic"
+ - reg : Offset and length of the register set for this device
+ - interrupt-controller
+
+ Example Discovery PIC node:
+ pic {
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ compatible = "marvell,mv64360-pic";
+ reg = <0x0 0x88>;
+ interrupt-controller;
+ };
+
+
+ m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes
+
+ Represent the Discovery's MPP hardware
+
+ Required properties:
+ - compatible : "marvell,mv64360-mpp"
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery MPP node:
+ mpp@f000 {
+ compatible = "marvell,mv64360-mpp";
+ reg = <0xf000 0x10>;
+ };
+
+
+ n) Marvell Discovery GPP (General Purpose Pins) nodes
+
+ Represent the Discovery's GPP hardware
+
+ Required properties:
+ - compatible : "marvell,mv64360-gpp"
+ - reg : Offset and length of the register set for this device
+
+ Example Discovery GPP node:
+ gpp@f000 {
+ compatible = "marvell,mv64360-gpp";
+ reg = <0xf100 0x20>;
+ };
+
+
+ o) Marvell Discovery PCI host bridge node
+
+ Represents the Discovery's PCI host bridge device. The properties
+ for this node conform to Rev 2.1 of the PCI Bus Binding to IEEE
+ 1275-1994. A typical value for the compatible property is
+ "marvell,mv64360-pci".
+
+ Example Discovery PCI host bridge node
+ pci@80000000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "marvell,mv64360-pci";
+ reg = <0xcf8 0x8>;
+ ranges = <0x01000000 0x0 0x0
+ 0x88000000 0x0 0x01000000
+ 0x02000000 0x0 0x80000000
+ 0x80000000 0x0 0x08000000>;
+ bus-range = <0 255>;
+ clock-frequency = <66000000>;
+ interrupt-parent = <&PIC>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x0a */
+ 0x5000 0 0 1 &PIC 80
+ 0x5000 0 0 2 &PIC 81
+ 0x5000 0 0 3 &PIC 91
+ 0x5000 0 0 4 &PIC 93
+
+ /* IDSEL 0x0b */
+ 0x5800 0 0 1 &PIC 91
+ 0x5800 0 0 2 &PIC 93
+ 0x5800 0 0 3 &PIC 80
+ 0x5800 0 0 4 &PIC 81
+
+ /* IDSEL 0x0c */
+ 0x6000 0 0 1 &PIC 91
+ 0x6000 0 0 2 &PIC 93
+ 0x6000 0 0 3 &PIC 80
+ 0x6000 0 0 4 &PIC 81
+
+ /* IDSEL 0x0d */
+ 0x6800 0 0 1 &PIC 93
+ 0x6800 0 0 2 &PIC 80
+ 0x6800 0 0 3 &PIC 81
+ 0x6800 0 0 4 &PIC 91
+ >;
+ };
+
+
+ p) Marvell Discovery CPU Error nodes
+
+ Represent the Discovery's CPU error handler device.
+
+ Required properties:
+ - compatible : "marvell,mv64360-cpu-error"
+ - reg : Offset and length of the register set for this device
+ - interrupts : the interrupt number for this device
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery CPU Error node:
+ cpu-error@0070 {
+ compatible = "marvell,mv64360-cpu-error";
+ reg = <0x70 0x10 0x128 0x28>;
+ interrupts = <3>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ q) Marvell Discovery SRAM Controller nodes
+
+ Represent the Discovery's SRAM controller device.
+
+ Required properties:
+ - compatible : "marvell,mv64360-sram-ctrl"
+ - reg : Offset and length of the register set for this device
+ - interrupts : the interrupt number for this device
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery SRAM Controller node:
+ sram-ctrl@0380 {
+ compatible = "marvell,mv64360-sram-ctrl";
+ reg = <0x380 0x80>;
+ interrupts = <13>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ r) Marvell Discovery PCI Error Handler nodes
+
+ Represent the Discovery's PCI error handler device.
+
+ Required properties:
+ - compatible : "marvell,mv64360-pci-error"
+ - reg : Offset and length of the register set for this device
+ - interrupts : the interrupt number for this device
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery PCI Error Handler node:
+ pci-error@1d40 {
+ compatible = "marvell,mv64360-pci-error";
+ reg = <0x1d40 0x40 0xc28 0x4>;
+ interrupts = <12>;
+ interrupt-parent = <&PIC>;
+ };
+
+
+ s) Marvell Discovery Memory Controller nodes
+
+ Represent the Discovery's memory controller device.
+
+ Required properties:
+ - compatible : "marvell,mv64360-mem-ctrl"
+ - reg : Offset and length of the register set for this device
+ - interrupts : the interrupt number for this device
+ - interrupt-parent : the phandle for the interrupt controller
+ that services interrupts for this device.
+
+ Example Discovery Memory Controller node:
+ mem-ctrl@1400 {
+ compatible = "marvell,mv64360-mem-ctrl";
+ reg = <0x1400 0x60>;
+ interrupts = <17>;
+ interrupt-parent = <&PIC>;
+ };
+
+
diff --git a/Documentation/powerpc/dts-bindings/phy.txt b/Documentation/powerpc/dts-bindings/phy.txt
new file mode 100644
index 0000000..bb8c742
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/phy.txt
@@ -0,0 +1,25 @@
+PHY nodes
+
+Required properties:
+
+ - device_type : Should be "ethernet-phy"
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - reg : The ID number for the phy, usually a small integer
+ - linux,phandle : phandle for this node; likely referenced by an
+ ethernet controller node.
+
+Example:
+
+ethernet-phy@0 {
+ linux,phandle = <2452000>
+ interrupt-parent = <40000>;
+ interrupts = <35 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+};
diff --git a/Documentation/powerpc/dts-bindings/spi-bus.txt b/Documentation/powerpc/dts-bindings/spi-bus.txt
new file mode 100644
index 0000000..e782add
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/spi-bus.txt
@@ -0,0 +1,57 @@
+SPI (Serial Peripheral Interface) busses
+
+SPI busses can be described with a node for the SPI master device
+and a set of child nodes for each SPI slave on the bus. For this
+discussion, it is assumed that the system's SPI controller is in
+SPI master mode. This binding does not describe SPI controllers
+in slave mode.
+
+The SPI master node requires the following properties:
+- #address-cells - number of cells required to define a chip select
+ address on the SPI bus.
+- #size-cells - should be zero.
+- compatible - name of SPI bus controller following generic names
+ recommended practice.
+No other properties are required in the SPI bus node. It is assumed
+that a driver for an SPI bus device will understand that it is an SPI bus.
+However, the binding does not attempt to define the specific method for
+assigning chip select numbers. Since SPI chip select configuration is
+flexible and non-standardized, it is left out of this binding with the
+assumption that board specific platform code will be used to manage
+chip selects. Individual drivers can define additional properties to
+support describing the chip select layout.
+
+SPI slave nodes must be children of the SPI master node and can
+contain the following properties.
+- reg - (required) chip select address of device.
+- compatible - (required) name of SPI device following generic names
+ recommended practice
+- spi-max-frequency - (required) Maximum SPI clocking speed of device in Hz
+- spi-cpol - (optional) Empty property indicating device requires
+ inverse clock polarity (CPOL) mode
+- spi-cpha - (optional) Empty property indicating device requires
+ shifted clock phase (CPHA) mode
+- spi-cs-high - (optional) Empty property indicating device requires
+ chip select active high
+
+SPI example for an MPC5200 SPI bus:
+ spi@f00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
+ reg = <0xf00 0x20>;
+ interrupts = <2 13 0 2 14 0>;
+ interrupt-parent = <&mpc5200_pic>;
+
+ ethernet-switch@0 {
+ compatible = "micrel,ks8995m";
+ spi-max-frequency = <1000000>;
+ reg = <0>;
+ };
+
+ codec@1 {
+ compatible = "ti,tlv320aic26";
+ spi-max-frequency = <100000>;
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/powerpc/dts-bindings/usb-ehci.txt b/Documentation/powerpc/dts-bindings/usb-ehci.txt
new file mode 100644
index 0000000..fa18612
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/usb-ehci.txt
@@ -0,0 +1,25 @@
+USB EHCI controllers
+
+Required properties:
+ - compatible : should be "usb-ehci".
+ - reg : should contain at least address and length of the standard EHCI
+ register set for the device. Optional platform-dependent registers
+ (debug-port or other) can be also specified here, but only after
+ definition of standard EHCI registers.
+ - interrupts : one EHCI interrupt should be described here.
+If device registers are implemented in big endian mode, the device
+node should have "big-endian-regs" property.
+If controller implementation operates with big endian descriptors,
+"big-endian-desc" property should be specified.
+If both big endian registers and descriptors are used by the controller
+implementation, "big-endian" property can be specified instead of having
+both "big-endian-regs" and "big-endian-desc".
+
+Example (Sequoia 440EPx):
+ ehci@e0000300 {
+ compatible = "ibm,usb-ehci-440epx", "usb-ehci";
+ interrupt-parent = <&UIC0>;
+ interrupts = <1a 4>;
+ reg = <0 e0000300 90 0 e0000390 70>;
+ big-endian;
+ };
diff --git a/Documentation/powerpc/dts-bindings/xilinx.txt b/Documentation/powerpc/dts-bindings/xilinx.txt
new file mode 100644
index 0000000..80339fe
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/xilinx.txt
@@ -0,0 +1,295 @@
+ d) Xilinx IP cores
+
+ The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
+ in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
+ of standard device types (network, serial, etc.) and miscellaneous
+ devices (gpio, LCD, spi, etc). Also, since these devices are
+ implemented within the fpga fabric every instance of the device can be
+ synthesised with different options that change the behaviour.
+
+ Each IP-core has a set of parameters which the FPGA designer can use to
+ control how the core is synthesized. Historically, the EDK tool would
+ extract the device parameters relevant to device drivers and copy them
+ into an 'xparameters.h' in the form of #define symbols. This tells the
+ device drivers how the IP cores are configured, but it requres the kernel
+ to be recompiled every time the FPGA bitstream is resynthesized.
+
+ The new approach is to export the parameters into the device tree and
+ generate a new device tree each time the FPGA bitstream changes. The
+ parameters which used to be exported as #defines will now become
+ properties of the device node. In general, device nodes for IP-cores
+ will take the following form:
+
+ (name): (generic-name)@(base-address) {
+ compatible = "xlnx,(ip-core-name)-(HW_VER)"
+ [, (list of compatible devices), ...];
+ reg = <(baseaddr) (size)>;
+ interrupt-parent = <&interrupt-controller-phandle>;
+ interrupts = < ... >;
+ xlnx,(parameter1) = "(string-value)";
+ xlnx,(parameter2) = <(int-value)>;
+ };
+
+ (generic-name): an open firmware-style name that describes the
+ generic class of device. Preferably, this is one word, such
+ as 'serial' or 'ethernet'.
+ (ip-core-name): the name of the ip block (given after the BEGIN
+ directive in system.mhs). Should be in lowercase
+ and all underscores '_' converted to dashes '-'.
+ (name): is derived from the "PARAMETER INSTANCE" value.
+ (parameter#): C_* parameters from system.mhs. The C_ prefix is
+ dropped from the parameter name, the name is converted
+ to lowercase and all underscore '_' characters are
+ converted to dashes '-'.
+ (baseaddr): the baseaddr parameter value (often named C_BASEADDR).
+ (HW_VER): from the HW_VER parameter.
+ (size): the address range size (often C_HIGHADDR - C_BASEADDR + 1).
+
+ Typically, the compatible list will include the exact IP core version
+ followed by an older IP core version which implements the same
+ interface or any other device with the same interface.
+
+ 'reg', 'interrupt-parent' and 'interrupts' are all optional properties.
+
+ For example, the following block from system.mhs:
+
+ BEGIN opb_uartlite
+ PARAMETER INSTANCE = opb_uartlite_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BAUDRATE = 115200
+ PARAMETER C_DATA_BITS = 8
+ PARAMETER C_ODD_PARITY = 0
+ PARAMETER C_USE_PARITY = 0
+ PARAMETER C_CLK_FREQ = 50000000
+ PARAMETER C_BASEADDR = 0xEC100000
+ PARAMETER C_HIGHADDR = 0xEC10FFFF
+ BUS_INTERFACE SOPB = opb_7
+ PORT OPB_Clk = CLK_50MHz
+ PORT Interrupt = opb_uartlite_0_Interrupt
+ PORT RX = opb_uartlite_0_RX
+ PORT TX = opb_uartlite_0_TX
+ PORT OPB_Rst = sys_bus_reset_0
+ END
+
+ becomes the following device tree node:
+
+ opb_uartlite_0: serial@ec100000 {
+ device_type = "serial";
+ compatible = "xlnx,opb-uartlite-1.00.b";
+ reg = <ec100000 10000>;
+ interrupt-parent = <&opb_intc_0>;
+ interrupts = <1 0>; // got this from the opb_intc parameters
+ current-speed = <d#115200>; // standard serial device prop
+ clock-frequency = <d#50000000>; // standard serial device prop
+ xlnx,data-bits = <8>;
+ xlnx,odd-parity = <0>;
+ xlnx,use-parity = <0>;
+ };
+
+ Some IP cores actually implement 2 or more logical devices. In
+ this case, the device should still describe the whole IP core with
+ a single node and add a child node for each logical device. The
+ ranges property can be used to translate from parent IP-core to the
+ registers of each device. In addition, the parent node should be
+ compatible with the bus type 'xlnx,compound', and should contain
+ #address-cells and #size-cells, as with any other bus. (Note: this
+ makes the assumption that both logical devices have the same bus
+ binding. If this is not true, then separate nodes should be used
+ for each logical device). The 'cell-index' property can be used to
+ enumerate logical devices within an IP core. For example, the
+ following is the system.mhs entry for the dual ps2 controller found
+ on the ml403 reference design.
+
+ BEGIN opb_ps2_dual_ref
+ PARAMETER INSTANCE = opb_ps2_dual_ref_0
+ PARAMETER HW_VER = 1.00.a
+ PARAMETER C_BASEADDR = 0xA9000000
+ PARAMETER C_HIGHADDR = 0xA9001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ PORT Sys_Intr1 = ps2_1_intr
+ PORT Sys_Intr2 = ps2_2_intr
+ PORT Clkin1 = ps2_clk_rx_1
+ PORT Clkin2 = ps2_clk_rx_2
+ PORT Clkpd1 = ps2_clk_tx_1
+ PORT Clkpd2 = ps2_clk_tx_2
+ PORT Rx1 = ps2_d_rx_1
+ PORT Rx2 = ps2_d_rx_2
+ PORT Txpd1 = ps2_d_tx_1
+ PORT Txpd2 = ps2_d_tx_2
+ END
+
+ It would result in the following device tree nodes:
+
+ opb_ps2_dual_ref_0: opb-ps2-dual-ref@a9000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,compound";
+ ranges = <0 a9000000 2000>;
+ // If this device had extra parameters, then they would
+ // go here.
+ ps2@0 {
+ compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+ reg = <0 40>;
+ interrupt-parent = <&opb_intc_0>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ ps2@1000 {
+ compatible = "xlnx,opb-ps2-dual-ref-1.00.a";
+ reg = <1000 40>;
+ interrupt-parent = <&opb_intc_0>;
+ interrupts = <3 0>;
+ cell-index = <0>;
+ };
+ };
+
+ Also, the system.mhs file defines bus attachments from the processor
+ to the devices. The device tree structure should reflect the bus
+ attachments. Again an example; this system.mhs fragment:
+
+ BEGIN ppc405_virtex4
+ PARAMETER INSTANCE = ppc405_0
+ PARAMETER HW_VER = 1.01.a
+ BUS_INTERFACE DPLB = plb_v34_0
+ BUS_INTERFACE IPLB = plb_v34_0
+ END
+
+ BEGIN opb_intc
+ PARAMETER INSTANCE = opb_intc_0
+ PARAMETER HW_VER = 1.00.c
+ PARAMETER C_BASEADDR = 0xD1000FC0
+ PARAMETER C_HIGHADDR = 0xD1000FDF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN opb_uart16550
+ PARAMETER INSTANCE = opb_uart16550_0
+ PARAMETER HW_VER = 1.00.d
+ PARAMETER C_BASEADDR = 0xa0000000
+ PARAMETER C_HIGHADDR = 0xa0001FFF
+ BUS_INTERFACE SOPB = opb_v20_0
+ END
+
+ BEGIN plb_v34
+ PARAMETER INSTANCE = plb_v34_0
+ PARAMETER HW_VER = 1.02.a
+ END
+
+ BEGIN plb_bram_if_cntlr
+ PARAMETER INSTANCE = plb_bram_if_cntlr_0
+ PARAMETER HW_VER = 1.00.b
+ PARAMETER C_BASEADDR = 0xFFFF0000
+ PARAMETER C_HIGHADDR = 0xFFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ END
+
+ BEGIN plb2opb_bridge
+ PARAMETER INSTANCE = plb2opb_bridge_0
+ PARAMETER HW_VER = 1.01.a
+ PARAMETER C_RNG0_BASEADDR = 0x20000000
+ PARAMETER C_RNG0_HIGHADDR = 0x3FFFFFFF
+ PARAMETER C_RNG1_BASEADDR = 0x60000000
+ PARAMETER C_RNG1_HIGHADDR = 0x7FFFFFFF
+ PARAMETER C_RNG2_BASEADDR = 0x80000000
+ PARAMETER C_RNG2_HIGHADDR = 0xBFFFFFFF
+ PARAMETER C_RNG3_BASEADDR = 0xC0000000
+ PARAMETER C_RNG3_HIGHADDR = 0xDFFFFFFF
+ BUS_INTERFACE SPLB = plb_v34_0
+ BUS_INTERFACE MOPB = opb_v20_0
+ END
+
+ Gives this device tree (some properties removed for clarity):
+
+ plb@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,plb-v34-1.02.a";
+ device_type = "ibm,plb";
+ ranges; // 1:1 translation
+
+ plb_bram_if_cntrl_0: bram@ffff0000 {
+ reg = <ffff0000 10000>;
+ }
+
+ opb@20000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <20000000 20000000 20000000
+ 60000000 60000000 20000000
+ 80000000 80000000 40000000
+ c0000000 c0000000 20000000>;
+
+ opb_uart16550_0: serial@a0000000 {
+ reg = <a00000000 2000>;
+ };
+
+ opb_intc_0: interrupt-controller@d1000fc0 {
+ reg = <d1000fc0 20>;
+ };
+ };
+ };
+
+ That covers the general approach to binding xilinx IP cores into the
+ device tree. The following are bindings for specific devices:
+
+ i) Xilinx ML300 Framebuffer
+
+ Simple framebuffer device from the ML300 reference design (also on the
+ ML403 reference design as well as others).
+
+ Optional properties:
+ - resolution = <xres yres> : pixel resolution of framebuffer. Some
+ implementations use a different resolution.
+ Default is <d#640 d#480>
+ - virt-resolution = <xvirt yvirt> : Size of framebuffer in memory.
+ Default is <d#1024 d#480>.
+ - rotate-display (empty) : rotate display 180 degrees.
+
+ ii) Xilinx SystemACE
+
+ The Xilinx SystemACE device is used to program FPGAs from an FPGA
+ bitstream stored on a CF card. It can also be used as a generic CF
+ interface device.
+
+ Optional properties:
+ - 8-bit (empty) : Set this property for SystemACE in 8 bit mode
+
+ iii) Xilinx EMAC and Xilinx TEMAC
+
+ Xilinx Ethernet devices. In addition to general xilinx properties
+ listed above, nodes for these devices should include a phy-handle
+ property, and may include other common network device properties
+ like local-mac-address.
+
+ iv) Xilinx Uartlite
+
+ Xilinx uartlite devices are simple fixed speed serial ports.
+
+ Required properties:
+ - current-speed : Baud rate of uartlite
+
+ v) Xilinx hwicap
+
+ Xilinx hwicap devices provide access to the configuration logic
+ of the FPGA through the Internal Configuration Access Port
+ (ICAP). The ICAP enables partial reconfiguration of the FPGA,
+ readback of the configuration information, and some control over
+ 'warm boots' of the FPGA fabric.
+
+ Required properties:
+ - xlnx,family : The family of the FPGA, necessary since the
+ capabilities of the underlying ICAP hardware
+ differ between different families. May be
+ 'virtex2p', 'virtex4', or 'virtex5'.
+
+ vi) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 but with
+ different register spacing and an offset from the base address.
+
+ Required properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
+
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
From: Anton Vorontsov @ 2009-06-19 15:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <7898009C-2A9D-45D3-8C2B-1AFA90C4CB31@kernel.crashing.org>
On Thu, Jun 18, 2009 at 09:25:46PM -0500, Kumar Gala wrote:
>
> On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote:
>
>> For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards,
>> so make 1-bit mode default. When we resolve the issue, u-boot will
>> remove sdhci,1-bit-only property from the device tree, while SDHCI
>> will still work with older u-boots.
>>
>> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
>> ---
>> arch/powerpc/boot/dts/mpc8569mds.dts | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> Did I miss the patch that adds this property defn. to our docs?
Yep. ;-)
http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/073394.html
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
From: Grant Likely @ 2009-06-19 15:31 UTC (permalink / raw)
To: avorontsov; +Cc: spi-devel-general, Rini van Zetten, linuxppc-dev list
In-Reply-To: <20090619132501.GA10886@oksana.dev.rtsoft.ru>
On Fri, Jun 19, 2009 at 7:25 AM, Anton
Vorontsov<avorontsov@ru.mvista.com> wrote:
> Surely we can hide the bridge into the SPI controller driver,
> but I think it would be beneficial to "factor-out" it to a
> stand-alone entity, so that other SPI controllers could work
> with this setup without any modifications (oh and btw, we could
> also create a bridge called "gpio-chipselects-bridge", and
> factor out all GPIO stuff from the drivers).
>
> There are two options of how we can factor out chip-select
> machines... the bad and the ugly. :-) No, the first one is bad,
> but the second should be OK.
[...]
> 2. Another option (which I like more), is to create "SPI chip-
> =A0 select machine driver framework", so we could (finally)
> =A0 separate two SPI entities: SPI IO and SPI chip-select machine.
> =A0 CS machines of different flavours: GPIO, built-in, and
> =A0 board-specific (!) with a lot of demuxing magic.
I agree, I think your option 2 is the way to go. It would probably
need to be implemented as some form of logical bridge so that SPI
requests don't go straight to the IO driver, but first go through the
CS machine so that the CS driver can do funky stuff like inserting or
modifying SPI requests before they go to the hardware.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH -mm v4][POWERPC] mpc8xxx : allow SPI without cs.
From: Rini van Zetten @ 2009-06-19 14:18 UTC (permalink / raw)
To: avorontsov; +Cc: spi-devel-general, linuxppc-dev list
In-Reply-To: <20090619134558.GA18872@oksana.dev.rtsoft.ru>
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = <&pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
&pio2 2 0>; /* cs2 */
This feature is needed on our home made board to program an onboard fpga.
The fpga needs some special pin toggling to put it in programming mode.
That's why we want to skip the usual gpio cs and do the pin toggling
in our driver
Signed-off-by: Rini van Zetten <rini@arvoo.nl>
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Changes :
patch against 2.6.30-rc8-mm1
style updates
compiler warning fix
v4 :
missing space in error text added
splitted lines combined
diff --git a/drivers/spi/spi_mpc8xxx.c b/drivers/spi/spi_mpc8xxx.c
index 0fd0ec4..de95790 100644
--- a/drivers/spi/spi_mpc8xxx.c
+++ b/drivers/spi/spi_mpc8xxx.c
@@ -666,9 +666,12 @@ static void mpc8xxx_spi_cs_control(struct spi_device *spi, bool on)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev->platform_data);
u16 cs = spi->chip_select;
int gpio = pinfo->gpios[cs];
- bool alow = pinfo->alow_flags[cs];
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo->alow_flags[cs];
+
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -678,7 +681,7 @@ static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(pdata);
unsigned int ngpios;
int i = 0;
- int ret;
+ int ret = 0;
ngpios = of_gpio_count(np);
if (!ngpios) {
@@ -707,27 +710,30 @@ static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, &flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, "can't request gpio #%d: %d\n",
+ i, ret);
+ goto err_loop;
+ }
+
+ pinfo->gpios[i] = gpio;
+ pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo->gpios[i],
+ pinfo->alow_flags[i]);
+ if (ret) {
+ dev_err(dev, "can't set output direction for "
+ "gpio #%d: %d\n", i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo->gpios[i] = -EEXIST;
+ } else {
dev_err(dev, "invalid gpio #%d: %d\n", i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, "can't request gpio #%d: %d\n", i, ret);
- goto err_loop;
- }
-
- pinfo->gpios[i] = gpio;
- pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
- if (ret) {
- dev_err(dev, "can't set output direction for gpio "
- "#%d: %d\n", i, ret);
- goto err_loop;
- }
}
pdata->max_chipselect = ngpios;
^ permalink raw reply related
* [RFC] Fix stuck on cpm-i2c driver
From: Michael Trimarchi @ 2009-06-19 12:50 UTC (permalink / raw)
To: jochen; +Cc: bruno, trimarchi, linux-i2c, linuxppc-dev
When a process tries to read/write a disconnected i2c device, it receives a signal (e.g. ctrl-c) and the kernel gets stuck.
BUG: soft lockup - CPU#0 stuck for 61s! [I2CEEpromTest:392]
NIP: c01628f8 LR: c01628f0 CTR: c00177cc
REGS: c39abd70 TRAP: 0901 Not tainted (2.6.25.7-alcore)
MSR: 00009032 <EE,ME,IR,DR> CR: 42042048 XER: 20000000
TASK = c3889bd0[392] 'I2CEEpromTest' THREAD: c39aa000
GPR00: 00009000 c39abe20 c3889bd0 c39075c8 c39abe28 00000001 00000000 00000001
GPR08: c3889bd0 c39075c8 00009032 c39abe34 00002437
NIP [c01628f8] cpm_i2c_xfer+0x5fc/0x6d0
LR [c01628f0] cpm_i2c_xfer+0x5f4/0x6d0
Call Trace:
[c39abe20] [c0162924] cpm_i2c_xfer+0x628/0x6d0 (unreliable)
[c39abe90] [c015f6a0] i2c_transfer+0x88/0xb4
[c39abeb0] [c0160164] i2c_master_recv+0x48/0x6c
[c39abed0] [c01618dc] i2cdev_read+0x50/0xe4
[c39abef0] [c0068b24] vfs_read+0xc4/0x108
[c39abf10] [c0068f4c] sys_read+0x4c/0x90
[c39abf40] [c000d348] ret_from_syscall+0x0/0x38
Instruction dump:
3bc00064 92610010 3bf201c8 92810014 3b61
This happen because though the wait_event_interruptible_timeout takes the
signals into account, the driver does not handle them.
We propose to change the wait_event_interruptible_timeout with
wait_event_timeout, leaving the signals to be handled in other points
on the upper layers.
Signed-off-by: Bruno Morelli <bruno@evidence.eu.com>
Signed-off-by: Michael Trimarchi <michael@evidence.eu.com>
---
diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c
index b5db8b8..9c2e100 100644
--- a/drivers/i2c/busses/i2c-cpm.c
+++ b/drivers/i2c/busses/i2c-cpm.c
@@ -140,7 +140,7 @@ static irqreturn_t cpm_i2c_interrupt(int irq, void *dev_id)
dev_dbg(&adap->dev, "Interrupt: %x\n", i);
- wake_up_interruptible(&cpm->i2c_wait);
+ wake_up(&cpm->i2c_wait);
return i ? IRQ_HANDLED : IRQ_NONE;
}
@@ -364,12 +364,12 @@ static int cpm_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)
dev_dbg(&adap->dev, "test ready.\n");
pmsg = &msgs[tptr];
if (pmsg->flags & I2C_M_RD)
- ret = wait_event_interruptible_timeout(cpm->i2c_wait,
+ ret = wait_event_timeout(cpm->i2c_wait,
(in_be16(&tbdf[tptr].cbd_sc) & BD_SC_NAK) ||
!(in_be16(&rbdf[rptr].cbd_sc) & BD_SC_EMPTY),
1 * HZ);
else
- ret = wait_event_interruptible_timeout(cpm->i2c_wait,
+ ret = wait_event_timeout(cpm->i2c_wait,
!(in_be16(&tbdf[tptr].cbd_sc) & BD_SC_READY),
1 * HZ);
if (ret == 0) {
^ permalink raw reply related
* Re: [PATCH -mm v3][POWERPC] mpc8xxx : allow SPI without cs.
From: Anton Vorontsov @ 2009-06-19 13:45 UTC (permalink / raw)
To: Rini van Zetten; +Cc: spi-devel-general, linuxppc-dev list
In-Reply-To: <4A3B3D90.5030100@arvoo.nl>
On Fri, Jun 19, 2009 at 09:26:08AM +0200, Rini van Zetten wrote:
> This patch adds the possibility to have a spi device without a cs.
>
> For example, the dts file should look something like this:
>
> spi-controller {
> gpios = <&pio1 1 0 /* cs0 */
> 0 /* cs1, no GPIO */
> &pio2 2 0>; /* cs2 */
>
> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
> ---
> Changes :
> patch against 2.6.30-rc8-mm1
> style updates
> compiler warning fix
> comment :
> This feature is needed on our home made board to program an onboard fpga.
> The fpga needs some special pin toggling to put it in programming mode.
> That's why we want to skip the usual gpio cs and do the pin toggling
> in our driver
Cool, thanks for the explanation. You may want to put it
into the commit message.
[...]
> + ret = gpio_direction_output(pinfo->gpios[i],
> + pinfo->alow_flags[i]);
> + if (ret) {
> + dev_err(dev, "can't set output direction for"
> + "gpio #%d: %d\n",
> + i, ret);
There is no space between 'for' and 'gpio' words.
(also the whole dev_err() may fit into two lines, no need to
split it into three lines).
Otherwise looks great. On the next resend feel free to add my
Acked-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ 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