* 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: 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
* 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: 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
* 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: [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
* [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: 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
* 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: [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: [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
* 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 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
* 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: 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
* 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: [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
* 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: 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: [PATCH 2/2] i2c-ibm_iic driver
From: Stephen Rothwell @ 2008-02-19 23:41 UTC (permalink / raw)
To: Sean MacLennan
Cc: Jean Delvare, linuxppc-dev, Stefan Roese, i2c, Arnd Bergmann
In-Reply-To: <47BB63AE.2090903@pikatech.com>
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
> > - depends on IBM_OCP
> > + depends on IBM_OCP || PPC_MERGE
not PPC_OF? or even OF (give the sparc guys the opportunity to build it
for us :-))?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] powerpc: don't create two devices for each cpm_uart device tree node
From: Nikita V. Youshchenko @ 2008-02-19 23:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]
powerpc: don't create two devices for each cpm_uart device tree node
Code in arch/powerpc/sysdev/fsl_soc.c used to create two 'struct device'
objects for each cpm_uart device tree node - one "fsl-cpm-scc:uart"
in cpm_uart_of_init() and one "fsl-cpm-smc:uart" in cpm_smc_uart_of_init().
This patch adds additional test to those routines, such that cpm_uart_of_init()
only registers devices with model "SCC", and cpm_smc_uart_of_init() only
registers devices with model "SMC".
Signed-off-by: Nikita Youshchenko <yoush@debian.org>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index f1b8412..536f8c9 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -890,6 +890,10 @@ static int __init cpm_uart_of_init(void)
const int *id;
const char *model;
+ model = of_get_property(np, "model", NULL);
+ if (!model || strcmp(model, "SCC") != 0)
+ continue;
+
memset(r, 0, sizeof(r));
memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
@@ -917,7 +921,6 @@ static int __init cpm_uart_of_init(void)
id = of_get_property(np, "device-id", NULL);
cpm_uart_data.fs_no = *id;
- model = of_get_property(np, "model", NULL);
strcpy(cpm_uart_data.fs_type, model);
cpm_uart_data.uart_clk = ppc_proc_freq;
@@ -1175,6 +1178,10 @@ static int __init cpm_smc_uart_of_init(void)
const int *id;
const char *model;
+ model = of_get_property(np, "model", NULL);
+ if (!model || strcmp(model, "SMC") != 0)
+ continue;
+
memset(r, 0, sizeof(r));
memset(&cpm_uart_data, 0, sizeof(cpm_uart_data));
@@ -1200,7 +1207,6 @@ static int __init cpm_smc_uart_of_init(void)
goto err;
}
- model = of_get_property(np, "model", NULL);
strcpy(cpm_uart_data.fs_type, model);
id = of_get_property(np, "device-id", NULL);
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH 2/2] i2c-ibm_iic driver
From: Arnd Bergmann @ 2008-02-19 23:54 UTC (permalink / raw)
To: linuxppc-dev
Cc: Jean Delvare, Stephen Rothwell, Stefan Roese, i2c, Sean MacLennan
In-Reply-To: <20080220104133.e9722e62.sfr@canb.auug.org.au>
On Wednesday 20 February 2008, Stephen Rothwell wrote:
> > > - =A0 =A0 =A0 depends on IBM_OCP
> > > + =A0 =A0 =A0 depends on IBM_OCP || PPC_MERGE
>=20
> not PPC_OF? =A0or even OF (give the sparc guys the opportunity to build it
> for us :-))?
>=20
Right, I was looking for that option but couldn't find it. I would
guess sparc doesn't work because it's lacking the necessary I/O functions,
in_8 and out_8 that are powerpc specific.
so maybe:
depends on PPC
depends on IBM_OCP || OF
Arnd <><
^ permalink raw reply
* Re: [patch v7 3/4] USB: add Cypress c67x00 OTG controller HCD driver
From: Greg KH @ 2008-02-19 23:55 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, dbrownell, stern, linux-usb
In-Reply-To: <20080219151149.684610000@sunsite.dk>
On Tue, Feb 19, 2008 at 04:09:19PM +0100, Peter Korsgaard wrote:
> This patch adds HCD support for the Cypress c67x00 family of devices.
>
> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
And it doesn't build:
CC [M] drivers/usb/c67x00/c67x00-hcd.o
distcc[2413] ERROR: compile /home/gregkh/.ccache/c67x00-hcd.tmp.mini.2409.i on localhost failed
drivers/usb/c67x00/c67x00-hcd.c:345: error: redefinition of 'c67x00_hcd_probe'
drivers/usb/c67x00/c67x00-hcd.h:119: error: previous definition of 'c67x00_hcd_probe' was here
drivers/usb/c67x00/c67x00-hcd.c:402: error: redefinition of 'c67x00_hcd_remove'
drivers/usb/c67x00/c67x00-hcd.h:126: error: previous definition of 'c67x00_hcd_remove' was here
make[2]: *** [drivers/usb/c67x00/c67x00-hcd.o] Error 1
make[1]: *** [drivers/usb/c67x00] Error 2
make: *** [_module_drivers/usb] Error 2
This is _after_ removing the obviously incorrect usb_disabled()
function that you included in your .h file.
I'm going to hold off applying any of these for now, as it doesn't look
like something is configured properly here.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] [POWERPC] fix warning in pseries/power.c
From: Stephen Rothwell @ 2008-02-20 0:27 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev, Greg KH
Introduced by commit 79393fc46ede43451a500a132e5de9856f5a4c83 ("kobject:
convert pseries/power.c to kobj_attr interface").
sys_create_file takes a "struct attrbute *" not a "struct kobj_addribute *".
arch/powerpc/platforms/pseries/power.c: In function 'apo_pm_init':
arch/powerpc/platforms/pseries/power.c:78: warning: passing argument 2 of 'sysfs_create_file' from incompatible pointer type
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/pseries/power.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/power.c b/arch/powerpc/platforms/pseries/power.c
index e95fc15..6d62662 100644
--- a/arch/powerpc/platforms/pseries/power.c
+++ b/arch/powerpc/platforms/pseries/power.c
@@ -75,7 +75,7 @@ core_initcall(pm_init);
#else
static int __init apo_pm_init(void)
{
- return (sysfs_create_file(power_kobj, &auto_poweron_attr));
+ return (sysfs_create_file(power_kobj, &auto_poweron_attr.attr));
}
__initcall(apo_pm_init);
#endif
--
1.5.4.2
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH v2][POWERPC] Fix initial lmb add region with a non-zero base
From: David Miller @ 2008-02-20 0:30 UTC (permalink / raw)
To: galak; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802191350590.10089@blarg.am.freescale.net>
From: Kumar Gala <galak@kernel.crashing.org>
Date: Tue, 19 Feb 2008 13:51:37 -0600 (CST)
> 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.
I think my tree has already or will soon be pulled in so
I don't want to rebase it.
Why don't you simply send me the relative bug fix instead?
Thanks!
^ 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