* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Kumar Gala @ 2009-04-01 13:27 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <49D367C7.5010802@grandegger.com>
On Apr 1, 2009, at 8:10 AM, Wolfgang Grandegger wrote:
> Grant Likely wrote:
>> On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger <wg@grandegger.com
>> > wrote:
>>> Anton Vorontsov wrote:
>>>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>>>> [...]
>>>>>>>>>> + soc8544@e0000000 {
>>>>>>>>>> + #address-cells = <1>;
>>>>>>>>>> + #size-cells = <1>;
>>>>>>>>>> + device_type = "soc";
>>>>>>>>> Drop device_type here too.
>>>>>>>> Grrr, I just realized that removing the devices type "soc"
>>>>>>>> has broken
>>>>>>>> fsl_get_sys_freq(). See:
>>>>>>>>
>>>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>>>>
>>>>>>>> We need a quick fix and we could take the occasion to
>>>>>>>> establish a common
>>>>>>>> function for the MPC52xx as well, but it's not obvious to me
>>>>>>>> how to find
>>>>>>>> the SOC node without the device type property.
>>>>>>> SoC node should have a compatible property, just like
>>>>>>> everything else.
>>>>>>>
>>>>>>> compatible = "fsl,mpc8544-immr"; (immr == Internally Memory
>>>>>>> Mapped Registers)
>>>>>>>
>>>>>>> Many other boards already do this.
>>>>>> Yes, it does, but searching for the SOC node is not straight-
>>>>>> forward
>>>>>> because there is no common compatibility string but many CPU-
>>>>>> specific
>>>>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I
>>>>>> missed
>>>>>> something?
>>>>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly
>>>>> what it
>>>>> means, and add add it to the end of the compatible list.
>>>> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
>>>> parts. There it's called CCSR.
>>>>
>>>> See this thread:
>>>>
>>>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>>>>
>>>> I still think that
>>>> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
>>>> and
>>>> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>>>>
>>>> would be OK, at least to start with. We can always deprecate
>>>> "fsl,soc"
>>>> compatible in favour of something more elegant, but "fsl,soc"
>>>> should be
>>>> just fine to replace device_type = "soc".
>>>>
>>>> Also, there is another good thing about "fsl,soc" -- U-Boot already
>>>> finds it for 83xx CPUs. ;-)
>>> Ugh! I just realize the full impact of removing device type "soc".
>>> It
>>> will break compatibility with U-Boot for many boards. Is it worth
>>> it?
>>
>> Yes, I know this. I'm not asking you to fix all the other boards,
>> but
>> make sure that it is not required for the new board.
>
> Hm, I'm confused, if we want to fix this issue we need first to
>
> - fix all functions in fsl_soc.c searching for the compatible string
> "fsl,soc" instead of the device type "soc" (or both for backward
> compatibility).
>
> - fix U-Boot to find the SOC node by looking for "fsl,soc" to insert
> the
> proper bus-frequency, at least.
>
> That affects *all* boards using CONFIG_FSL_SOC and requires an
> up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
> can remove the "device_type = "soc";" from socrates.dts (and may
> more),
> but not right now. Or have I missed something?
I presume the intent is not to break old u-boots w/new kernels, but to
make it so new .dts don't require device_type = soc in them if using
new kernels.
- k
^ permalink raw reply
* Re: Broken CONFIG_HIGHPTE
From: Kumar Gala @ 2009-04-01 13:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1238564280.17330.119.camel@pasglop>
On Apr 1, 2009, at 12:38 AM, Benjamin Herrenschmidt wrote:
> Hi !
>
> Just noticed... And I'll be travelling for a while so with no much
> time to look at it.
>
> Your changes to use the PTE page free batch via RCU on ppc32 broke
> CONFIG_HIGHPTE for hash32...
>
> You rely on passing a page_address() of the PTE page down to the
> freeing layer. That doesn't work for highmem pages. That needs to
> be changes to a struct page * on 32-bit (not on 64-bit where we
> are using slabs though)
I can look into this, how does this show up?
- k
^ permalink raw reply
* [PATCH v2] powerpc: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-01 13:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: devicetree-discuss
This patch makes the I2C bus speed configurable by using the I2C node
property "clock-frequency". If the property is not defined, the old
fixed clock settings will be used for backward compatibility.
The generic I2C clock properties, especially the CPU-specific source
clock pre-scaler are defined via the OF match table:
static const struct of_device_id mpc_i2c_of_match[] = {
...
{.compatible = "fsl,mpc8543-i2c",
.data = &(struct fsl_i2c_match_data) {
.setclock = mpc_i2c_setclock_8xxx,
.prescaler = 2,
},
},
The "data" field defines the relevant I2C setclock function and the
relevant prescaler for the I2C source clock frequency.
It uses arch-specific tables and functions to determine resonable
Freqency Divider Register (fdr) values for MPC83xx, MPC85xx, MPC86xx,
MPC5200 and MPC5200B.
The i2c->flags field and the corresponding FSL_I2C_DEV_* definitions
have been removed as they are obsolete.
Furthermore dev_dbg() and dev_info() are now used to profit from a more
comprehensive output.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
---
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 43 +++++--
arch/powerpc/include/asm/mpc52xx.h | 11 +
arch/powerpc/platforms/52xx/mpc52xx_common.c | 57 ++++++++++
arch/powerpc/sysdev/fsl_soc.c | 90 ++++++++++++++++
arch/powerpc/sysdev/fsl_soc.h | 12 ++
drivers/i2c/busses/i2c-mpc.c | 138 ++++++++++++++++++-------
include/linux/fsl_devices.h | 9 -
7 files changed, 302 insertions(+), 58 deletions(-)
Index: linux-2.6/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- linux-2.6.orig/drivers/i2c/busses/i2c-mpc.c 2009-03-31 21:29:21.000000000 +0200
+++ linux-2.6/drivers/i2c/busses/i2c-mpc.c 2009-04-01 14:56:43.824970544 +0200
@@ -20,12 +20,15 @@
#include <linux/of_platform.h>
#include <linux/of_i2c.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <linux/fsl_devices.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
+#include <asm/mpc52xx.h>
+#include <sysdev/fsl_soc.h>
+
#define DRV_NAME "mpc-i2c"
#define MPC_I2C_FDR 0x04
@@ -50,12 +53,19 @@
#define CSR_RXAK 0x01
struct mpc_i2c {
+ struct device *dev;
void __iomem *base;
u32 interrupt;
wait_queue_head_t queue;
struct i2c_adapter adap;
int irq;
- u32 flags;
+};
+
+struct fsl_i2c_match_data {
+ void (*setclock)(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler);
+ u32 prescaler;
};
static __inline__ void writeccr(struct mpc_i2c *i2c, u32 x)
@@ -105,7 +115,7 @@
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
if (time_after(jiffies, orig_jiffies + timeout)) {
- pr_debug("I2C: timeout\n");
+ dev_dbg(i2c->dev, "timeout\n");
writeccr(i2c, 0);
result = -EIO;
break;
@@ -119,10 +129,10 @@
(i2c->interrupt & CSR_MIF), timeout * HZ);
if (unlikely(result < 0)) {
- pr_debug("I2C: wait interrupted\n");
+ dev_dbg(i2c->dev, "wait interrupted\n");
writeccr(i2c, 0);
} else if (unlikely(!(i2c->interrupt & CSR_MIF))) {
- pr_debug("I2C: wait timeout\n");
+ dev_dbg(i2c->dev, "wait timeout\n");
writeccr(i2c, 0);
result = -ETIMEDOUT;
}
@@ -135,17 +145,17 @@
return result;
if (!(x & CSR_MCF)) {
- pr_debug("I2C: unfinished\n");
+ dev_dbg(i2c->dev, "unfinished\n");
return -EIO;
}
if (x & CSR_MAL) {
- pr_debug("I2C: MAL\n");
+ dev_dbg(i2c->dev, "MAL\n");
return -EIO;
}
if (writing && (x & CSR_RXAK)) {
- pr_debug("I2C: No RXAK\n");
+ dev_dbg(i2c->dev, "No RXAK\n");
/* generate stop */
writeccr(i2c, CCR_MEN);
return -EIO;
@@ -153,16 +163,30 @@
return 0;
}
-static void mpc_i2c_setclock(struct mpc_i2c *i2c)
-{
- /* Set clock and filters */
- if (i2c->flags & FSL_I2C_DEV_SEPARATE_DFSRR) {
- writeb(0x31, i2c->base + MPC_I2C_FDR);
- writeb(0x10, i2c->base + MPC_I2C_DFSRR);
- } else if (i2c->flags & FSL_I2C_DEV_CLOCK_5200)
- writeb(0x3f, i2c->base + MPC_I2C_FDR);
- else
- writel(0x1031, i2c->base + MPC_I2C_FDR);
+static void mpc_i2c_setclock_52xx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = mpc52xx_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr < 0)
+ fdr = 0x3f; /* backward compatibility */
+ writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
+ dev_info(i2c->dev, "clock %d Hz (fdr=%d)\n", clock, fdr);
+}
+
+static void mpc_i2c_setclock_8xxx(struct device_node *node,
+ struct mpc_i2c *i2c,
+ u32 clock, u32 prescaler)
+{
+ int fdr = fsl_i2c_get_fdr(node, clock, prescaler);
+
+ if (fdr < 0)
+ fdr = 0x1031; /* backward compatibility */
+ writeb(fdr & 0xff, i2c->base + MPC_I2C_FDR);
+ writeb((fdr >> 8) & 0xff, i2c->base + MPC_I2C_DFSRR);
+ dev_info(i2c->dev, "clock %d Hz (dfsrr=%d fdr=%d)\n",
+ clock, fdr >> 8, fdr & 0xff);
}
static void mpc_i2c_start(struct mpc_i2c *i2c)
@@ -267,12 +291,12 @@
/* Allow bus up to 1s to become not busy */
while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
if (signal_pending(current)) {
- pr_debug("I2C: Interrupted\n");
+ dev_dbg(i2c->dev, "interrupted\n");
writeccr(i2c, 0);
return -EINTR;
}
if (time_after(jiffies, orig_jiffies + HZ)) {
- pr_debug("I2C: timeout\n");
+ dev_dbg(i2c->dev, "timeout\n");
if (readb(i2c->base + MPC_I2C_SR) ==
(CSR_MCF | CSR_MBB | CSR_RXAK))
mpc_i2c_fixup(i2c);
@@ -283,9 +307,10 @@
for (i = 0; ret >= 0 && i < num; i++) {
pmsg = &msgs[i];
- pr_debug("Doing %s %d bytes to 0x%02x - %d of %d messages\n",
- pmsg->flags & I2C_M_RD ? "read" : "write",
- pmsg->len, pmsg->addr, i + 1, num);
+ dev_dbg(i2c->dev,
+ "doing %s %d bytes to 0x%02x - %d of %d messages\n",
+ pmsg->flags & I2C_M_RD ? "read" : "write",
+ pmsg->len, pmsg->addr, i + 1, num);
if (pmsg->flags & I2C_M_RD)
ret =
mpc_read(i2c, pmsg->addr, pmsg->buf, pmsg->len, i);
@@ -316,13 +341,18 @@
static int __devinit fsl_i2c_probe(struct of_device *op, const struct of_device_id *match)
{
- int result = 0;
struct mpc_i2c *i2c;
+ const u32 *prop;
+ u32 clock = 0;
+ int result = 0;
+ int plen;
i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
if (!i2c)
return -ENOMEM;
+ i2c->dev = &op->dev; /* for device printouts */
+
init_waitqueue_head(&i2c->queue);
i2c->base = of_iomap(op->node, 0);
@@ -343,14 +373,20 @@
}
if (!of_get_property(op->node, "fsl,preserve-clocking", NULL)) {
- if (of_get_property(op->node, "dfsrr", NULL))
- i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
- of_device_is_compatible(op->node, "mpc5200-i2c"))
- i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
-
- mpc_i2c_setclock(i2c);
+ prop = of_get_property(op->node, "clock-frequency", &plen);
+ if (prop && plen == sizeof(u32))
+ clock = *prop;
+
+ if (match->data) {
+ struct fsl_i2c_match_data *data =
+ (struct fsl_i2c_match_data *)match->data;
+ data->setclock(op->node, i2c, clock, data->prescaler);
+ } else {
+ /* Backwards compatibility */
+ if (of_get_property(op->node, "dfsrr", NULL))
+ mpc_i2c_setclock_8xxx(op->node, i2c,
+ clock, 0);
+ }
}
dev_set_drvdata(&op->dev, i2c);
@@ -396,9 +432,43 @@
};
static const struct of_device_id mpc_i2c_of_match[] = {
- {.compatible = "fsl-i2c",},
+ {.compatible = "mpc5200-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_52xx,
+ },
+ },
+ {.compatible = "fsl,mpc5200b-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_52xx,
+ },
+ },
+ {.compatible = "fsl,mpc5200-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_52xx,
+ },
+ },
+ {.compatible = "fsl,mpc8313-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_8xxx,
+ },
+ },
+ {.compatible = "fsl,mpc8543-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 2,
+ },
+ },
+ {.compatible = "fsl,mpc8544-i2c",
+ .data = &(struct fsl_i2c_match_data) {
+ .setclock = mpc_i2c_setclock_8xxx,
+ .prescaler = 3,
+ },
+ /* Backward compatibility */
+ },
+ {.compatible = "fsl-i2c", },
{},
};
+
MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
@@ -419,7 +489,7 @@
rv = of_register_platform_driver(&mpc_i2c_driver);
if (rv)
- printk(KERN_ERR DRV_NAME
+ printk(KERN_ERR DRV_NAME
" of_register_platform_driver failed (%i)\n", rv);
return rv;
}
Index: linux-2.6/arch/powerpc/sysdev/fsl_soc.c
===================================================================
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c 2009-03-31 21:27:52.000000000 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-04-01 12:09:18.796719327 +0200
@@ -39,7 +39,7 @@
#include <sysdev/fsl_soc.h>
#include <mm/mmu_decl.h>
#include <asm/cpm2.h>
-
+#define DEBUG
extern void init_fcc_ioports(struct fs_platform_info*);
extern void init_fec_ioports(struct fs_platform_info*);
extern void init_smc_ioports(struct fs_uart_platform_info*);
@@ -102,6 +102,94 @@
}
EXPORT_SYMBOL(fsl_get_sys_freq);
+#ifdef CONFIG_I2C_MPC
+static const struct fsl_i2c_8xxx_divider {
+ u16 divider;
+ u16 fdr; /* including dfsrr */
+} fsl_i2c_8xxx_dividers[] = {
+ {160, 0x0120}, {192, 0x0121}, {224, 0x0122}, {256, 0x0123},
+ {288, 0x0100}, {320, 0x0101}, {352, 0x0601}, {384, 0x0102},
+ {416, 0x0602}, {448, 0x0126}, {480, 0x0103}, {512, 0x0127},
+ {544, 0x0b03}, {576, 0x0104}, {608, 0x1603}, {640, 0x0105},
+ {672, 0x2003}, {704, 0x0b05}, {736, 0x2b03}, {768, 0x0106},
+ {800, 0x3603}, {832, 0x0b06}, {896, 0x012a}, {960, 0x0107},
+ {1024, 0x012b}, {1088, 0x1607}, {1152, 0x0108}, {1216, 0x2b07},
+ {1280, 0x0109}, {1408, 0x1609}, {1536, 0x010a}, {1664, 0x160a},
+ {1792, 0x012e}, {1920, 0x010b}, {2048, 0x012f}, {2176, 0x2b0b},
+ {2304, 0x010c}, {2560, 0x010d}, {2816, 0x2b0d}, {3072, 0x010e},
+ {3328, 0x2b0e}, {3584, 0x0132}, {3840, 0x010f}, {4096, 0x0133},
+ {4608, 0x0110}, {5120, 0x0111}, {6144, 0x0112}, {7168, 0x0136},
+ {7680, 0x0113}, {8192, 0x0137}, {9216, 0x0114}, {10240, 0x0115},
+ {12288, 0x0116}, {14336, 0x013a}, {15360, 0x0117}, {16384, 0x013b},
+ {18432, 0x0118}, {20480, 0x0119}, {24576, 0x011a}, {28672, 0x013e},
+ {30720, 0x011b}, {32768, 0x013f}, {36864, 0x011c}, {40960, 0x011d},
+ {49152, 0x011e}, {61440, 0x011f}
+};
+
+u32 fsl_i2c_get_sec_cfg(void)
+{
+ struct device_node *node = NULL;
+ u32 __iomem *reg;
+ u32 val = 0;
+
+ node = of_find_node_by_name(NULL, "global-utilities");
+ if (node) {
+ const u32 *prop = of_get_property(node, "reg", NULL);
+ if (prop) {
+ /*
+ * Map and check POR Device Status Register 2
+ * (PORDEVSR2) at 0xE0014
+ */
+ reg = ioremap(get_immrbase() + *prop + 0x14, 0x4);
+ if (!reg)
+ printk(KERN_ERR
+ "Error: couldn't map PORDEVSR2\n");
+ else
+ val = in_be32(reg) & 0x00000080; /* sec-cfg */
+ iounmap(reg);
+ }
+ }
+ if (node)
+ of_node_put(node);
+
+ return val;
+}
+
+int fsl_i2c_get_fdr(struct device_node *node, u32 clock, u32 prescaler)
+{
+ const struct fsl_i2c_8xxx_divider *div = NULL;
+ u32 divider;
+ int i;
+
+ if (!clock)
+ return -EINVAL;
+
+ /* Determine proper divider value */
+ if (of_device_is_compatible(node, "fsl,mpc8544-i2c"))
+ prescaler = fsl_i2c_get_sec_cfg() ? 3 : 2;
+ if (!prescaler)
+ prescaler = 1;
+
+ divider = fsl_get_sys_freq() / clock / prescaler;
+
+ pr_debug("I2C: src_clock=%d clock=%d divider=%d\n",
+ fsl_get_sys_freq(), clock, divider);
+
+ /*
+ * We want to choose an FDR/DFSR that generates an I2C bus speed that
+ * is equal to or lower than the requested speed.
+ */
+ for (i = 0; i < ARRAY_SIZE(fsl_i2c_8xxx_dividers); i++) {
+ div = &fsl_i2c_8xxx_dividers[i];
+ if (div->divider >= divider)
+ break;
+ }
+
+ return div ? (int)div->fdr : -EINVAL;
+}
+EXPORT_SYMBOL(fsl_i2c_get_fdr);
+#endif /* CONFIG_I2C_MPC */
+
#if defined(CONFIG_CPM2) || defined(CONFIG_QUICC_ENGINE) || defined(CONFIG_8xx)
static u32 brgfreq = -1;
Index: linux-2.6/include/linux/fsl_devices.h
===================================================================
--- linux-2.6.orig/include/linux/fsl_devices.h 2009-03-31 21:27:52.000000000 +0200
+++ linux-2.6/include/linux/fsl_devices.h 2009-04-01 11:22:36.677719938 +0200
@@ -60,15 +60,6 @@
#define FSL_GIANFAR_BRD_HAS_PHY_INTR 0x00000001 /* set or use a timer */
#define FSL_GIANFAR_BRD_IS_REDUCED 0x00000002 /* Set if RGMII, RMII */
-struct fsl_i2c_platform_data {
- /* device specific information */
- u32 device_flags;
-};
-
-/* Flags related to I2C device features */
-#define FSL_I2C_DEV_SEPARATE_DFSRR 0x00000001
-#define FSL_I2C_DEV_CLOCK_5200 0x00000002
-
enum fsl_usb2_operating_modes {
FSL_USB2_MPH_HOST,
FSL_USB2_DR_HOST,
Index: linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31 21:27:52.000000000 +0200
+++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-04-01 12:05:33.945719636 +0200
@@ -225,3 +225,60 @@
while (1);
}
+
+/**
+ * fsl_i2c_get_fdr: get calculate and return I2 frequency divider register
+ */
+static const struct mpc52xx_i2c_divider {
+ u16 divider;
+ u16 fdr; /* including dfsrr */
+} mpc52xx_i2c_dividers[] = {
+ {20, 0x20}, {22, 0x21}, {24, 0x22}, {26, 0x23},
+ {28, 0x24}, {30, 0x01}, {32, 0x25}, {34, 0x02},
+ {36, 0x26}, {40, 0x27}, {44, 0x04}, {48, 0x28},
+ {52, 0x63}, {56, 0x29}, {60, 0x41}, {64, 0x2a},
+ {68, 0x07}, {72, 0x2b}, {80, 0x2c}, {88, 0x09},
+ {96, 0x2d}, {104, 0x0a}, {112, 0x2e}, {120, 0x81},
+ {128, 0x2f}, {136, 0x47}, {144, 0x0c}, {160, 0x30},
+ {176, 0x49}, {192, 0x31}, {208, 0x4a}, {224, 0x32},
+ {240, 0x0f}, {256, 0x33}, {272, 0x87}, {288, 0x10},
+ {320, 0x34}, {352, 0x89}, {384, 0x35}, {416, 0x8a},
+ {448, 0x36}, {480, 0x13}, {512, 0x37}, {576, 0x14},
+ {640, 0x38}, {768, 0x39}, {896, 0x3a}, {960, 0x17},
+ {1024, 0x3b}, {1152, 0x18}, {1280, 0x3c}, {1536, 0x3d},
+ {1792, 0x3e}, {1920, 0x1b}, {2048, 0x3f}, {2304, 0x1c},
+ {2560, 0x1d}, {3072, 0x1e}, {3584, 0x7e}, {3840, 0x1f},
+ {4096, 0x7f}, {4608, 0x5c}, {5120, 0x5d}, {6144, 0x5e},
+ {7168, 0xbe}, {7680, 0x5f}, {8192, 0xbf}, {9216, 0x9c},
+ {10240, 0x9d}, {12288, 0x9e}, {15360, 0x9f}
+};
+
+int mpc52xx_i2c_get_fdr(struct device_node *node, u32 clock, int prescaler)
+{
+ const struct mpc52xx_i2c_divider *div = NULL;
+ unsigned int pvr = mfspr(SPRN_PVR);
+ u32 divider;
+ int i;
+
+ if (!clock)
+ return -EINVAL;
+
+ /* Determine divider value */
+ divider = mpc52xx_find_ipb_freq(node) / clock;
+
+ /*
+ * We want to choose an FDR/DFSR that generates an I2C bus speed that
+ * is equal to or lower than the requested speed.
+ */
+ for (i = 0; i < ARRAY_SIZE(mpc52xx_i2c_dividers); i++) {
+ div = &mpc52xx_i2c_dividers[i];
+ /* Old MPC5200 rev A CPUs do not support the high bits */
+ if (div->fdr & 0xc0 && pvr == 0x80822011)
+ continue;
+ if (div->divider >= divider)
+ break;
+ }
+
+ return div ? (int)div->fdr : -EINVAL;
+}
+EXPORT_SYMBOL(mpc52xx_i2c_get_fdr);
Index: linux-2.6/arch/powerpc/include/asm/mpc52xx.h
===================================================================
--- linux-2.6.orig/arch/powerpc/include/asm/mpc52xx.h 2009-03-17 10:28:10.000000000 +0100
+++ linux-2.6/arch/powerpc/include/asm/mpc52xx.h 2009-04-01 12:30:00.389718130 +0200
@@ -287,6 +287,17 @@
static inline void mpc52xx_setup_pci(void) { }
#endif
+#ifdef CONFIG_PPC_MPC52xx
+extern int mpc52xx_i2c_get_fdr(struct device_node *node,
+ u32 clock, int prescaler);
+#else
+static inline int mpc52xx_i2c_get_fdr(struct device_node *node,
+ u32 clock, u32 prescaler)
+{
+ return -EINVAL;
+}
+#endif
+
#endif /* __ASSEMBLY__ */
#ifdef CONFIG_PM
Index: linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt
===================================================================
--- linux-2.6.orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2009-03-31 21:35:51.000000000 +0200
+++ linux-2.6/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2009-04-01 12:27:51.962721274 +0200
@@ -7,8 +7,10 @@
Recommended properties :
- - compatible : Should be "fsl-i2c" for parts compatible with
- Freescale I2C specifications.
+ - compatible : compatibility list with 2 entries, the first should
+ be "fsl,CHIP-i2c" where CHIP is the name of a compatible processor,
+ e.g. mpc8313, mpc8443, mpc8444 or mpc5200b. The second should be
+ "fsl-i2c".
- 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
@@ -16,19 +18,32 @@
controller you have.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- - dfsrr : boolean; if defined, indicates that this I2C device has
- a digital filter sampling rate register
- - fsl5200-clocking : boolean; if defined, indicated that this device
- uses the FSL 5200 clocking mechanism.
- fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
+ - clock-frequency : desired I2C bus clock frequency in Hz.
-Example :
- i2c@3000 {
- interrupt-parent = <40000>;
- interrupts = <1b 3>;
- reg = <3000 18>;
- device_type = "i2c";
- compatible = "fsl-i2c";
- dfsrr;
+Examples :
+
+ i2c@3d00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
+ cell-index = <0>;
+ reg = <0x3d00 0x40>;
+ interrupts = <2 15 0>;
+ interrupt-parent = <&mpc5200_pic>;
+ fsl,preserve-clocking;
+ };
+
+ i2c@3100 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <1>;
+ compatible = "fsl,mpc8544-i2c", "fsl-i2c";
+ reg = <0x3100 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <&mpic>;
+ clock-frequency = <400000>;
};
+
+
Index: linux-2.6/arch/powerpc/sysdev/fsl_soc.h
===================================================================
--- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.h 2009-04-01 14:28:43.000000000 +0200
+++ linux-2.6/arch/powerpc/sysdev/fsl_soc.h 2009-04-01 14:29:10.629721056 +0200
@@ -14,6 +14,18 @@
#endif
extern u32 fsl_get_sys_freq(void);
+
+#ifdef CONFIG_FSL_SOC
+extern int fsl_i2c_get_fdr(struct device_node *node,
+ u32 clock, u32 divider);
+#else
+static inline int fsl_i2c_get_fdr(struct device_node *node,
+ u32 clock, u32 prescaler)
+{
+ return -EINVAL;
+}
+#endif
+
struct spi_board_info;
struct device_node;
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-04-01 13:10 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <fa686aa40904010540h53c8975ao196657f6fdd66583@mail.gmail.com>
Grant Likely wrote:
> On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> Anton Vorontsov wrote:
>>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>>> [...]
>>>>>>>>> + soc8544@e0000000 {
>>>>>>>>> + #address-cells = <1>;
>>>>>>>>> + #size-cells = <1>;
>>>>>>>>> + device_type = "soc";
>>>>>>>> Drop device_type here too.
>>>>>>> Grrr, I just realized that removing the devices type "soc" has broken
>>>>>>> fsl_get_sys_freq(). See:
>>>>>>>
>>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>>>
>>>>>>> We need a quick fix and we could take the occasion to establish a common
>>>>>>> function for the MPC52xx as well, but it's not obvious to me how to find
>>>>>>> the SOC node without the device type property.
>>>>>> SoC node should have a compatible property, just like everything else.
>>>>>>
>>>>>> compatible = "fsl,mpc8544-immr"; (immr == Internally Memory Mapped Registers)
>>>>>>
>>>>>> Many other boards already do this.
>>>>> Yes, it does, but searching for the SOC node is not straight-forward
>>>>> because there is no common compatibility string but many CPU-specific
>>>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I missed
>>>>> something?
>>>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly what it
>>>> means, and add add it to the end of the compatible list.
>>> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
>>> parts. There it's called CCSR.
>>>
>>> See this thread:
>>>
>>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>>>
>>> I still think that
>>> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
>>> and
>>> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>>>
>>> would be OK, at least to start with. We can always deprecate "fsl,soc"
>>> compatible in favour of something more elegant, but "fsl,soc" should be
>>> just fine to replace device_type = "soc".
>>>
>>> Also, there is another good thing about "fsl,soc" -- U-Boot already
>>> finds it for 83xx CPUs. ;-)
>> Ugh! I just realize the full impact of removing device type "soc". It
>> will break compatibility with U-Boot for many boards. Is it worth it?
>
> Yes, I know this. I'm not asking you to fix all the other boards, but
> make sure that it is not required for the new board.
Hm, I'm confused, if we want to fix this issue we need first to
- fix all functions in fsl_soc.c searching for the compatible string
"fsl,soc" instead of the device type "soc" (or both for backward
compatibility).
- fix U-Boot to find the SOC node by looking for "fsl,soc" to insert the
proper bus-frequency, at least.
That affects *all* boards using CONFIG_FSL_SOC and requires an
up-to-date version of U-Boot for new kernels :-(. If that is fixed, I
can remove the "device_type = "soc";" from socrates.dts (and may more),
but not right now. Or have I missed something?
Wolfgang.
^ permalink raw reply
* Re: linux-next: tracing/powerpc tree build failure
From: Stephen Rothwell @ 2009-04-01 13:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: linuxppc-dev, Steven Rostedt, linux-next, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20090401125148.GL12966@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]
Hi Ingo,
[Its midnight, so this is just a quick reply.]
On Wed, 1 Apr 2009 14:51:48 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > This patch is now applicable to the tracing tree after merging
> > with Linus' tree.
>
> Thanks, that's useful info.
>
> There's the skb tracepoints related merge fixlet needed too.
> Anything else in this context you are aware of?
They are the only two build fixes I have at the moment. On top of that
these are the only conflicts I get when merging the tip trees:
Merging tip-core/auto-core-next
CONFLICT (content): Merge conflict in include/linux/netfilter/xt_limit.h
CONFLICT (content): Merge conflict in include/linux/netfilter/xt_statistic.h
CONFLICT (content): Merge conflict in lib/Kconfig.debug
Merging cpus4096/auto-cpus4096-next
CONFLICT (content): Merge conflict in arch/x86/include/asm/topology.h
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/common.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/intel_cacheinfo.c
CONFLICT (content): Merge conflict in drivers/oprofile/buffer_sync.c
Merging tracing/auto-tracing-next
CONFLICT (add/add): Merge conflict in arch/parisc/include/asm/ftrace.h
CONFLICT (content): Merge conflict in include/linux/slub_def.h
CONFLICT (content): Merge conflict in kernel/extable.c
CONFLICT (content): Merge conflict in mm/slob.c
CONFLICT (content): Merge conflict in mm/slub.c
I think these are mostly trivial (except the parisc one you commented on
before). Some are caused by the same commit being in two trees and
further work in one of them. Anything non-tivial will have been reported
previously.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: tracing/powerpc tree build failure
From: Ingo Molnar @ 2009-04-01 12:51 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linuxppc-dev, Steven Rostedt, linux-next, Paul Mackerras,
H. Peter Anvin, Thomas Gleixner
In-Reply-To: <20090331165430.383fe51d.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> This patch is now applicable to the tracing tree after merging
> with Linus' tree.
Thanks, that's useful info.
There's the skb tracepoints related merge fixlet needed too.
Anything else in this context you are aware of?
Ingo
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Grant Likely @ 2009-04-01 12:40 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <49D3197C.7000806@grandegger.com>
On Wed, Apr 1, 2009 at 1:36 AM, Wolfgang Grandegger <wg@grandegger.com> wro=
te:
> Anton Vorontsov wrote:
>> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
>> [...]
>>>>>>>> + =A0 =A0 =A0 soc8544@e0000000 {
>>>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #address-cells =3D <1>;
>>>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 #size-cells =3D <1>;
>>>>>>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 device_type =3D "soc";
>>>>>>> Drop device_type here too.
>>>>>> Grrr, I just realized that removing the devices type "soc" has broke=
n
>>>>>> fsl_get_sys_freq(). See:
>>>>>>
>>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>>
>>>>>> We need a quick fix and we could take the occasion to establish a co=
mmon
>>>>>> function for the MPC52xx as well, but it's not obvious to me how to =
find
>>>>>> the SOC node without the device type property.
>>>>> SoC node should have a compatible property, just like everything else=
.
>>>>>
>>>>> compatible =3D "fsl,mpc8544-immr"; =A0(immr =3D=3D Internally Memory =
Mapped Registers)
>>>>>
>>>>> Many other boards already do this.
>>>> Yes, it does, but searching for the SOC node is not straight-forward
>>>> because there is no common compatibility string but many CPU-specific
>>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I missed
>>>> something?
>>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly what it
>>> means, and add add it to the end of the compatible list.
>>
>> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
>> parts. There it's called CCSR.
>>
>> See this thread:
>>
>> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>>
>> I still think that
>> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
>> and
>> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>>
>> would be OK, at least to start with. We can always deprecate "fsl,soc"
>> compatible in favour of something more elegant, but "fsl,soc" should be
>> just fine to replace device_type =3D "soc".
>>
>> Also, there is another good thing about "fsl,soc" -- U-Boot already
>> finds it for 83xx CPUs. ;-)
>
> Ugh! I just realize the full impact of removing device type "soc". It
> will break compatibility with U-Boot for many boards. Is it worth it?
Yes, I know this. I'm not asking you to fix all the other boards, but
make sure that it is not required for the new board.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: Anton Vorontsov @ 2009-04-01 12:30 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev, devicetree-discuss
In-Reply-To: <20090401110955.GA7507@yookeroo.seuss>
On Wed, Apr 01, 2009 at 10:09:55PM +1100, David Gibson wrote:
> On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
> > Hi David,
> >
> > this patch went out by mistake, sorry.
> >
> > David Gibson wrote:
> > > On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
> > >> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
> > >> ===================================================================
> > >> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
> > >> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
> > >> @@ -52,6 +52,7 @@
> > >> soc8544@e0000000 {
> > >> #address-cells = <1>;
> > >> #size-cells = <1>;
> > >> + device_type = "soc";
> > >
> > > You should not be adding device_type to a new board's dts. You
> > > *especially* shouldn't be doing that with no patch comment explaining
> > > why.
> >
> > In the final patch I have removed the device_type = "soc", but it makes
> > trouble as some mpc85xx rely on it.
>
> Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
> don't see how something that affects "some mpc85xx" is relevant.
Not some, but *all* mpc85xx. The thing is that U-Boot is searching
for device_type = "soc" to fixup some properties (for example,
bus-frequency) for all mpc85xx parts, so you can't easily remove
the device_type w/o breaking boot for firmwares that customers have
pre-programmed in their products.
Note that upgrading firmware without JTAG is dangerous, so it's not
an option to "force" everybody to upgrade their firmware just
because we want to remove some cruft from the device tree.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Arnd Bergmann @ 2009-04-01 12:11 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, Cell Broadband Engine OSS Development
In-Reply-To: <1238583750.17330.125.camel@pasglop>
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
> > No, QPACE does not have any PCI devices whatsoever.
>
> so something like select PPC_OF_PLATFORM_PCI if PCI would work you
> think ?
Yes, that sounds good.
Arnd <><
^ permalink raw reply
* /dev/random on PPC40EXr
From: Felix Radensky @ 2009-04-01 12:00 UTC (permalink / raw)
To: linuxppc-dev
Hi,
On my custom board based on 405EXr /dev/random produces no output
at all, and /dev/urandom is not random enough for our purposes. Saving
entropy pool between reboots doesn't help much.
What can be done to increase the entropy of the system ?
I was thinking of adding IRQF_SAMPLE_RANDOM to network driver,
but since not too many drivers implement it, I don't know whether
it's a good idea or not.
Is there any work in progress to develop hw_random driver for 4xx
TRNG ?
Thanks a lot.
Felix.
--
View this message in context: http://www.nabble.com/-dev-random-on-PPC40EXr-tp22824979p22824979.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: Wolfgang Grandegger @ 2009-04-01 11:59 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev, devicetree-discuss
In-Reply-To: <20090401110955.GA7507@yookeroo.seuss>
David Gibson wrote:
> On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
>> Hi David,
>>
>> this patch went out by mistake, sorry.
>>
>> David Gibson wrote:
>>> On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
>>>> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
>>>> ===================================================================
>>>> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
>>>> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
>>>> @@ -52,6 +52,7 @@
>>>> soc8544@e0000000 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> + device_type = "soc";
>>> You should not be adding device_type to a new board's dts. You
>>> *especially* shouldn't be doing that with no patch comment explaining
>>> why.
>> In the final patch I have removed the device_type = "soc", but it makes
>> trouble as some mpc85xx rely on it.
>
> Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
> don't see how something that affects "some mpc85xx" is relevant.
Well, to be more precise, it affects all boards using CONFIG_FSL_SOC
because they use functions searching for the device type "soc", e.g.
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
This needs to be fixed before the line 'device_type = "soc"' can be removed.
Wolfgang.
^ permalink raw reply
* Re: [ppc64] 2.6.29-git7 : offlining a cpu causes an exception
From: Sachin Sant @ 2009-04-01 11:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <49D30C48.4090902@in.ibm.com>
Sachin Sant wrote:
> Benjamin Herrenschmidt wrote:
>> On Tue, 2009-03-31 at 14:57 +0530, Sachin Sant wrote:
>>
>>> While executing CPU HotPlug[1] tests i observed that during
>>> every cpu offline process an exception is thrown.
>>>
>>
>> Looks like a BUG_ON() to me... can you look at what other
>> messages just before that ?
>
Ben, seems like the following patch is causing the cpu hotplug
test failure.
[PATCH 6/6] powerpc/mm: Introduce early_init_mmu() on 64-bit
http://ozlabs.org/pipermail/linuxppc-dev/2009-March/069613.html
If i back out this patch, i am able to offline/online cpu's
without any issue.
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* RFC ML510 Linux support
From: Roderick Colenbrander @ 2009-04-01 11:35 UTC (permalink / raw)
To: linuxppc-dev; +Cc: John.Linn
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
Hi,
This is a draft version of my patch to add Linux support for the Xilinx ML510. The patch adds support for the board and a pci implementation which allows you to use onboard pci devices (usb, ide, audio) and pci slots (only slot 3 and 5 for now).
This is an intial version of my work. There is some ide hack in which I need to submit to the ide list and I guess that I need to make my pci driver OF aware.
Regards,
Roderick Colenbrander
--
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a
[-- Attachment #2: ml510.patch --]
[-- Type: text/x-diff, Size: 30972 bytes --]
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts
--- linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts 1970-01-01 01:00:00.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/boot/dts/virtex440-ml510.dts 2009-04-01 13:18:50.000000000 +0200
@@ -0,0 +1,452 @@
+/*
+ * Xilinx ML510 Reference Design support
+ * This DTS file was created for the ml510_bsb1_pcores_ppc440 reference design.
+ * The reference design contains two bugs which prevent PCI from working which
+ * should be fixed by the user:
+ * - the MPLB output of the soft-core should be connected to plbv46_plb_1 which
+ * corresponds to SPLB0 of the ppc440 to allow the soft-core to access system
+ * memory
+ * - C_IPIFBAR2PCIBAR_0 of the soft-core should be set to 0x80000000 in order to
+ * reserve 0x80000000-0xffffffff (PCI) for memory mapped i/o and the lower addresses
+ * can be used by PCI devices to access system memory (DMA).
+ *
+ * Copyright 2009, Roderick Colenbrander
+ */
+
+/dts-v1/;
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,ml510-ref-design";
+ dcr-parent = <&ppc440_0>;
+ model = "testing";
+ DDR2_SDRAM_DIMM0: memory@0 {
+ device_type = "memory";
+ reg = < 0x0 0x20000000 >;
+ } ;
+ chosen {
+ bootargs = "console=ttyS0 root=/dev/xsa2 init=/etc/preinit";
+ linux,stdout-path = "/plb@0/serial@83e00000";
+ } ;
+ cpus {
+ #address-cells = <1>;
+ #cpus = <0x1>;
+ #size-cells = <0>;
+ ppc440_0: cpu@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clock-frequency = <300000000>;
+ compatible = "PowerPC,440", "ibm,ppc440";
+ d-cache-line-size = <0x20>;
+ d-cache-size = <0x8000>;
+ dcr-access-method = "native";
+ dcr-controller ;
+ device_type = "cpu";
+ i-cache-line-size = <0x20>;
+ i-cache-size = <0x8000>;
+ model = "PowerPC,440";
+ reg = <0>;
+ timebase-frequency = <300000000>;
+ xlnx,apu-control = <0x2000>;
+ xlnx,apu-udi-0 = <0x0>;
+ xlnx,apu-udi-1 = <0x0>;
+ xlnx,apu-udi-10 = <0x0>;
+ xlnx,apu-udi-11 = <0x0>;
+ xlnx,apu-udi-12 = <0x0>;
+ xlnx,apu-udi-13 = <0x0>;
+ xlnx,apu-udi-14 = <0x0>;
+ xlnx,apu-udi-15 = <0x0>;
+ xlnx,apu-udi-2 = <0x0>;
+ xlnx,apu-udi-3 = <0x0>;
+ xlnx,apu-udi-4 = <0x0>;
+ xlnx,apu-udi-5 = <0x0>;
+ xlnx,apu-udi-6 = <0x0>;
+ xlnx,apu-udi-7 = <0x0>;
+ xlnx,apu-udi-8 = <0x0>;
+ xlnx,apu-udi-9 = <0x0>;
+ xlnx,dcr-autolock-enable = <0x1>;
+ xlnx,dcu-rd-ld-cache-plb-prio = <0x0>;
+ xlnx,dcu-rd-noncache-plb-prio = <0x0>;
+ xlnx,dcu-rd-touch-plb-prio = <0x0>;
+ xlnx,dcu-rd-urgent-plb-prio = <0x0>;
+ xlnx,dcu-wr-flush-plb-prio = <0x0>;
+ xlnx,dcu-wr-store-plb-prio = <0x0>;
+ xlnx,dcu-wr-urgent-plb-prio = <0x0>;
+ xlnx,dma0-control = <0x0>;
+ xlnx,dma0-plb-prio = <0x0>;
+ xlnx,dma0-rxchannelctrl = <0x1010000>;
+ xlnx,dma0-rxirqtimer = <0x3ff>;
+ xlnx,dma0-txchannelctrl = <0x1010000>;
+ xlnx,dma0-txirqtimer = <0x3ff>;
+ xlnx,dma1-control = <0x0>;
+ xlnx,dma1-plb-prio = <0x0>;
+ xlnx,dma1-rxchannelctrl = <0x1010000>;
+ xlnx,dma1-rxirqtimer = <0x3ff>;
+ xlnx,dma1-txchannelctrl = <0x1010000>;
+ xlnx,dma1-txirqtimer = <0x3ff>;
+ xlnx,dma2-control = <0x0>;
+ xlnx,dma2-plb-prio = <0x0>;
+ xlnx,dma2-rxchannelctrl = <0x1010000>;
+ xlnx,dma2-rxirqtimer = <0x3ff>;
+ xlnx,dma2-txchannelctrl = <0x1010000>;
+ xlnx,dma2-txirqtimer = <0x3ff>;
+ xlnx,dma3-control = <0x0>;
+ xlnx,dma3-plb-prio = <0x0>;
+ xlnx,dma3-rxchannelctrl = <0x1010000>;
+ xlnx,dma3-rxirqtimer = <0x3ff>;
+ xlnx,dma3-txchannelctrl = <0x1010000>;
+ xlnx,dma3-txirqtimer = <0x3ff>;
+ xlnx,endian-reset = <0x0>;
+ xlnx,generate-plb-timespecs = <0x1>;
+ xlnx,icu-rd-fetch-plb-prio = <0x0>;
+ xlnx,icu-rd-spec-plb-prio = <0x0>;
+ xlnx,icu-rd-touch-plb-prio = <0x0>;
+ xlnx,interconnect-imask = <0xffffffff>;
+ xlnx,mplb-allow-lock-xfer = <0x1>;
+ xlnx,mplb-arb-mode = <0x0>;
+ xlnx,mplb-awidth = <0x20>;
+ xlnx,mplb-counter = <0x500>;
+ xlnx,mplb-dwidth = <0x80>;
+ xlnx,mplb-max-burst = <0x8>;
+ xlnx,mplb-native-dwidth = <0x80>;
+ xlnx,mplb-p2p = <0x0>;
+ xlnx,mplb-prio-dcur = <0x2>;
+ xlnx,mplb-prio-dcuw = <0x3>;
+ xlnx,mplb-prio-icu = <0x4>;
+ xlnx,mplb-prio-splb0 = <0x1>;
+ xlnx,mplb-prio-splb1 = <0x0>;
+ xlnx,mplb-read-pipe-enable = <0x1>;
+ xlnx,mplb-sync-tattribute = <0x0>;
+ xlnx,mplb-wdog-enable = <0x1>;
+ xlnx,mplb-write-pipe-enable = <0x1>;
+ xlnx,mplb-write-post-enable = <0x1>;
+ xlnx,num-dma = <0x0>;
+ xlnx,pir = <0xf>;
+ xlnx,ppc440mc-addr-base = <0x0>;
+ xlnx,ppc440mc-addr-high = <0x1fffffff>;
+ xlnx,ppc440mc-arb-mode = <0x0>;
+ xlnx,ppc440mc-bank-conflict-mask = <0x1800000>;
+ xlnx,ppc440mc-control = <0xf810008f>;
+ xlnx,ppc440mc-max-burst = <0x8>;
+ xlnx,ppc440mc-prio-dcur = <0x2>;
+ xlnx,ppc440mc-prio-dcuw = <0x3>;
+ xlnx,ppc440mc-prio-icu = <0x4>;
+ xlnx,ppc440mc-prio-splb0 = <0x1>;
+ xlnx,ppc440mc-prio-splb1 = <0x0>;
+ xlnx,ppc440mc-row-conflict-mask = <0x7ffe00>;
+ xlnx,ppcdm-asyncmode = <0x0>;
+ xlnx,ppcds-asyncmode = <0x0>;
+ xlnx,user-reset = <0x0>;
+ } ;
+ } ;
+ plb_v46_0: plb@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,plb-v46-1.03.a", "simple-bus";
+ ranges ;
+ FLASH: flash@fc000000 {
+ bank-width = <2>;
+ compatible = "xlnx,xps-mch-emc-2.00.a", "cfi-flash";
+ reg = < 0xfc000000 0x2000000 >;
+ xlnx,family = "virtex5";
+ xlnx,include-datawidth-matching-0 = <0x1>;
+ xlnx,include-datawidth-matching-1 = <0x0>;
+ xlnx,include-datawidth-matching-2 = <0x0>;
+ xlnx,include-datawidth-matching-3 = <0x0>;
+ xlnx,include-negedge-ioregs = <0x0>;
+ xlnx,include-plb-ipif = <0x1>;
+ xlnx,include-wrbuf = <0x1>;
+ xlnx,max-mem-width = <0x10>;
+ xlnx,mch-native-dwidth = <0x20>;
+ xlnx,mch-plb-clk-period-ps = <0x2710>;
+ xlnx,mch-splb-awidth = <0x20>;
+ xlnx,mch0-accessbuf-depth = <0x10>;
+ xlnx,mch0-protocol = <0x0>;
+ xlnx,mch0-rddatabuf-depth = <0x10>;
+ xlnx,mch1-accessbuf-depth = <0x10>;
+ xlnx,mch1-protocol = <0x0>;
+ xlnx,mch1-rddatabuf-depth = <0x10>;
+ xlnx,mch2-accessbuf-depth = <0x10>;
+ xlnx,mch2-protocol = <0x0>;
+ xlnx,mch2-rddatabuf-depth = <0x10>;
+ xlnx,mch3-accessbuf-depth = <0x10>;
+ xlnx,mch3-protocol = <0x0>;
+ xlnx,mch3-rddatabuf-depth = <0x10>;
+ xlnx,mem0-width = <0x10>;
+ xlnx,mem1-width = <0x20>;
+ xlnx,mem2-width = <0x20>;
+ xlnx,mem3-width = <0x20>;
+ xlnx,num-banks-mem = <0x1>;
+ xlnx,num-channels = <0x2>;
+ xlnx,priority-mode = <0x0>;
+ xlnx,synch-mem-0 = <0x0>;
+ xlnx,synch-mem-1 = <0x0>;
+ xlnx,synch-mem-2 = <0x0>;
+ xlnx,synch-mem-3 = <0x0>;
+ xlnx,synch-pipedelay-0 = <0x2>;
+ xlnx,synch-pipedelay-1 = <0x2>;
+ xlnx,synch-pipedelay-2 = <0x2>;
+ xlnx,synch-pipedelay-3 = <0x2>;
+ xlnx,tavdv-ps-mem-0 = <0x1adb0>;
+ xlnx,tavdv-ps-mem-1 = <0x3a98>;
+ xlnx,tavdv-ps-mem-2 = <0x3a98>;
+ xlnx,tavdv-ps-mem-3 = <0x3a98>;
+ xlnx,tcedv-ps-mem-0 = <0x1adb0>;
+ xlnx,tcedv-ps-mem-1 = <0x3a98>;
+ xlnx,tcedv-ps-mem-2 = <0x3a98>;
+ xlnx,tcedv-ps-mem-3 = <0x3a98>;
+ xlnx,thzce-ps-mem-0 = <0x88b8>;
+ xlnx,thzce-ps-mem-1 = <0x1b58>;
+ xlnx,thzce-ps-mem-2 = <0x1b58>;
+ xlnx,thzce-ps-mem-3 = <0x1b58>;
+ xlnx,thzoe-ps-mem-0 = <0x1b58>;
+ xlnx,thzoe-ps-mem-1 = <0x1b58>;
+ xlnx,thzoe-ps-mem-2 = <0x1b58>;
+ xlnx,thzoe-ps-mem-3 = <0x1b58>;
+ xlnx,tlzwe-ps-mem-0 = <0x88b8>;
+ xlnx,tlzwe-ps-mem-1 = <0x0>;
+ xlnx,tlzwe-ps-mem-2 = <0x0>;
+ xlnx,tlzwe-ps-mem-3 = <0x0>;
+ xlnx,twc-ps-mem-0 = <0x1adb0>;
+ xlnx,twc-ps-mem-1 = <0x3a98>;
+ xlnx,twc-ps-mem-2 = <0x3a98>;
+ xlnx,twc-ps-mem-3 = <0x3a98>;
+ xlnx,twp-ps-mem-0 = <0x11170>;
+ xlnx,twp-ps-mem-1 = <0x2ee0>;
+ xlnx,twp-ps-mem-2 = <0x2ee0>;
+ xlnx,twp-ps-mem-3 = <0x2ee0>;
+ xlnx,xcl0-linesize = <0x4>;
+ xlnx,xcl0-writexfer = <0x1>;
+ xlnx,xcl1-linesize = <0x4>;
+ xlnx,xcl1-writexfer = <0x1>;
+ xlnx,xcl2-linesize = <0x4>;
+ xlnx,xcl2-writexfer = <0x1>;
+ xlnx,xcl3-linesize = <0x4>;
+ xlnx,xcl3-writexfer = <0x1>;
+ } ;
+ Hard_Ethernet_MAC: xps-ll-temac@81c00000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,compound";
+ ethernet@81c00000 {
+ compatible = "xlnx,xps-ll-temac-1.01.b";
+ device_type = "network";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 8 2 >;
+ llink-connected = <&Hard_Ethernet_MAC_fifo>;
+ local-mac-address = [ 02 00 00 00 00 00 ];
+ reg = < 0x81c00000 0x40 >;
+ xlnx,bus2core-clk-ratio = <0x1>;
+ xlnx,phy-type = <0x3>;
+ xlnx,phyaddr = <0x1>;
+ xlnx,rxcsum = <0x0>;
+ xlnx,rxfifo = <0x8000>;
+ xlnx,temac-type = <0x0>;
+ xlnx,txcsum = <0x0>;
+ xlnx,txfifo = <0x8000>;
+ } ;
+ } ;
+ Hard_Ethernet_MAC_fifo: xps-ll-fifo@81a00000 {
+ compatible = "xlnx,xps-ll-fifo-1.01.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 6 2 >;
+ reg = < 0x81a00000 0x10000 >;
+ xlnx,family = "virtex5";
+ } ;
+ IIC_EEPROM: i2c@81600000 {
+ compatible = "xlnx,xps-iic-2.00.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 9 2 >;
+ reg = < 0x81600000 0x10000 >;
+ xlnx,clk-freq = <0x5f5e100>;
+ xlnx,family = "virtex5";
+ xlnx,gpo-width = <0x1>;
+ xlnx,iic-freq = <0x186a0>;
+ xlnx,scl-inertial-delay = <0x5>;
+ xlnx,sda-inertial-delay = <0x5>;
+ xlnx,ten-bit-adr = <0x0>;
+ } ;
+ LCD_OPTIONAL: gpio@81420000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = < 0x81420000 0x10000 >;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,family = "virtex5";
+ xlnx,gpio-width = <0xb>;
+ xlnx,interrupt-present = <0x0>;
+ xlnx,is-bidir = <0x1>;
+ xlnx,is-bidir-2 = <0x1>;
+ xlnx,is-dual = <0x0>;
+ xlnx,tri-default = <0xffffffff>;
+ xlnx,tri-default-2 = <0xffffffff>;
+ } ;
+ LEDs_4Bit: gpio@81400000 {
+ compatible = "xlnx,xps-gpio-1.00.a";
+ reg = < 0x81400000 0x10000 >;
+ xlnx,all-inputs = <0x0>;
+ xlnx,all-inputs-2 = <0x0>;
+ xlnx,dout-default = <0x0>;
+ xlnx,dout-default-2 = <0x0>;
+ xlnx,family = "virtex5";
+ xlnx,gpio-width = <0x4>;
+ xlnx,interrupt-present = <0x0>;
+ xlnx,is-bidir = <0x1>;
+ xlnx,is-bidir-2 = <0x1>;
+ xlnx,is-dual = <0x0>;
+ xlnx,tri-default = <0xffffffff>;
+ xlnx,tri-default-2 = <0xffffffff>;
+ } ;
+ RS232_Uart_1: serial@83e00000 {
+ clock-frequency = <100000000>;
+ compatible = "xlnx,xps-uart16550-2.00.b", "ns16550";
+ current-speed = <9600>;
+ device_type = "serial";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 11 2 >;
+ reg = < 0x83e00000 0x10000 >;
+ reg-offset = <0x1003>;
+ reg-shift = <2>;
+ xlnx,family = "virtex5";
+ xlnx,has-external-rclk = <0x0>;
+ xlnx,has-external-xin = <0x0>;
+ xlnx,is-a-16550 = <0x1>;
+ } ;
+ SPI_EEPROM: xps-spi@feff8000 {
+ compatible = "xlnx,xps-spi-2.00.b";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 10 2 >;
+ reg = < 0xfeff8000 0x80 >;
+ xlnx,family = "virtex5";
+ xlnx,fifo-exist = <0x1>;
+ xlnx,num-ss-bits = <0x1>;
+ xlnx,num-transfer-bits = <0x8>;
+ xlnx,sck-ratio = <0x80>;
+ } ;
+ SysACE_CompactFlash: sysace@83600000 {
+ compatible = "xlnx,xps-sysace-1.00.a";
+ interrupt-parent = <&xps_intc_0>;
+ interrupts = < 7 2 >;
+ reg = < 0x83600000 0x10000 >;
+ xlnx,family = "virtex5";
+ xlnx,mem-width = <0x10>;
+ } ;
+ dcr_v29_0: dcr@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "xlnx,dcr-v29-1.00.a", "simple-bus";
+ ranges = < 0x0 0x44a00000 0x1000 >;
+ } ;
+ plbv46_dcr_bridge_0: plbv46-dcr-bridge@44a00000 {
+ compatible = "xlnx,plbv46-dcr-bridge-1.00.a";
+ dcr-access-method = "mmio";
+ dcr-controller ;
+ dcr-mmio-range = < 0x44a00000 0x1000 >;
+ dcr-mmio-stride = <4>;
+ reg = < 0x44a00000 0x1000 >;
+ xlnx,family = "virtex5";
+ } ;
+ plbv46_dvi_cntlr_0: plbv46-dvi-cntlr@c9800000 {
+ compatible = "xlnx,plbv46-dvi-cntlr-1.00.a";
+ dcr-parent = <&plbv46_dcr_bridge_0>;
+ dcr-reg = < 0x100 0x4 >;
+ reg = < 0xc9800000 0x10000 >;
+ xlnx,default-tft-base-addr = <0x0>;
+ xlnx,dps-init = <0x1>;
+ xlnx,family = "virtex5";
+ xlnx,mplb-awidth = <0x20>;
+ xlnx,mplb-clk-period-ps = <0x2710>;
+ xlnx,mplb-dwidth = <0x80>;
+ xlnx,mplb-native-dwidth = <0x40>;
+ xlnx,mplb-p2p = <0x1>;
+ xlnx,mplb-smallest-slave = <0x80>;
+ xlnx,on-init = <0x1>;
+ } ;
+ plbv46_pci_0: plbv46-pci@85e00000 {
+ #size-cells = <2>;
+ #address-cells = <3>;
+ compatible = "xlnx,plbv46-pci-1.03.a";
+ device_type = "pci";
+ reg = < 0x85e00000 0x10000 >; /* addr is at +0x10c, data at +0x110 */
+
+ /* The PCI bus is implemented by a soft-core which is connected to the PLB bus which is seen by the CPU at 0xa0000000.
+ * Both the PLB and PCI have their own address domain. The PCI soft-core performs this translation. The Xilinx plbpci doc
+ * mentions 'the number of high-order bits substituted in the PLB address presented to the bridge is given by the number
+ * of bits that are the SAME between C_IPIFBAR_N and C_IPIF_HIGHADDR_N.'
+ *
+ * For the default ml510_bsb1_pcores_ppc440 reference design this means:
+ * C_IPIFBAR_0 = 0xa0000000
+ * C_IPIF_HIGHADDR_0 = 0xbfffffff <- only the last 3 bits of (0xa=1010b, 0xb=1011b) are similar
+ * C_IPIFBAR2PCIBAR_0 = 0x00000000
+ *
+ * C_IPIFBAR_1 = 0x94000000
+ * C_IPIF_HIGHADDR_1 = 0x97ffffff <- only the last 6 bits are similar
+ * C_IPIFBAR2PCIBAR_1 = 0x00000000
+ *
+ * This means that a CPU write to 0xa0001234 translates to 0x00001234 on the PCI bus and that
+ * the pcibar_0 base and pcibar_1 base are zero. In order to prevent collision between inbound
+ * and outbound memory reads/writes C_IPIFBAR2PCIBAR_0 needs to be set to 0x80000000.
+ */
+ ranges = <0x02000000 0x00000000 0x80000000 0xa0000000 0x00000000 0x20000000
+ 0x01000000 0x00000000 0x00000000 0x94000000 0x00000000 0x00010000>;
+
+ #interrupt-cells = <1>;
+ interrupt-parent = <&xps_intc_0>;
+ interrupt-map-mask = <0xff00 0x0 0x0 0x7>;
+ interrupt-map = <
+ /* IDSEL 0x15 / dev=5, bus=0 / PCI slot 5 */
+ /* pci irq a is connected to xintc irq 5, b to 4, c to 3 and d to 2 */
+ /* According to the datasheet + schematic ABCD [FPGA] of slot 5 is mapped to DABC, testing showed that at least A maps to B */
+ 0x2800 0 0 1 &xps_intc_0 4 2
+// 0x2800 0 0 2 &xps_intc_0 5 2
+// 0x2800 0 0 3 &xps_intc_0 4 2
+// 0x2800 0 0 4 &xps_intc_0 3 2
+
+ /* IDSEL 0x16 / dev=6, bus=0 / PCI slot 3 */
+ 0x3000 0 0 1 &xps_intc_0 3 2
+ 0x3000 0 0 2 &xps_intc_0 2 2
+ 0x3000 0 0 3 &xps_intc_0 5 2
+ 0x3000 0 0 4 &xps_intc_0 4 2
+
+ /* IDSEL 0x11 / dev=1, bus=0 / AC97 audio */
+ 0x0800 0 0 1 &i8259 7 2
+
+ /* IDSEL 0x1b / dev=11, bus=0 / IDE */
+ 0x5800 0 0 1 &i8259 14 2
+
+ /* IDSEL 0x1f / dev 15, bus=0 / USB */
+ 0x7800 0 0 1 &i8259 7 2
+ >;
+ ali_m1533 {
+ #size-cells = <1>;
+ #address-cells = <2>;
+ i8259: interrupt-controller@20 {
+ reg = <1 0x20 2
+ 1 0xa0 2
+ 1 0x4d0 2>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ compatible = "chrp,iic";
+
+ interrupts = <1 2>;
+ interrupt-parent = <&xps_intc_0>;
+ };
+ };
+ } ;
+ xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffff0000 {
+ compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
+ reg = < 0xffff0000 0x10000 >;
+ xlnx,family = "virtex5";
+ } ;
+ xps_intc_0: interrupt-controller@81800000 {
+ #interrupt-cells = <0x2>;
+ compatible = "xlnx,xps-intc-1.00.a";
+ interrupt-controller ;
+ reg = < 0x81800000 0x10000 >;
+ xlnx,num-intr-inputs = <0xc>;
+ } ;
+ } ;
+} ;
Binary files linux-2.6.29/arch/powerpc/boot/simpleImage.virtex440-ml510 and ml510-dev/linux-2.6.29/arch/powerpc/boot/simpleImage.virtex440-ml510 differ
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig ml510-dev/linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig
--- linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/configs/44x/virtex5_defconfig 2009-04-01 13:20:29.000000000 +0200
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
-# Linux kernel version: 2.6.29-rc2
-# Tue Jan 20 08:22:49 2009
+# Linux kernel version: 2.6.29
+# Wed Apr 1 13:20:29 2009
#
# CONFIG_PPC64 is not set
@@ -75,6 +75,15 @@
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
+
+#
+# RCU Subsystem
+#
+CONFIG_CLASSIC_RCU=y
+# CONFIG_TREE_RCU is not set
+# CONFIG_PREEMPT_RCU is not set
+# CONFIG_TREE_RCU_TRACE is not set
+# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=14
@@ -88,10 +97,12 @@
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
+CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
@@ -101,10 +112,8 @@
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
-CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
-CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
@@ -113,6 +122,7 @@
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
+CONFIG_COMPAT_BRK=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
@@ -152,13 +162,9 @@
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
-CONFIG_CLASSIC_RCU=y
-# CONFIG_TREE_RCU is not set
-# CONFIG_PREEMPT_RCU is not set
-# CONFIG_TREE_RCU_TRACE is not set
-# CONFIG_PREEMPT_RCU_TRACE is not set
# CONFIG_FREEZER is not set
# CONFIG_PPC4xx_PCI_EXPRESS is not set
+CONFIG_XILINX_VIRTEX_PCI=y
#
# Platform support
@@ -179,6 +185,7 @@
# CONFIG_GLACIER is not set
# CONFIG_YOSEMITE is not set
CONFIG_XILINX_VIRTEX440_GENERIC_BOARD=y
+CONFIG_XILINX_ML510=y
# CONFIG_PPC44x_SIMPLE is not set
# CONFIG_PPC4xx_GPIO is not set
CONFIG_XILINX_VIRTEX=y
@@ -186,7 +193,7 @@
# CONFIG_IPIC is not set
# CONFIG_MPIC is not set
# CONFIG_MPIC_WEIRD is not set
-# CONFIG_PPC_I8259 is not set
+CONFIG_PPC_I8259=y
# CONFIG_PPC_RTAS is not set
# CONFIG_MMIO_NVRAM is not set
# CONFIG_PPC_MPC106 is not set
@@ -290,7 +297,6 @@
#
# Networking options
#
-# CONFIG_NET_NS is not set
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
@@ -499,12 +505,16 @@
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_PHANTOM is not set
-# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_C2PORT is not set
+
+#
+# EEPROM support
+#
+# CONFIG_EEPROM_93CX6 is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
@@ -545,6 +555,7 @@
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
+# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC is not set
@@ -578,6 +589,7 @@
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
+# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
@@ -637,7 +649,6 @@
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
-CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/platforms/44x/Kconfig ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.29/arch/powerpc/platforms/44x/Kconfig 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Kconfig 2009-03-27 15:50:28.000000000 +0100
@@ -160,6 +160,16 @@
Most Virtex 5 designs should use this unless it needs to do some
special configuration at board probe time.
+config XILINX_ML510
+ bool "Xilinx ML510 Reference Design support"
+ depends on 44x
+ default n
+ select XILINX_VIRTEX_5_FXT
+ select PPC_PCI_CHOICE
+ select XILINX_VIRTEX_PCI if PCI
+ select PPC_INDIRECT_PCI if PCI
+ select PPC_I8259 if PCI
+
config PPC44x_SIMPLE
bool "Simple PowerPC 44x board support"
depends on 44x
@@ -232,4 +242,3 @@
config XILINX_VIRTEX_5_FXT
bool
select XILINX_VIRTEX
-
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/platforms/44x/Makefile ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Makefile
--- linux-2.6.29/arch/powerpc/platforms/44x/Makefile 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/Makefile 2009-04-01 11:59:28.000000000 +0200
@@ -4,3 +4,4 @@
obj-$(CONFIG_SAM440EP) += sam440ep.o
obj-$(CONFIG_WARP) += warp.o
obj-$(CONFIG_XILINX_VIRTEX_5_FXT) += virtex.o
+obj-$(CONFIG_XILINX_ML510) += ml510.o
\ No newline at end of file
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/platforms/44x/ml510.c ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/ml510.c
--- linux-2.6.29/arch/powerpc/platforms/44x/ml510.c 1970-01-01 01:00:00.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/platforms/44x/ml510.c 2009-04-01 12:42:28.000000000 +0200
@@ -0,0 +1,161 @@
+/*
+ * Xilinx ML510 Reference Design support, derived from
+ * the generic Xilinx Virtex 5 board support
+ *
+ * Copyright 2007 Secret Lab Technologies Ltd.
+ * Copyright 2008 Xilinx, Inc.
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The i8259 cascade code was derived from 86xx/pic.c which is copyrighted by Freescale Semiconductor, Inc.
+ * Xilinx ML510 PCI initialization code, derived from the Xilinx ML300/ML410 based board support.
+ *
+ * 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.
+ */
+
+#include <linux/init.h>
+#include <linux/of_platform.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/time.h>
+#include <asm/xilinx_intc.h>
+#include <asm/reg.h>
+#include <asm/ppc4xx.h>
+#ifdef CONFIG_PPC_I8259
+#include <asm/i8259.h>
+#endif
+#ifdef CONFIG_PCI
+#include <linux/pci.h>
+#endif
+#include "44x.h"
+
+static struct of_device_id xilinx_of_bus_ids[] __initdata = {
+ { .compatible = "simple-bus", },
+ { .compatible = "xlnx,plb-v46-1.00.a", },
+ { .compatible = "xlnx,plb-v46-1.02.a", },
+ { .compatible = "xlnx,plb-v34-1.01.a", },
+ { .compatible = "xlnx,plb-v34-1.02.a", },
+ { .compatible = "xlnx,opb-v20-1.10.c", },
+ { .compatible = "xlnx,dcr-v29-1.00.a", },
+ { .compatible = "xlnx,compound", },
+ {}
+};
+
+#ifdef CONFIG_PPC_I8259
+static void ml510_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ unsigned int cascade_irq = i8259_irq();
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ /* Let xilinx_intc end the interrupt */
+ desc->chip->ack(irq);
+ desc->chip->unmask(irq);
+}
+
+static void __init ml510_setup_i8259_cascade(void)
+{
+ struct device_node *np, *cascade_node = NULL;
+ int cascade_irq;
+
+ /* Initialize i8259 controller */
+ for_each_node_by_type(np, "interrupt-controller")
+ if (of_device_is_compatible(np, "chrp,iic")) {
+ cascade_node = np;
+ break;
+ }
+
+ if (cascade_node == NULL) {
+ printk(KERN_DEBUG "Could not find i8259 PIC\n");
+ return;
+ }
+
+ cascade_irq = irq_of_parse_and_map(cascade_node, 0);
+ if (cascade_irq == NO_IRQ) {
+ printk(KERN_ERR "Failed to map cascade interrupt\n");
+ return;
+ }
+
+ i8259_init(cascade_node, 0);
+
+ of_node_put(cascade_node);
+ set_irq_chained_handler(cascade_irq, ml510_8259_cascade);
+}
+#endif /* CONFIG_PPC_I8259 */
+
+#ifdef CONFIG_PCI
+static void __devinit ali_quirk(struct pci_dev *dev)
+{
+ /* Enable the IDE controller */
+ pci_write_config_byte(dev, 0x58, 0x4c);
+ /* Assign irq 14 to the primary ide channel */
+ pci_write_config_byte(dev, 0x44, 0x0d);
+ /* Assign irq 15 to the secondary ide channel */
+ pci_write_config_byte(dev, 0x75, 0x0f);
+ /* Set the ide controller in native mode */
+ pci_write_config_byte(dev, 0x09, 0xff);
+
+ pci_write_config_byte(dev, 0x48, 0x00); // INTB = disabled, INTA = disabled
+ pci_write_config_byte(dev, 0x4a, 0x00); // INTD = disabled, INTC = disabled
+ pci_write_config_byte(dev, 0x4b, 0x00); // Audio = INT7, Modem = disabled.
+ pci_write_config_byte(dev, 0x74, 0x06); // USB = INT7
+}
+DECLARE_PCI_FIXUP_EARLY(0x10b9, 0x1533, ali_quirk);
+#endif /* CONFIG_PCI */
+
+static int __init ml510_device_probe(void)
+{
+ of_platform_bus_probe(NULL, xilinx_of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(ml510, ml510_device_probe);
+
+static int __init ml510_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if (!of_flat_dt_is_compatible(root, "xlnx,ml510-ref-design"))
+ return 0;
+
+ return 1;
+}
+
+void virtex_pci_init(void);
+static void __init ml510_setup_arch(void)
+{
+ struct device_node *pci_node = of_find_compatible_node(NULL, NULL, "xlnx,plbv46-pci-1.03.a");
+
+#ifdef CONFIG_PCI
+ if(pci_node)
+ {
+//Is this the right way or should this be done using OF?
+ /* Register the host bridge */
+ virtex_pci_init();
+ }
+#endif /* CONFIG_PCI */
+}
+
+static void ml510_init_IRQ(void)
+{
+ xilinx_intc_init_tree();
+
+#ifdef CONFIG_PPC_I8259
+ /* The devices on the ALI M1553 south bridge are connected to an internal i8259 */
+ ml510_setup_i8259_cascade();
+ /* Program irq 7 (usb/audio), 14/15 (ide) to level sensitive */
+ outb(0xc0, 0x4d0);
+ outb(0xc0, 0x4d1);
+#endif /* CONFIG_PPC_I8259 */
+}
+
+define_machine(ml510) {
+ .name = "Xilinx ML510 Reference Design support",
+ .probe = ml510_probe,
+ .setup_arch = ml510_setup_arch,
+ .init_IRQ = ml510_init_IRQ,
+ .get_irq = xilinx_intc_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+ .restart = ppc4xx_reset_system,
+};
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/sysdev/Kconfig ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Kconfig
--- linux-2.6.29/arch/powerpc/sysdev/Kconfig 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Kconfig 2009-03-27 12:50:29.000000000 +0100
@@ -12,3 +12,7 @@
depends on PCI_MSI
default y if MPIC
default y if FSL_PCI
+
+config XILINX_VIRTEX_PCI
+ bool
+ depends on PCI
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/sysdev/Makefile ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Makefile
--- linux-2.6.29/arch/powerpc/sysdev/Makefile 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/Makefile 2009-03-27 11:57:45.000000000 +0100
@@ -34,6 +34,7 @@
obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX) += xilinx_intc.o
+obj-$(CONFIG_XILINX_VIRTEX_PCI) += virtex_pci.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c ml510-dev/linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c
--- linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c 1970-01-01 01:00:00.000000000 +0100
+++ ml510-dev/linux-2.6.29/arch/powerpc/sysdev/virtex_pci.c 2009-04-01 12:54:42.000000000 +0200
@@ -0,0 +1,95 @@
+/*
+ * PCI support for Xilinx plbv46_pci soft-core which can be used on Xilinx Virtex ML410 / ML510 boards.
+ *
+ * Copyright 2009 Roderick Colenbrander
+ *
+ * The pci bridge fixup code was copied from ppc4xx_pci.c and was written by Benjamin Herrenschmidt.
+ * Copyright 2007 Ben. Herrenschmidt <benh@kernel.crashing.org>, IBM Corp.
+ *
+ * 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.
+ */
+
+#include <linux/pci.h>
+#include <mm/mmu_decl.h>
+#include <asm/io.h>
+
+#define XPLB_PCI_ADDR 0x10c
+#define XPLB_PCI_DATA 0x110
+#define XPLB_PCI_BUS 0x114
+
+#define PCI_HOST_ENABLE_CMD PCI_COMMAND_SERR | PCI_COMMAND_PARITY | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
+
+static void fixup_virtex_pci_bridge(struct pci_dev *dev)
+{
+ struct pci_controller *hose;
+ int i;
+
+ if (dev->devfn != 0 || dev->bus->self != NULL)
+ return;
+
+ hose = pci_bus_to_host(dev->bus);
+ if (hose == NULL)
+ return;
+
+ if(!of_device_is_compatible(hose->dn, "xlnx,plbv46-pci-1.03.a"))
+ return;
+
+ /* Hide the PCI host BARs from the kernel as their content doesn't
+ * fit well in the resource management
+ */
+ for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
+ dev->resource[i].start = dev->resource[i].end = 0;
+ dev->resource[i].flags = 0;
+ }
+
+ printk(KERN_INFO "PCI: Hiding Xilinx plb-pci host bridge resources %s\n",
+ pci_name(dev));
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, fixup_virtex_pci_bridge);
+
+void virtex_pci_init(void)
+{
+ struct device_node *pci_node = of_find_compatible_node(NULL, NULL, "xlnx,plbv46-pci-1.03.a");
+
+ if(pci_node)
+ {
+ struct pci_controller *hose;
+ struct resource r;
+ void __iomem *pci_reg;
+
+ printk("Found a Xilinx plb-pci host bridge\n");
+
+ if(of_address_to_resource(pci_node, 0, &r))
+ {
+ printk("No address for Xilinx plb-pci host bridge\n");
+ return;
+ }
+
+ hose = pcibios_alloc_controller(pci_node);
+ if (!hose)
+ return;
+
+ hose->first_busno = 0;
+ hose->last_busno = 1; /* there are two slots behind a TI2250 pci-to-pci bridge */
+
+ /* Setup config space */
+ setup_indirect_pci(hose, r.start + XPLB_PCI_ADDR, r.start + XPLB_PCI_DATA, 0);
+
+ /* According to the xilinx plbv46_pci documentation the soft-core starts a self-init when the bus master enable bit is set.
+ * Without this bit set the pci bus can't be scanned. */
+ early_write_config_word(hose, 0, 0, PCI_COMMAND, PCI_HOST_ENABLE_CMD);
+
+ /* Set the max latency timer to 255 */
+ early_write_config_byte(hose, 0, 0, PCI_LATENCY_TIMER, 0xff);
+
+ /* Set the max bus number to 255 */
+ pci_reg = of_iomap(pci_node, 0);
+ out_8(pci_reg + XPLB_PCI_BUS, 0xff);
+ iounmap(pci_reg);
+
+ /* Register the host bridge with the linux kernel! */
+ pci_process_bridge_OF_ranges(hose, pci_node, 1 /* primary=yes */);
+ }
+}
diff -urN -X linux-2.6.29/Documentation/dontdiff linux-2.6.29/drivers/ide/alim15x3.c ml510-dev/linux-2.6.29/drivers/ide/alim15x3.c
--- linux-2.6.29/drivers/ide/alim15x3.c 2009-03-24 00:12:14.000000000 +0100
+++ ml510-dev/linux-2.6.29/drivers/ide/alim15x3.c 2009-03-27 14:47:50.000000000 +0100
@@ -401,7 +401,8 @@
return cbl;
}
-#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
+#if !defined(CONFIG_SPARC64)
+// && !defined(CONFIG_PPC)
/**
* init_hwif_ali15x3 - Initialize the ALI IDE x86 stuff
* @hwif: interface to configure
^ permalink raw reply
* Re: Problem with module_init?
From: Josh Boyer @ 2009-04-01 11:27 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20090331231153.256d1bf4@lappy.seanm.ca>
On Tue, Mar 31, 2009 at 11:11:53PM -0400, Sean MacLennan wrote:
>8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5 is first bad commit
>commit 8d1cf34e7ad5c7738ce20d20bd7f002f562cb8b5
>Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>Date: Thu Mar 19 19:34:08 2009 +0000
>
> powerpc/mm: Tweak PTE bit combination definitions
>
> This patch tweaks the way some PTE bit combinations are defined, in
> such a way that the 32 and 64-bit variant become almost identical
> and that will make it easier to bring in a new common pte-* file
> for the new variant of the Book3-E support.
>
> The combination of bits defining access to kernel pages are now
> clearly separated from the combination used by userspace and the
> core VM. The resulting generated code should remain identical
> unless I made a mistake.
> Note: While at it, I removed a non-sensical statement related to
> CONFIG_KGDB in ppc_mmu_32.c which could cause kernel mappings to be
> user accessible when that option is enabled. Probably something
> that bitrot.
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>:040000 040000 c105fb9641b078f1a8a60c2a7900ca2dd088b364
>e90678246962d7a455aa27ba12814c11cd9b3c22 M arch
I'm assuming this is the result of a git-bisect run?
Can I also assume you were loading the module on your Warp board?
Ben, have you tested module loads on 4xx since you redid this?
josh
^ permalink raw reply
* Re: [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
From: David Gibson @ 2009-04-01 11:09 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <49D31856.9060808@grandegger.com>
On Wed, Apr 01, 2009 at 09:31:34AM +0200, Wolfgang Grandegger wrote:
> Hi David,
>
> this patch went out by mistake, sorry.
>
> David Gibson wrote:
> > On Tue, Mar 31, 2009 at 02:37:33PM +0200, Wolfgang Grandegger wrote:
> >> Index: linux-2.6/arch/powerpc/boot/dts/socrates.dts
> >> ===================================================================
> >> --- linux-2.6.orig/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:24:38.078719288 +0200
> >> +++ linux-2.6/arch/powerpc/boot/dts/socrates.dts 2009-03-31 13:47:56.986720719 +0200
> >> @@ -52,6 +52,7 @@
> >> soc8544@e0000000 {
> >> #address-cells = <1>;
> >> #size-cells = <1>;
> >> + device_type = "soc";
> >
> > You should not be adding device_type to a new board's dts. You
> > *especially* shouldn't be doing that with no patch comment explaining
> > why.
>
> In the final patch I have removed the device_type = "soc", but it makes
> trouble as some mpc85xx rely on it.
Um.. what? Some mpc85xx? This is the dts for *one specific board*, I
don't see how something that affects "some mpc85xx" is relevant.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Benjamin Herrenschmidt @ 2009-04-01 11:02 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, linuxppc-dev,
Cell Broadband Engine OSS Development
In-Reply-To: <200904011245.01483.arnd@arndb.de>
On Wed, 2009-04-01 at 12:45 +0200, Arnd Bergmann wrote:
> On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> > > PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
> > > causing build failures if PCI is not set.
> >
> > Maybe it should only select it if PCI is enabled ? Is qpace using PCI ?
>
> No, QPACE does not have any PCI devices whatsoever.
so something like select PPC_OF_PLATFORM_PCI if PCI would work you
think ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Arnd Bergmann @ 2009-04-01 10:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Geert Uytterhoeven, Cell Broadband Engine OSS Development
In-Reply-To: <1238579652.17330.124.camel@pasglop>
On Wednesday 01 April 2009, Benjamin Herrenschmidt wrote:
> On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> > PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
> > causing build failures if PCI is not set.
>
> Maybe it should only select it if PCI is enabled ? Is qpace using PCI ?
No, QPACE does not have any PCI devices whatsoever.
Arnd <><
^ permalink raw reply
* [Patch next] powerpc: pseries/dtl.c should include asm/firmware.h
From: Sachin Sant @ 2009-04-01 10:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, linux-next, jk
In-Reply-To: <20090401164450.f8192631.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 558 bytes --]
randconfig build on powerpc failed with :
arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’:
arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of function ‘firmware_has_feature’
arch/powerpc/platforms/pseries/dtl.c:238: error: ‘FW_FEATURE_SPLPAR’ undeclared (first use in this function)
arch/powerpc/platforms/pseries/dtl.c:238: error: (Each undeclared identifier is reported only once
arch/powerpc/platforms/pseries/dtl.c:238: error: for each function it appears in.)
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fix-dtl-build-break.patch --]
[-- Type: text/x-patch; name="fix-dtl-build-break.patch", Size: 1005 bytes --]
* Fixes the following build error
*
* arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’:
* arch/powerpc/platforms/pseries/dtl.c:238:
* error: implicit declaration of function ‘firmware_has_feature’
* arch/powerpc/platforms/pseries/dtl.c:238:
* error: ‘FW_FEATURE_SPLPAR’ undeclared (first use in this function)
* arch/powerpc/platforms/pseries/dtl.c:238:
* error: (Each undeclared identifier is reported only once
* arch/powerpc/platforms/pseries/dtl.c:238:
* error: for each function it appears in.)
Signed-off-by : Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/arch/powerpc/platforms/pseries/dtl.c b/arch/powerpc/platforms/pseries/dtl.c
--- a/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:46:59.000000000 +0530
+++ b/arch/powerpc/platforms/pseries/dtl.c 2009-04-01 15:47:58.000000000 +0530
@@ -25,6 +25,7 @@
#include <asm/smp.h>
#include <asm/system.h>
#include <asm/uaccess.h>
+#include <asm/firmware.h>
#include "plpar_wrappers.h"
^ permalink raw reply
* Re: [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Benjamin Herrenschmidt @ 2009-04-01 9:54 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development
In-Reply-To: <alpine.LRH.2.00.0904011141550.13419@vixen.sonytel.be>
On Wed, 2009-04-01 at 11:42 +0200, Geert Uytterhoeven wrote:
> PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
> causing build failures if PCI is not set.
Maybe it should only select it if PCI is enabled ? Is qpace using PCI ?
Cheers,
Ben.
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> ---
> arch/powerpc/platforms/cell/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
> index 40e24c3..33f534f 100644
> --- a/arch/powerpc/platforms/cell/Kconfig
> +++ b/arch/powerpc/platforms/cell/Kconfig
> @@ -14,6 +14,7 @@ config PPC_CELL_NATIVE
> bool
> select PPC_CELL_COMMON
> select PPC_OF_PLATFORM_PCI
> + select PCI
> select MPIC
> select IBM_NEW_EMAC_EMAC4
> select IBM_NEW_EMAC_RGMII
^ permalink raw reply
* [PATCH] powerpc: PPC_CELL_NATIVE should select PCI
From: Geert Uytterhoeven @ 2009-04-01 9:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux/PPC Development, Cell Broadband Engine OSS Development
PPC_CELL_NATIVE selects PPC_OF_PLATFORM_PCI, but not the underlying PCI,
causing build failures if PCI is not set.
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/platforms/cell/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/cell/Kconfig b/arch/powerpc/platforms/cell/Kconfig
index 40e24c3..33f534f 100644
--- a/arch/powerpc/platforms/cell/Kconfig
+++ b/arch/powerpc/platforms/cell/Kconfig
@@ -14,6 +14,7 @@ config PPC_CELL_NATIVE
bool
select PPC_CELL_COMMON
select PPC_OF_PLATFORM_PCI
+ select PCI
select MPIC
select IBM_NEW_EMAC_EMAC4
select IBM_NEW_EMAC_RGMII
--
1.6.0.4
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply related
* RE: USB does not work on mpc8347
From: Li Yang-R58472 @ 2009-04-01 9:22 UTC (permalink / raw)
To: 山崎 精二, linuxppc-dev
In-Reply-To: <20090401180230.04BE.YAMAZAKI.SEIJI@kk.jp.panasonic.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=freescale.com@ozlabs.org]
> On Behalf Of 山崎 精二
> Sent: Wednesday, April 01, 2009 5:14 PM
> To: linuxppc-dev@ozlabs.org
> Subject: USB does not work on mpc8347
>
> Hi all,
>
> I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
> I have some problem.
>
> One is USB does not work on mpc8347.
> platform_driver_probe(&udc_driver, fsl_udc_probe) is failed.
> struct is
> static struct platform_driver udc_driver = {
> .probe = fsl_udc_probe,
> .remove = __exit_p(fsl_udc_remove),
> /* these suspend and resume are not usb suspend and resume */
> .suspend = fsl_udc_suspend,
> .resume = fsl_udc_resume,
> .driver = {
> // .name = (char *)driver_name,
> .name = "fsl-usb2-mph",
Why are you changing this? Mph module can only be host, not the device mode supported by this driver.
> .owner = THIS_MODULE,
> },
> };
> I do not know why it fails.
> Do i have to do something ?
So what function did you try to test? Host or device? For host mode, you should look into the drivers/usb/host/ehci-fsl.c file.
- Leo
^ permalink raw reply
* USB does not work on mpc8347
From: 山崎 精二 @ 2009-04-01 9:13 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have some problem.
One is USB does not work on mpc8347.
platform_driver_probe(&udc_driver, fsl_udc_probe) is failed.
struct is
static struct platform_driver udc_driver = {
.probe = fsl_udc_probe,
.remove = __exit_p(fsl_udc_remove),
/* these suspend and resume are not usb suspend and resume */
.suspend = fsl_udc_suspend,
.resume = fsl_udc_resume,
.driver = {
// .name = (char *)driver_name,
.name = "fsl-usb2-mph",
.owner = THIS_MODULE,
},
};
I do not know why it fails.
Do i have to do something ?
-Seiji
--
yamazaki seiji <yamazaki.seiji@kk.jp.panasonic.com>
^ permalink raw reply
* Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-01 7:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <fa686aa40903310841x42876819rafe3e8bf24b8646e@mail.gmail.com>
Grant Likely wrote:
> On Tue, Mar 31, 2009 at 6:37 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> This patch makes the I2C bus speed configurable by using the I2C node
>> property "clock-frequency". If the property is not defined, the old
>> fixed clock settings will be used for backward comptibility.
>>
>> The generic I2C clock properties, especially the CPU-specific source
>> clock pre-scaler are defined via the OF match table:
>>
>> static const struct of_device_id mpc_i2c_of_match[] = {
>> {.compatible = "fsl,mpc5200b-i2c",
>> .data = (void *)FSL_I2C_DEV_CLOCK_5200, },
>> {.compatible = "fsl,mpc5200-i2c",
>> .data = (void *)FSL_I2C_DEV_CLOCK_5200, },
>> {.compatible = "fsl,mpc8313-i2c",
>> .data = (void *)FSL_I2C_DEV_SEPARATE_DFSRR, },
>> {.compatible = "fsl,mpc8543-i2c",
>> .data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
>> FSL_I2C_DEV_CLOCK_DIV2), },
>> {.compatible = "fsl,mpc8544-i2c",
>> .data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
>> FSL_I2C_DEV_CLOCK_DIV23), },
>> /* Backward compatibility */
>> {.compatible = "fsl-i2c", },
>> {},
>> };
>
>
> Instead passing in a flag (and using an ugly cast to do it) which is
> then checked inside the mpc_i2c_setclock(), you should do this
> instead:
>
> struct fsl_i2c_match_data {
> int static void *(setclock)(struct device_node *node, struct
> mpc_i2c *i2c, u32 clock);
> int flags;
> /* Other stuff can go here */
> };
>
> static const struct of_device_id mpc_i2c_of_match[] = {
> {.compatible = "fsl,mpc5200b-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_mpc5200, },
> },
> {.compatible = "fsl,mpc5200-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_mpc5200, },
> },
> {.compatible = "fsl,mpc8313-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> },
> {.compatible = "fsl,mpc8543-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> .flags = FSL_I2C_DEV_CLOCK_DIV2,
> },
> {.compatible = "fsl,mpc8544-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> .flags = FSL_I2C_DEV_CLOCK_DIV23,
> },
> /* Backward compatibility */
> {.compatible = "fsl-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock, },
> },
> {},
> };
>
> The table definition is more verbose this way, but I think it results
> in more understandable and easier to extend code. It also adds lets
> the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly "dfsrr"
property, right? Then it seems consequent to continue using i2c->flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
> Also, this ...
>
>> --- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c 2009-03-31 13:25:08.000000000 +0200
>> +++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-03-31 13:34:40.531721011 +0200
>> +int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
>> +{
>> [...]
>> +}
>> +EXPORT_SYMBOL(fsl_i2c_get_fdr);
>
> ... and this ...
>
>> --- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31 13:25:08.000000000 +0200
>> +++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31 13:28:54.309718526 +0200
>> +int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
>> +{
>> [...]
>> +}
>> +EXPORT_SYMBOL(fsl_i2c_get_fdr);
>
> does not work on a multiplatform kernel. Both 8xxx and 52xx support
> can be selected at the same time.
OK, then we need different functions including stubs.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: i2c-mpc: preserve I2C clocking
From: Wolfgang Grandegger @ 2009-04-01 7:40 UTC (permalink / raw)
To: Wolfgang Grandegger, linuxppc-dev, devicetree-discuss
In-Reply-To: <20090331230626.GB23304@yookeroo.seuss>
David Gibson wrote:
> On Tue, Mar 31, 2009 at 02:43:39PM +0200, Wolfgang Grandegger wrote:
>> The I2c node property "fsl,preserve-clocking" allows to overtake the
>> clock settings from the boot loader and avoids the hard-coded setting.
>
> Hrm. This is dubious. The device tree should generally describe
> hardware, not OS/driver behaviour which is what this appears to be
> doing. There are exceptions, but you need to justify them.
I think the purpose of this property is clear. How would you provide
that functionality instead? I suggested that a "clock-frequency = <0>"
property should do the trick but Grant preferred to be more explicit.
Wolfgang.
^ permalink raw reply
* Re: powerpc/85xx: Add support for the "socrates" board (MPC8544)
From: Wolfgang Grandegger @ 2009-04-01 7:36 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, Scott Wood
In-Reply-To: <20090331155443.GA28242@oksana.dev.rtsoft.ru>
Anton Vorontsov wrote:
> On Tue, Mar 31, 2009 at 09:05:28AM -0600, Grant Likely wrote:
> [...]
>>>>>>> + soc8544@e0000000 {
>>>>>>> + #address-cells = <1>;
>>>>>>> + #size-cells = <1>;
>>>>>>> + device_type = "soc";
>>>>>> Drop device_type here too.
>>>>> Grrr, I just realized that removing the devices type "soc" has broken
>>>>> fsl_get_sys_freq(). See:
>>>>>
>>>>> http://lxr.linux.no/linux+v2.6.29/arch/powerpc/sysdev/fsl_soc.c#L80
>>>>>
>>>>> We need a quick fix and we could take the occasion to establish a common
>>>>> function for the MPC52xx as well, but it's not obvious to me how to find
>>>>> the SOC node without the device type property.
>>>> SoC node should have a compatible property, just like everything else.
>>>>
>>>> compatible = "fsl,mpc8544-immr"; (immr == Internally Memory Mapped Registers)
>>>>
>>>> Many other boards already do this.
>>> Yes, it does, but searching for the SOC node is not straight-forward
>>> because there is no common compatibility string but many CPU-specific
>>> compatibility strings, e.g. "fsl,mpc8560-immr", etc. Have I missed
>>> something?
>> Choose a new value ("fsl,mpc-immr" perhaps?), document exactly what it
>> means, and add add it to the end of the compatible list.
>
> As Scott Wood once pointed out, IMMR does not exists for MPC85xx
> parts. There it's called CCSR.
>
> See this thread:
>
> http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg12665.html
>
> I still think that
> "fsl,mpc83NN-immr", "fsl,soc", "simple-bus" for 83xx
> and
> "fsl,mpc85NN-ccsr", "fsl,soc", "simple-bus" for 85xx
>
> would be OK, at least to start with. We can always deprecate "fsl,soc"
> compatible in favour of something more elegant, but "fsl,soc" should be
> just fine to replace device_type = "soc".
>
> Also, there is another good thing about "fsl,soc" -- U-Boot already
> finds it for 83xx CPUs. ;-)
Ugh! I just realize the full impact of removing device type "soc". It
will break compatibility with U-Boot for many boards. Is it worth it?
Wolfgang.
^ 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