* [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 23:36 UTC (permalink / raw)
To: i2c, linuxppc-dev
New verision, addresses whitespace issues
The following series implements standard linux module aliasing for i2c modules
It then converts the mpc i2c driver from being a platform driver to an open
firmware one. I2C device names are picked up from the device tree. Module
aliasing is used to translate from device tree names into to linux kernel
names. Several i2c drivers are updated to use the new aliasing.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH 2/4] Modify several rtc drivers to use the alias names list property of i2c
From: Jon Smirl @ 2007-12-09 23:36 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071209233648.2327.14584.stgit@terra.home>
This patch modifies the ds1307, ds1374, and rs5c372 i2c drivers to support
device tree names using the new i2c mod alias support
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/sysdev/fsl_soc.c | 44 ++++++-----------------------------------
drivers/rtc/rtc-ds1307.c | 38 +++++++++++++++++++----------------
drivers/rtc/rtc-ds1374.c | 11 +++++++++-
drivers/rtc/rtc-rs5c372.c | 31 ++++++++++++++++-------------
4 files changed, 53 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..268638a 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -320,48 +320,12 @@ arch_initcall(gfar_of_init);
#ifdef CONFIG_I2C_BOARDINFO
#include <linux/i2c.h>
-struct i2c_driver_device {
- char *of_device;
- char *i2c_driver;
- char *i2c_type;
-};
-
-static struct i2c_driver_device i2c_devices[] __initdata = {
- {"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
- {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
- {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
- {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
- {"dallas,ds1307", "rtc-ds1307", "ds1307",},
- {"dallas,ds1337", "rtc-ds1307", "ds1337",},
- {"dallas,ds1338", "rtc-ds1307", "ds1338",},
- {"dallas,ds1339", "rtc-ds1307", "ds1339",},
- {"dallas,ds1340", "rtc-ds1307", "ds1340",},
- {"stm,m41t00", "rtc-ds1307", "m41t00"},
- {"dallas,ds1374", "rtc-ds1374", "rtc-ds1374",},
-};
-
-static int __init of_find_i2c_driver(struct device_node *node,
- struct i2c_board_info *info)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
- if (!of_device_is_compatible(node, i2c_devices[i].of_device))
- continue;
- if (strlcpy(info->driver_name, i2c_devices[i].i2c_driver,
- KOBJ_NAME_LEN) >= KOBJ_NAME_LEN ||
- strlcpy(info->type, i2c_devices[i].i2c_type,
- I2C_NAME_SIZE) >= I2C_NAME_SIZE)
- return -ENOMEM;
- return 0;
- }
- return -ENODEV;
-}
static void __init of_register_i2c_devices(struct device_node *adap_node,
int bus_num)
{
struct device_node *node = NULL;
+ const char *compatible;
while ((node = of_get_next_child(adap_node, node))) {
struct i2c_board_info info = {};
@@ -378,8 +342,12 @@ static void __init of_register_i2c_devices(struct device_node *adap_node,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, &info) < 0)
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible attribute\n");
continue;
+ }
+ strncpy(info.driver_name, compatible, sizeof(info.driver_name));
info.addr = *addr;
diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index bc1c7fe..a4dec4b 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -99,45 +99,46 @@ struct ds1307 {
};
struct chip_desc {
- char name[9];
unsigned nvram56:1;
unsigned alarm:1;
enum ds_type type;
};
static const struct chip_desc chips[] = { {
- .name = "ds1307",
.type = ds_1307,
.nvram56 = 1,
}, {
- .name = "ds1337",
.type = ds_1337,
.alarm = 1,
}, {
- .name = "ds1338",
.type = ds_1338,
.nvram56 = 1,
}, {
- .name = "ds1339",
.type = ds_1339,
.alarm = 1,
}, {
- .name = "ds1340",
.type = ds_1340,
}, {
- .name = "m41t00",
.type = m41t00,
}, };
-static inline const struct chip_desc *find_chip(const char *s)
-{
- unsigned i;
-
- for (i = 0; i < ARRAY_SIZE(chips); i++)
- if (strnicmp(s, chips[i].name, sizeof chips[i].name) == 0)
- return &chips[i];
- return NULL;
-}
+static struct i2c_device_id ds1307_id[] = {
+ {"rtc-ds1307", ds_1307},
+ {"ds1307", ds_1307},
+ {"ds1337", ds_1337},
+ {"ds1338", ds_1338},
+ {"ds1339", ds_1339},
+ {"ds1340", ds_1340},
+ {"m41t00", m41t00},
+ {"dallas,ds1307", ds_1307},
+ {"dallas,ds1337", ds_1337},
+ {"dallas,ds1338", ds_1338},
+ {"dallas,ds1339", ds_1339},
+ {"dallas,ds1340", ds_1340},
+ {"stm,m41t00", m41t00},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ds1307_id);
static int ds1307_get_time(struct device *dev, struct rtc_time *t)
{
@@ -326,7 +327,7 @@ static struct bin_attribute nvram = {
static struct i2c_driver ds1307_driver;
-static int __devinit ds1307_probe(struct i2c_client *client)
+static int __devinit ds1307_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct ds1307 *ds1307;
int err = -ENODEV;
@@ -334,7 +335,7 @@ static int __devinit ds1307_probe(struct i2c_client *client)
const struct chip_desc *chip;
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
- chip = find_chip(client->name);
+ chip = &chips[id->driver_data];
if (!chip) {
dev_err(&client->dev, "unknown chip type '%s'\n",
client->name);
@@ -537,6 +538,7 @@ static struct i2c_driver ds1307_driver = {
},
.probe = ds1307_probe,
.remove = __devexit_p(ds1307_remove),
+ .id_table = ds1307_id,
};
static int __init ds1307_init(void)
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 45bda18..2b852f3 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -41,6 +41,14 @@
#define DS1374_REG_SR_AF 0x01 /* Alarm Flag */
#define DS1374_REG_TCR 0x09 /* Trickle Charge */
+static struct i2c_device_id ds1374_id[] = {
+ {"rtc-ds1374", 0},
+ {"ds1374", 0},
+ {"dallas,ds1374", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, ds1374_id);
+
struct ds1374 {
struct i2c_client *client;
struct rtc_device *rtc;
@@ -355,7 +363,7 @@ static const struct rtc_class_ops ds1374_rtc_ops = {
.ioctl = ds1374_ioctl,
};
-static int ds1374_probe(struct i2c_client *client)
+static int ds1374_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct ds1374 *ds1374;
int ret;
@@ -429,6 +437,7 @@ static struct i2c_driver ds1374_driver = {
},
.probe = ds1374_probe,
.remove = __devexit_p(ds1374_remove),
+ .id_table = ds1374_id,
};
static int __init ds1374_init(void)
diff --git a/drivers/rtc/rtc-rs5c372.c b/drivers/rtc/rtc-rs5c372.c
index 6b67b50..de0d458 100644
--- a/drivers/rtc/rtc-rs5c372.c
+++ b/drivers/rtc/rtc-rs5c372.c
@@ -62,13 +62,26 @@
enum rtc_type {
- rtc_undef = 0,
rtc_rs5c372a,
rtc_rs5c372b,
rtc_rv5c386,
rtc_rv5c387a,
};
+static struct i2c_device_id rs5c372_id[] = {
+ {"rtc-rs5c372", rtc_rs5c372a},
+ {"rs5c372a", rtc_rs5c372a},
+ {"rs5c372b", rtc_rs5c372b},
+ {"rv5c386", rtc_rv5c386},
+ {"rv5c387a", rtc_rv5c387a},
+ {"ricoh,rs5c372a", rtc_rs5c372a},
+ {"ricoh,rs5c372b", rtc_rs5c372b},
+ {"ricoh,rv5c386", rtc_rv5c386},
+ {"ricoh,rv5c387a", rtc_rv5c387a},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, rs5c372_id);
+
/* REVISIT: this assumes that:
* - we're in the 21st century, so it's safe to ignore the century
* bit for rv5c38[67] (REG_MONTH bit 7);
@@ -494,7 +507,7 @@ static void rs5c_sysfs_unregister(struct device *dev)
static struct i2c_driver rs5c372_driver;
-static int rs5c372_probe(struct i2c_client *client)
+static int rs5c372_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
int err = 0;
struct rs5c372 *rs5c372;
@@ -522,18 +535,7 @@ static int rs5c372_probe(struct i2c_client *client)
if (err < 0)
goto exit_kfree;
- if (strcmp(client->name, "rs5c372a") == 0)
- rs5c372->type = rtc_rs5c372a;
- else if (strcmp(client->name, "rs5c372b") == 0)
- rs5c372->type = rtc_rs5c372b;
- else if (strcmp(client->name, "rv5c386") == 0)
- rs5c372->type = rtc_rv5c386;
- else if (strcmp(client->name, "rv5c387a") == 0)
- rs5c372->type = rtc_rv5c387a;
- else {
- rs5c372->type = rtc_rs5c372b;
- dev_warn(&client->dev, "assuming rs5c372b\n");
- }
+ rs5c372->type = id->driver_data;
/* clock may be set for am/pm or 24 hr time */
switch (rs5c372->type) {
@@ -651,6 +653,7 @@ static struct i2c_driver rs5c372_driver = {
},
.probe = rs5c372_probe,
.remove = rs5c372_remove,
+ .id_table = rs5c372_id,
};
static __init int rs5c372_init(void)
^ permalink raw reply related
* [PATCH 3/4] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
From: Jon Smirl @ 2007-12-09 23:36 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071209233648.2327.14584.stgit@terra.home>
Convert MPC i2c driver from being a platform_driver to an open firmware version. Error returns were improved. Routine names were changed from fsl_ to mpc_ to make them match the file name.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
arch/powerpc/sysdev/fsl_soc.c | 96 ---------------------
drivers/i2c/busses/i2c-mpc.c | 190 ++++++++++++++++++++++++++++-------------
2 files changed, 129 insertions(+), 157 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 268638a..d6ef264 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -318,102 +318,6 @@ err:
arch_initcall(gfar_of_init);
-#ifdef CONFIG_I2C_BOARDINFO
-#include <linux/i2c.h>
-
-static void __init of_register_i2c_devices(struct device_node *adap_node,
- int bus_num)
-{
- struct device_node *node = NULL;
- const char *compatible;
-
- while ((node = of_get_next_child(adap_node, node))) {
- struct i2c_board_info info = {};
- const u32 *addr;
- int len;
-
- addr = of_get_property(node, "reg", &len);
- if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
- printk(KERN_WARNING "fsl_soc.c: invalid i2c device entry\n");
- continue;
- }
-
- info.irq = irq_of_parse_and_map(node, 0);
- if (info.irq == NO_IRQ)
- info.irq = -1;
-
- compatible = of_get_property(node, "compatible", &len);
- if (!compatible) {
- printk(KERN_WARNING "i2c-mpc.c: invalid entry, missing compatible attribute\n");
- continue;
- }
- strncpy(info.driver_name, compatible, sizeof(info.driver_name));
-
- info.addr = *addr;
-
- i2c_register_board_info(bus_num, &info, 1);
- }
-}
-
-static int __init fsl_i2c_of_init(void)
-{
- struct device_node *np;
- unsigned int i;
- struct platform_device *i2c_dev;
- int ret;
-
- for (np = NULL, i = 0;
- (np = of_find_compatible_node(np, "i2c", "fsl-i2c")) != NULL;
- i++) {
- struct resource r[2];
- struct fsl_i2c_platform_data i2c_data;
- const unsigned char *flags = NULL;
-
- memset(&r, 0, sizeof(r));
- memset(&i2c_data, 0, sizeof(i2c_data));
-
- ret = of_address_to_resource(np, 0, &r[0]);
- if (ret)
- goto err;
-
- of_irq_to_resource(np, 0, &r[1]);
-
- i2c_dev = platform_device_register_simple("fsl-i2c", i, r, 2);
- if (IS_ERR(i2c_dev)) {
- ret = PTR_ERR(i2c_dev);
- goto err;
- }
-
- i2c_data.device_flags = 0;
- flags = of_get_property(np, "dfsrr", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
-
- flags = of_get_property(np, "fsl5200-clocking", NULL);
- if (flags)
- i2c_data.device_flags |= FSL_I2C_DEV_CLOCK_5200;
-
- ret =
- platform_device_add_data(i2c_dev, &i2c_data,
- sizeof(struct
- fsl_i2c_platform_data));
- if (ret)
- goto unreg;
-
- of_register_i2c_devices(np, i);
- }
-
- return 0;
-
-unreg:
- platform_device_unregister(i2c_dev);
-err:
- return ret;
-}
-
-arch_initcall(fsl_i2c_of_init);
-#endif
-
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
{
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d8de4ac..3f26313 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -17,7 +17,7 @@
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/init.h>
-#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <asm/io.h>
#include <linux/fsl_devices.h>
@@ -25,13 +25,13 @@
#include <linux/interrupt.h>
#include <linux/delay.h>
-#define MPC_I2C_ADDR 0x00
+#define DRV_NAME "mpc-i2c"
+
#define MPC_I2C_FDR 0x04
#define MPC_I2C_CR 0x08
#define MPC_I2C_SR 0x0c
#define MPC_I2C_DR 0x10
#define MPC_I2C_DFSRR 0x14
-#define MPC_I2C_REGION 0x20
#define CCR_MEN 0x80
#define CCR_MIEN 0x40
@@ -180,7 +180,7 @@ static void mpc_i2c_stop(struct mpc_i2c *i2c)
static int mpc_write(struct mpc_i2c *i2c, int target,
const u8 * data, int length, int restart)
{
- int i;
+ int i, result;
unsigned timeout = i2c->adap.timeout;
u32 flags = restart ? CCR_RSTA : 0;
@@ -192,15 +192,17 @@ static int mpc_write(struct mpc_i2c *i2c, int target,
/* Write target byte */
writeb((target << 1), i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
for (i = 0; i < length; i++) {
/* Write data byte */
writeb(data[i], i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
}
return 0;
@@ -210,7 +212,7 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
u8 * data, int length, int restart)
{
unsigned timeout = i2c->adap.timeout;
- int i;
+ int i, result;
u32 flags = restart ? CCR_RSTA : 0;
/* Start with MEN */
@@ -221,8 +223,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
/* Write target address byte - this time with the read flag set */
writeb((target << 1) | 1, i2c->base + MPC_I2C_DR);
- if (i2c_wait(i2c, timeout, 1) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 1);
+ if (result < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +237,9 @@ static int mpc_read(struct mpc_i2c *i2c, int target,
}
for (i = 0; i < length; i++) {
- if (i2c_wait(i2c, timeout, 0) < 0)
- return -1;
+ result = i2c_wait(i2c, timeout, 0);
+ if (result < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -312,105 +316,169 @@ static struct i2c_adapter mpc_ops = {
.retries = 1
};
-static int fsl_i2c_probe(struct platform_device *pdev)
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static void of_register_i2c_devices(struct i2c_adapter *adap, struct device_node *adap_node)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ const char *compatible;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
+ printk(KERN_ERR "i2c-mpc.c: invalid entry, missing reg attribute\n");
+ continue;
+ }
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ compatible = of_get_property(node, "compatible", &len);
+ if (!compatible) {
+ printk(KERN_ERR "i2c-mpc.c: invalid entry, missing compatible attribute\n");
+ continue;
+ }
+ strncpy(info.driver_name, compatible, sizeof(info.driver_name));
+ info.type[0] = '\0';
+
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ if (!i2c_new_device(adap, &info)) {
+ printk(KERN_ERR "i2c-mpc.c: Failed to load driver for %s\n", info.driver_name);
+ continue;
+ }
+ }
+}
+
+static int mpc_i2c_probe(struct of_device *op, const struct of_device_id *match)
{
int result = 0;
struct mpc_i2c *i2c;
- struct fsl_i2c_platform_data *pdata;
- struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
-
- if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL))) {
+ i2c = kzalloc(sizeof(*i2c), GFP_KERNEL);
+ if (!i2c)
return -ENOMEM;
- }
- i2c->irq = platform_get_irq(pdev, 0);
- if (i2c->irq < 0) {
- result = -ENXIO;
- goto fail_get_irq;
- }
- i2c->flags = pdata->device_flags;
- init_waitqueue_head(&i2c->queue);
+ if (of_get_property(op->node, "dfsrr", NULL))
+ i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
- i2c->base = ioremap((phys_addr_t)r->start, MPC_I2C_REGION);
+ if (of_device_is_compatible(op->node, "mpc5200-i2c"))
+ i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
+ init_waitqueue_head(&i2c->queue);
+
+ i2c->base = of_iomap(op->node, 0);
if (!i2c->base) {
printk(KERN_ERR "i2c-mpc - failed to map controller\n");
result = -ENOMEM;
goto fail_map;
}
- if (i2c->irq != 0)
- if ((result = request_irq(i2c->irq, mpc_i2c_isr,
- IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
- printk(KERN_ERR
- "i2c-mpc - failed to attach interrupt\n");
- goto fail_irq;
- }
+ i2c->irq = irq_of_parse_and_map(op->node, 0);
+ if (i2c->irq == NO_IRQ) {
+ result = -ENXIO;
+ goto fail_irq;
+ }
+
+ result = request_irq(i2c->irq, mpc_i2c_isr, IRQF_SHARED, "i2c-mpc", i2c));
+ if (result < 0) {
+ printk(KERN_ERR "i2c-mpc - failed to attach interrupt\n");
+ goto fail_request;
+ }
mpc_i2c_setclock(i2c);
- platform_set_drvdata(pdev, i2c);
+
+ dev_set_drvdata(&op->dev, i2c);
i2c->adap = mpc_ops;
- i2c->adap.nr = pdev->id;
i2c_set_adapdata(&i2c->adap, i2c);
- i2c->adap.dev.parent = &pdev->dev;
- if ((result = i2c_add_numbered_adapter(&i2c->adap)) < 0) {
+ i2c->adap.dev.parent = &op->dev;
+
+ result = i2c_add_adapter(&i2c->adap);
+ if (result < 0) {
printk(KERN_ERR "i2c-mpc - failed to add adapter\n");
goto fail_add;
}
+ of_register_i2c_devices(&i2c->adap, op->node);
+
return result;
- fail_add:
- if (i2c->irq != 0)
- free_irq(i2c->irq, i2c);
- fail_irq:
+fail_add:
+ free_irq(i2c->irq, i2c);
+fail_request:
+ irq_dispose_mapping(i2c->irq);
+fail_irq:
iounmap(i2c->base);
- fail_map:
- fail_get_irq:
+fail_map:
kfree(i2c);
return result;
};
-static int fsl_i2c_remove(struct platform_device *pdev)
+static int mpc_i2c_remove(struct of_device *op)
{
- struct mpc_i2c *i2c = platform_get_drvdata(pdev);
+ struct mpc_i2c *i2c = dev_get_drvdata(&op->dev);
i2c_del_adapter(&i2c->adap);
- platform_set_drvdata(pdev, NULL);
+ dev_set_drvdata(&op->dev, NULL);
- if (i2c->irq != 0)
+ if (i2c->irq != NO_IRQ)
free_irq(i2c->irq, i2c);
+ irq_dispose_mapping(i2c->irq);
iounmap(i2c->base);
kfree(i2c);
return 0;
};
+static struct of_device_id mpc_i2c_of_match[] = {
+ {
+ .compatible = "fsl-i2c",
+ },
+};
+MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
+
+
/* Structure for a device driver */
-static struct platform_driver fsl_i2c_driver = {
- .probe = fsl_i2c_probe,
- .remove = fsl_i2c_remove,
- .driver = {
- .owner = THIS_MODULE,
- .name = "fsl-i2c",
+static struct of_platform_driver mpc_i2c_driver = {
+ .match_table = mpc_i2c_of_match,
+ .probe = mpc_i2c_probe,
+ .remove = __devexit_p(mpc_i2c_remove),
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = DRV_NAME,
},
};
-static int __init fsl_i2c_init(void)
+static int __init mpc_i2c_init(void)
{
- return platform_driver_register(&fsl_i2c_driver);
+ int rv;
+
+ rv = of_register_platform_driver(&mpc_i2c_driver);
+ if (rv) {
+ printk(KERN_ERR DRV_NAME " of_register_platform_driver failed (%i)\n", rv);
+ return rv;
+ }
+ return 0;
}
-static void __exit fsl_i2c_exit(void)
+static void __exit mpc_i2c_exit(void)
{
- platform_driver_unregister(&fsl_i2c_driver);
+ of_unregister_platform_driver(&mpc_i2c_driver);
}
-module_init(fsl_i2c_init);
-module_exit(fsl_i2c_exit);
+module_init(mpc_i2c_init);
+module_exit(mpc_i2c_exit);
MODULE_AUTHOR("Adrian Cox <adrian@humboldt.co.uk>");
MODULE_DESCRIPTION
^ permalink raw reply related
* [PATCH 1/4] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2007-12-09 23:36 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071209233648.2327.14584.stgit@terra.home>
This patch allows new style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). I've
tested it on PowerPC and x86. This change is required for PowerPC
device tree support.
Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
---
drivers/i2c/i2c-core.c | 34 +++++++++++++++++++++++++++-------
include/linux/i2c.h | 5 ++---
include/linux/mod_devicetable.h | 9 +++++++++
3 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index b5e13e4..6fa6bab 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -47,10 +47,26 @@ static DEFINE_IDR(i2c_adapter_idr);
/* ------------------------------------------------------------------------- */
-static int i2c_device_match(struct device *dev, struct device_driver *drv)
+static const struct i2c_device_id *i2c_device_match(const struct i2c_device_id *id, struct i2c_client *client)
+{
+ /* new style drivers use the same kind of driver matching policy
+ * as platform devices or SPI: compare device and driver IDs.
+ */
+ if (id) {
+ while (id->name[0]) {
+ if (strcmp(client->driver_name, id->name) == 0)
+ return id;
+ id++;
+ }
+ }
+ return NULL;
+}
+
+static int i2c_bus_match(struct device *dev, struct device_driver *drv)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(drv);
+ const struct i2c_device_id *found_id;
/* make legacy i2c drivers bypass driver model probing entirely;
* such drivers scan each i2c adapter/bus themselves.
@@ -58,10 +74,11 @@ static int i2c_device_match(struct device *dev, struct device_driver *drv)
if (!is_newstyle_driver(driver))
return 0;
- /* new style drivers use the same kind of driver matching policy
- * as platform devices or SPI: compare device and driver IDs.
- */
- return strcmp(client->driver_name, drv->name) == 0;
+ found_id = i2c_device_match(driver->id_table, client);
+ if (found_id)
+ return 1;
+
+ return 0;
}
#ifdef CONFIG_HOTPLUG
@@ -89,12 +106,15 @@ static int i2c_device_probe(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
struct i2c_driver *driver = to_i2c_driver(dev->driver);
+ const struct i2c_device_id *id;
if (!driver->probe)
return -ENODEV;
client->driver = driver;
dev_dbg(dev, "probe\n");
- return driver->probe(client);
+
+ id = i2c_device_match(driver->id_table, client);
+ return driver->probe(client, id);
}
static int i2c_device_remove(struct device *dev)
@@ -189,7 +209,7 @@ static struct device_attribute i2c_dev_attrs[] = {
static struct bus_type i2c_bus_type = {
.name = "i2c",
.dev_attrs = i2c_dev_attrs,
- .match = i2c_device_match,
+ .match = i2c_bus_match,
.uevent = i2c_device_uevent,
.probe = i2c_device_probe,
.remove = i2c_device_remove,
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a100c9f..0ca1a59 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -126,7 +126,7 @@ struct i2c_driver {
* With the driver model, device enumeration is NEVER done by drivers;
* it's done by infrastructure. (NEW STYLE DRIVERS ONLY)
*/
- int (*probe)(struct i2c_client *);
+ int (*probe)(struct i2c_client *, const struct i2c_device_id *id);
int (*remove)(struct i2c_client *);
/* driver model interfaces that don't relate to enumeration */
@@ -141,11 +141,10 @@ struct i2c_driver {
struct device_driver driver;
struct list_head list;
+ struct i2c_device_id *id_table;
};
#define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
-#define I2C_NAME_SIZE 20
-
/**
* struct i2c_client - represent an I2C slave device
* @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index e9fddb4..688fad6 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -367,4 +367,13 @@ struct virtio_device_id {
};
#define VIRTIO_DEV_ANY_ID 0xffffffff
+/* i2c */
+
+#define I2C_NAME_SIZE 40
+struct i2c_device_id {
+ char name[I2C_NAME_SIZE];
+ kernel_ulong_t driver_data; /* Data private to the driver */
+};
+
+
#endif /* LINUX_MOD_DEVICETABLE_H */
^ permalink raw reply related
* Re: [PATCH] IB/ehca: Serialize HCA-related hCalls on POWER5
From: Roland Dreier @ 2007-12-09 23:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Joachim Fenkes, LKML, OF-EWG, linuxppc-dev, Christoph Raisch,
Marcus Eder, OF-General, Stefan Roscher
In-Reply-To: <200712071058.38416.arnd@arndb.de>
> I think it needs some more inspection. The msleep in there is only called
> for hcalls that return H_IS_LONG_BUSY(). In theory, you can call
> ehca_plpar_hcall_norets() from inside an interrupt handler if the
> hcall in question never returns long busy.
Fair enough... according to Documentation/infiniband/core_locking.txt,
the only driver methods that cannot sleep are:
create_ah
modify_ah
query_ah
destroy_ah
bind_mw
post_send
post_recv
poll_cq
req_notify_cq
map_phys_fmr
and I don't think ehca does an hcall from any of those. Of course
there might be other driver-internal code paths that I don't know
about. Maybe do a quick audit and then stick might_sleep() in the
hcall functions to catch any mistakes?
- R.
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-09 21:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <1197236326.6563.22.camel@pasglop>
On Mon, Dec 10, 2007 at 08:38:46AM +1100, Benjamin Herrenschmidt wrote:
>
> > +static struct i2c_device_id rs5c372_id[] = {
> > + {"rtc-rs5c372", rtc_rs5c372a},
> > + {"rs5c372a", rtc_rs5c372a},
> > + {"rs5c372b", rtc_rs5c372b},
> > + {"rv5c386", rtc_rv5c386},
> > + {"rv5c387a", rtc_rv5c387a},
> > + DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
> > + DT_NAME({"ricoh,rs5c372b", rtc_rs5c372b},)
> > + DT_NAME({"ricoh,rv5c386", rtc_rv5c386},)
> > + DT_NAME({"ricoh,rv5c387a", rtc_rv5c387a},)
> > + {},
> >
> > But what's the point in making these names specific to device trees?
> > They are perfectly valid names for the devices that could be used from
> > any platform.
>
> The more I think about it, the more I tend to agree that tagging isn't
> necessary and you are right. We should just match the name against the
> "compatible" property of the OF nodes (which mean we need to support
> multiple matches though since "compatible" is a list of strings).
>
> Now, I have a question about your example: Why do you have both
> "rs5c372a" and "ricoh,rs5c372a" ?
>
> I would argue that we should keep only the later...
I think existing platforms register with the simpler name, so they would
need to be changed. Having both shouldn't do harm though, we tend to
sometimes do the same with of_platform drivers for legacy reasons.
Unless someone adds a ridicously simple match name (by mistake or
whatever), it shouldn't be a problem. And if someone does it to some
dts/firmware, then we'll just need to add device tree fixups to set the
"vendor,product" string instead, yet again similar to how we have to do
sometimes with other drivers/devices.
-Olof
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 21:46 UTC (permalink / raw)
To: benh; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <1197236326.6563.22.camel@pasglop>
On 12/9/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > +static struct i2c_device_id rs5c372_id[] = {
> > + {"rtc-rs5c372", rtc_rs5c372a},
> > + {"rs5c372a", rtc_rs5c372a},
> > + {"rs5c372b", rtc_rs5c372b},
> > + {"rv5c386", rtc_rv5c386},
> > + {"rv5c387a", rtc_rv5c387a},
> > + DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
> > + DT_NAME({"ricoh,rs5c372b", rtc_rs5c372b},)
> > + DT_NAME({"ricoh,rv5c386", rtc_rv5c386},)
> > + DT_NAME({"ricoh,rv5c387a", rtc_rv5c387a},)
> > + {},
> >
> > But what's the point in making these names specific to device trees?
> > They are perfectly valid names for the devices that could be used from
> > any platform.
>
> The more I think about it, the more I tend to agree that tagging isn't
> necessary and you are right. We should just match the name against the
> "compatible" property of the OF nodes (which mean we need to support
> multiple matches though since "compatible" is a list of strings).
>
> Now, I have a question about your example: Why do you have both
> "rs5c372a" and "ricoh,rs5c372a" ?
The "rs5c372a" is unrelated to the device tree changes. In the
existing i2c driver code the driver is named rtc-rs5c372. But this
driver supports five different devices. A secondary i2c parameter
(driver_name, name) is used to tell the rtc-rs5c372 driver that it is
being loaded for use on a rs5c372a, rv5c387a, etc. When I fixed i2c to
support device tree name aliases I also fixed it to use kernel
aliasing to support these drivers that support multiple devices.
>
> I would argue that we should keep only the later...
>
> Cheers,
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Benjamin Herrenschmidt @ 2007-12-09 21:38 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091335g534d9248gcd920850f9f679a1@mail.gmail.com>
> +static struct i2c_device_id rs5c372_id[] = {
> + {"rtc-rs5c372", rtc_rs5c372a},
> + {"rs5c372a", rtc_rs5c372a},
> + {"rs5c372b", rtc_rs5c372b},
> + {"rv5c386", rtc_rv5c386},
> + {"rv5c387a", rtc_rv5c387a},
> + DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
> + DT_NAME({"ricoh,rs5c372b", rtc_rs5c372b},)
> + DT_NAME({"ricoh,rv5c386", rtc_rv5c386},)
> + DT_NAME({"ricoh,rv5c387a", rtc_rv5c387a},)
> + {},
>
> But what's the point in making these names specific to device trees?
> They are perfectly valid names for the devices that could be used from
> any platform.
The more I think about it, the more I tend to agree that tagging isn't
necessary and you are right. We should just match the name against the
"compatible" property of the OF nodes (which mean we need to support
multiple matches though since "compatible" is a list of strings).
Now, I have a question about your example: Why do you have both
"rs5c372a" and "ricoh,rs5c372a" ?
I would argue that we should keep only the later...
Cheers,
Ben.
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 21:35 UTC (permalink / raw)
To: benh; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <1197234799.6563.19.camel@pasglop>
On 12/9/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-12-09 at 15:57 -0500, Jon Smirl wrote:
> >
> > Are there technical concerns with this series? The white space can be
> > fixed in a few minutes.
> >
> > Adding a tag to differentiate matching types has implications that are
> > broader than just i2c. Shouldn't we do this first with the existing
> > scheme and then change the tagging process with later patches?
>
> No, we should decide on what to do with the tagging process (or not do)
> first, don't you think ? (If we need a tagging process, Scott had a
> concern but it might be moot, let's discuss that first).
Right now the tags are simply strings. The second parameter is driver specific.
+static struct i2c_device_id rs5c372_id[] = {
+ {"rtc-rs5c372", rtc_rs5c372a},
+ {"rs5c372a", rtc_rs5c372a},
+ {"rs5c372b", rtc_rs5c372b},
+ {"rv5c386", rtc_rv5c386},
+ {"rv5c387a", rtc_rv5c387a},
+ {"ricoh,rs5c372a", rtc_rs5c372a},
+ {"ricoh,rs5c372b", rtc_rs5c372b},
+ {"ricoh,rv5c386", rtc_rv5c386},
+ {"ricoh,rv5c387a", rtc_rv5c387a},
+ {},
+};
The current mechanism is simple string matching there are no platform
specific namespaces.
We could wrap the device tree style names in a macro that adds a
non-printable character to the front.
Something like this:
#define DT_NAMESPACE "\1"
#define DT_NAME(x) (DT_NAMESPACE x)
+ {DT_NAME("ricoh,rv5c386"), rtc_rv5c386},
And then modify the mpc i2c driver to insert the DT_NAMESPACE in front
of the string.
Another solution would be to make the names disappear on non-device
tree platforms
in mod_devicetable.h:
#ifdef USING_DEVICE_TREES
#define DT_NAME(x) x
#else
#define DTNAME(x)
#endif
+static struct i2c_device_id rs5c372_id[] = {
+ {"rtc-rs5c372", rtc_rs5c372a},
+ {"rs5c372a", rtc_rs5c372a},
+ {"rs5c372b", rtc_rs5c372b},
+ {"rv5c386", rtc_rv5c386},
+ {"rv5c387a", rtc_rv5c387a},
+ DT_NAME({"ricoh,rs5c372a", rtc_rs5c372a},)
+ DT_NAME({"ricoh,rs5c372b", rtc_rs5c372b},)
+ DT_NAME({"ricoh,rv5c386", rtc_rv5c386},)
+ DT_NAME({"ricoh,rv5c387a", rtc_rv5c387a},)
+ {},
But what's the point in making these names specific to device trees?
They are perfectly valid names for the devices that could be used from
any platform.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Benjamin Herrenschmidt @ 2007-12-09 21:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091257x4ba5e07aue55934fb6898aa2d@mail.gmail.com>
On Sun, 2007-12-09 at 15:57 -0500, Jon Smirl wrote:
>
> Are there technical concerns with this series? The white space can be
> fixed in a few minutes.
>
> Adding a tag to differentiate matching types has implications that are
> broader than just i2c. Shouldn't we do this first with the existing
> scheme and then change the tagging process with later patches?
No, we should decide on what to do with the tagging process (or not do)
first, don't you think ? (If we need a tagging process, Scott had a
concern but it might be moot, let's discuss that first).
Ben.
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 20:57 UTC (permalink / raw)
To: benh; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <1197233208.6563.14.camel@pasglop>
On 12/9/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> > What is the status of this series, is there anything I can do to help
> > get this into the i2c subsystem?
>
> I think there were a few comments such as whitespace issues and Scott
> had a comment about a tag to differenciate matching type.
Are there technical concerns with this series? The white space can be
fixed in a few minutes.
Adding a tag to differentiate matching types has implications that are
broader than just i2c. Shouldn't we do this first with the existing
scheme and then change the tagging process with later patches?
>
> Thus the expectation is that you'll respin the serie with those
> addressed.
>
> Ben.
>
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Benjamin Herrenschmidt @ 2007-12-09 20:46 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091224mcb43f0ci69f578d221505ba7@mail.gmail.com>
On Sun, 2007-12-09 at 15:24 -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I think there were a few comments such as whitespace issues and Scott
had a comment about a tag to differenciate matching type.
Thus the expectation is that you'll respin the serie with those
addressed.
Ben.
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-09 20:39 UTC (permalink / raw)
To: Jon Smirl; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <9e4733910712091224mcb43f0ci69f578d221505ba7@mail.gmail.com>
On Sun, Dec 09, 2007 at 03:24:55PM -0500, Jon Smirl wrote:
> What is the status of this series, is there anything I can do to help
> get this into the i2c subsystem?
I never saw the comments about whitespace cleanups being addressed. If
you run them through checkpatch you'll see quite a few things that needs
fixups. Care to do the round of cleanups and repost the series?
Besides that I'm fine with the approach of moving the matching to the
i2c layer, it does seem like a reasonable thing to do.
-Olof
^ permalink raw reply
* Re: [i2c] [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-09 20:24 UTC (permalink / raw)
To: i2c, linuxppc-dev, Jean Delvare
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>
What is the status of this series, is there anything I can do to help
get this into the i2c subsystem?
On 12/3/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> The following series implements standard linux module aliasing for i2c modules
> It then converts the mpc i2c driver from being a platform driver to an open
> firmware one. I2C device names are picked up from the device tree. Module
> aliasing is used to translate from device tree names into to linux kernel
> names. Several i2c drivers are updated to use the new aliasing.
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
> _______________________________________________
> i2c mailing list
> i2c@lm-sensors.org
> http://lists.lm-sensors.org/mailman/listinfo/i2c
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Grant Likely @ 2007-12-09 20:23 UTC (permalink / raw)
To: Jean-Samuel Chenard; +Cc: linuxppc-embedded
In-Reply-To: <169c03cb0712090932y52cb2744p245cdeb0cccc2ff2@mail.gmail.com>
On 12/9/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> On Dec 9, 2007 1:18 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> > > Thanks to the valuable information provided by this discussion group and
> > > particularly by Grant Likely from Secret Lab Technologies, I was able to
> > > setup and run Linux 2.6 on my ML-310 development platform.
> >
> > Congratulations. If you had to make any changes to get it to work
> > then please send me your patches.
>
> Thank you for the quick reply.
No problem.
>
> I will directly update Secret Lab's Wiki pages. Those pages are the
> ones that got me going really quickly, so I will add a few of my
> observations directly on your pages so everyone can benefit.
Much appreciated; thank you!
> My real target is the control FPGA on a BEE2 box
> (http://bee2.eecs.berkeley.edu) and on that particular setup, the
> control FPGA is directly connected to an LXT971A Ethernet PHY, so I'll
> use the ethernet MAC from Xilinx.
Cool platform. Yes, you should have much better luck with the EMAC
core. The driver needs some work to be acceptable for mainline, but
it should be functional.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Olof Johansson @ 2007-12-09 20:20 UTC (permalink / raw)
To: Josh Boyer; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071209122408.40d8a865@vader.jdub.homelinux.org>
On Sun, Dec 09, 2007 at 12:24:08PM -0600, Josh Boyer wrote:
> Yeah, I just did Reply-to-all. I've never seen CC's be stripped
> though. Anyway, I'll try to remember in the future.
Actually, my mail that you replied to had your address stripped off the
Cc list when it came out on the list (at least for me). :-)
It was on it when I sent it though.
-Olof
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Benjamin Herrenschmidt @ 2007-12-09 19:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <20071209172404.GA26651@lixom.net>
On Sun, 2007-12-09 at 11:24 -0600, Olof Johansson wrote:
> On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
>
> > Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> > he's the author).
>
> I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
> a reply-all. Seems as if the mailing list manager strips Cc fields of
> people already subscribed to the list, I've seen it before.
Yeah, my script for mailing quilt series doesn't do the selective CC
thingy... Bah, mpe wrote it, I suppose I can either nag him to fix it or
start learning perl :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Josh Boyer @ 2007-12-09 18:24 UTC (permalink / raw)
To: Olof Johansson; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20071209172404.GA26651@lixom.net>
On Sun, 9 Dec 2007 11:24:04 -0600
Olof Johansson <olof@lixom.net> wrote:
> On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
>
> > Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> > he's the author).
>
> I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
> a reply-all. Seems as if the mailing list manager strips Cc fields of
> people already subscribed to the list, I've seen it before.
Yeah, I just did Reply-to-all. I've never seen CC's be stripped
though. Anyway, I'll try to remember in the future.
josh
^ permalink raw reply
* Re: Xilinx ML310 Linux 2.6 PCI bridge
From: Jean-Samuel Chenard @ 2007-12-09 17:32 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40712082218k7e520e45q1266ecb4692b7dbb@mail.gmail.com>
On Dec 9, 2007 1:18 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 12/8/07, Jean-Samuel Chenard <jsamch@macs.ece.mcgill.ca> wrote:
> > Thanks to the valuable information provided by this discussion group an=
d
> > particularly by Grant Likely from Secret Lab Technologies, I was able t=
o
> > setup and run Linux 2.6 on my ML-310 development platform.
>
> Congratulations. If you had to make any changes to get it to work
> then please send me your patches.
Thank you for the quick reply.
I will directly update Secret Lab's Wiki pages. Those pages are the
ones that got me going really quickly, so I will add a few of my
observations directly on your pages so everyone can benefit.
I ended up using Secret Lab's GIT tree as my source archive, so I'll
let you know if I need to fix some code.
> You'll have to go back into the mailing list archives to find a patch
> for adding PCI support for a Virtex platform. I don't have any of
> that in my tree. It probably only exists for the 2.4 kernel. You'll
> need to port forward to use it on 2.6 (I'm more than willing to help
> you with this)
Hmmm... I'm not really ready to invest that much time into the PCI for ML-3=
10.
My real target is the control FPGA on a BEE2 box
(http://bee2.eecs.berkeley.edu) and on that particular setup, the
control FPGA is directly connected to an LXT971A Ethernet PHY, so I'll
use the ethernet MAC from Xilinx.
I use the ML-310 as a stepping stone for quickly prototyping some of
my FPGA changes since the VirtexII-Pro in the ML-310 is much smaller
and doesn't eat up all my workstation resources when re-compiling the
FPGA.
> However, word of warning. The Xilinx PCI bridge is badly broken.
> Xilinx is not supporting the PCI core and it is missing the ability to
> do certain types of transfers. Last I heard, Xilinx has no plans to
> fix their PCI core either.
Ok, its nice to know the status of that module. Too bad Xilinx is
dropping the support for it.
In that case, it would probably be more beneficial for all to adapt an
"open core" project such as this PCI bridge:
http://www.opencores.org/projects.cgi/web/pci/home
Along with the help of an OPB to Wishbone wrapper like that one:
http://www.opencores.org/projects.cgi/web/opb_wb_wrapper/overview
With some work (and ideally some PCI expertise) one could get an open
implementation of a PCI bridge that can integrate in the Xilinx EDK
flow and could be repaired or adapted as time goes... I am a complete
newbie to PCI, so I'll leave that to some willing "hacker".
I'll continue on my quest to run Linux 2.6 on the BEE2 control FPGA.
There is no PCI bus involved in that architecture. Just raw buses and
a sea of FPGA logic.
Regards,
Jean-Samuel
--=20
Integrated Microsystems Laboratory
McGill University, Montr=E9al, QC, CANADA
Web Page: http://chaos.ece.mcgill.ca
^ permalink raw reply
* Re: [PATCH 18/25] powerpc: Base support for 440GX Taishan eval board
From: Olof Johansson @ 2007-12-09 17:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Stephen Rothwell
In-Reply-To: <1197183715.6572.8.camel@pasglop>
On Sun, Dec 09, 2007 at 06:01:55PM +1100, Benjamin Herrenschmidt wrote:
> Ah yeah, indeed. I'll fix these. (BTW. Could you CC Hugh next time as
> he's the author).
I didn't see him Cc:d on the patch submission, and I'm guessing Josh did
a reply-all. Seems as if the mailing list manager strips Cc fields of
people already subscribed to the list, I've seen it before.
-Olof
^ permalink raw reply
* Re: Kernel symbol version history
From: David H. Lynch Jr. @ 2007-12-09 16:41 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <200712051807.36357.jcd@tribudubois.net>
Thank you.
I made use of one of the linux cross reference sites.
Though unless I don't know how to effectively use them trying to
track the history of a function, typdef, define, ..
is not particularly easy using lxr.
Grant's sugestion with git was closer to what I was looking for -
except that in some instances
needed to go back farther than it would take me..
Jean-Christophe Dubois wrote:
> Hi David,
>
> You could try the various "linux cross reference" web site out there. It is
> not necessarily complete (some linux version might be missing) but it can be
> usefull to lookup if some symbols/define/typedef were available in a
> particular Linux version.
>
> Have a look there.
>
> http://free-electrons.com/community/kernel/lxr
>
> Regards
>
> JC
>
> On Wednesday 05 December 2007 17:17:25 David H. Lynch Jr. wrote:
>
>> This might be slightly OT here, but would anyone know where there
>> might be a reference that indicates at precisely what version a given
>> symbol either appeared or disappeared within the Linux kernel ?
>>
>> As an example if a driver is supposed to work for 2.6 and 2.4 and
>> uses sysfs, or cdev, or alloc_chr_dev_region or ...
>> How can one tell at what point that api or symbol appeared so that
>> the proper conditionals appear within the driver.
>>
>> The last one that bit me was I made a collection of casting changes
>> to address 64bit vs. 32bit targets, and found that using the C99 fixed
>> size types - uint32_t, ... made life much more pleasant, after putting
>> them I nobody else could build because uintptr_t did not appear until
>> 2.6.24, and I still have not figured out exactly when uint32_t etc.
>> appeared.
>>
>> I would think there ought to be some resource besides group memory
>> to look this up ?
>> Is there a way to use git to look back through the history of a
>> symbol rather than a file.
>>
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: Powerpc PCI cleanups (mainly iSeries)
From: Josh Boyer @ 2007-12-09 14:40 UTC (permalink / raw)
To: benh; +Cc: Stephen Rothwell, ppc-dev
In-Reply-To: <1197185366.6572.43.camel@pasglop>
On Sun, 09 Dec 2007 18:29:26 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Thu, 2007-12-06 at 09:44 -0600, Josh Boyer wrote:
> > On Fri, 7 Dec 2007 02:07:26 +1100
> > Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > On Thu, 6 Dec 2007 18:00:45 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > I started out looking for ways to remove our dependencies on pci_dn and
> > > > got sidetracked into clening up the iSeries PCI code. The intention of
> > > > the following set of patches is that there be no semantic changes
> > > > (mostly).
> > >
> > > Some of these will clearly conflict with Benh's PCI work. We will sot
> > > that out between us. :-)
> >
> > In the meantime...
> >
> > My tree is going to carry BenH's patches since they're obviously
> > important to 4xx. If these conflicts get sorted out soon, that would
> > be good :). At some point I'm going to start sending stuff to Paul.
>
> The PCI merge serie of my patches shoudn't go through your tree (it's a
> separate serie from my 4xx stuff and isn't quite ready just yet...).
I wasn't talking about your series of 10 patches. You'll have
conflicts in your series of 25 too, though those should be fairly minor.
josh
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Balbir Singh @ 2007-12-09 13:20 UTC (permalink / raw)
To: Pavel Machek; +Cc: Olof Johansson, linuxppc-dev, LKML, David Rientjes
In-Reply-To: <20071209131636.GF4381@ucw.cz>
Pavel Machek wrote:
> On Sat 2007-12-08 09:52:06, Balbir Singh wrote:
>> David Rientjes wrote:
>>> On Sat, 8 Dec 2007, Balbir Singh wrote:
>>>
>>>> To be able to test the memory controller under NUMA, I use fake NUMA
>>>> nodes. x86-64 has a similar feature, the code I have here is the
>>>> simplest I could come up with for PowerPC.
>>>>
>>> Magnus Damm had patches from over a year ago that, I believe, made much of
>>> the x86_64 fake NUMA code generic so that it could be extended for
>>> architectures such as i386. Perhaps he could resurrect those patches if
>>> there is wider interest in such a tool.
>> That would be a very interesting patch, but what I have here is the
>> simplest patch and we could build on it incrementally. The interface is
>> non-standard but it does amazing things for 59 lines of code change.
>
> Well, maybe it is amazing, but having non-standard interface is also
> wrong...
>
I tend to agree with you, but in this case it's mostly debug
infrastructure that is architecture specific.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: [PATCH] Fake NUMA emulation for PowerPC
From: Pavel Machek @ 2007-12-09 13:16 UTC (permalink / raw)
To: Balbir Singh; +Cc: LKML, linuxppc-dev, David Rientjes, Olof Johansson
In-Reply-To: <475A1BEE.2050109@linux.vnet.ibm.com>
On Sat 2007-12-08 09:52:06, Balbir Singh wrote:
> David Rientjes wrote:
> > On Sat, 8 Dec 2007, Balbir Singh wrote:
> >
> >> To be able to test the memory controller under NUMA, I use fake NUMA
> >> nodes. x86-64 has a similar feature, the code I have here is the
> >> simplest I could come up with for PowerPC.
> >>
> >
> > Magnus Damm had patches from over a year ago that, I believe, made much of
> > the x86_64 fake NUMA code generic so that it could be extended for
> > architectures such as i386. Perhaps he could resurrect those patches if
> > there is wider interest in such a tool.
>
> That would be a very interesting patch, but what I have here is the
> simplest patch and we could build on it incrementally. The interface is
> non-standard but it does amazing things for 59 lines of code change.
Well, maybe it is amazing, but having non-standard interface is also
wrong...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Please pull linux-2.6-8xx.git for-paulus branch
From: Vitaly Bordug @ 2007-12-09 8:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <CF849773-F9A6-45D1-A36E-9A350BE5FB6D@kernel.crashing.org>
On Sat, 8 Dec 2007 09:17:06 -0600
Kumar Gala wrote:
>
> On Dec 8, 2007, at 4:09 AM, Vitaly Bordug wrote:
>
> > On Sat, 8 Dec 2007 13:00:25 +0300
> > Vitaly Bordug wrote:
> >
> >> Paul,
> >>
> >> please do
> >> git-pull
> >> git://git.kernel.org/pub/scm/linux/kernel/git/vitb/linux-2.6-8xx.git
> >> for-paulus
> >>
> >> to receive the following updates:
> >>
> > Forgot to tell that this is .25 material...
>
> Vitaly, if you don't mind I'll pull these into my tree for Paul to
> collect all the FSL stuff in one place.
>
I'm ok with either way.
--
Sincerely, Vitaly
^ 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