* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 23:18 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c
In-Reply-To: <200802192355.17707.arnd@arndb.de>
Arnd Bergmann wrote:
> On Tuesday 19 February 2008, Stefan Roese wrote:
>
>> On Tuesday 19 February 2008, Jean Delvare wrote:
>>
>>> With this Kconfig change, "make menuconfig" lets me select the
>>> i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
>>> that you want to restrict the build to PPC machines somehow, or at
>>> least make sure that either IBM_OCP or OF support is present.
>>>
>> How about this:
>>
>> - depends on IBM_OCP
>> + depends on 4xx
>>
>
> I think we should allow it to be built on other platforms as well,
> as long as they have of_platform_device support.
>
> The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
> even though it's managed by the firmware and we probably don't want
> to use it at this time, someone could use the same chip in a new
> design and actually do that.
>
> In general, I also like to make it possible to enable drivers just
> for the benefit of compile testing, even for stuff that you can't
> find in any existing HW configuration, so as long as it builds on
> a platform, I think we shouldn't forbid it:
>
> - depends on IBM_OCP
> + depends on IBM_OCP || PPC_MERGE
>
>
I have no problem with this change. If everybody agrees, I can respin
the patch.
Cheers,
Sean
^ permalink raw reply
* Re: Difference between vmlinux and vmlinux.bin
From: Timur Tabi @ 2008-02-19 23:11 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, lkml
In-Reply-To: <47BB5D82.6070806@freescale.com>
Timur Tabi wrote:
> So when Kbuild creates vmlinux.bin, what does it do besides extract the PT_LOAD
> segment?
Never mind, I was doing something stupid which was trashing my in-memory copy of
vmlinux.bin.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-02-19 22:55 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jean Delvare, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <200802190959.41253.sr@denx.de>
On Tuesday 19 February 2008, Stefan Roese wrote:
> On Tuesday 19 February 2008, Jean Delvare wrote:
> >
> > With this Kconfig change, "make menuconfig" lets me select the
> > i2c-ibm_iic driver on x86_64, but it fails to build horribly. I think
> > that you want to restrict the build to PPC machines somehow, or at
> > least make sure that either IBM_OCP or OF support is present.
>=20
> How about this:
>=20
> -=A0=A0=A0=A0=A0=A0=A0depends on IBM_OCP
> +=A0=A0=A0=A0=A0=A0=A0depends on 4xx
I think we should allow it to be built on other platforms as well,
as long as they have of_platform_device support.
The Axon south bridge used on IBMs QS21 blade probably has an ibm_iic,
even though it's managed by the firmware and we probably don't want
to use it at this time, someone could use the same chip in a new
design and actually do that.
In general, I also like to make it possible to enable drivers just
for the benefit of compile testing, even for stuff that you can't
find in any existing HW configuration, so as long as it builds on
a platform, I think we shouldn't forbid it:
=2D depends on IBM_OCP
+ depends on IBM_OCP || PPC_MERGE
Arnd <><
^ permalink raw reply
* Difference between vmlinux and vmlinux.bin
From: Timur Tabi @ 2008-02-19 22:51 UTC (permalink / raw)
To: linuxppc-dev, lkml
I'm trying to write an ELF loader for a PowerPC vmlinux, and I've come across
something I don't understand.
In vmlinux, there are two Program Segments, the first of which is PT_LOAD. What
is the difference between the block of data inside this section, and
vmlinux.bin? I thought that vmlinux.bin is nothing more than the PT_LOAD
section of vmlinux. However, when I do a memcmp, there is a difference at
offset 3080192 (vmlinux.bin is 4874532 bytes long):
memcmp @ 3080192 125 != 31
32 bytes @ 412f0000:
7d 20 00 28 31 29 ff ff 7d 20 01 2d 40 a2 ff f4
2f 89 00 00 41 9e 01 9c 7f e3 fb 78 4b d7 b0 75
32 bytes @ 42300000:
1f 8b 08 08 b7 e7 7a 44 00 03 62 75 73 79 62 6f
78 2d 31 2e 31 2e 33 2e 69 6d 67 00 ec 5d 7d 74
So when Kbuild creates vmlinux.bin, what does it do besides extract the PT_LOAD
segment?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: RTC woes
From: Clemens Koller @ 2008-02-19 22:30 UTC (permalink / raw)
To: Marc LeFevre; +Cc: linuxppc-embedded
In-Reply-To: <06cb01c87315$5dad6010$f30213ac@isd.cypress.com>
Marc LeFevre schrieb:
> I’m new to the list.
Welcome! :-)
> I have an e500-based embedded Linux system running
> a 2.6.22 kernel. I have a PCF8563T i2c based RTC chip attached to the
> PPC i2c bus. In my kernel config file I have selected
> CONFIG_RTC_INTF_DEV=y and CONFIG_RTC_DRV_PCF8563=y. I do a mknod for
> /dev/rtc as c 10 135 (standard Linux) and link /dev/rtc0 to it.
>
> When I boot, get the following message:
>
> drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
2.6.22.x and 2.6.23.x i2c rtc code was quite messy around PCF8563.
> 3) Does the PPC have some quirks regarding i2c operation that are
> at the root of this problem?
The RTC subsystem was improved quite a bit lately. Try 2.6.24' powerpc
architecture with a proper device tree instead. It works over here on
mpc8540 / mpc8548 whereas the older ones were just a waste of time.
Regards,
Clemens
^ permalink raw reply
* Re: [PATCH 1/3] Fix Unlikely(x) == y
From: Nick Piggin @ 2008-02-19 22:25 UTC (permalink / raw)
To: Andi Kleen
Cc: Roel Kluin, lkml, Willy Tarreau, linuxppc-dev, cbe-oss-dev,
Arjan van de Ven
In-Reply-To: <20080219095702.GA6940@one.firstfloor.org>
On Tuesday 19 February 2008 20:57, Andi Kleen wrote:
> On Tue, Feb 19, 2008 at 08:46:46PM +1100, Nick Piggin wrote:
> > I think it was just a simple context switch benchmark, but not lmbench
> > (which I found to be a bit too variable). But it was a long time ago...
>
> Do you still have it?
>
> I thought about writing my own but ended up being too lazy for that @)
Had a quick look but couldn't find it. It was just two threads running
and switching to each other with a couple of mutexes or yield. If I
find it, then I'll send it over.
> > > > Actually one thing I don't like about gcc is that I think it still
> > > > emits cmovs for likely/unlikely branches,
> > >
> > > That's -Os.
> >
> > And -O2 and -O3, on the gccs that I'm using, AFAIKS.
>
> Well if it still happens on gcc 4.2 with P4 tuning you should
> perhaps open a gcc PR. They tend to ignore these bugs mostly in
> my experience, but sometimes they act on them.
I'm not sure about P4 tuning... But even IMO it should not on
predictable branches too much for any (especially OOOE) CPU.
> > > > which is silly (the gcc developers
> > >
> > > It depends on the CPU. e.g. on K8 and P6 using CMOV if possible
> > > makes sense. P4 doesn't like it though.
> >
> > If the branch is completely predictable (eg. annotated), then I
> > think branches should be used anyway. Even on well predicted
> > branches, cmov is similar speed on microbenchmarks, but it will
> > increase data hazards I think, so it will probably be worse for
> > some real world situations.
>
> At least the respective optimization manuals say they should be used.
> I presume they only made this recommendation after some extensive
> benchmarking.
What I have seen is that they tell you definitely not to use it for
predictable branches. Eg. the Intel optimization manual says
Use the setcc and cmov instructions to eliminate unpredictable
conditional branches where possible. Do not do this for predictable
branches. Do not use these instructions to eliminate all
unpredictable conditional branches, because using these instructions
will incur execution overhead due to executing both paths of a
conditional branch. In addition, converting conditional branches to
cmovs or setcc trades control-flow dependence for data dependence
and restricts the capability of the out-of-order engine.
> > But a likely branch will be _strongly_ predicted to be taken,
> > wheras a lot of the gcc heuristics simply have slightly more or
> > slightly less probability. So it's not just a question of which
> > way is more likely, but also _how_ likely it is to go that way.
>
> Yes, but a lot of the heuristics are pretty strong (>80%) and gcc will
> act on them unless it has a very strong contra cue. And that should
> normally not be the case.
True, but if you know a branch is 99%+, then use of likely/unlikely
can still be a good idea. 80% may not be enough to choose a branch
over a cmov for example.
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 22:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: Jean Delvare, linuxppc-dev, i2c
In-Reply-To: <200802190959.41253.sr@denx.de>
Stefan Roese wrote:
> How about this:
>
> - depends on IBM_OCP
> + depends on 4xx
>
That's what I did, great minds think alike ;) But the email does not
seem to have come through, so I will repost the patch. If you already
got an email with the above patch, you can ignore this one ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
--- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c 2008-02-18 16:36:30.000000000 -0500
+++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-02-19 16:46:35.000000000 -0500
@@ -6,6 +6,9 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
* Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -657,6 +665,7 @@
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -828,5 +837,181 @@
ocp_unregister_driver(&ibm_iic_driver);
}
+#else /* !CONFIG_IBM_OCP */
+
+static int __devinit iic_request_irq(struct of_device *ofdev,
+ struct ibm_iic_private *dev)
+{
+ struct device_node *np = ofdev->node;
+ int irq;
+
+ if (iic_force_poll)
+ return NO_IRQ;
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ dev_err(&ofdev->dev, "irq_of_parse_and_map failed\n");
+ return NO_IRQ;
+ }
+
+ /* Disable interrupts until we finish initialization, assumes
+ * level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(irq, iic_handler, 0, "IBM IIC", dev)) {
+ dev_err(&ofdev->dev, "request_irq %d failed\n", irq);
+ /* Fallback to the polling mode */
+ return NO_IRQ;
+ }
+
+ return irq;
+}
+
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private *dev;
+ struct i2c_adapter *adap;
+ const u32 *indexp, *freq;
+ int ret;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&ofdev->dev, "failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ indexp = of_get_property(np, "index", NULL);
+ if (!indexp) {
+ dev_err(&ofdev->dev, "no index specified\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ dev->idx = *indexp;
+
+ dev->vaddr = of_iomap(np, 0);
+ if (dev->vaddr == NULL) {
+ dev_err(&ofdev->dev, "failed to iomap device\n");
+ ret = -ENXIO;
+ goto error_cleanup;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ dev->irq = iic_request_irq(ofdev, dev);
+ if (dev->irq == NO_IRQ)
+ dev_warn(&ofdev->dev, "using polling mode\n");
+
+ /* Board specific settings */
+ if (iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+
+ freq = of_get_property(np, "clock-frequency", NULL);
+ if (freq == NULL) {
+ freq = of_get_property(np->parent, "clock-frequency", NULL);
+ if (freq == NULL) {
+ dev_err(&ofdev->dev, "Unable to get bus frequency\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ dev_dbg(&ofdev->dev, "clckdiv = %d\n", dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strlcpy(adap->name, "IBM IIC", sizeof(adap->name));
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->timeout = 1;
+ adap->nr = dev->idx;
+
+ ret = i2c_add_numbered_adapter(adap);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "failed to register i2c adapter\n");
+ goto error_cleanup;
+ }
+
+ dev_info(&ofdev->dev, "using %s mode\n",
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+error_cleanup:
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ if (dev->vaddr)
+ iounmap(dev->vaddr);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private *dev = dev_get_drvdata(&ofdev->dev);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ i2c_del_adapter(&dev->adap);
+
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+ kfree(dev);
+
+ return 0;
+}
+
+static const struct of_device_id ibm_iic_match[] = {
+ { .compatible = "ibm,iic-405ex", },
+ { .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440gp", },
+ { .compatible = "ibm,iic-440gpx", },
+ { .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver = {
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = __devexit_p(iic_remove),
+};
+
+static int __init iic_init(void)
+{
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+#endif /* CONFIG_IBM_OCP */
+
module_init(iic_init);
module_exit(iic_exit);
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b61f56b..bda87a0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -244,7 +244,7 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
+ depends on 4xx
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
^ permalink raw reply related
* BUG: scheduling while atomic
From: John Linn @ 2008-02-19 22:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
I'm using 2.6.24-rc8 on a PPC 440 and getting this error. I've also seen
another form of it when doing Telnet.
In this case, I'm doing a copy of a file on an NFS mount.
Any help would be appreciated.
Thanks,
John Linn
# cp ftptest2 ftptest2_copied
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[cfc89ec0] [c000725c] show_stack+0x4c/0x174 (unreliable)
[cfc89ef0] [c0016880] __schedule_bug+0x54/0x68
[cfc89f10] [c01df464] schedule+0x50/0x300
[cfc89f40] [c0002374] recheck+0x0/0x24
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[cfc89c50] [c000725c] show_stack+0x4c/0x174 (unreliable)
[cfc89c80] [c0016880] __schedule_bug+0x54/0x68
[cfc89ca0] [c01df464] schedule+0x50/0x300
[cfc89cd0] [c01df744] io_schedule+0x30/0x54
[cfc89cf0] [c003d79c] sync_page+0x44/0x58
[cfc89d00] [c01dfaf0] __wait_on_bit_lock+0x68/0xc8
[cfc89d20] [c003da28] __lock_page+0x64/0x78
[cfc89d60] [c00402d0] do_generic_mapping_read+0x218/0x418
[cfc89db0] [c00405fc] generic_file_aio_read+0x12c/0x1a8
[cfc89e00] [c00cba0c] nfs_file_read+0xf0/0x104
[cfc89e30] [c005b3d4] do_sync_read+0xb8/0x10c
[cfc89ef0] [c005b840] vfs_read+0xc0/0x154
[cfc89f10] [c005c3bc] sys_read+0x4c/0x8c
[cfc89f40] [c0001960] ret_from_syscall+0x0/0x3c
BUG: scheduling while atomic: cp/355/0x0ffffefe
Call Trace:
[-- Attachment #2: Type: text/html, Size: 11524 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-02-19 21:58 UTC (permalink / raw)
To: Jean Delvare; +Cc: LinuxPPC-dev, i2c
In-Reply-To: <20080219092321.1fed233d@hyperion.delvare>
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
--- for-2.6.25/drivers/i2c/busses/orig-i2c-ibm_iic.c 2008-02-18 16:36:30.000000000 -0500
+++ for-2.6.25/drivers/i2c/busses/i2c-ibm_iic.c 2008-02-19 16:46:35.000000000 -0500
@@ -6,6 +6,9 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
* Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -657,6 +665,7 @@
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -828,5 +837,181 @@
ocp_unregister_driver(&ibm_iic_driver);
}
+#else /* !CONFIG_IBM_OCP */
+
+static int __devinit iic_request_irq(struct of_device *ofdev,
+ struct ibm_iic_private *dev)
+{
+ struct device_node *np = ofdev->node;
+ int irq;
+
+ if (iic_force_poll)
+ return NO_IRQ;
+
+ irq = irq_of_parse_and_map(np, 0);
+ if (irq == NO_IRQ) {
+ dev_err(&ofdev->dev, "irq_of_parse_and_map failed\n");
+ return NO_IRQ;
+ }
+
+ /* Disable interrupts until we finish initialization, assumes
+ * level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(irq, iic_handler, 0, "IBM IIC", dev)) {
+ dev_err(&ofdev->dev, "request_irq %d failed\n", irq);
+ /* Fallback to the polling mode */
+ return NO_IRQ;
+ }
+
+ return irq;
+}
+
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private *dev;
+ struct i2c_adapter *adap;
+ const u32 *indexp, *freq;
+ int ret;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ dev_err(&ofdev->dev, "failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ indexp = of_get_property(np, "index", NULL);
+ if (!indexp) {
+ dev_err(&ofdev->dev, "no index specified\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ dev->idx = *indexp;
+
+ dev->vaddr = of_iomap(np, 0);
+ if (dev->vaddr == NULL) {
+ dev_err(&ofdev->dev, "failed to iomap device\n");
+ ret = -ENXIO;
+ goto error_cleanup;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ dev->irq = iic_request_irq(ofdev, dev);
+ if (dev->irq == NO_IRQ)
+ dev_warn(&ofdev->dev, "using polling mode\n");
+
+ /* Board specific settings */
+ if (iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+
+ freq = of_get_property(np, "clock-frequency", NULL);
+ if (freq == NULL) {
+ freq = of_get_property(np->parent, "clock-frequency", NULL);
+ if (freq == NULL) {
+ dev_err(&ofdev->dev, "Unable to get bus frequency\n");
+ ret = -EINVAL;
+ goto error_cleanup;
+ }
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ dev_dbg(&ofdev->dev, "clckdiv = %d\n", dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strlcpy(adap->name, "IBM IIC", sizeof(adap->name));
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->timeout = 1;
+ adap->nr = dev->idx;
+
+ ret = i2c_add_numbered_adapter(adap);
+ if (ret < 0) {
+ dev_err(&ofdev->dev, "failed to register i2c adapter\n");
+ goto error_cleanup;
+ }
+
+ dev_info(&ofdev->dev, "using %s mode\n",
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+error_cleanup:
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ if (dev->vaddr)
+ iounmap(dev->vaddr);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private *dev = dev_get_drvdata(&ofdev->dev);
+
+ dev_set_drvdata(&ofdev->dev, NULL);
+
+ i2c_del_adapter(&dev->adap);
+
+ if (dev->irq != NO_IRQ) {
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+ kfree(dev);
+
+ return 0;
+}
+
+static const struct of_device_id ibm_iic_match[] = {
+ { .compatible = "ibm,iic-405ex", },
+ { .compatible = "ibm,iic-405gp", },
+ { .compatible = "ibm,iic-440gp", },
+ { .compatible = "ibm,iic-440gpx", },
+ { .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver = {
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = __devexit_p(iic_remove),
+};
+
+static int __init iic_init(void)
+{
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+
+static void __exit iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+#endif /* CONFIG_IBM_OCP */
+
module_init(iic_init);
module_exit(iic_exit);
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index b61f56b..bda87a0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -244,7 +244,7 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
+ depends on 4xx
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
^ permalink raw reply related
* Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Benjamin Herrenschmidt @ 2008-02-19 20:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200802190911.56901.bjorn.helgaas@hp.com>
> > That is, whatever the arch code decides to use to decide whether
> > resources are assigned by firmware or by the first pass assignment code
> > or not and collide or not, once that phase is finished (which is the
> > case when calling pcibios_enable_device(), having the resource in the
> > resource-tree or not is, I believe, the proper way to test whether it's
> > a useable resource.
>
> So should x86 adopt that collision check? I don't hear anything about
> actual architecture differences that are behind this implementation
> difference.
Well, on powerpc we do allow under some circumstances a 0 start value
in BARs, which is why I wanted to use a different check.
Ben.
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Kumar Gala @ 2008-02-19 20:19 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BB0ADE.60501@freescale.com>
On Feb 19, 2008, at 10:59 AM, Jon Loeliger wrote:
> Marco Stornelli wrote:
>
>> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18
>> if it
>> could help. What do you think about it? Do you think this problem
>> could
>> be not present in 2.6.24?
>
> I have no idea there, honestly. Sorry.
As Jon said, try 2.6.24 and see if it has an issue, if so we can look
at helping. if not, you know you need to back port the fixes.
- k
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: Josh Boyer @ 2008-02-19 20:17 UTC (permalink / raw)
To: Scott Wood; +Cc: maxime louvel, linuxppc-embedded
In-Reply-To: <47BB177E.1070602@freescale.com>
On Tue, 19 Feb 2008 11:53:02 -0600
Scott Wood <scottwood@freescale.com> wrote:
> maxime louvel wrote:
> > Hi again,
> >
> > this time I have tried to compile the kernel, with an embedded compiler
> > on the board.
> > here is the result...
> >
> > ....
> > BOOTAS arch/powerpc/boot/ps3-hvcall.o
> > BOOTCC arch/powerpc/boot/ps3.o
> > BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> > BOOTCC arch/powerpc/boot/cuboot-8xx.o
> > BOOTCC arch/powerpc/boot/cuboot-pq2.o
> > BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> > BOOTCC arch/powerpc/boot/treeboot-walnut.o
> > Assembler messages:
> > Error: Internal assembler error for instruction icbt
> > Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
> > ppc_setup_opcodes
> > Please report this bug.
> > make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> > make[1]: *** [uImage] Error 2
> > make: *** [sub-make] Error 2
>
> That's a bug in older toolchains, which is aggravated by a misguided
> policy that we build all wrapper platforms, always. Either use a newer
> toolchain, or remove treeboot-walnut from arch/powerpc/boot/Makefile.
It would be good to know what versions of binutils and gcc are being
used though.
josh
^ permalink raw reply
* [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-19 19:51 UTC (permalink / raw)
To: davem; +Cc: sparclinux, linuxppc-dev, linux-kernel
If we add to an empty lmb region with a non-zero base we will not coalesce
the number of regions down to one. This causes problems on ppc32 for the
memory region as its assumed to only have one region.
We can fix this easily by causing the initial add to replace the dummy
region.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Fix a bug the initial patch introduced if we have a region that gets added
at the beginning of the list we wouldn't actually add it.
Dave can you replace the patch in you tree with this one.
arch/powerpc/mm/lmb.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 4ce23bc..4bf8f19 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -141,6 +141,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
unsigned long coalesced = 0;
long adjacent, i;
+ if ((rgn->cnt == 1) && (rgn->region[0].size == 0)) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ return 0;
+ }
+
/* First try and coalesce this LMB with another. */
for (i=0; i < rgn->cnt; i++) {
unsigned long rgnbase = rgn->region[i].base;
@@ -185,6 +191,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
break;
}
}
+
+ if (base < rgn->region[0].base) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ }
+
rgn->cnt++;
return 0;
--
1.5.3.8
^ permalink raw reply related
* Re: [patch 0/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Bjorn Helgaas @ 2008-02-19 18:02 UTC (permalink / raw)
To: benh
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, Russell King, linux-arm-kernel
In-Reply-To: <1203415712.6740.102.camel@pasglop>
On Tuesday 19 February 2008 03:08:32 am Benjamin Herrenschmidt wrote:
> On Tue, 2008-02-19 at 08:09 +0000, Russell King wrote:
> > On Mon, Feb 18, 2008 at 09:39:52PM -0700, Bjorn Helgaas wrote:
> > >
> > > ARM and PA-RISC, in particular, have interesting differences:
> > > - ARM always enables bridge devices, which no other arch does
> >
> > ARM does this because there is nothing else which would do that - which
> > means devices behind bridges would be completely inaccessible.
>
> That's normally done by pci_enable_bridges() called by
> pci_assign_unassigned_resources().
alpha, mips, mn10300, powerpc, and x86 use pci_enable_bridges() via
pci_assign_unassigned_resources(). parisc uses pci_enable_bridges()
directly from lba_driver_probe(). I guess the other arches (except
arm) rely on firmware to enable bridge.
I think pci_assign_unassigned_resources() is a bit of an anachronism --
it's a boot-time thing that does it for all root buses at once. A
more hot-plug oriented scheme would do it like parisc, where every
time we discover a root bridge, we do any necessary resource assignment
and bridge enablement underneath it.
For ARM, maybe that could happen in pcibios_init_hw() or something
similar.
> > > - PA-RISC always turns on SERR and PARITY, which no other arch does
> >
> > ARM also does this, unless pdev_bad_for_parity(dev) is true. See
> > ARMs pcibios_fixup_bus().
>
> While that sounds like a good idea to generalize, I think it should
> remain arch stuff tho, not move to generic code.
>
> On some platforms, weirdo firmwares handle error handling and will be
> unhappy if the kernel mucks around (such as pSeries).
I agree the SERR and PARITY stuff probably needs to remain arch code.
But it would be nice to at least have this and the bridge enable done in
similar places across arches.
Bjorn
^ permalink raw reply
* Re: [patch 4/4] RFC: PCI: consolidate several pcibios_enable_resources() implementations
From: Ivan Kokshaysky @ 2008-02-19 17:08 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-arch, Chris Zankel, Grant Grundler, linux-parisc,
Matthew Wilcox, Kyle McMartin, linuxppc-dev, Paul Mackerras,
linux-pci, linux-arm-kernel, Russell King
In-Reply-To: <200802190911.56901.bjorn.helgaas@hp.com>
On Tue, Feb 19, 2008 at 09:11:55AM -0700, Bjorn Helgaas wrote:
> > That is, whatever the arch code decides to use to decide whether
> > resources are assigned by firmware or by the first pass assignment code
> > or not and collide or not, once that phase is finished (which is the
> > case when calling pcibios_enable_device(), having the resource in the
> > resource-tree or not is, I believe, the proper way to test whether it's
> > a useable resource.
>
> So should x86 adopt that collision check?
Yes, and other arches as well, I believe.
> I don't hear anything about
> actual architecture differences that are behind this implementation
> difference.
On ppc64 "0" can be a valid value for resource start, as far as I know.
Ivan.
^ permalink raw reply
* RE: Frustrated question with insmod
From: Sugathan, Rupesh @ 2008-02-19 18:04 UTC (permalink / raw)
To: Bruce_Leonard; +Cc: linuxppc-embedded
> Bruce_Leonard@selinc.com wrote:
> > Sorry if this is the wrong place to post this question. I'm
developing a=20
> > NAND flash driver and I need to do some detailed dubugging using GDB
with=20
> > a BDI2K. According to the Denx web site, to find out the address=20
> > that
the=20
> > module is loading at you load it using the -m parameter to insmod
(i.e.,=20
> > "insmod -m mymodule"). However, every version of insmod I've tried=20
> > doesn't recognize ANY options much less -m. Can anyone please point
me in=20
> > the right direction, or give me another way of knowing what the load
> > address of my module is?
>=20
> # cat /sys/module/<name>/sections/.text
>=20
> Do not forget to enable CONFIG_KALLSYMS.
Although this may not solve your problem, I once had to build insmod
with CONFIG_FEATURE_INSMOD_LOAD_MAP (this is not enabled by default)
option in its configuration to enable the -m option.
Thanks
..
Rupesh Sugathan
^ permalink raw reply
* Status of I2C on mpc5200
From: Eric DUJARDIN @ 2008-02-19 18:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1793 bytes --]
Hello all,
I have a question regarding the stability of I2C on mpc52xx.
According to menuconfig's help it isn't still stable as it says:
"The driver may also work on 52xx family processors, though interrupts are
known not to work"
However there has been a patch from Domen Puncer that apparently fixed the
driver in 2.6.23.
commit 254db9b5e7b1b0d38a4f177c2c23a5685c78221a
Author: Domen Puncer <domen.puncer@telargo.com>
Date: Thu Jul 12 14:12:31 2007 +0200
i2c-mpc: work around missing-9th-clock-pulse bug
Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias Fechner and me.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
If any kind soul could provide a status I'd be glad to provide the patch
for the help file...
Thanks,
Eric Dujardin
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite."
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."
[-- Attachment #2: Type: text/html, Size: 2666 bytes --]
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: Scott Wood @ 2008-02-19 17:53 UTC (permalink / raw)
To: maxime louvel; +Cc: linuxppc-embedded
In-Reply-To: <dda529d0802190838h7c72b590gc6b26ed868bac8e5@mail.gmail.com>
maxime louvel wrote:
> Hi again,
>
> this time I have tried to compile the kernel, with an embedded compiler
> on the board.
> here is the result...
>
> ....
> BOOTAS arch/powerpc/boot/ps3-hvcall.o
> BOOTCC arch/powerpc/boot/ps3.o
> BOOTCC arch/powerpc/boot/treeboot-bamboo.o
> BOOTCC arch/powerpc/boot/cuboot-8xx.o
> BOOTCC arch/powerpc/boot/cuboot-pq2.o
> BOOTCC arch/powerpc/boot/cuboot-sequoia.o
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
> ppc_setup_opcodes
> Please report this bug.
> make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
> make[1]: *** [uImage] Error 2
> make: *** [sub-make] Error 2
That's a bug in older toolchains, which is aggravated by a misguided
policy that we build all wrapper platforms, always. Either use a newer
toolchain, or remove treeboot-walnut from arch/powerpc/boot/Makefile.
-Scott
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Jon Loeliger @ 2008-02-19 16:59 UTC (permalink / raw)
To: Marco Stornelli; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BB071E.4020204@coritel.it>
Marco Stornelli wrote:
> No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it
> could help. What do you think about it? Do you think this problem could
> be not present in 2.6.24?
I have no idea there, honestly. Sorry.
jdl
^ permalink raw reply
* Re: reg Philips ISP 1562 usb controller support in linux2.6.23.11
From: Clemens Koller @ 2008-02-19 16:53 UTC (permalink / raw)
To: mahendra varman; +Cc: linuxppc-embedded
In-Reply-To: <4ac2955e0802190807s5a19cdfeo6788fc5874424847@mail.gmail.com>
Hello, Magendra!
mahendra varman schrieb:
> Iam using a powerpc processor (7448)
> cat proc/cpu info is
> processor : 0
> cpu : 7448
> revision : 2.2 (pvr 8004 0202)
> bogomips : 995.32
> vendor : Cornet India Ltd
> machine : CTP7448
> PB freq : 133Mhz
> SDC freq : 0Mhz
>
> Sir, Today I noticed that when ever i insert a mp3usb stick it is giving
> Unlink after no-IRQ? "
> "Controller is probably using the wrong IRQ"
Try booting the kernel with "irqpoll". Example:
> linux noapic pci=irqroute pci=noacpi acpi=off irqpoll
Check if that helps.
> but if i insert an usbflash stick(without mp3) It is enumerating and i
> can able to mount the usb and read the content
>
> I wonder why iam getting unlink after no IRQ for some devices and for
> others iam not getting that
Well, I just don't know.
What kernel architecture do you use? ppc or powerpc?
In case you use the former (which is deprecated),
you might want to try the latter.
> Please clear my query sir
(-: Please follow my advices:
1. DO NOT remove the mailing list from CC: (and the chance anybody is
able to help you!)
2. post the output of lspci -vv.
Next step is: contact the guys in the linux-usb mailing list.
Regards,
Clemens
^ permalink raw reply
* Re: [PATCH] mpc i2c driver, compare to NO_IRQ instead of zero
From: Jean Delvare @ 2008-02-19 16:42 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080121200740.13800.20524.stgit@terra.home>
Hi Jon,
On Mon, 21 Jan 2008 15:07:40 -0500, Jon Smirl wrote:
> Alter the mpc i2c driver to use the NO_IRQ symbol instead of
> the constant zero when checking for valid interrupts. NO_IRQ=-1
> on ppc and NO_IRQ=0 on powerpc so the checks against zero are
> not correct.
Using NO_IRQ sounds good, just one question:
>
> Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> ---
>
> drivers/i2c/busses/i2c-mpc.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
>
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index bbe787b..d20959d 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -99,7 +99,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> u32 x;
> int result = 0;
>
> - if (i2c->irq == 0)
> + if (i2c->irq == NO_IRQ)
> {
> while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
> schedule();
> @@ -329,7 +329,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> i2c->irq = platform_get_irq(pdev, 0);
> - if (i2c->irq < 0) {
> + if (i2c->irq < NO_IRQ) {
I am skeptical about this one. Can platform_get_irq() really return
NO_IRQ? I thought that the IRQ resource would be plain missing if the
device has no IRQ, so I would expect:
i2c->irq = platform_get_irq(pdev, 0);
if (i2c->irq < 0)
i2c->irq = NO_IRQ; /* Use polling */
Testing against NO_IRQ suggests that devices with no IRQ would still
have an IRQ resource defined and explicitly set to NO_IRQ. Sounds weird
to me. Can you please clarify this point?
For what it's worth, no other kernel driver checks for irq < NO_IRQ.
They all check for irq < 0 after calling platform_get_irq().
> result = -ENXIO;
> goto fail_get_irq;
> }
> @@ -344,7 +344,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> goto fail_map;
> }
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> if ((result = request_irq(i2c->irq, mpc_i2c_isr,
> IRQF_SHARED, "i2c-mpc", i2c)) < 0) {
> printk(KERN_ERR
> @@ -367,7 +367,7 @@ static int fsl_i2c_probe(struct platform_device *pdev)
> return result;
>
> fail_add:
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
> fail_irq:
> iounmap(i2c->base);
> @@ -384,7 +384,7 @@ static int fsl_i2c_remove(struct platform_device *pdev)
> i2c_del_adapter(&i2c->adap);
> platform_set_drvdata(pdev, NULL);
>
> - if (i2c->irq != 0)
> + if (i2c->irq != NO_IRQ)
> free_irq(i2c->irq, i2c);
>
> iounmap(i2c->base);
The rest looks good.
--
Jean Delvare
^ permalink raw reply
* RTC woes
From: Marc LeFevre @ 2008-02-19 16:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]
Hi:
I'm new to the list. I have an e500-based embedded Linux system running a
2.6.22 kernel. I have a PCF8563T i2c based RTC chip attached to the PPC i2c
bus. In my kernel config file I have selected CONFIG_RTC_INTF_DEV=y and
CONFIG_RTC_DRV_PCF8563=y. I do a mknod for /dev/rtc as c 10 135 (standard
Linux) and link /dev/rtc0 to it.
When I boot, get the following message:
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
and, of course I cannot access /dev/rtc after booting. I can, however, talk
to the rtc if I use /dev/i2c and a generic i2c read and write utility.
When I look in /proc/devices, I see that rtc has taken major number 254
which puzzles me. RTC should not need a dynamic major number, right? I have
perused the drivers in linux/drivers/rtc and don't find any of them calling
register_chrdev() to get a dynamic major number. So here are my questions:
1) Shouldn't rtc automagically use major/minor 10/135?
2) How can I find where in the source it asks for a dynamic major
number?
3) Does the PPC have some quirks regarding i2c operation that are at
the root of this problem?
BYW, I tried making the rtc device file as c 254 0 to match what's in
/proc/devices and that gives me the same bejavior.
Thanks in advance for any help you can offer.
Marc
[-- Attachment #2: Type: text/html, Size: 6488 bytes --]
^ permalink raw reply
* Re: MPC8641D PCI-Express error
From: Marco Stornelli @ 2008-02-19 16:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: LinuxPPC-Embedded
In-Reply-To: <47BAFE6A.9050801@freescale.com>
Jon Loeliger ha scritto:
> Marco Stornelli wrote:
>>
>> Board: MPC8641D HPCN
>> SoC: MPC8641D rev. 2
>
> OK, this is good.
>
>> Kernel: 2.6.18
>
> And this is really old. Any chance of up-rev'ing
> that to something modern like 2.6.24? You may find
> that your PCI-E issues are Just Fixed there. Dunno.
>
> HTH,
> jdl
>
No, but I can try to backport the PCI-E code from 2.6.24 to 2.6.18 if it
could help. What do you think about it? Do you think this problem could
be not present in 2.6.24?
^ permalink raw reply
* Re: 2.6.24 for mpc8458amc
From: maxime louvel @ 2008-02-19 16:38 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <47BAEE3F.2070209@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
Hi again,
this time I have tried to compile the kernel, with an embedded compiler on
the board.
here is the result...
....
BOOTAS arch/powerpc/boot/ps3-hvcall.o
BOOTCC arch/powerpc/boot/ps3.o
BOOTCC arch/powerpc/boot/treeboot-bamboo.o
BOOTCC arch/powerpc/boot/cuboot-8xx.o
BOOTCC arch/powerpc/boot/cuboot-pq2.o
BOOTCC arch/powerpc/boot/cuboot-sequoia.o
BOOTCC arch/powerpc/boot/treeboot-walnut.o
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at ../../gas/config/tc-ppc.c line 1300 in
ppc_setup_opcodes
Please report this bug.
make[2]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
make[1]: *** [uImage] Error 2
make: *** [sub-make] Error 2
any idea ?
cheers,
Maxime
On Feb 19, 2008 2:57 PM, Jon Loeliger <jdl@freescale.com> wrote:
> maxime louvel wrote:
> > Thanks for your answer,
> >
> > I am going to check this ppc / powerpc things.
> > I should use the architecture powerpc, don't I?
>
> ARCH == ppc is scheduled for _removal_ from the
> entire Kernel source base is just about 4 months.
> Feel free to move the deck chairs around. :-)
>
> > I'm not really sure I have understand what do you want to do with a
> > BDI-2000.
>
> Perhaps, for starters, you read "Building Embedded Linux Systems"
> as found here:
> http://www.oreilly.com/catalog/belinuxsys/
>
> > I access the cards through a serial line directly.
>
> Of course. But when you get no information there,
> you might try a different interface.
>
> jdl
>
--
Maxime Louvel
0044 7964 5555 80
43 Allen road
Whitemore reans
WV60AW Wolverhampton
United Kingdom
[-- Attachment #2: Type: text/html, Size: 2261 bytes --]
^ permalink raw reply
* Re: [PATCH] Convert pfc8563 i2c driver from old style to new style
From: Jean Delvare @ 2008-02-19 16:37 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: linuxppc-dev, i2c
In-Reply-To: <20080219172450.0e4ccc7c@i1501.lan.towertech.it>
On Tue, 19 Feb 2008 17:24:50 +0100, Alessandro Zummo wrote:
> On Tue, 19 Feb 2008 16:10:20 +0100
> Jean Delvare <khali@linux-fr.org> wrote:
>
> > Hi Jon,
> >
> > On Mon, 21 Jan 2008 15:09:01 -0500, Jon Smirl wrote:
> > > Convert pfc8563 i2c driver from old style to new style.
> > >
> > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > > ---
> > >
> > > drivers/rtc/rtc-pcf8563.c | 107 +++++++++++----------------------------------
> > > 1 files changed, 27 insertions(+), 80 deletions(-)
> >
> > Preliminary note: this driver belongs to the RTC subsystem, so it will
> > be up to Alessandro Zummo (Cc'd) to push this patch upstream... when it
> > is ready to go there.
>
> A conversion to new style for this driver has already been
> pushed upstream. Adapting platforms to instantiate the device
> should be fairly easy, especially when you use the dts.
Ah, excellent. I didn't know, thanks for pointing it out. I'm glad I
added you to Cc :)
--
Jean Delvare
^ 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