* [PATCH 7/7] powerpc: BestComm GenBD task support
From: Sylvain Munaut @ 2007-09-16 10:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Grant Likely, Sylvain Munaut, PowerPC dev list
In-Reply-To: <11899400103383-git-send-email-tnt@246tNt.com>
This is the microcode for the GenBD task and the associated
support code. This is a generic task that copy data to/from
a hardware FIFO. This is currently locked to 32bits wide
access but could be extended as needed.
The microcode itself comes directly from the offical
API (v2.2)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
---
arch/powerpc/sysdev/bestcomm/Kconfig | 7 +
arch/powerpc/sysdev/bestcomm/Makefile | 2 +
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c | 63 +++++
arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c | 69 +++++
arch/powerpc/sysdev/bestcomm/gen_bd.c | 260 ++++++++++++++++++++
arch/powerpc/sysdev/bestcomm/gen_bd.h | 48 ++++
6 files changed, 449 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.c
create mode 100644 arch/powerpc/sysdev/bestcomm/gen_bd.h
diff --git a/arch/powerpc/sysdev/bestcomm/Kconfig b/arch/powerpc/sysdev/bestcomm/Kconfig
index 831763b..57cc565 100644
--- a/arch/powerpc/sysdev/bestcomm/Kconfig
+++ b/arch/powerpc/sysdev/bestcomm/Kconfig
@@ -30,3 +30,10 @@ config PPC_BESTCOMM_FEC
help
This option enables the support for the FEC tasks.
+config PPC_BESTCOMM_GEN_BD
+ tristate "Bestcomm GenBD tasks support"
+ depends on PPC_BESTCOMM
+ default n
+ help
+ This option enables the support for the GenBD tasks.
+
diff --git a/arch/powerpc/sysdev/bestcomm/Makefile b/arch/powerpc/sysdev/bestcomm/Makefile
index 537d174..aed2df2 100644
--- a/arch/powerpc/sysdev/bestcomm/Makefile
+++ b/arch/powerpc/sysdev/bestcomm/Makefile
@@ -5,8 +5,10 @@
bestcomm-core-objs := bestcomm.o sram.o
bestcomm-ata-objs := ata.o bcom_ata_task.o
bestcomm-fec-objs := fec.o bcom_fec_rx_task.o bcom_fec_tx_task.o
+bestcomm-gen-bd-objs := gen_bd.o bcom_gen_bd_rx_task.o bcom_gen_bd_tx_task.o
obj-$(CONFIG_PPC_BESTCOMM) += bestcomm-core.o
obj-$(CONFIG_PPC_BESTCOMM_ATA) += bestcomm-ata.o
obj-$(CONFIG_PPC_BESTCOMM_FEC) += bestcomm-fec.o
+obj-$(CONFIG_PPC_BESTCOMM_GEN_BD) += bestcomm-gen-bd.o
diff --git a/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c b/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
new file mode 100644
index 0000000..efee022
--- /dev/null
+++ b/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_rx_task.c
@@ -0,0 +1,63 @@
+/*
+ * Bestcomm GenBD RX task microcode
+ *
+ * Copyright (C) 2006 AppSpec Computer Technologies Corp.
+ * Jeff Gibbons <jeff.gibbons@appspec.com>
+ * Copyright (c) 2004 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Based on BestCommAPI-2.2/code_dma/image_rtos1/dma_image.hex
+ * on Tue Mar 4 10:14:12 2006 GMT
+ *
+ */
+
+#include <asm/types.h>
+
+/*
+ * The header consists of the following fields:
+ * u32 magic;
+ * u8 desc_size;
+ * u8 var_size;
+ * u8 inc_size;
+ * u8 first_var;
+ * u8 reserved[8];
+ *
+ * The size fields contain the number of 32-bit words.
+ */
+
+u32 bcom_gen_bd_rx_task[] = {
+ /* header */
+ 0x4243544b,
+ 0x0d020409,
+ 0x00000000,
+ 0x00000000,
+
+ /* Task descriptors */
+ 0x808220da, /* LCD: idx0 = var1, idx1 = var4; idx1 <= var3; idx0 += inc3, idx1 += inc2 */
+ 0x13e01010, /* DRD1A: var4 = var2; FN=0 MORE init=31 WS=0 RS=0 */
+ 0xb880025b, /* LCD: idx2 = *idx1, idx3 = var0; idx2 < var9; idx2 += inc3, idx3 += inc3 */
+ 0x10001308, /* DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=0 */
+ 0x60140002, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2 */
+ 0x0cccfcca, /* DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
+ 0xd9190240, /* LCDEXT: idx2 = idx2; idx2 > var9; idx2 += inc0 */
+ 0xb8c5e009, /* LCD: idx3 = *(idx1 + var00000015); ; idx3 += inc1 */
+ 0x07fecf80, /* DRD1A: *idx3 = *idx0; FN=0 INT init=31 WS=3 RS=3 */
+ 0x99190024, /* LCD: idx2 = idx2; idx2 once var0; idx2 += inc4 */
+ 0x60000005, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0 */
+ 0x0c4cf889, /* DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
+ 0x000001f8, /* NOP */
+
+ /* VAR[9]-VAR[10] */
+ 0x40000000,
+ 0x7fff7fff,
+
+ /* INC[0]-INC[3] */
+ 0x40000000,
+ 0xe0000000,
+ 0xa0000008,
+ 0x20000000,
+};
+
diff --git a/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c b/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
new file mode 100644
index 0000000..c605aa4
--- /dev/null
+++ b/arch/powerpc/sysdev/bestcomm/bcom_gen_bd_tx_task.c
@@ -0,0 +1,69 @@
+/*
+ * Bestcomm GenBD TX task microcode
+ *
+ * Copyright (C) 2006 AppSpec Computer Technologies Corp.
+ * Jeff Gibbons <jeff.gibbons@appspec.com>
+ * Copyright (c) 2004 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Based on BestCommAPI-2.2/code_dma/image_rtos1/dma_image.hex
+ * on Tue Mar 4 10:14:12 2006 GMT
+ *
+ */
+
+#include <asm/types.h>
+
+/*
+ * The header consists of the following fields:
+ * u32 magic;
+ * u8 desc_size;
+ * u8 var_size;
+ * u8 inc_size;
+ * u8 first_var;
+ * u8 reserved[8];
+ *
+ * The size fields contain the number of 32-bit words.
+ */
+
+u32 bcom_gen_bd_tx_task[] = {
+ /* header */
+ 0x4243544b,
+ 0x0f040609,
+ 0x00000000,
+ 0x00000000,
+
+ /* Task descriptors */
+ 0x800220e3, /* LCD: idx0 = var0, idx1 = var4; idx1 <= var3; idx0 += inc4, idx1 += inc3 */
+ 0x13e01010, /* DRD1A: var4 = var2; FN=0 MORE init=31 WS=0 RS=0 */
+ 0xb8808264, /* LCD: idx2 = *idx1, idx3 = var1; idx2 < var9; idx2 += inc4, idx3 += inc4 */
+ 0x10001308, /* DRD1A: var4 = idx1; FN=0 MORE init=0 WS=0 RS=0 */
+ 0x60140002, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=2 EXT init=0 WS=2 RS=2 */
+ 0x0cccfcca, /* DRD2B1: *idx3 = EU3(); EU3(*idx3,var10) */
+ 0xd9190300, /* LCDEXT: idx2 = idx2; idx2 > var12; idx2 += inc0 */
+ 0xb8c5e009, /* LCD: idx3 = *(idx1 + var00000015); ; idx3 += inc1 */
+ 0x03fec398, /* DRD1A: *idx0 = *idx3; FN=0 init=31 WS=3 RS=3 */
+ 0x9919826a, /* LCD: idx2 = idx2, idx3 = idx3; idx2 > var9; idx2 += inc5, idx3 += inc2 */
+ 0x0feac398, /* DRD1A: *idx0 = *idx3; FN=0 TFD INT init=31 WS=1 RS=1 */
+ 0x99190036, /* LCD: idx2 = idx2; idx2 once var0; idx2 += inc6 */
+ 0x60000005, /* DRD2A: EU0=0 EU1=0 EU2=0 EU3=5 EXT init=0 WS=0 RS=0 */
+ 0x0c4cf889, /* DRD2B1: *idx1 = EU3(); EU3(idx2,var9) */
+ 0x000001f8, /* NOP */
+
+ /* VAR[9]-VAR[12] */
+ 0x40000000,
+ 0x7fff7fff,
+ 0x00000000,
+ 0x40000004,
+
+ /* INC[0]-INC[5] */
+ 0x40000000,
+ 0xe0000000,
+ 0xe0000000,
+ 0xa0000008,
+ 0x20000000,
+ 0x4000ffff,
+};
+
diff --git a/arch/powerpc/sysdev/bestcomm/gen_bd.c b/arch/powerpc/sysdev/bestcomm/gen_bd.c
new file mode 100644
index 0000000..4470482
--- /dev/null
+++ b/arch/powerpc/sysdev/bestcomm/gen_bd.c
@@ -0,0 +1,260 @@
+/*
+ * Driver for MPC52xx processor BestComm General Buffer Descriptor
+ *
+ * Copyright (C) 2007 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2006 AppSpec Computer Technologies Corp.
+ * Jeff Gibbons <jeff.gibbons@appspec.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <asm/errno.h>
+#include <asm/io.h>
+
+#include <asm/mpc52xx.h>
+
+#include "bestcomm.h"
+#include "bestcomm_priv.h"
+#include "gen_bd.h"
+
+
+/* ======================================================================== */
+/* Task image/var/inc */
+/* ======================================================================== */
+
+/* gen_bd tasks images */
+extern u32 bcom_gen_bd_rx_task[];
+extern u32 bcom_gen_bd_tx_task[];
+
+/* rx task vars that need to be set before enabling the task */
+struct bcom_gen_bd_rx_var {
+ u32 enable; /* (u16*) address of task's control register */
+ u32 fifo; /* (u32*) address of gen_bd's fifo */
+ u32 bd_base; /* (struct bcom_bd*) beginning of ring buffer */
+ u32 bd_last; /* (struct bcom_bd*) end of ring buffer */
+ u32 bd_start; /* (struct bcom_bd*) current bd */
+ u32 buffer_size; /* size of receive buffer */
+};
+
+/* rx task incs that need to be set before enabling the task */
+struct bcom_gen_bd_rx_inc {
+ u16 pad0;
+ s16 incr_bytes;
+ u16 pad1;
+ s16 incr_dst;
+};
+
+/* tx task vars that need to be set before enabling the task */
+struct bcom_gen_bd_tx_var {
+ u32 fifo; /* (u32*) address of gen_bd's fifo */
+ u32 enable; /* (u16*) address of task's control register */
+ u32 bd_base; /* (struct bcom_bd*) beginning of ring buffer */
+ u32 bd_last; /* (struct bcom_bd*) end of ring buffer */
+ u32 bd_start; /* (struct bcom_bd*) current bd */
+ u32 buffer_size; /* set by uCode for each packet */
+};
+
+/* tx task incs that need to be set before enabling the task */
+struct bcom_gen_bd_tx_inc {
+ u16 pad0;
+ s16 incr_bytes;
+ u16 pad1;
+ s16 incr_src;
+ u16 pad2;
+ s16 incr_src_ma;
+};
+
+/* private structure */
+struct bcom_gen_bd_priv {
+ phys_addr_t fifo;
+ int initiator;
+ int ipr;
+ int maxbufsize;
+};
+
+
+/* ======================================================================== */
+/* Task support code */
+/* ======================================================================== */
+
+struct bcom_task *
+bcom_gen_bd_rx_init(int queue_len, phys_addr_t fifo,
+ int initiator, int ipr, int maxbufsize)
+{
+ struct bcom_task *tsk;
+ struct bcom_gen_bd_priv *priv;
+
+ tsk = bcom_task_alloc(queue_len, sizeof(struct bcom_gen_bd),
+ sizeof(struct bcom_gen_bd_priv));
+ if (!tsk)
+ return NULL;
+
+ tsk->flags = BCOM_FLAGS_NONE;
+
+ priv = tsk->priv;
+ priv->fifo = fifo;
+ priv->initiator = initiator;
+ priv->ipr = ipr;
+ priv->maxbufsize = maxbufsize;
+
+ if (bcom_gen_bd_rx_reset(tsk)) {
+ bcom_task_release(tsk);
+ return NULL;
+ }
+
+ return tsk;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_rx_init);
+
+int
+bcom_gen_bd_rx_reset(struct bcom_task *tsk)
+{
+ struct bcom_gen_bd_priv *priv = tsk->priv;
+ struct bcom_gen_bd_rx_var *var;
+ struct bcom_gen_bd_rx_inc *inc;
+
+ /* Shutdown the task */
+ bcom_disable_task(tsk->tasknum);
+
+ /* Reset the microcode */
+ var = (struct bcom_gen_bd_rx_var *) bcom_task_var(tsk->tasknum);
+ inc = (struct bcom_gen_bd_rx_inc *) bcom_task_inc(tsk->tasknum);
+
+ if (bcom_load_image(tsk->tasknum, bcom_gen_bd_rx_task))
+ return -1;
+
+ var->enable = bcom_eng->regs_base +
+ offsetof(struct mpc52xx_sdma, tcr[tsk->tasknum]);
+ var->fifo = (u32) priv->fifo;
+ var->bd_base = tsk->bd_pa;
+ var->bd_last = tsk->bd_pa + ((tsk->num_bd-1) * tsk->bd_size);
+ var->bd_start = tsk->bd_pa;
+ var->buffer_size = priv->maxbufsize;
+
+ inc->incr_bytes = -(s16)sizeof(u32);
+ inc->incr_dst = sizeof(u32);
+
+ /* Reset the BDs */
+ tsk->index = 0;
+ tsk->outdex = 0;
+
+ memset(tsk->bd, 0x00, tsk->num_bd * tsk->bd_size);
+
+ /* Configure some stuff */
+ bcom_set_task_pragma(tsk->tasknum, BCOM_GEN_RX_BD_PRAGMA);
+ bcom_set_task_auto_start(tsk->tasknum, tsk->tasknum);
+
+ out_8(&bcom_eng->regs->ipr[priv->initiator], priv->ipr);
+ bcom_set_initiator(tsk->tasknum, priv->initiator);
+
+ out_be32(&bcom_eng->regs->IntPend, 1<<tsk->tasknum); /* Clear ints */
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_rx_reset);
+
+void
+bcom_gen_bd_rx_release(struct bcom_task *tsk)
+{
+ /* Nothing special for the GenBD tasks */
+ bcom_task_release(tsk);
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_rx_release);
+
+
+extern struct bcom_task *
+bcom_gen_bd_tx_init(int queue_len, phys_addr_t fifo,
+ int initiator, int ipr)
+{
+ struct bcom_task *tsk;
+ struct bcom_gen_bd_priv *priv;
+
+ tsk = bcom_task_alloc(queue_len, sizeof(struct bcom_gen_bd),
+ sizeof(struct bcom_gen_bd_priv));
+ if (!tsk)
+ return NULL;
+
+ tsk->flags = BCOM_FLAGS_NONE;
+
+ priv = tsk->priv;
+ priv->fifo = fifo;
+ priv->initiator = initiator;
+ priv->ipr = ipr;
+
+ if (bcom_gen_bd_tx_reset(tsk)) {
+ bcom_task_release(tsk);
+ return NULL;
+ }
+
+ return tsk;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_init);
+
+int
+bcom_gen_bd_tx_reset(struct bcom_task *tsk)
+{
+ struct bcom_gen_bd_priv *priv = tsk->priv;
+ struct bcom_gen_bd_tx_var *var;
+ struct bcom_gen_bd_tx_inc *inc;
+
+ /* Shutdown the task */
+ bcom_disable_task(tsk->tasknum);
+
+ /* Reset the microcode */
+ var = (struct bcom_gen_bd_tx_var *) bcom_task_var(tsk->tasknum);
+ inc = (struct bcom_gen_bd_tx_inc *) bcom_task_inc(tsk->tasknum);
+
+ if (bcom_load_image(tsk->tasknum, bcom_gen_bd_tx_task))
+ return -1;
+
+ var->enable = bcom_eng->regs_base +
+ offsetof(struct mpc52xx_sdma, tcr[tsk->tasknum]);
+ var->fifo = (u32) priv->fifo;
+ var->bd_base = tsk->bd_pa;
+ var->bd_last = tsk->bd_pa + ((tsk->num_bd-1) * tsk->bd_size);
+ var->bd_start = tsk->bd_pa;
+
+ inc->incr_bytes = -(s16)sizeof(u32);
+ inc->incr_src = sizeof(u32);
+ inc->incr_src_ma = sizeof(u8);
+
+ /* Reset the BDs */
+ tsk->index = 0;
+ tsk->outdex = 0;
+
+ memset(tsk->bd, 0x00, tsk->num_bd * tsk->bd_size);
+
+ /* Configure some stuff */
+ bcom_set_task_pragma(tsk->tasknum, BCOM_GEN_TX_BD_PRAGMA);
+ bcom_set_task_auto_start(tsk->tasknum, tsk->tasknum);
+
+ out_8(&bcom_eng->regs->ipr[priv->initiator], priv->ipr);
+ bcom_set_initiator(tsk->tasknum, priv->initiator);
+
+ out_be32(&bcom_eng->regs->IntPend, 1<<tsk->tasknum); /* Clear ints */
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_reset);
+
+void
+bcom_gen_bd_tx_release(struct bcom_task *tsk)
+{
+ /* Nothing special for the GenBD tasks */
+ bcom_task_release(tsk);
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_release);
+
+
+MODULE_DESCRIPTION("BestComm General Buffer Descriptor tasks driver");
+MODULE_AUTHOR("Jeff Gibbons <jeff.gibbons@appspec.com>");
+MODULE_LICENSE("GPL v2");
+
diff --git a/arch/powerpc/sysdev/bestcomm/gen_bd.h b/arch/powerpc/sysdev/bestcomm/gen_bd.h
new file mode 100644
index 0000000..5b6fa80
--- /dev/null
+++ b/arch/powerpc/sysdev/bestcomm/gen_bd.h
@@ -0,0 +1,48 @@
+/*
+ * Header for Bestcomm General Buffer Descriptor tasks driver
+ *
+ *
+ * Copyright (C) 2007 Sylvain Munaut <tnt@246tNt.com>
+ * Copyright (C) 2006 AppSpec Computer Technologies Corp.
+ * Jeff Gibbons <jeff.gibbons@appspec.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ *
+ */
+
+#ifndef __BESTCOMM_GEN_BD_H__
+#define __BESTCOMM_GEN_BD_H__
+
+struct bcom_gen_bd {
+ u32 status;
+ u32 buf_pa;
+};
+
+
+extern struct bcom_task *
+bcom_gen_bd_rx_init(int queue_len, phys_addr_t fifo,
+ int initiator, int ipr, int maxbufsize);
+
+extern int
+bcom_gen_bd_rx_reset(struct bcom_task *tsk);
+
+extern void
+bcom_gen_bd_rx_release(struct bcom_task *tsk);
+
+
+extern struct bcom_task *
+bcom_gen_bd_tx_init(int queue_len, phys_addr_t fifo,
+ int initiator, int ipr);
+
+extern int
+bcom_gen_bd_tx_reset(struct bcom_task *tsk);
+
+extern void
+bcom_gen_bd_tx_release(struct bcom_task *tsk);
+
+
+#endif /* __BESTCOMM_GEN_BD_H__ */
+
--
1.5.3
^ permalink raw reply related
* [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Stefan Roese @ 2007-09-16 11:52 UTC (permalink / raw)
To: i2c, linuxppc-dev; +Cc: Jean Delvare
This patch reworks existing ibm-iic driver to an of_platform_device
and enables it to talk to device tree directly. The ocp quirks are
completely removed by this patch.
This is done to enable I2C support for the PPC4xx platforms now
being moved from arch/ppc (OCP) to arch/powerpc (of). The first board
using this driver will be the AMCC Sequoia (PPC440EPx).
Signed-off-by: Stefan Roese <sr@denx.de>
=2D--
2nd try with some cleanups. Please let me know if there still are some
problems.
Thanks.
commit 5748f81ff53277fa5c16de815b7d6b172ca284e9
tree 8284b3f1c836eb6eb06ee6882ee13b9e8f6cbb6b
parent d0174640eedc1cd756754f03afe2dbb3d56de74e
author Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
committer Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
drivers/i2c/busses/Kconfig | 12 -
drivers/i2c/busses/Makefile | 1=20
drivers/i2c/busses/i2c-ibm_iic.h | 3=20
drivers/i2c/busses/i2c-ibm_of.c | 858 ++++++++++++++++++++++++++++++++++=
++++
4 files changed, 873 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 9f3a4cd..12453e2 100644
=2D-- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -220,7 +220,17 @@ config I2C_PIIX4
=20
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
=2D depends on IBM_OCP
+ depends on !PPC_MERGE
+ help
+ Say Y here if you want to use IIC peripheral found on=20
+ embedded IBM PPC 4xx based systems.=20
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-ibm_iic.
+
+config I2C_IBM_OF
+ tristate "IBM PPC 4xx on-chip I2C interface"
+ depends on PPC_MERGE
help
Say Y here if you want to use IIC peripheral found on=20
embedded IBM PPC 4xx based systems.=20
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 5b752e4..0cd0bac 100644
=2D-- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_I2C_HYDRA) +=3D i2c-hydra.o
obj-$(CONFIG_I2C_I801) +=3D i2c-i801.o
obj-$(CONFIG_I2C_I810) +=3D i2c-i810.o
obj-$(CONFIG_I2C_IBM_IIC) +=3D i2c-ibm_iic.o
+obj-$(CONFIG_I2C_IBM_OF) +=3D i2c-ibm_of.o
obj-$(CONFIG_I2C_IOP3XX) +=3D i2c-iop3xx.o
obj-$(CONFIG_I2C_IXP2000) +=3D i2c-ixp2000.o
obj-$(CONFIG_I2C_IXP4XX) +=3D i2c-ixp4xx.o
diff --git a/drivers/i2c/busses/i2c-ibm_iic.h b/drivers/i2c/busses/i2c-ibm_=
iic.h
index 59d7b43..485c72c 100644
=2D-- a/drivers/i2c/busses/i2c-ibm_iic.h
+++ b/drivers/i2c/busses/i2c-ibm_iic.h
@@ -23,6 +23,7 @@
#define __I2C_IBM_IIC_H_
=20
#include <linux/i2c.h>=20
+#include <linux/of.h>
=20
struct iic_regs {
u16 mdbuf;
@@ -50,6 +51,8 @@ struct ibm_iic_private {
int irq;
int fast_mode;
u8 clckdiv;
+ struct device_node *np;
+ phys_addr_t paddr;
};
=20
/* IICx_CNTL register */
diff --git a/drivers/i2c/busses/i2c-ibm_of.c b/drivers/i2c/busses/i2c-ibm_o=
f.c
new file mode 100644
index 0000000..5e5b3e5
=2D-- /dev/null
+++ b/drivers/i2c/busses/i2c-ibm_of.c
@@ -0,0 +1,858 @@
+/*
+ * drivers/i2c/busses/i2c-ibm_of.c
+ *
+ * Support for the IIC peripheral on IBM PPC 4xx
+ *
+ * Copyright (c) 2003, 2004 Zultys Technologies.
+ * Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
+ *
+ * Based on original work by
+ * Ian DaSilva <idasilva@mvista.com>
+ * Armin Kuster <akuster@mvista.com>
+ * Matt Porter <mporter@mvista.com>
+ *
+ * Copyright 2000-2003 MontaVista Software Inc.
+ *
+ * Original driver version was highly leveraged from i2c-elektor.c
+ *
+ * Copyright 1995-97 Simon G. Vogl
+ * 1998-99 Hans Berglund
+ *
+ * With some changes from Ky=F6sti M=E4lkki <kmalkki@cc.hut.fi>
+ * and even Frodo Looijaard <frodol@dds.nl>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/ioport.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <asm/irq.h>
+#include <asm/io.h>
+#include <linux/i2c.h>
+#include <linux/i2c-id.h>
+
+#include <linux/of_platform.h>
+
+#include "i2c-ibm_iic.h"
+
+#define DRIVER_VERSION "2.1"
+
+MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
+MODULE_LICENSE("GPL");
+
+static int device_idx =3D -1;
+
+static int iic_force_poll;
+module_param(iic_force_poll, bool, 0);
+MODULE_PARM_DESC(iic_force_poll, "Force polling mode");
+
+static int iic_force_fast;
+module_param(iic_force_fast, bool, 0);
+MODULE_PARM_DESC(iic_fast_poll, "Force fast mode (400 kHz)");
+
+#define DBG_LEVEL 0
+
+#ifdef DBG
+#undef DBG
+#endif
+
+#ifdef DBG2
+#undef DBG2
+#endif
+
+#if DBG_LEVEL > 0
+# define DBG(f,x...) printk(KERN_DEBUG "ibm-iic" f, ##x)
+#else
+# define DBG(f,x...) ((void)0)
+#endif
+#if DBG_LEVEL > 1
+# define DBG2(f,x...) DBG(f, ##x)
+#else
+# define DBG2(f,x...) ((void)0)
+#endif
+#if DBG_LEVEL > 2
+static void dump_iic_regs(const char* header, struct ibm_iic_private* dev)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ printk(KERN_DEBUG "ibm-iic(%s): %s\n", dev->np->full_name, header);
+ printk(KERN_DEBUG " cntl =3D 0x%02x, mdcntl =3D 0x%02x\n"
+ KERN_DEBUG " sts =3D 0x%02x, extsts =3D 0x%02x\n"
+ KERN_DEBUG " clkdiv =3D 0x%02x, xfrcnt =3D 0x%02x\n"
+ KERN_DEBUG " xtcntlss =3D 0x%02x, directcntl =3D 0x%02x\n",
+ in_8(&iic->cntl), in_8(&iic->mdcntl), in_8(&iic->sts),
+ in_8(&iic->extsts), in_8(&iic->clkdiv), in_8(&iic->xfrcnt),
+ in_8(&iic->xtcntlss), in_8(&iic->directcntl));
+}
+# define DUMP_REGS(h,dev) dump_iic_regs((h),(dev))
+#else
+# define DUMP_REGS(h,dev) ((void)0)
+#endif
+
+/* Bus timings (in ns) for bit-banging */
+static struct i2c_timings {
+ unsigned int hd_sta;
+ unsigned int su_sto;
+ unsigned int low;
+ unsigned int high;
+ unsigned int buf;
+} timings [] =3D {
+/* Standard mode (100 KHz) */
+{
+ .hd_sta =3D 4000,
+ .su_sto =3D 4000,
+ .low =3D 4700,
+ .high =3D 4000,
+ .buf =3D 4700,
+},
+/* Fast mode (400 KHz) */
+{
+ .hd_sta =3D 600,
+ .su_sto =3D 600,
+ .low =3D 1300,
+ .high =3D 600,
+ .buf =3D 1300,
+}};
+
+/* Enable/disable interrupt generation */
+static inline void iic_interrupt_mode(struct ibm_iic_private* dev, int ena=
ble)
+{
+ out_8(&dev->vaddr->intmsk, enable ? INTRMSK_EIMTC : 0);
+}
+
+/*
+ * Initialize IIC interface.
+ */
+static void iic_dev_init(struct ibm_iic_private* dev)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+
+ DBG("%s: init\n", dev->np->full_name);
+
+ /* Clear master address */
+ out_8(&iic->lmadr, 0);
+ out_8(&iic->hmadr, 0);
+
+ /* Clear slave address */
+ out_8(&iic->lsadr, 0);
+ out_8(&iic->hsadr, 0);
+
+ /* Clear status & extended status */
+ out_8(&iic->sts, STS_SCMP | STS_IRQA);
+ out_8(&iic->extsts, EXTSTS_IRQP | EXTSTS_IRQD | EXTSTS_LA
+ | EXTSTS_ICT | EXTSTS_XFRA);
+
+ /* Set clock divider */
+ out_8(&iic->clkdiv, dev->clckdiv);
+
+ /* Clear transfer count */
+ out_8(&iic->xfrcnt, 0);
+
+ /* Clear extended control and status */
+ out_8(&iic->xtcntlss, XTCNTLSS_SRC | XTCNTLSS_SRS | XTCNTLSS_SWC
+ | XTCNTLSS_SWS);
+
+ /* Clear control register */
+ out_8(&iic->cntl, 0);
+
+ /* Enable interrupts if possible */
+ iic_interrupt_mode(dev, dev->irq >=3D 0);
+
+ /* Set mode control */
+ out_8(&iic->mdcntl, MDCNTL_FMDB | MDCNTL_EINT | MDCNTL_EUBS
+ | (dev->fast_mode ? MDCNTL_FSM : 0));
+
+ DUMP_REGS("iic_init", dev);
+}
+
+/*
+ * Reset IIC interface
+ */
+static void iic_dev_reset(struct ibm_iic_private* dev)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ int i;
+ u8 dc;
+
+ DBG("%s: soft reset\n", dev->np->full_name);
+ DUMP_REGS("reset", dev);
+
+ /* Place chip in the reset state */
+ out_8(&iic->xtcntlss, XTCNTLSS_SRST);
+
+ /* Check if bus is free */
+ dc =3D in_8(&iic->directcntl);
+ if (!DIRCTNL_FREE(dc)) {
+ DBG("%s: trying to regain bus control\n", dev->np->full_name);
+
+ /* Try to set bus free state */
+ out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+
+ /* Wait until we regain bus control */
+ for (i =3D 0; i < 100; ++i) {
+ dc =3D in_8(&iic->directcntl);
+ if (DIRCTNL_FREE(dc))
+ break;
+
+ /* Toggle SCL line */
+ dc ^=3D DIRCNTL_SCC;
+ out_8(&iic->directcntl, dc);
+ udelay(10);
+ dc ^=3D DIRCNTL_SCC;
+ out_8(&iic->directcntl, dc);
+
+ /* be nice */
+ cond_resched();
+ }
+ }
+
+ /* Remove reset */
+ out_8(&iic->xtcntlss, 0);
+
+ /* Reinitialize interface */
+ iic_dev_init(dev);
+}
+
+/*
+ * Do 0-length transaction using bit-banging through IIC_DIRECTCNTL regist=
er.
+ */
+
+/* Wait for SCL and/or SDA to be high */
+static int iic_dc_wait(volatile struct iic_regs __iomem *iic, u8 mask)
+{
+ unsigned long x =3D jiffies + HZ / 28 + 2;
+ while ((in_8(&iic->directcntl) & mask) !=3D mask) {
+ if (unlikely(time_after(jiffies, x)))
+ return -1;
+ cond_resched();
+ }
+ return 0;
+}
+
+static int iic_smbus_quick(struct ibm_iic_private* dev, const struct i2c_m=
sg* p)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ const struct i2c_timings* t =3D &timings[dev->fast_mode ? 1 : 0];
+ u8 mask, v, sda;
+ int i, res;
+
+ /* Only 7-bit addresses are supported */
+ if (unlikely(p->flags & I2C_M_TEN)) {
+ DBG("%s: smbus_quick - 10 bit addresses are not supported\n",
+ dev->np->full_name);
+ return -EINVAL;
+ }
+
+ DBG("%s: smbus_quick(0x%02x)\n", dev->np->full_name, p->addr);
+
+ /* Reset IIC interface */
+ out_8(&iic->xtcntlss, XTCNTLSS_SRST);
+
+ /* Wait for bus to become free */
+ out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+ if (unlikely(iic_dc_wait(iic, DIRCNTL_MSDA | DIRCNTL_MSC)))
+ goto err;
+ ndelay(t->buf);
+
+ /* START */
+ out_8(&iic->directcntl, DIRCNTL_SCC);
+ sda =3D 0;
+ ndelay(t->hd_sta);
+
+ /* Send address */
+ v =3D (u8)((p->addr << 1) | ((p->flags & I2C_M_RD) ? 1 : 0));
+ for (i =3D 0, mask =3D 0x80; i < 8; ++i, mask >>=3D 1) {
+ out_8(&iic->directcntl, sda);
+ ndelay(t->low / 2);
+ sda =3D (v & mask) ? DIRCNTL_SDAC : 0;
+ out_8(&iic->directcntl, sda);
+ ndelay(t->low / 2);
+
+ out_8(&iic->directcntl, DIRCNTL_SCC | sda);
+ if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+ goto err;
+ ndelay(t->high);
+ }
+
+ /* ACK */
+ out_8(&iic->directcntl, sda);
+ ndelay(t->low / 2);
+ out_8(&iic->directcntl, DIRCNTL_SDAC);
+ ndelay(t->low / 2);
+ out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+ if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+ goto err;
+ res =3D (in_8(&iic->directcntl) & DIRCNTL_MSDA) ? -EREMOTEIO : 1;
+ ndelay(t->high);
+
+ /* STOP */
+ out_8(&iic->directcntl, 0);
+ ndelay(t->low);
+ out_8(&iic->directcntl, DIRCNTL_SCC);
+ if (unlikely(iic_dc_wait(iic, DIRCNTL_MSC)))
+ goto err;
+ ndelay(t->su_sto);
+ out_8(&iic->directcntl, DIRCNTL_SDAC | DIRCNTL_SCC);
+
+ ndelay(t->buf);
+
+ DBG("%s: smbus_quick -> %s\n",
+ dev->np->full_name, res ? "NACK" : "ACK");
+out:
+ /* Remove reset */
+ out_8(&iic->xtcntlss, 0);
+
+ /* Reinitialize interface */
+ iic_dev_init(dev);
+
+ return res;
+err:
+ DBG("%s: smbus_quick - bus is stuck\n", dev->np->full_name);
+ res =3D -EREMOTEIO;
+ goto out;
+}
+
+/*
+ * IIC interrupt handler
+ */
+static irqreturn_t iic_handler(int irq, void *dev_id)
+{
+ struct ibm_iic_private* dev =3D dev_id;
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+
+ DBG2("%s: irq handler, STS =3D 0x%02x, EXTSTS =3D 0x%02x\n",
+ dev->np->full_name, in_8(&iic->sts), in_8(&iic->extsts));
+
+ /* Acknowledge IRQ and wakeup iic_wait_for_tc */
+ out_8(&iic->sts, STS_IRQA | STS_SCMP);
+ wake_up_interruptible(&dev->wq);
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * Get master transfer result and clear errors if any.
+ * Returns the number of actually transferred bytes or error (<0)
+ */
+static int iic_xfer_result(struct ibm_iic_private* dev)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+
+ if (unlikely(in_8(&iic->sts) & STS_ERR)) {
+ DBG("%s: xfer error, EXTSTS =3D 0x%02x\n", dev->np->full_name,
+ in_8(&iic->extsts));
+
+ /* Clear errors and possible pending IRQs */
+ out_8(&iic->extsts, EXTSTS_IRQP | EXTSTS_IRQD |
+ EXTSTS_LA | EXTSTS_ICT | EXTSTS_XFRA);
+
+ /* Flush master data buffer */
+ out_8(&iic->mdcntl, in_8(&iic->mdcntl) | MDCNTL_FMDB);
+
+ /* Is bus free?
+ * If error happened during combined xfer
+ * IIC interface is usually stuck in some strange
+ * state, the only way out - soft reset.
+ */
+ if ((in_8(&iic->extsts) & EXTSTS_BCS_MASK) !=3D EXTSTS_BCS_FREE) {
+ DBG("%s: bus is stuck, resetting\n",
+ dev->np->full_name);
+ iic_dev_reset(dev);
+ }
+ return -EREMOTEIO;
+ } else
+ return in_8(&iic->xfrcnt) & XFRCNT_MTC_MASK;
+}
+
+/*
+ * Try to abort active transfer.
+ */
+static void iic_abort_xfer(struct ibm_iic_private* dev)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ unsigned long x;
+
+ DBG("%s: iic_abost_xfer\n", dev->np->full_name);
+
+ out_8(&iic->cntl, CNTL_HMT);
+
+ /*
+ * Wait for the abort command to complete.
+ * It's not worth to be optimized, just poll (timeout >=3D 1 tick)
+ */
+ x =3D jiffies + 2;
+ while ((in_8(&iic->extsts) & EXTSTS_BCS_MASK) !=3D EXTSTS_BCS_FREE) {
+ if (time_after(jiffies, x)) {
+ DBG("%s: abort timeout, resetting...\n",
+ dev->np->full_name);
+ iic_dev_reset(dev);
+ return;
+ }
+ schedule();
+ }
+
+ /* Just to clear errors */
+ iic_xfer_result(dev);
+}
+
+/*
+ * Wait for master transfer to complete.
+ * It puts current process to sleep until we get interrupt or timeout expi=
res.
+ * Returns the number of transferred bytes or error (<0)
+ */
+static int iic_wait_for_tc(struct ibm_iic_private* dev) {
+
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ int ret =3D 0;
+
+ if (dev->irq >=3D 0) {
+ /* Interrupt mode */
+ ret =3D wait_event_interruptible_timeout(dev->wq,
+ !(in_8(&iic->sts) & STS_PT), dev->adap.timeout * HZ);
+
+ if (unlikely(ret < 0))
+ DBG("%s: wait interrupted\n", dev->np->full_name);
+ else if (unlikely(in_8(&iic->sts) & STS_PT)) {
+ DBG("%s: wait timeout\n", dev->np->full_name);
+ ret =3D -ETIMEDOUT;
+ }
+ } else {
+ /* Polling mode */
+ unsigned long x =3D jiffies + dev->adap.timeout * HZ;
+
+ while (in_8(&iic->sts) & STS_PT) {
+ if (unlikely(time_after(jiffies, x))) {
+ DBG("%s: poll timeout\n", dev->np->full_name);
+ ret =3D -ETIMEDOUT;
+ break;
+ }
+
+ if (unlikely(signal_pending(current))) {
+ DBG("%s: poll interrupted\n",
+ dev->np->full_name);
+ ret =3D -ERESTARTSYS;
+ break;
+ }
+ schedule();
+ }
+ }
+
+ if (unlikely(ret < 0))
+ iic_abort_xfer(dev);
+ else
+ ret =3D iic_xfer_result(dev);
+
+ DBG2("%s: iic_wait_for_tc -> %d\n", dev->np->full_name, ret);
+
+ return ret;
+}
+
+/*
+ * Low level master transfer routine
+ */
+static int iic_xfer_bytes(struct ibm_iic_private* dev, struct i2c_msg* pm,
+ int combined_xfer)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ char* buf =3D pm->buf;
+ int i, j, loops, ret =3D 0;
+ int len =3D pm->len;
+
+ u8 cntl =3D (in_8(&iic->cntl) & CNTL_AMD) | CNTL_PT;
+ if (pm->flags & I2C_M_RD)
+ cntl |=3D CNTL_RW;
+
+ loops =3D (len + 3) / 4;
+ for (i =3D 0; i < loops; ++i, len -=3D 4) {
+ int count =3D len > 4 ? 4 : len;
+ u8 cmd =3D cntl | ((count - 1) << CNTL_TCT_SHIFT);
+
+ if (!(cntl & CNTL_RW))
+ for (j =3D 0; j < count; ++j)
+ out_8((void __iomem *)&iic->mdbuf, *buf++);
+
+ if (i < loops - 1)
+ cmd |=3D CNTL_CHT;
+ else if (combined_xfer)
+ cmd |=3D CNTL_RPST;
+
+ DBG2("%s: xfer_bytes, %d, CNTL =3D 0x%02x\n",
+ dev->np->full_name, count, cmd);
+
+ /* Start transfer */
+ out_8(&iic->cntl, cmd);
+
+ /* Wait for completion */
+ ret =3D iic_wait_for_tc(dev);
+
+ if (unlikely(ret < 0))
+ break;
+ else if (unlikely(ret !=3D count)) {
+ DBG("%s: xfer_bytes, requested %d, transfered %d\n",
+ dev->np->full_name, count, ret);
+
+ /* If it's not a last part of xfer, abort it */
+ if (combined_xfer || (i < loops - 1))
+ iic_abort_xfer(dev);
+
+ ret =3D -EREMOTEIO;
+ break;
+ }
+
+ if (cntl & CNTL_RW)
+ for (j =3D 0; j < count; ++j)
+ *buf++ =3D in_8((void __iomem *)&iic->mdbuf);
+ }
+
+ return ret > 0 ? 0 : ret;
+}
+
+/*
+ * Set target slave address for master transfer
+ */
+static inline void iic_address(struct ibm_iic_private* dev, struct i2c_msg=
* msg)
+{
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ u16 addr =3D msg->addr;
+
+ DBG2("%s: iic_address, 0x%03x (%d-bit)\n", dev->np->full_name,
+ addr, msg->flags & I2C_M_TEN ? 10 : 7);
+
+ if (msg->flags & I2C_M_TEN) {
+ out_8(&iic->cntl, CNTL_AMD);
+ out_8(&iic->lmadr, addr);
+ out_8(&iic->hmadr, 0xf0 | ((addr >> 7) & 0x06));
+ } else {
+ out_8(&iic->cntl, 0);
+ out_8(&iic->lmadr, addr << 1);
+ }
+}
+
+static inline int iic_invalid_address(const struct i2c_msg* p)
+{
+ return (p->addr > 0x3ff) || (!(p->flags & I2C_M_TEN) && (p->addr > 0x7f));
+}
+
+static inline int iic_address_neq(const struct i2c_msg* p1,
+ const struct i2c_msg* p2)
+{
+ return (p1->addr !=3D p2->addr)
+ || ((p1->flags & I2C_M_TEN) !=3D (p2->flags & I2C_M_TEN));
+}
+
+/*
+ * Generic master transfer entrypoint.
+ * Returns the number of processed messages or error (<0)
+ */
+static int iic_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int nu=
m)
+{
+ struct ibm_iic_private* dev =3D i2c_get_adapdata(adap);
+ volatile struct iic_regs __iomem *iic =3D dev->vaddr;
+ int i, ret =3D 0;
+
+ DBG2("%s: iic_xfer, %d msg(s)\n", dev->np->full_name, num);
+
+ if (!num)
+ return 0;
+
+ /* Check the sanity of the passed messages.
+ * Uhh, generic i2c layer is more suitable place for such code...
+ */
+ if (unlikely(iic_invalid_address(&msgs[0]))) {
+ DBG("%s: invalid address 0x%03x (%d-bit)\n", dev->np->full_name,
+ msgs[0].addr, msgs[0].flags & I2C_M_TEN ? 10 : 7);
+ return -EINVAL;
+ }
+ for (i =3D 0; i < num; ++i) {
+ if (unlikely(msgs[i].len <=3D 0)) {
+ if (num =3D=3D 1 && !msgs[0].len) {
+ /* Special case for I2C_SMBUS_QUICK emulation.
+ * IBM IIC doesn't support 0-length transactions
+ * so we have to emulate them using bit-banging.
+ */
+ return iic_smbus_quick(dev, &msgs[0]);
+ }
+ DBG("%s: invalid len %d in msg[%d]\n",
+ dev->np->full_name,
+ msgs[i].len, i);
+ return -EINVAL;
+ }
+ if (unlikely(iic_address_neq(&msgs[0], &msgs[i]))) {
+ DBG("%s: invalid addr in msg[%d]\n",
+ dev->np->full_name, i);
+ return -EINVAL;
+ }
+ }
+
+ /* Check bus state */
+ if (unlikely((in_8(&iic->extsts) & EXTSTS_BCS_MASK)
+ !=3D EXTSTS_BCS_FREE)) {
+ DBG("%s: iic_xfer, bus is not free\n", dev->np->full_name);
+
+ /* Usually it means something serious has happend.
+ * We *cannot* have unfinished previous transfer
+ * so it doesn't make any sense to try to stop it.
+ * Probably we were not able to recover from the
+ * previous error.
+ * The only *reasonable* thing I can think of here
+ * is soft reset. --ebs
+ */
+ iic_dev_reset(dev);
+
+ if ((in_8(&iic->extsts) & EXTSTS_BCS_MASK) !=3D EXTSTS_BCS_FREE) {
+ DBG("%s: iic_xfer, bus is still not free\n",
+ dev->np->full_name);
+ return -EREMOTEIO;
+ }
+ } else {
+ /* Flush master data buffer (just in case) */
+ out_8(&iic->mdcntl, in_8(&iic->mdcntl) | MDCNTL_FMDB);
+ }
+
+ /* Load slave address */
+ iic_address(dev, &msgs[0]);
+
+ /* Do real transfer */
+ for (i =3D 0; i < num && !ret; ++i)
+ ret =3D iic_xfer_bytes(dev, &msgs[i], i < num - 1);
+
+ return ret < 0 ? ret : num;
+}
+
+static u32 iic_func(struct i2c_adapter *adap)
+{
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR;
+}
+
+static const struct i2c_algorithm iic_algo =3D {
+ .master_xfer =3D iic_xfer,
+ .functionality =3D iic_func
+};
+
+/*
+ * Calculates IICx_CLCKDIV value for a specific OPB clock frequency
+ */
+static inline u8 iic_clckdiv(unsigned int opb)
+{
+ /* Compatibility kludge, should go away after all cards
+ * are fixed to fill correct value for opbfreq.
+ * Previous driver version used hardcoded divider value 4,
+ * it corresponds to OPB frequency from the range (40, 50] MHz
+ */
+ if (!opb) {
+ printk(KERN_WARNING
+ "ibm-iic: using compatibility value for OPB freq,"
+ " fix your board specific setup\n");
+ opb =3D 50000000;
+ }
+
+ /* Convert to MHz */
+ opb /=3D 1000000;
+
+ if (opb < 20 || opb > 150) {
+ printk(KERN_CRIT "ibm-iic: invalid OPB clock frequency %u MHz\n",
+ opb);
+ opb =3D opb < 20 ? 20 : 150;
+ }
+ return (u8)((opb + 9) / 10 - 1);
+}
+
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe (struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct ibm_iic_private* dev;
+ struct i2c_adapter* adap;
+ struct device_node *np;
+ int ret =3D -ENODEV;
+ int irq, len;
+ const u32 *prop;
+ struct resource res;
+
+ np =3D ofdev->node;
+ if (!(dev =3D kzalloc(sizeof(*dev), GFP_KERNEL))) {
+ printk(KERN_CRIT "ibm-iic(%s): failed to allocate device data\n",
+ np->full_name);
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ dev->np =3D np;
+ irq =3D irq_of_parse_and_map(np, 0);
+
+ if (of_address_to_resource(np, 0, &res)) {
+ printk(KERN_ERR "ibd-iic(%s): Can't get registers address\n",
+ np->full_name);
+ goto fail1;
+ }
+ dev->paddr =3D res.start;
+
+ if (!request_mem_region(dev->paddr, sizeof(struct iic_regs),
+ "ibm_iic")) {
+ ret =3D -EBUSY;
+ goto fail1;
+ }
+ dev->vaddr =3D ioremap(dev->paddr, sizeof(struct iic_regs));
+
+ if (dev->vaddr =3D=3D NULL) {
+ printk(KERN_CRIT "ibm-iic(%s): failed to ioremap device regs\n",
+ dev->np->full_name);
+ ret =3D -ENXIO;
+ goto fail2;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ dev->irq =3D iic_force_poll ? -1 : (irq =3D=3D NO_IRQ) ? -1 : irq;
+ if (dev->irq >=3D 0) {
+ /* Disable interrupts until we finish initialization,
+ assumes level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)) {
+ printk(KERN_ERR "ibm-iic(%s): request_irq %d failed\n",
+ dev->np->full_name, dev->irq);
+ /* Fallback to the polling mode */
+ dev->irq =3D -1;
+ }
+ }
+
+ if (dev->irq < 0)
+ printk(KERN_WARNING "ibm-iic(%s): using polling mode\n",
+ dev->np->full_name);
+
+ /* Board specific settings */
+ prop =3D of_get_property(np, "iic-mode", &len);
+ /* use 400kHz only if stated in dts, 100kHz otherwise */
+ dev->fast_mode =3D (prop && (*prop =3D=3D 400));
+ /* clckdiv is the same for *all* IIC interfaces,
+ * but I'd rather make a copy than introduce another global. --ebs
+ */
+ /* Parent bus should have frequency filled */
+ prop =3D of_get_property(of_get_parent(np), "clock-frequency", &len);
+ if (prop =3D=3D NULL) {
+ printk(KERN_ERR
+ "ibm-iic(%s):no clock-frequency prop on parent bus!\n",
+ dev->np->full_name);
+ goto fail;
+ }
+
+ dev->clckdiv =3D iic_clckdiv(*prop);
+ DBG("%s: clckdiv =3D %d\n", dev->np->full_name, dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap =3D &dev->adap;
+ adap->dev.parent =3D &ofdev->dev;
+ strcpy(adap->name, "IBM IIC");
+ i2c_set_adapdata(adap, dev);
+ adap->id =3D I2C_HW_OCP;
+ adap->class =3D I2C_CLASS_HWMON;
+ adap->algo =3D &iic_algo;
+ adap->client_register =3D NULL;
+ adap->client_unregister =3D NULL;
+ adap->timeout =3D 1;
+ adap->retries =3D 1;
+
+ adap->nr =3D ++device_idx;
+ if ((ret =3D i2c_add_numbered_adapter(adap)) < 0) {
+ printk(KERN_CRIT "ibm-iic(%s): failed to register i2c adapter\n",
+ dev->np->full_name);
+ goto fail;
+ }
+
+ printk(KERN_INFO "ibm-iic(%s): using %s mode\n", dev->np->full_name,
+ dev->fast_mode ?
+ "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+fail:
+ if (dev->irq >=3D 0) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+fail2:
+ release_mem_region(dev->paddr, sizeof(struct iic_regs));
+fail1:
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private *dev =3D dev_get_drvdata(&ofdev->dev);
+
+ BUG_ON(dev =3D=3D NULL);
+ if (i2c_del_adapter(&dev->adap)) {
+ printk(KERN_CRIT "ibm-iic(%s): failed to delete i2c adapter\n",
+ dev->np->full_name);
+ /* That's *very* bad, just shutdown IRQ ... */
+ if (dev->irq >=3D 0) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ dev->irq =3D -1;
+ }
+ } else {
+ if (dev->irq >=3D 0) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+ iounmap(dev->vaddr);
+ release_mem_region(dev->paddr, sizeof(struct iic_regs));
+ kfree(dev);
+ }
+
+ return 0;
+}
+
+static struct of_device_id ibm_iic_match[] =3D {
+ {
+ .type =3D "i2c",
+ .compatible =3D "ibm,iic",
+ },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, ibm_iic_match);
+
+static struct of_platform_driver ibm_iic_driver =3D {
+ .name =3D "ibm-iic",
+ .match_table =3D ibm_iic_match,
+ .probe =3D iic_probe,
+ .remove =3D iic_remove,
+};
+
+static int __init iic_init(void)
+{
+ printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+
+module_init(iic_init);
+module_exit(iic_exit);
^ permalink raw reply
* Re: [PATCH 4/7] powerpc: BestComm core support for Freescale MPC5200
From: Stephen Rothwell @ 2007-09-16 12:31 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Grant Likely, Paul Mackerras, PowerPC dev list
In-Reply-To: <1189940011134-git-send-email-tnt@246tNt.com>
[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]
On Sun, 16 Sep 2007 12:53:27 +0200 Sylvain Munaut <tnt@246tNt.com> wrote:
>
> +++ b/arch/powerpc/sysdev/bestcomm/Makefile
> @@ -0,0 +1,8 @@
> +#
> +# Makefile for BestComm & co
> +#
> +
> +bestcomm-core-objs := bestcomm.o sram.o
> +
> +obj-$(CONFIG_PPC_BESTCOMM) += bestcomm-core.o
Or just obj-y since the whole makefile is dependent on CONFIG_PPC_BESTCOMM.
> +++ b/arch/powerpc/sysdev/bestcomm/bestcomm.c
>
> +#include <asm/io.h>
> +#include <asm/irq.h>
> +#include <asm/prom.h>
> +#include <asm/mpc52xx.h>
> +#include <asm/of_device.h>
> +#include <asm/of_platform.h>
Please include linux/of_device.h and linux/of_platform.h instead.
And linux/of.h instead of asm/prom.h.
> + ofn_bcom = op->node;
> + of_node_get(ofn_bcom);
The usual idiom is ofn_bcom = of_get_node(op->node);
> + /* Save the node */
> + bcom_eng->ofnode = ofn_bcom;
> +
> + /* Get, reserve & map io */
> + if (of_address_to_resource(bcom_eng->ofnode, 0, &res_bcom)) {
^^^^^^^^^^^^^^^^
Any reason not to use ofn_bcom here?
> + /* Error path */
> +error_unmap:
> + iounmap(bcom_eng->regs);
> +error_release:
> + release_mem_region(res_bcom.start, sizeof(struct mpc52xx_sdma));
> +error_sramclean:
> + bcom_sram_cleanup();
> +error_ofput:
> + of_node_put(bcom_eng->ofnode);
^^^^^^^^^^^^^^^^
And here? Also bcom_eng doesn't get freed in the error path.
> +++ b/arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
> +#include <linux/spinlock.h>
> +#include <asm/io.h>
> +#include <asm/prom.h>
Again please include linux/of.h instead of asm/prom.h
> +++ b/arch/powerpc/sysdev/bestcomm/sram.c
> +
> +#include <asm/io.h>
> +#include <asm/mmu.h>
> +#include <asm/prom.h>
And again.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: Linux booting problem on Xilinx ppc
From: Stelios Koroneos @ 2007-09-16 15:37 UTC (permalink / raw)
To: Junqiang Hu, linuxppc-embedded
In-Reply-To: <12696686.post@talk.nabble.com>
We are seeing similar problems (wrong memory displayed, kernel hangup) when
compiling a 2.6.23-rc2 kernel with gcc 4.1.1 for an ml403 board.
Using gcc 3.4.4 to compile the kernel, then there is no problem (the kernel
boots)
Setting mem in the kernel config does not solve the issue.
Stelios S. Koroneos
Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+stelios=stelioscellar.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+stelios=stelioscellar.com@ozlabs
> .org]On Behalf Of Junqiang Hu
> Sent: Sunday, September 16, 2007 7:40 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux booting problem on Xilinx ppc
>
>
>
>
> Hi Grant,
>
> Thank you so much for the reply! Fortunately I got it work now -- it's
> the crosstool compiler problem. Originally I was using
> gcc-4.1.0, yet when
> compiling kernel 2.6.22, I noticed that it says gcc-4.1.0 will miscompile
> the kernel, so I changed to another version, and now I can let it go!
>
> Right now still not fully booted because of the SystemACE problem, or
> maybe the partition is not correct. I'm still working on it, hopefully to
> get it solved soon :-)
>
> Thanks,
> -J.
>
>
> Grant Likely-2 wrote:
> >
> > On 9/15/07, Junqiang Hu <jqhu936@yahoo.com> wrote:
> >>
> >>
> >> Dear friends,
> >>
> >> I'm trying to run Linux in AvNet (Memec) Xilinx-XC2VP50-EVKT-FF1152
> >> board. The Linux version I'm using is 2.4; the cross-compiler is
> >> gcc-4.1.0, glibc 2.3.6. When booting the kernel, it shows:
> >> loaded at: 00400000 004B51E4
> >> board data at: 00000000 00000018
> >> relocated to: 0040526C 00405284
> >> zimage at: 00405B2B 004B177C
> >> avail ram: 004B6000 60000000
> >
> > I strongly recommend moving to a 2.6 kernel. Recent mainline has
> > support for the Xilinx ppc built in.
> >>
> >> Linux/PPC load: console=ttyS0,9600
> root=/dev/xsysace/disc0/part3 rw
> >> Uncompressing Linux...done.
> >> Now booting the kernel
> >>
> >> Then it hangs. First it seems to me that the "avail ram" is
> not correct,
> >> since I configured only 32MB SDRAM. Moreover, if it's first
> powered on,
> >> the
> >> end address of "avail ram" would be FFD9FBED. Then I tried to
> investigate
> >> the problem using xmd. When launched, it says:
> >
> > (If you're using u-boot) You might have a mismatch between the board
> > info structure used by u-boot and the one used by Linux.
> >
> > Also, you should use your debugger to inspect the __log_buf memory of
> > the kernel. A common problem is the kernel starts booting, but the
> > console is setup incorrectly and so you see nothing. But, you can
> > read the console output directly from memory if you look at the
> > __log_buf region (find the address in the System.map file; you might
> > need to subtract 0xC0000000 from the address to view the memory)
> >
> > Cheers,
> > g.
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> > grant.likely@secretlab.ca
> > (403) 399-0195
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Linux-booting-problem-on-Xilinx-ppc-tf444906
0.html#a12696686
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 2/7] powerpc: Changes the config mechanism for rheap
From: Kumar Gala @ 2007-09-16 15:59 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Grant Likely, Paul Mackerras, PowerPC dev list
In-Reply-To: <1189940011152-git-send-email-tnt@246tNt.com>
On Sep 16, 2007, at 5:53 AM, Sylvain Munaut wrote:
> Instead of having in the makefile all the option that
> requires rheap, we define a configuration symbol
> and when needed we make sure it's selected.
>
> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> arch/powerpc/Kconfig | 2 ++
> arch/powerpc/lib/Kconfig | 3 +++
> arch/powerpc/lib/Makefile | 5 +----
> arch/powerpc/platforms/Kconfig | 2 ++
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> 5 files changed, 9 insertions(+), 4 deletions(-)
> create mode 100644 arch/powerpc/lib/Kconfig
This probably breaks arch/ppc in that you'll need to add the proper
select PPC_LIB_RHEAP to its Kconfig(s) for 8xx & CPM2.
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 00099ef..76063b9 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -634,6 +634,8 @@ source "fs/Kconfig"
>
> source "arch/powerpc/sysdev/qe_lib/Kconfig"
>
> +source "arch/powerpc/lib/Kconfig"
> +
> source "lib/Kconfig"
>
> menu "Instrumentation Support"
> diff --git a/arch/powerpc/lib/Kconfig b/arch/powerpc/lib/Kconfig
> new file mode 100644
> index 0000000..f383ad4
why not just stick this in the toplevel powerpc/Kconfig
> --- /dev/null
> +++ b/arch/powerpc/lib/Kconfig
> @@ -0,0 +1,3 @@
> +config PPC_LIB_RHEAP
> + bool
> + default n
Please add a help description here.
[snip]
- k
^ permalink raw reply
* Re: [PATCH 4/7] powerpc: BestComm core support for Freescale MPC5200
From: Kumar Gala @ 2007-09-16 16:07 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Grant Likely, Paul Mackerras, PowerPC dev list
In-Reply-To: <1189940011134-git-send-email-tnt@246tNt.com>
On Sep 16, 2007, at 5:53 AM, Sylvain Munaut wrote:
> This patch adds support for the core of the BestComm API
> for the Freescale MPC5200(b). The BestComm engine is a
> microcode-controlled / tasks-based DMA used by several
> of the onchip devices.
>
> Setting up the tasks / memory allocation and all common
> low level functions are handled by this patch.
> The specifics details of each tasks and their microcode
> are split-out in separate patches.
>
> This is not the official API, but a much cleaner one.
> (hopefully)
>
> Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
> ---
> arch/powerpc/platforms/Kconfig | 2 +
> arch/powerpc/sysdev/Makefile | 1 +
> arch/powerpc/sysdev/bestcomm/Kconfig | 18 +
> arch/powerpc/sysdev/bestcomm/Makefile | 8 +
> arch/powerpc/sysdev/bestcomm/bestcomm.c | 657 +++++++++++++++
> +++++++++++
> arch/powerpc/sysdev/bestcomm/bestcomm.h | 136 ++++++
> arch/powerpc/sysdev/bestcomm/bestcomm_priv.h | 325 +++++++++++++
> arch/powerpc/sysdev/bestcomm/sram.c | 177 +++++++
> arch/powerpc/sysdev/bestcomm/sram.h | 54 +++
> 9 files changed, 1378 insertions(+), 0 deletions(-)
> create mode 100644 arch/powerpc/sysdev/bestcomm/Kconfig
> create mode 100644 arch/powerpc/sysdev/bestcomm/Makefile
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.c
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm.h
> create mode 100644 arch/powerpc/sysdev/bestcomm/bestcomm_priv.h
> create mode 100644 arch/powerpc/sysdev/bestcomm/sram.c
> create mode 100644 arch/powerpc/sysdev/bestcomm/sram.h
this version still doesn't address comments made back in may:
http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036224.html
Also, what about splitting bestcomm.c into bestcomm_task.c &
bestcomm_drv.c (or just bestcomm.c) or something like that. It seems
'private API' isn't really the proper term.
- k
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Robert Schwebel @ 2007-09-16 16:27 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200709161352.03459.sr@denx.de>
On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 9f3a4cd..12453e2 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -220,7 +220,17 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on !PPC_MERGE
> + help
> + Say Y here if you want to use IIC peripheral found on
> + embedded IBM PPC 4xx based systems.
Can we agree on one nomenclature - either i2c or iic?
> + This driver can also be built as a module. If so, the module
> + will be called i2c-ibm_iic.
Are these drivers the same functionality (host i2c driver for 4xx)? If
yes, shouldn't all in-tree users be migrated over and the old style
driver be removed (with deprecation period)?
> +#define DBG_LEVEL 0
> +
> +#ifdef DBG
> +#undef DBG
> +#endif
> +
> +#ifdef DBG2
> +#undef DBG2
> +#endif
> +
> +#if DBG_LEVEL > 0
> +# define DBG(f,x...) printk(KERN_DEBUG "ibm-iic" f, ##x)
> +#else
> +# define DBG(f,x...) ((void)0)
> +#endif
> +#if DBG_LEVEL > 1
> +# define DBG2(f,x...) DBG(f, ##x)
> +#else
> +# define DBG2(f,x...) ((void)0)
> +#endif
Any reason why you can't use pr_debug?
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Josh Boyer @ 2007-09-16 16:37 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916162747.GV23573@pengutronix.de>
On Sun, 16 Sep 2007 18:27:47 +0200
Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
>
> Can we agree on one nomenclature - either i2c or iic?
>
> > + This driver can also be built as a module. If so, the module
> > + will be called i2c-ibm_iic.
>
> Are these drivers the same functionality (host i2c driver for 4xx)? If
> yes, shouldn't all in-tree users be migrated over and the old style
> driver be removed (with deprecation period)?
They are the same functionality, but for two different versions of the
arch. The old one is arch/ppc, the new one is arch/powerpc. 4xx is
being migrated to arch/powerpc so eventually what you say will happen.
The arch/ppc tree is scheduled for removal in June of 2008. For now,
we need both drivers since not everything in 4xx has moved yet.
josh
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 17:00 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709150855k6ba6dc8fye9762817566208b4@mail.gmail.com>
On 9/15/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 9/15/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > On 15/09/07 00:28 -0400, Jon Smirl wrote:
> > > On 9/14/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > > > This patch doesn't seem to working quite right on my hardware (Phytec
> > > > pcm030). At boot I get a long pause.
> > >
> > > It also doesn't compile if CONFIG_FEC_MPC52xx_MDIO is undefined.
> >
> > Right, darn.
> > Try this one: http://coderock.org/tmp/fec-v3rc1/
>
> 0.776407] 0x00f40000-0x00f80000 : "oftree"
> [ 0.782101] 0x00f80000-0x01000000 : "space"
> [ 0.788100] TCP cubic registered
> [ 0.791427] NET: Registered protocol family 1
> [ 0.795904] NET: Registered protocol family 17
> [ 1.305579] f0003000:00 not found
> [ 1.308985] net eth0: phy_connect failed
> [ 1.312961] net eth0: fec_init_phy failed
> [ 1.317188] IP-Config: Failed to open eth0
> [ 1.321362] IP-Config: No network devices available.
> [ 1.326973] Looking up port of RPC 100003/3 on 192.168.1.4
This fixes the problem....
diff --git a/drivers/net/fec_mpc52xx/fec.c b/drivers/net/fec_mpc52xx/fec.c
index 922e9a8..c4442e0 100644
--- a/drivers/net/fec_mpc52xx/fec.c
+++ b/drivers/net/fec_mpc52xx/fec.c
@@ -1087,11 +1087,13 @@ static struct of_platform_driver mpc52xx_fec_driver = {
/* ======================================================================== */
/* Module */
/* ======================================================================== */
+extern int fec_mdio_init(void);
+void fec_mdio_exit(void);
static int __init
mpc52xx_fec_init(void)
{
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
int ret;
ret = fec_mdio_init();
if (ret) {
@@ -1106,7 +1108,7 @@ static void __exit
mpc52xx_fec_exit(void)
{
of_unregister_platform_driver(&mpc52xx_fec_driver);
-#ifdef FEC_MPC52xx_MDIO
+#ifdef CONFIG_FEC_MPC52xx_MDIO
fec_mdio_exit();
#endif
}
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply related
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 17:05 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161000i64622520i77caa00e56abc7a8@mail.gmail.com>
[ 1.309662] net eth0: attached phy 0 to driver Generic PHY
[ 2.316013] Sending DHCP requests .<6>PHY: f0003000:00 - Link is Up
- 100/Full
[ 4.392000] ., OK
[ 7.100005] IP-Config: Got DHCP answer from 192.168.1.200, my
address is 192.168.1.5
[ 7.108154] IP-Config: Complete:
[ 7.111247] device=eth0, addr=192.168.1.5,
mask=255.255.255.0, gw=192.168.1.200,
[ 7.119249] host=MPC, domain=home, nis-domain=(none),
[ 7.124811] bootserver=192.168.1.200, rootserver=192.168.1.4, rootpath=
DHCP wants to print "Sending DHCP requests .., OK"
But the interrupt from the link coming up printed "<6>PHY: f0003000:00
- Link is Up - 100/Full"
The <6> is visible since it wasn't on the beginning of a line.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:00 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161005u4f400ab7wb1bf55dac1b45193@mail.gmail.com>
Another problem...
Ifconfig eth0 down
hangs the system.
I'll try debugging it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:25 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709161100i456c176ay664d89ac638c9958@mail.gmail.com>
On 9/16/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Another problem...
>
> Ifconfig eth0 down
>
> hangs the system.
> I'll try debugging it.
The hang is something to do with lockd in NFS, it doesn't appear to
have anything to do with fec. I think I need to build more of NFS into
my kernel.
My DNS servers are not getting set up, but that's probably an issue
with the distro I'm using.
I did some big copy commands and fec seems to working ok.
Next I'll look at how the pcm030 supplies an Ethernet address. It has
an EEPROM on the board that holds it. Is this something that can be
read from of?
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Robert Schwebel @ 2007-09-16 18:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161125u15dcd02cj300c0e3a7fda4c0a@mail.gmail.com>
On Sun, Sep 16, 2007 at 02:25:09PM -0400, Jon Smirl wrote:
> Next I'll look at how the pcm030 supplies an Ethernet address. It has
> an EEPROM on the board that holds it. Is this something that can be
> read from of?
If you use our u-boot port, the mac addresses are being written by
u-boot and should already be present when linux comes in.
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:38 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <20070916183446.GX23573@pengutronix.de>
On 9/16/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 02:25:09PM -0400, Jon Smirl wrote:
> > Next I'll look at how the pcm030 supplies an Ethernet address. It has
> > an EEPROM on the board that holds it. Is this something that can be
> > read from of?
>
> If you use our u-boot port, the mac addresses are being written by
> u-boot and should already be present when linux comes in.
Your right, it is already there.
Any idea why my DNS servers are getting set up from DHCP?
>
> Robert
> --
> Pengutronix - Linux Solutions for Science and Industry
> Entwicklungszentrum Nord http://www.pengutronix.de
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Robert Schwebel @ 2007-09-16 18:50 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161138m177edb1k99e5df120e9ca9df@mail.gmail.com>
On Sun, Sep 16, 2007 at 02:38:55PM -0400, Jon Smirl wrote:
> Any idea why my DNS servers are getting set up from DHCP?
Well, check your DHCP server config :-)
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-09-16 18:53 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200709161352.03459.sr@denx.de>
On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> This patch reworks existing ibm-iic driver to an of_platform_device
> and enables it to talk to device tree directly. The ocp quirks are
> completely removed by this patch.
>
> This is done to enable I2C support for the PPC4xx platforms now
> being moved from arch/ppc (OCP) to arch/powerpc (of). The first board
> using this driver will be the AMCC Sequoia (PPC440EPx).
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> ---
> 2nd try with some cleanups. Please let me know if there still are some
> problems.
>
> Thanks.
>
> commit 5748f81ff53277fa5c16de815b7d6b172ca284e9
> tree 8284b3f1c836eb6eb06ee6882ee13b9e8f6cbb6b
> parent d0174640eedc1cd756754f03afe2dbb3d56de74e
> author Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> committer Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
>
> drivers/i2c/busses/Kconfig | 12 -
> drivers/i2c/busses/Makefile | 1
> drivers/i2c/busses/i2c-ibm_iic.h | 3
> drivers/i2c/busses/i2c-ibm_of.c | 858 ++++++++++++++++++++++++++++++++++++++
> 4 files changed, 873 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index 9f3a4cd..12453e2 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -220,7 +220,17 @@ config I2C_PIIX4
>
> config I2C_IBM_IIC
> tristate "IBM PPC 4xx on-chip I2C interface"
> - depends on IBM_OCP
> + depends on !PPC_MERGE
> + help
> + Say Y here if you want to use IIC peripheral found on
> + embedded IBM PPC 4xx based systems.
> +
> + This driver can also be built as a module. If so, the module
> + will be called i2c-ibm_iic.
> +
> +config I2C_IBM_OF
> + tristate "IBM PPC 4xx on-chip I2C interface"
> + depends on PPC_MERGE
> help
> Say Y here if you want to use IIC peripheral found on
> embedded IBM PPC 4xx based systems.
> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> index 5b752e4..0cd0bac 100644
> --- a/drivers/i2c/busses/Makefile
> +++ b/drivers/i2c/busses/Makefile
> @@ -17,6 +17,7 @@ obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> obj-$(CONFIG_I2C_I801) += i2c-i801.o
> obj-$(CONFIG_I2C_I810) += i2c-i810.o
> obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
> +obj-$(CONFIG_I2C_IBM_OF) += i2c-ibm_of.o
> obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
> obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o
> obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
Hmm, I just noticed that you basically added a copy of existing
driver with small changes to support OF while keeping OCP one.
Why not just add OF support to the existing code (under some ifdef),
and then remove OCP support as soon as ppc -> powerpc transition is
finished? Why have two almost identical code in the tree?
I also personally don't like this _iic -> _of name change (you
removed peripheral name and added something which has nothing to do
with iic, I never heard of OF peripheral in 4xx chips). Whether you
use OCP or OF to pass a little information is quite irrelevant to the
iic driver operation.
If you insist on this approach, please add yourself as a maintainer of
this code, because I'm not going to support two identical copies of my
code in the kernel tree.
--
Eugene
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 18:54 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <20070916185041.GY23573@pengutronix.de>
On 9/16/07, Robert Schwebel <r.schwebel@pengutronix.de> wrote:
> On Sun, Sep 16, 2007 at 02:38:55PM -0400, Jon Smirl wrote:
> > Any idea why my DNS servers are getting set up from DHCP?
>
> Well, check your DHCP server config :-)
My x86/arm boxes are getting it ok from same server.
>
> Robert
> --
> Pengutronix - Linux Solutions for Science and Industry
> Entwicklungszentrum Nord http://www.pengutronix.de
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: Eugene Surovegin @ 2007-09-16 18:55 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, i2c, linuxppc-dev
In-Reply-To: <200709161107.23309.sr@denx.de>
On Sun, Sep 16, 2007 at 11:07:23AM +0200, Stefan Roese wrote:
> On Saturday 15 September 2007, Vitaly Bordug wrote:
> > > Where is dev->clkdiv initialized?
> > >
> > > My original version used iic_clkdiv() to calculate correct devider
> > > based on OPB frequency. Did you even test this code?
>
> Yes, I tested it successfully on the Sequoia eval board.
I meant with the scope attached to i2c lines to verify correct i2c
speed.
--
Eugene
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jon Smirl @ 2007-09-16 19:05 UTC (permalink / raw)
To: Domen Puncer; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910709150855k6ba6dc8fye9762817566208b4@mail.gmail.com>
This adjustment to the error counting is in the Efika patches and not
in yours, should it be in yours too?
--- a/drivers/net/fec_mpc52xx/fec.c 2007-05-30 16:04:50.000000000 +0200
+++ b/drivers/net/fec_mpc52xx/fec.c 2007-05-30 16:09:02.000000000 +0200
@@ -411,7 +411,9 @@
stats->rx_bytes = in_be32(&fec->rmon_r_octets);
stats->rx_packets = in_be32(&fec->rmon_r_packets);
- stats->rx_errors = stats->rx_packets - in_be32(&fec->ieee_r_frame_ok);
+ stats->rx_errors = stats->rx_packets - (
+ in_be32(&fec->ieee_r_frame_ok) +
+ in_be32(&fec->rmon_r_mc_pkt));
stats->tx_bytes = in_be32(&fec->rmon_t_octets);
stats->tx_packets = in_be32(&fec->rmon_t_packets);
stats->tx_errors = stats->tx_packets - (
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Domen's MPC5200 FEC cleanup patch.
From: Jeff Mock @ 2007-09-16 18:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: Domen Puncer, linuxppc-embedded
In-Reply-To: <9e4733910709161125u15dcd02cj300c0e3a7fda4c0a@mail.gmail.com>
Jon Smirl wrote:
> On 9/16/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> Another problem...
>>
>> Ifconfig eth0 down
>>
>> hangs the system.
>> I'll try debugging it.
>
> The hang is something to do with lockd in NFS, it doesn't appear to
> have anything to do with fec. I think I need to build more of NFS into
> my kernel.
>
I think the NFS hang has something to do with not having a copy of
portmap running. I've had this happen with other embedded systems, and
can usually work around it by using the "-o nolock" option when doing
the NFS mount.
jeff
^ permalink raw reply
* Re: FDT for Microblaze and PPC405
From: Michal Simek @ 2007-09-14 19:35 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev
In-Reply-To: <fa686aa40709111009j64925edag511078d88ff904c@mail.gmail.com>
Hi,
I made EDK tcl script for generation DTS test scructure for FDT. Script
support Microblaze and PowerPC 405.
Script was primary built for generation U-BOOT configs files for Microblaze.
For Microblaze can you generate both files (FDT and U-BOOT).
For PowerPC can you generate only DTS file. Generation U-BOOT configs files
aren't supported yet. Script ends after generation DTS.
Script has 2.00.a mark.
It is available at www.monstr.eu.
Cheers,
Michal Simek
> On 9/11/07, Michal Simek <Monstr@seznam.cz> wrote:
>> Hi Grant,
>
> (Adding linuxppc-dev mailing list to CC list because we're discussing
> FDT issues)
>
>> I made EDK repository file for generation dts file from Xilinx design. I
>> sent it to Wolfgang and Steve this week.
>> It is in the same config file as I use for configuration Microblaze for
>> U-BOOT. If you want I can send you this repository files.
>
> Yes, please do.
>
>> And I start with redesigning Linux kernel for Microblaze. I ported some
>> peripherals as timer and intc etc.
>> But for some peripherals I need better configuration.
>>
>> I have no time to read information about fdt. Can you tell me what labels
>> I can use?
>
> Steve has already done a bunch of work in this direction on
> microblaze, I would converse with him.
>
>>
>> For example emaclite driver needs information about turning on/off ping
>> pong buffer...
>>
>> I would like to make this properly.
>
> FDT design is just as much art as it is science. It takes taste and
> judgement to desgin a nice set of bindings. Your best option is to
> draft something and post it to the linuxppc-embedded mailing list for
> review.
>
>>
>> And second question is on early console logs and timers setting. I read
>> about aliases in FDT. I think that aliases can cover this setting.
>> For example my design contain 4 serial line and I would like to know
>> which serial line is set on early console.
>
> You use the chosen node for this. In the chosen node, you add a
> property called "linux,stdout-path" which holds the path to your
> console. You can look at examples under arch/powerpc/boot/dts/*
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.15/1002 - Release Date:
> 11.9.2007 05:46
>
>
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-09-17 1:31 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916185330.GA32314@gate.ebshome.net>
On Sun, Sep 16, 2007 at 11:53:30AM -0700, Eugene Surovegin wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > This patch reworks existing ibm-iic driver to an of_platform_device
> > and enables it to talk to device tree directly. The ocp quirks are
> > completely removed by this patch.
> >
> > This is done to enable I2C support for the PPC4xx platforms now
> > being moved from arch/ppc (OCP) to arch/powerpc (of). The first board
> > using this driver will be the AMCC Sequoia (PPC440EPx).
> >
> > Signed-off-by: Stefan Roese <sr@denx.de>
> >
> > ---
> > 2nd try with some cleanups. Please let me know if there still are some
> > problems.
> >
> > Thanks.
> >
> > commit 5748f81ff53277fa5c16de815b7d6b172ca284e9
> > tree 8284b3f1c836eb6eb06ee6882ee13b9e8f6cbb6b
> > parent d0174640eedc1cd756754f03afe2dbb3d56de74e
> > author Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> > committer Stefan Roese <sr@denx.de> Sun, 16 Sep 2007 13:46:40 +0200
> >
> > drivers/i2c/busses/Kconfig | 12 -
> > drivers/i2c/busses/Makefile | 1
> > drivers/i2c/busses/i2c-ibm_iic.h | 3
> > drivers/i2c/busses/i2c-ibm_of.c | 858 ++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 873 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called i2c-ibm_iic.
> > +
> > +config I2C_IBM_OF
> > + tristate "IBM PPC 4xx on-chip I2C interface"
> > + depends on PPC_MERGE
> > help
> > Say Y here if you want to use IIC peripheral found on
> > embedded IBM PPC 4xx based systems.
> > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> > index 5b752e4..0cd0bac 100644
> > --- a/drivers/i2c/busses/Makefile
> > +++ b/drivers/i2c/busses/Makefile
> > @@ -17,6 +17,7 @@ obj-$(CONFIG_I2C_HYDRA) += i2c-hydra.o
> > obj-$(CONFIG_I2C_I801) += i2c-i801.o
> > obj-$(CONFIG_I2C_I810) += i2c-i810.o
> > obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
> > +obj-$(CONFIG_I2C_IBM_OF) += i2c-ibm_of.o
> > obj-$(CONFIG_I2C_IOP3XX) += i2c-iop3xx.o
> > obj-$(CONFIG_I2C_IXP2000) += i2c-ixp2000.o
> > obj-$(CONFIG_I2C_IXP4XX) += i2c-ixp4xx.o
>
> Hmm, I just noticed that you basically added a copy of existing
> driver with small changes to support OF while keeping OCP one.
>
> Why not just add OF support to the existing code (under some ifdef),
> and then remove OCP support as soon as ppc -> powerpc transition is
> finished? Why have two almost identical code in the tree?
>
> I also personally don't like this _iic -> _of name change (you
> removed peripheral name and added something which has nothing to do
> with iic, I never heard of OF peripheral in 4xx chips). Whether you
> use OCP or OF to pass a little information is quite irrelevant to the
> iic driver operation.
I concur on this point. Especially since on 4xx the device tree will
generally be a flattened device tree which is vaguely OF-like, but not
from an actual Open Firmware.
> If you insist on this approach, please add yourself as a maintainer of
> this code, because I'm not going to support two identical copies of my
> code in the kernel tree.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] i2c: devtree-aware iic support for PPC4xx
From: David Gibson @ 2007-09-17 1:32 UTC (permalink / raw)
To: Robert Schwebel; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <20070916162747.GV23573@pengutronix.de>
On Sun, Sep 16, 2007 at 06:27:47PM +0200, Robert Schwebel wrote:
> On Sun, Sep 16, 2007 at 01:52:02PM +0200, Stefan Roese wrote:
> > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> > index 9f3a4cd..12453e2 100644
> > --- a/drivers/i2c/busses/Kconfig
> > +++ b/drivers/i2c/busses/Kconfig
> > @@ -220,7 +220,17 @@ config I2C_PIIX4
> >
> > config I2C_IBM_IIC
> > tristate "IBM PPC 4xx on-chip I2C interface"
> > - depends on IBM_OCP
> > + depends on !PPC_MERGE
> > + help
> > + Say Y here if you want to use IIC peripheral found on
> > + embedded IBM PPC 4xx based systems.
>
> Can we agree on one nomenclature - either i2c or iic?
The dual nomenclature comes because linux uses i2c throughout the
subsystem, but all the hardware documentation refers to the controller
ASIC in question as 'IIC'. So I think the convention is that 'i2c' is
used to refer to the type of bus in general, 'iic' is used to refer to
this particular type of bus controller.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: David Gibson @ 2007-09-17 2:02 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <20070915150901.AC712247CE@gemini.denx.de>
On Sat, Sep 15, 2007 at 05:09:01PM +0200, Wolfgang Denk wrote:
> In message <1189866379.17593.2.camel@localhost.localdomain> Josh Boyer wrote:
> > On Sat, 2007-09-15 at 05:23 +0200, Stefan Roese wrote:
> ...
> > > There are not only Bamboo board running PIBS, but running U-Boot too. How
> > > should we handle this different FLASH partitioning? Same goes for Ebony too
> > > btw.
> >
> > That's a good question. I'm working on making the NOR flash show up for
> > Bamboo right now, and I had intended to just leave the partition
> > subnodes missing.
>
> Maybe we can have U-Boot add the partition information if it's
> missing in the device tree, and extend the mtdparts command in U-Boot
> to add / adjust settings so they match what is defined in U-Boot.
>
> Stefan, what do you think?
If U-Boot is supplying a device tree, it should certainly make the
partition information match its own idea of the partitions.
For older non-device-tree away u-boot, I guess we'll have to make the
cuboot and treeboot wrappers mangle the device tree differently to
correct the partition information.
I suspect the easiest way to do this will be for the dts to contain
both treeboot and u-boot partition info, and have the wrapper delete
or nop the nodes for the other firmware.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/4] 4xx: Convert Walnut flash mappings to new binding
From: David Gibson @ 2007-09-17 2:03 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Stefan Roese
In-Reply-To: <addcdbe0ab5b83aa58fc4e7df37b0925@kernel.crashing.org>
On Sat, Sep 15, 2007 at 09:20:10PM +0200, Segher Boessenkool wrote:
> >> Maybe we can have U-Boot add the partition information if it's
> >> missing in the device tree, and extend the mtdparts command in U-Boot
> >> to add / adjust settings so they match what is defined in U-Boot.
> >
> > That would be great for newer U-Boots. For existing older ones, it
> > doesn't really solve the problem. But then again, there's no way to
> > possibly define all the partitioning schemes people may have adopted to
> > their needs on their boards. And I believe that is why David has
> > RedBoot and command line partitioning override what is in the DTS
> > today.
>
> Yeah, partitioning information really doesn't belong in the device
> tree -- with the possible exception of the partitions that the
> firmware (uboot in this case) needs to know about anyway.
Indeed - but we had just the same problem, only worse, with the old
approach of hardcoded, configured-in flash maps.
> You *can* put all partitioning info in the device tree, but that
> doesn't mean you *should* :-)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
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