* [PATCH 0/2] QE clock source improvements
From: Timur Tabi @ 2007-12-03 21:17 UTC (permalink / raw)
To: netdev, linuxppc-dev, galak
This patch set adds a new property to make specifying QE clock sources
easier, adds a function to help parse the property, and updates the ucc_geth
driver to take advantage of all this.
Patch #1 is an arch/powerpc patch meant for Kumar's for-2.6.25 branch.
Patch #2 is a netdev patch, so it's either for Jeff G and/or Kumar.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: Jon Tollefson @ 2007-12-03 21:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Linux Memory Management List
In-Reply-To: <20071203020648.GF26919@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
>
>> This patch adds reliability to the 64K huge page option by making use of
>> the PMD for 64K huge pages when base pages are 4k. So instead of a 12
>> bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
>> would continue as 9 bits and 7 bits respectively. This will allow the
>> pgtable to fit in one base page. This patch would have to be applied
>> after part 1.
>>
>
> Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size
> setup? There's not a whole lot of point to it, after all...
>
Banning the base and huge page size from being the same size feels like
an artificial barrier. It is probably not the most massively useful
combination, but it shouldn't hurt performance.
Jon
^ permalink raw reply
* Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Scott Wood @ 2007-12-03 20:46 UTC (permalink / raw)
To: Clemens Koller; +Cc: Alessandro Zummo, rtc-linux, linuxppc-embedded
In-Reply-To: <47545A81.90804@anagramm.de>
On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
> >> Here, the next idea which comes to my mind:
> >> Maybe we should think about a kernel-config -> dts compiler for
> >> the future where the enabled drivers generate their default dts
> >> entries automagically?
> >
> > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs)
It's not uncommon for RTCs to have an alarm IRQ. It's not uncommon for
multiple not-quite-compatible RTC chips to be driven by the same driver,
which needs to know what it's dealing with.
> to .config, it might be an idea to extend the current structure for this
> use instead of duplicating and maintaining a second repository.
.config is not nearly as flexible in describing hardware as the device tree
is. Sorry, but even apart from the multiplatform issue, it's the wrong tool
for the job.
> And regarding the DS1337 (or the PCF8563 and similar RTCs):
> It's address (0x68) is immutable fixed by the manufacturer
> of that device. So, why do we include it in the DT, when we
> already told the kernel what driver we want to use?
You did not tell the kernel what driver you wanted to use; you told the
driver which address the chip will be on. There are other chips that also
use address 0x68, such as DS1374, which is completely incompatible with
DS1337 and uses a different driver.
> Even if I have an eeprom which can have varying addresses,
> I can simply tell the driver/the kernel .config what address
> it should use...
That's precisely what we do, via the device tree. It is not practical to do
it with kconfig. Again putting aside multiplatform kernels for the moment,
what would you do in kconfig to describe the addresses of multiple chips
without having a fixed-size list of possibilities? How would you tell the
kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus
0, and a "bar" chip at address 0x68 on i2c bus 1?
-Scott
^ permalink raw reply
* [PATCH 1/2] qe: add function qe_clock_source()
From: Timur Tabi @ 2007-12-03 21:17 UTC (permalink / raw)
To: netdev, linuxppc-dev, galak; +Cc: Timur Tabi
In-Reply-To: <11967166791607-git-send-email-timur@freescale.com>
Add function qe_clock_source() which takes a string containing the name of a
QE clock source (as is typically found in device trees) and returns the
matching enum qe_clock value.
Update booting-without-of.txt to indicate that the UCC properties rx-clock
and tx-clock are deprecated and replaced with rx-clock-name and tx-clock-name,
which use strings instead of numbers to indicate QE clock sources.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch applies to Kumar's for-2.6.25 branch. You may need to apply
my other pending patch, "qe: add ability to upload QE firmware", first.
Documentation/powerpc/booting-without-of.txt | 13 ++++++++++
arch/powerpc/sysdev/qe_lib/qe.c | 32 ++++++++++++++++++++++++++
include/asm-powerpc/qe.h | 1 +
3 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index e9a3cb1..c4342d3 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1626,6 +1626,19 @@ platforms are moved over to use the flattened-device-tree model.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- pio-handle : The phandle for the Parallel I/O port configuration.
+ - rx-clock-name: the UCC receive clock source
+ "none": clock source is disabled
+ "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+ "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+ - tx-clock-name: the UCC transmit clock source
+ "none": clock source is disabled
+ "brg1" through "brg16": clock source is BRG1-BRG16, respectively
+ "clk1" through "clk24": clock source is CLK1-CLK24, respectively
+ The following two properties are deprecated. rx-clock has been replaced
+ with rx-clock-name, and tx-clock has been replaced with tx-clock-name.
+ Drivers that currently use the deprecated properties should continue to
+ do so, in order to support older device trees, but they should be updated
+ to check for the new properties first.
- rx-clock : represents the UCC receive clock source.
0x00 : clock source is disabled;
0x1~0x10 : clock source is BRG1~BRG16 respectively;
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 865277b..5df8530 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -204,6 +204,38 @@ int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier)
}
EXPORT_SYMBOL(qe_setbrg);
+/* Convert a string to a QE clock source enum
+ *
+ * This function takes a string, typically from a property in the device
+ * tree, and returns the corresponding "enum qe_clock" value.
+*/
+enum qe_clock qe_clock_source(const char *source)
+{
+ unsigned int i;
+
+ if (strcasecmp(source, "none") == 0)
+ return QE_CLK_NONE;
+
+ if (strncasecmp(source, "brg", 3) == 0) {
+ i = simple_strtoul(source + 3, NULL, 10);
+ if ((i >= 1) && (i <= 16))
+ return (QE_BRG1 - 1) + i;
+ else
+ return QE_CLK_DUMMY;
+ }
+
+ if (strncasecmp(source, "clk", 3) == 0) {
+ i = simple_strtoul(source + 3, NULL, 10);
+ if ((i >= 1) && (i <= 24))
+ return (QE_CLK1 - 1) + i;
+ else
+ return QE_CLK_DUMMY;
+ }
+
+ return QE_CLK_DUMMY;
+}
+EXPORT_SYMBOL(qe_clock_source);
+
/* Initialize SNUMs (thread serial numbers) according to
* QE Module Control chapter, SNUM table
*/
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index 35c7b8d..430dc77 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -84,6 +84,7 @@ extern int par_io_data_set(u8 port, u8 pin, u8 val);
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
+enum qe_clock qe_clock_source(const char *source);
int qe_setbrg(enum qe_clock brg, unsigned int rate, unsigned int multiplier);
int qe_get_snum(void);
void qe_put_snum(u8 snum);
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: Chris Snook @ 2007-12-03 21:51 UTC (permalink / raw)
To: kniht, linuxppc-dev, Linux Memory Management List
In-Reply-To: <20071203020648.GF26919@localhost.localdomain>
David Gibson wrote:
> On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
>> This patch adds reliability to the 64K huge page option by making use of
>> the PMD for 64K huge pages when base pages are 4k. So instead of a 12
>> bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
>> would continue as 9 bits and 7 bits respectively. This will allow the
>> pgtable to fit in one base page. This patch would have to be applied
>> after part 1.
>
> Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size
> setup? There's not a whole lot of point to it, after all...
>
Actually, it sounds to me like an ideal way to benchmark the efficiency of the
hugepage implementation and VM effects, without the TLB performance obscuring
the results.
I agree that it's not something people will want to do very often, but the same
can be said about quite a lot of strange things that we allow just because
there's no fundamental reason why they cannot be.
-- Chris
^ permalink raw reply
* [PATCH 3/4] Convert PowerPC MPC i2c to of_platform_driver from platform_driver
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071203212032.23543.3453.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.
---
arch/powerpc/sysdev/fsl_soc.c | 96 ---------------------
drivers/i2c/busses/i2c-mpc.c | 185 +++++++++++++++++++++++++++--------------
2 files changed, 123 insertions(+), 158 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index e4c766e..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..bb6284e 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,15 @@ 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;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 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;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 0)
+ return result;
}
return 0;
@@ -210,7 +210,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 +221,8 @@ 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;
+ if ((result = i2c_wait(i2c, timeout, 1)) < 0)
+ return result;
if (length) {
if (length == 1)
@@ -234,8 +234,8 @@ 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;
+ if ((result = i2c_wait(i2c, timeout, 0)) < 0)
+ return result;
/* Generate txack on next to last byte */
if (i == length - 2)
@@ -312,105 +312,166 @@ 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))) {
+ if (!(i2c = kzalloc(sizeof(*i2c), GFP_KERNEL)))
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;
+ }
+
+ 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_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;
+ if ((result = i2c_add_adapter(&i2c->adap)) < 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 2/4] Modify several rtc drivers to use the alias names list property of i2c
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071203212032.23543.3453.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
---
arch/powerpc/sysdev/fsl_soc.c | 46 ++++++-----------------------------------
drivers/rtc/rtc-ds1307.c | 38 ++++++++++++++++++----------------
drivers/rtc/rtc-ds1374.c | 11 +++++++++-
drivers/rtc/rtc-rs5c372.c | 31 +++++++++++++++-------------
4 files changed, 54 insertions(+), 72 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3ace747..e4c766e 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,9 +342,13 @@ 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;
i2c_register_board_info(bus_num, &info, 1);
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 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
To: i2c, linuxppc-dev
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 1/4] Implement module aliasing for i2c to translate from device tree names
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071203212032.23543.3453.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.
---
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..76f48be 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..56d2dca 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
* [PATCH 4/4] Convert pfc8563 i2c driver from old style to new style
From: Jon Smirl @ 2007-12-03 21:20 UTC (permalink / raw)
To: i2c, linuxppc-dev
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>
Convert pfc8563 i2c driver from old style to new style. The
driver is also modified to support device tree names via the
i2c mod alias mechanism.
---
drivers/rtc/rtc-pcf8563.c | 114 +++++++++++++--------------------------------
1 files changed, 32 insertions(+), 82 deletions(-)
diff --git a/drivers/rtc/rtc-pcf8563.c b/drivers/rtc/rtc-pcf8563.c
index 0242d80..20b1acf 100644
--- a/drivers/rtc/rtc-pcf8563.c
+++ b/drivers/rtc/rtc-pcf8563.c
@@ -25,10 +25,6 @@
* located at 0x51 will pass the validation routine due to
* the way the registers are implemented.
*/
-static unsigned short normal_i2c[] = { I2C_CLIENT_END };
-
-/* Module parameters */
-I2C_CLIENT_INSMOD;
#define PCF8563_REG_ST1 0x00 /* status */
#define PCF8563_REG_ST2 0x01
@@ -72,9 +68,6 @@ struct pcf8563 {
int c_polarity; /* 0: MO_C=1 means 19xx, otherwise MO_C=1 means 20xx */
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind);
-static int pcf8563_detach(struct i2c_client *client);
-
/*
* In the routines that deal directly with the pcf8563 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -257,98 +250,55 @@ static const struct rtc_class_ops pcf8563_rtc_ops = {
.set_time = pcf8563_rtc_set_time,
};
-static int pcf8563_attach(struct i2c_adapter *adapter)
+static int pcf8563_remove(struct i2c_client *client)
{
- return i2c_probe(adapter, &addr_data, pcf8563_probe);
+ struct rtc_device *rtc = i2c_get_clientdata(client);
+
+ if (rtc)
+ rtc_device_unregister(rtc);
+
+ return 0;
}
+static struct i2c_device_id pcf8563_id[] = {
+ {"rtc-pcf8563", 0},
+ {"pcf8563", 0},
+ {"philips,pcf8563", 0},
+ {"rtc8564", 0},
+ {"epson,rtc8564", 0},
+ {},
+};
+MODULE_DEVICE_TABLE(i2c, pcf8563_id);
+
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id);
+
static struct i2c_driver pcf8563_driver = {
.driver = {
- .name = "pcf8563",
+ .name = "rtc-pcf8563",
},
.id = I2C_DRIVERID_PCF8563,
- .attach_adapter = &pcf8563_attach,
- .detach_client = &pcf8563_detach,
+ .probe = &pcf8563_probe,
+ .remove = &pcf8563_remove,
+ .id_table = pcf8563_id,
};
-static int pcf8563_probe(struct i2c_adapter *adapter, int address, int kind)
+static int pcf8563_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
- struct pcf8563 *pcf8563;
- struct i2c_client *client;
+ int result;
struct rtc_device *rtc;
-
- int err = 0;
-
- dev_dbg(&adapter->dev, "%s\n", __FUNCTION__);
-
- if (!i2c_check_functionality(adapter, I2C_FUNC_I2C)) {
- err = -ENODEV;
- goto exit;
- }
-
- if (!(pcf8563 = kzalloc(sizeof(struct pcf8563), GFP_KERNEL))) {
- err = -ENOMEM;
- goto exit;
- }
-
- client = &pcf8563->client;
- client->addr = address;
- client->driver = &pcf8563_driver;
- client->adapter = adapter;
-
- strlcpy(client->name, pcf8563_driver.driver.name, I2C_NAME_SIZE);
-
- /* Verify the chip is really an PCF8563 */
- if (kind < 0) {
- if (pcf8563_validate_client(client) < 0) {
- err = -ENODEV;
- goto exit_kfree;
- }
- }
-
- /* Inform the i2c layer */
- if ((err = i2c_attach_client(client)))
- goto exit_kfree;
-
- dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
-
+
+ result = pcf8563_validate_client(client);
+ if (result)
+ return result;
+
rtc = rtc_device_register(pcf8563_driver.driver.name, &client->dev,
&pcf8563_rtc_ops, THIS_MODULE);
-
- if (IS_ERR(rtc)) {
- err = PTR_ERR(rtc);
- goto exit_detach;
- }
+ if (IS_ERR(rtc))
+ return PTR_ERR(rtc);
i2c_set_clientdata(client, rtc);
return 0;
-
-exit_detach:
- i2c_detach_client(client);
-
-exit_kfree:
- kfree(pcf8563);
-
-exit:
- return err;
-}
-
-static int pcf8563_detach(struct i2c_client *client)
-{
- struct pcf8563 *pcf8563 = container_of(client, struct pcf8563, client);
- int err;
- struct rtc_device *rtc = i2c_get_clientdata(client);
-
- if (rtc)
- rtc_device_unregister(rtc);
-
- if ((err = i2c_detach_client(client)))
- return err;
-
- kfree(pcf8563);
-
- return 0;
}
static int __init pcf8563_init(void)
^ permalink raw reply related
* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: Benjamin Herrenschmidt @ 2007-12-03 22:36 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1196715974.13978.176.camel@pmac.infradead.org>
On Mon, 2007-12-03 at 21:06 +0000, David Woodhouse wrote:
> On Tue, 2007-12-04 at 07:45 +1100, Benjamin Herrenschmidt wrote:
> > On Mon, 2007-12-03 at 17:04 +0000, David Woodhouse wrote:
> > > It would be good to migrate the platform code to register RTC devices
> > > directly, but for now this will make them functional enough for most
> > > purposes...
> >
> > Wouldn't it be best to do the other way around at some stage ?
>
> Yes, definitely. We can migrate them one at a time to the RTC class.
>
> > We need to solve the problem of ppc_md. stuff being called by the core
> > in atomic contexts first though.
>
> Where from?
Worst one is time_init :-) Way too early to do any i2c babbling. Then
there used to be something with the NTP writeback, dunno if it's
changed.
Ben.
^ permalink raw reply
* Re: [PATCH] Generic RTC class support for ppc_md.[gs]et_rtc_time
From: David Woodhouse @ 2007-12-03 22:44 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1196721397.13230.236.camel@pasglop>
On Tue, 2007-12-04 at 09:36 +1100, Benjamin Herrenschmidt wrote:
> Worst one is time_init :-) Way too early to do any i2c babbling. Then
> there used to be something with the NTP writeback, dunno if it's
> changed.
Setting the system time seems to be done in the new RTC class by a
late_initcall() in drivers/rtc/hctosys.c. In fact, it could even be done
in userspace.
NTP uses update_persistent_clock() and doesn't seem to have been
'solved' yet for the new RTC class. I don't think there's any particular
reason for it to do i2c stuff in that context though.
--
dwmw2
^ permalink raw reply
* Re: SMP on linux with Microblaze?
From: John Williams @ 2007-12-03 21:18 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <14137760.post@talk.nabble.com>
Hi,
khollan wrote:
>Now that Full Linux can run on Microblaze with the addition of the MMU, are
>there plans to enable Symmetric Multi-Processing of two or more Microblaze
>cores running Linux?
>
>
This isn't really the right list for direct microblaze discussion, but
since you asked.. The challenge with SMP is not an MMU, but cache
coherency. This is why native SMP on dual PPC on V4/V5 is also a
non-starter. It is possible to build software driven snoop/invalidate
mechanisms that might allow a crippled SMP on MicroBlaze, but I think
the performance would be pretty nasty.
The Blackfin Linux team have done some interesting things towards SMP on
non cache-coherent dual CPUs. Basically they do a local cache
invalidation upon acquiring any kernel lock, on the theory that if you
are accessing a shared data structure you will grab a lock first. Thus,
the cache flush will make sure you get the "true" value, not some stale
locally cached result. But, it's still pretty inefficient, and cannot
do things like processor affinity and process migration. Google the
bfin lists for details and patches.
Regards,
John
^ permalink raw reply
* Re: [PATCH 09/28] blk_end_request: changing ps3disk (take 3)
From: Kiyoshi Ueda @ 2007-12-03 22:55 UTC (permalink / raw)
To: Geert.Uytterhoeven
Cc: k-ueda, linux-scsi, linuxppc-dev, jens.axboe, linux-kernel,
linux-ide, dm-devel, bharrosh, j-nomura
In-Reply-To: <Pine.LNX.4.64.0712021032490.29349@anakin>
Hi Geert,
On Sun, 2 Dec 2007 10:34:56 +0100 (CET), Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> wrote:
> On Fri, 30 Nov 2007, Kiyoshi Ueda wrote:
> > This patch converts ps3disk to use blk_end_request().
> ^^^^^^^^^^^^^^^
> Patch subject and description are inconsistent with actual change.
>
> > Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
> > Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
> > ---
> > drivers/block/ps3disk.c | 6 +-----
> > 1 files changed, 1 insertion(+), 5 deletions(-)
> >
> > Index: 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > ===================================================================
> > --- 2.6.24-rc3-mm2.orig/drivers/block/ps3disk.c
> > +++ 2.6.24-rc3-mm2/drivers/block/ps3disk.c
> > @@ -280,11 +280,7 @@ static irqreturn_t ps3disk_interrupt(int
> > }
> >
> > spin_lock(&priv->lock);
> > - if (!end_that_request_first(req, uptodate, num_sectors)) {
> > - add_disk_randomness(req->rq_disk);
> > - blkdev_dequeue_request(req);
> > - end_that_request_last(req, uptodate);
> > - }
> > + __blk_end_request(req, uptodate, num_sectors << 9);
> ^^^^^^^^^^^^^^^^^
Thank you for the comment.
The description meant the blk_end_request family, not actual function,
blk_end_request(). But as you pointed out, it is misleading.
I'll change the description of all related patches.
Thanks,
Kiyoshi Ueda
^ permalink raw reply
* Re: Problem compiling sequoia using DENX kernel. Xenomai-patch required?
From: Wolfgang Denk @ 2007-12-03 23:08 UTC (permalink / raw)
To: niklaus.giger; +Cc: linuxppc-embedded
In-Reply-To: <200712022141.36467.niklaus.giger@member.fsf.org>
In message <200712022141.36467.niklaus.giger@member.fsf.org> you wrote:
>
> I tried with (tags DENX-v2.6.23.9, DENX-v.2.6.23, master) to build a kernel
> for the sequoia board.
> I am using ELDK 4.1. I did a
> git checkout -b copy-master master
> make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g sequoia_defconfig
> make ARCH=powerpc CROSS_COMPILE=ppc_4xx- CFLAGS=-g zImage
The ARCH=powerpc is the "interesting" part here.
> First I stumbled about problem compiling arch/powerpc/platforms/44x/ppc4xx*.c
> file with errors like
> arch/powerpc/platforms/44x/ppc4xx-pci.c: In function 'ppc4xx_setup_pci':
> arch/powerpc/platforms/44x/ppc4xx-pci.c:62: sorry, unimplemented: inlining
> failed in call to 'pci_cfg_out': function body not available
> arch/powerpc/platforms/44x/ppc4xx-pci.c:98: sorry, unimplemented: called from
> here
There are many moving targets in the ARCH=powerpc hemisphere for 4xx
systems...
> I thought that denx compiled images for the sequoia using 2.6.23.
Yes, we do. But stable support is only available with the arch/ppc
tree yet.
> Do they only work after having applied the Xenomai patch? Because if I apply
No.
> the Xenomai patch, the kernel compiles cleanly. In this case I think it
That's just lucky coincidence...
> would be nice to get somewhere a hint (or did I missed it somewhere) that
> this is a requirement. I lost quite a few hours as I wanted to first compile
> a "normal" kernel and afterwars apply the xenomai patch.
I'm afraid "normal" here still means arch/ppc - hopefully for not
long any more. Note: a matching Xenomai patch for arch/ppc will be in
Xenomai 2.4 when it comes out in a few days.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Good manners are the settled medium of social, as specie is of
commercial, life; returns are equally expected for both.
- Lord Chesterfield _Letters to his Son_, 25 December 1753
^ permalink raw reply
* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-03 23:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203212032.23543.3453.stgit@terra.home>
On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl 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.
May I ask why you want to modify the i2c layer instead of keeping the
OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
PPC-specific code, since otherwise you might end up with confused i2c
driver writers that make up their own OF names without knowing for sure
that's what will be used. No?
I recently posted (and asked Paulus to pull) a patch where I consolidate
the fsl_soc mapping code so I can also use that on pasemi, and modified
the pasemi platform code to setup the board_info from the device tree
accordingly.
Finally, whitespace is broken in several of your patches.
-Olof
^ permalink raw reply
* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Jon Smirl @ 2007-12-03 23:52 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203233752.GA7041@lixom.net>
On 12/3/07, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl 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.
>
> May I ask why you want to modify the i2c layer instead of keeping the
> OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
> PPC-specific code, since otherwise you might end up with confused i2c
> driver writers that make up their own OF names without knowing for sure
> that's what will be used. No?
Audio codecs have the same problem. That table is could end up with
hundreds of entries. The right place to store the mappings is in the
device driver for the device.
A side effect of moving the mappings into the device drivers is that
the correct i2c drivers can be automatically loaded by the kernel.
This lets you make distro CDs with all of the i2c drivers on disk and
the device tree will cause insmod of the correct ones.
I'm working on a parallel patch for Alsa SOC but it isn't ready yet.
>
> I recently posted (and asked Paulus to pull) a patch where I consolidate
> the fsl_soc mapping code so I can also use that on pasemi, and modified
> the pasemi platform code to setup the board_info from the device tree
> accordingly.
>
> Finally, whitespace is broken in several of your patches.
>
>
> -Olof
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Scott Wood @ 2007-12-03 23:51 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, i2c
In-Reply-To: <20071203233752.GA7041@lixom.net>
Olof Johansson wrote:
> On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl 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.
>
> May I ask why you want to modify the i2c layer instead of keeping the
> OF->i2c driver mapping in PPC code?
Because it doesn't belong there -- at the least, it should be in
drivers/of. But putting it in the driver is better, IMHO.
> It seems simpler to keep it in the
> PPC-specific code, since otherwise you might end up with confused i2c
> driver writers that make up their own OF names without knowing for sure
> that's what will be used. No?
How is this different from drivers that have of_platform bindings?
That said, there should probably be some sort of tag to indicate the
namespace being matched against (OF, Linux, etc), to avoid matching an
OF device with a non-OF name (or vice versa).
> I recently posted (and asked Paulus to pull) a patch where I consolidate
> the fsl_soc mapping code so I can also use that on pasemi, and modified
> the pasemi platform code to setup the board_info from the device tree
> accordingly.
Having just one bit i2c glue code for arch/powerpc is certainly an
improvement over the current situation, but it's not really powerpc
specific. Just because other architectures don't use it now doesn't
mean they won't in the future -- and I don't like the "we'll move it
when they do" argument because I want to make it easy for other
architectures to decide to use it. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 0/4] Series to add device tree naming to i2c
From: Olof Johansson @ 2007-12-04 0:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, paulus, i2c
In-Reply-To: <9e4733910712031552j36efd4b2u933f0f4e9832a003@mail.gmail.com>
On Mon, Dec 03, 2007 at 06:52:06PM -0500, Jon Smirl wrote:
> On 12/3/07, Olof Johansson <olof@lixom.net> wrote:
> > On Mon, Dec 03, 2007 at 04:20:32PM -0500, Jon Smirl 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.
> >
> > May I ask why you want to modify the i2c layer instead of keeping the
> > OF->i2c driver mapping in PPC code? It seems simpler to keep it in the
> > PPC-specific code, since otherwise you might end up with confused i2c
> > driver writers that make up their own OF names without knowing for sure
> > that's what will be used. No?
>
> Audio codecs have the same problem. That table is could end up with
> hundreds of entries. The right place to store the mappings is in the
> device driver for the device.
>
> A side effect of moving the mappings into the device drivers is that
> the correct i2c drivers can be automatically loaded by the kernel.
> This lets you make distro CDs with all of the i2c drivers on disk and
> the device tree will cause insmod of the correct ones.
Ok, good enough reasons. I'll back out my i2c commits and wait for yours
to settle, then add the pasemi stuff in the same way.
(Whitespace comments still apply).
-Olof
^ permalink raw reply
* Re: Please pull pasemi.git for-2.6.25 branch
From: Olof Johansson @ 2007-12-04 0:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20071203050446.GC24492@lixom.net>
On Sun, Dec 02, 2007 at 11:04:47PM -0600, Olof Johansson wrote:
> Paul,
>
> Please do:
>
> git pull \
> git://git.kernel.org/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.25
>
> For the following patches queued up for 2.6.25. All but one are PA
> Semi-specific (the i2c boardinfo consolidation that's a pre-req for the
> platform-specific one).
Sorry for the churn here, I hope you haven't pulled yet.
Based on today's i2c patches from Jon Smirl, it makes more sense for me
to hold off on my i2c changes and make them on top of his work once that
has been merged.
I've backed out and rebased the patch set, new shortlog and diffstat:
arch/powerpc/platforms/pasemi/Kconfig | 2
arch/powerpc/platforms/pasemi/cpufreq.c | 19 +++++-
arch/powerpc/platforms/pasemi/gpio_mdio.c | 94 ++++++++++++++++++------------
arch/powerpc/platforms/pasemi/pasemi.h | 6 +
arch/powerpc/platforms/pasemi/powersave.S | 11 +++
arch/powerpc/platforms/pasemi/setup.c | 16 ++++-
drivers/char/hw_random/Kconfig | 2
drivers/char/hw_random/pasemi-rng.c | 7 --
drivers/edac/pasemi_edac.c | 4 -
9 files changed, 111 insertions(+), 50 deletions(-)
Olof Johansson (5):
[POWERPC] pasemi: clean up mdio_gpio a bit
[POWERPC] pasemi: Broaden specific references to 1682M
[POWERPC] pasemi: Don't enter powersaving states from elevated astates
[POWERPC] pasemi: Move cpus to hold loop before restart
[POWERPC] pasemi: Fix module information for gpio-mdio
-Olof
^ permalink raw reply
* Re: [PATCH 1/5] PowerPC 74xx: Katana Qp device tree
From: David Gibson @ 2007-12-04 0:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1196709993.7735.3.camel@ld0161-tx32>
On Mon, Dec 03, 2007 at 01:26:34PM -0600, Jon Loeliger wrote:
> On Sun, 2007-12-02 at 19:50, David Gibson wrote:
>
> > > + clock-frequency = <7f28155>; /* 133.333333 MHz */
> > You can use <d# 133333333> to avoid the ugly hex.
>
> Better still, blaze a new trail, convert it to /dts-v1/ and
> use clock-frequency = <133333333> straight up!
Hrm.. probably best to wait for dtc to go into the kernel for that.
--
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
* dtc: Fix uninitialized use of structure_ok
From: David Gibson @ 2007-12-04 0:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
My rework of the tree checking code introduced a potentially nasty bug
- it uses the structure_ok variable uninitialized. This patch fixes
the problem. It's a fairly ugly bandaid approach, but the ugly will
disappear once future patches have folded the semantic checks into the
new framework.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/checks.c
===================================================================
--- dtc.orig/checks.c 2007-12-03 17:14:27.000000000 +1100
+++ dtc/checks.c 2007-12-03 17:14:39.000000000 +1100
@@ -270,8 +270,12 @@ static struct check *check_table[] = {
&phandle_references,
};
-void process_checks(int force, struct node *dt)
+int check_semantics(struct node *dt, int outversion, int boot_cpuid_phys);
+
+void process_checks(int force, struct boot_info *bi,
+ int checkflag, int outversion, int boot_cpuid_phys)
{
+ struct node *dt = bi->dt;
int i;
int error = 0;
@@ -292,6 +296,16 @@ void process_checks(int force, struct no
"output forced\n");
}
}
+
+ if (checkflag) {
+ if (error) {
+ fprintf(stderr, "Warning: Skipping semantic checks due to structural errors\n");
+ } else {
+ if (!check_semantics(bi->dt, outversion,
+ boot_cpuid_phys))
+ fprintf(stderr, "Warning: Input tree has semantic errors\n");
+ }
+ }
}
/*
Index: dtc/dtc.c
===================================================================
--- dtc.orig/dtc.c 2007-12-03 17:14:27.000000000 +1100
+++ dtc/dtc.c 2007-12-03 17:14:39.000000000 +1100
@@ -119,7 +119,6 @@ int main(int argc, char *argv[])
FILE *outf = NULL;
int outversion = DEFAULT_FDT_VERSION;
int boot_cpuid_phys = 0xfeedbeef;
- int structure_ok;
quiet = 0;
reservenum = 0;
@@ -193,17 +192,7 @@ int main(int argc, char *argv[])
if (! bi || ! bi->dt)
die("Couldn't read input tree\n");
- process_checks(force, bi->dt);
-
- if (check) {
- if (!structure_ok) {
- fprintf(stderr, "Warning: Skipping semantic checks due to structural errors\n");
- } else {
- if (!check_semantics(bi->dt, outversion,
- boot_cpuid_phys))
- fprintf(stderr, "Warning: Input tree has semantic errors\n");
- }
- }
+ process_checks(force, bi, check, outversion, boot_cpuid_phys);
if (streq(outname, "-")) {
outf = stdout;
Index: dtc/dtc.h
===================================================================
--- dtc.orig/dtc.h 2007-12-03 17:15:04.000000000 +1100
+++ dtc/dtc.h 2007-12-03 17:15:14.000000000 +1100
@@ -236,8 +236,8 @@ struct boot_info *build_boot_info(struct
/* Checks */
-void process_checks(int force, struct node *dt);
-int check_semantics(struct node *dt, int outversion, int boot_cpuid_phys);
+void process_checks(int force, struct boot_info *bi,
+ int checkflag, int outversion, int boot_cpuid_phys);
/* Flattened trees */
--
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: current ARCH=powerpc for v2pro.
From: Stephen Neuendorffer @ 2007-12-04 0:48 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711302239u56a264ddyaaad454bc00bb4dd@mail.gmail.com>
I tried that, which essentially differed from what I was trying in that
interrupts were turned off.
It fails in the same way as before.
I've booted ARCH=3Dppc from your tree on the exact same hardware design,
and as near as I can tell, the code that runs in the kernel proper up to
the point where I see the machine check is almost identical.
The machine check (a trap into the Machine Check handler at 0x200)
occurs at a nondeterministic point during the execution of memset_io in
early_init.
In the kernel I have, _bss_start is c02c8000, and these are the
registers in the trap handler on two different runs of the kernel:
r3: c02c80cc r5: 00022874
r3: c02c8248 r5: 000226f4
r3 is the current point being initialized, and r5 is the count remaining
in the .bss.
So, what would cause a machine check in the middle of a loop, in the
middle of the almost the simplest code absolutely possible, and not on
an obvious memory boundary?
Steve
> -----Original Message-----
> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On=20
> Behalf Of Grant Likely
> Sent: Friday, November 30, 2007 10:40 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded
> Subject: Re: current ARCH=3Dpowerpc for v2pro.
>=20
> On 11/30/07, Stephen Neuendorffer=20
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Grant,
> >
> > I'm trying to bring up your arch/powerpc work, using a compiled in
> > device tree. I added this:
> >
> <snip>
> >
> > Which seems bizarre, because that code is very simple. I'm guessing
> > that something in the memory configuration is wierd (or maybe
> > zImage.virtex is not the right way to do this?) but I'm a=20
> little lost
> > where to look from here. I also tried it with both=20
> paulus_master and
> > your virtex-for-2.6.24 branch.
>=20
>=20
> I've got a patch that adds 'raw' image support (originally written by
> Scott Wood) which somewhat works for booting (but not entirely; I
> haven't had time to dig into it properly yet). It's not suitable to
> go into mainline yet. I'll try to get the patch out to my tree this
> evening... actually I've been trying to get my tree pushed out all
> today, but other things keep coming up. :-)
>=20
> <several hours after I wrote the above>
>=20
> Okay, I pushed my current patch set out to the master branch of my
> linux-2.6-virtex tree. Give it a whirl. It's not perfect, but it
> should be usable for booting.
>=20
> Cheers,
> g.
>=20
> --=20
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>=20
>=20
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: make 64K huge pages more reliable
From: David Gibson @ 2007-12-04 0:28 UTC (permalink / raw)
To: Chris Snook; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <47547A79.2060206@redhat.com>
On Mon, Dec 03, 2007 at 04:51:53PM -0500, Chris Snook wrote:
> David Gibson wrote:
> > On Tue, Nov 27, 2007 at 11:03:16PM -0600, Jon Tollefson wrote:
> >> This patch adds reliability to the 64K huge page option by making use of
> >> the PMD for 64K huge pages when base pages are 4k. So instead of a 12
> >> bit pte it would be 7 bit pmd and a 5 bit pte. The pgd and pud offsets
> >> would continue as 9 bits and 7 bits respectively. This will allow the
> >> pgtable to fit in one base page. This patch would have to be applied
> >> after part 1.
> >
> > Hrm.. shouldn't we just ban 64K hugepages on a 64K base page size
> > setup? There's not a whole lot of point to it, after all...
> >
>
> Actually, it sounds to me like an ideal way to benchmark the
> efficiency of the hugepage implementation and VM effects, without
> the TLB performance obscuring the results.
Well.. maybe. The pagetable format, and therefore the hugepage size,
will affect the size of that overhead so even with this its not clear
how meaningful test results would be.
> I agree that it's not something people will want to do very often,
> but the same can be said about quite a lot of strange things that we
> allow just because there's no fundamental reason why they cannot be.
Hrm, yeah I guess, since this was a fairly simple fix. I still don't
think it's worth jumping through too many hoops to make this possible,
though.
--
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] Improved documentation of device tree 'ranges'.
From: David Gibson @ 2007-12-04 0:52 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-dev
In-Reply-To: <20071203174403.C740719B0073@mail119-sin.bigfish.com>
On Mon, Dec 03, 2007 at 09:45:03AM -0800, Stephen Neuendorffer wrote:
> I was misled by the prior language. I've attempted to clarify how
> 'ranges' are used, in particular, how to get a 1:1 mapping.
Sounds good, except for one detail. I think we should avoid using
the "1:1" terminology: to a mathematician, at least, "1:1" is much
weaker than "identity mapping" which is what an empty ranges actually
implies.
So, I think we should explicitly say that an empty ranges implies that
parent bus address space is identical to child bus address space.
> Signed-off-by: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
> index e9a3cb1..aad8bf5 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -711,13 +711,14 @@ define a bus type with a more complex address format, including things
> like address space bits, you'll have to add a bus translator to the
> prom_parse.c file of the recent kernels for your bus type.
>
> -The "reg" property only defines addresses and sizes (if #size-cells
> -is non-0) within a given bus. In order to translate addresses upward
> +The "reg" property only defines addresses and sizes (if #size-cells is
> +non-0) within a given bus. In order to translate addresses upward
> (that is into parent bus addresses, and possibly into CPU physical
> addresses), all busses must contain a "ranges" property. If the
> "ranges" property is missing at a given level, it's assumed that
> -translation isn't possible. The format of the "ranges" property for a
> -bus is a list of:
> +translation isn't possible, i.e., the registers are not visible on the
> +parent bus. The format of the "ranges" property for a bus is a list
> +of:
>
> bus address, parent bus address, size
>
> @@ -735,6 +736,8 @@ fit in a single 32-bit word. New 32-bit powerpc boards should use a
> 1/1 format, unless the processor supports physical addresses greater
> than 32-bits, in which case a 2/1 format is recommended.
>
> +Alternatively, the "ranges" property may be empty, indicating that the
> +registers are visible on the parent bus, with 1:1 address translation.
>
> 2) Note about "compatible" properties
> -------------------------------------
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox