* Re: [PATCH 08/11] [POWERPC] qe_lib: implement QE GTM support
From: Scott Wood @ 2008-02-04 20:30 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080203171019.GH28024@localhost.localdomain>
On Sun, Feb 03, 2008 at 08:10:19PM +0300, Anton Vorontsov wrote:
> GTM stands for General-purpose Timers Module and able to generate
> timer{1,2,3,4} interrupts.
>
> There are several limitations in this support:
> 1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
> This is straightforward to implement when needed, two timers should
> be marked as "requested" and configured as appropriate.
> 2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
> This is also straightforward to implement when needed, all timers
> should be marked as "requested" and configured as appropriate.
This isn't QE-specific; the same (as far as I see) timer hardware exists on,
for example, mpc8313 and mpc8349.
> +config QE_GTM
> + bool
> + help
> + QE General-Purpose Timers Module support
No bool text?
> +struct gtm_timer {
> + unsigned int irq;
> + bool requested;
> +
> + u8 __iomem *gtcfr;
> + u16 __iomem *gtmdr;
> + u16 __iomem *gtpsr;
> + u16 __iomem *gtcnr;
> + u16 __iomem *gtrfr;
> + u16 __iomem *gtevr;
> +};
__be16
> +static struct gtm_timer timers[4];
> +static struct qe_timers __iomem *qet;
> +static spinlock_t gtm_lock = __SPIN_LOCK_UNLOCKED(gtm_lock);
static DEFINE_SPINLOCK(gtm_lock);
Put these in a struct so multiple timer blocks can be supported (the non-QE
chips tend to have two blocks).
> +int qe_reset_ref_timer_16(int num, unsigned int hz, u16 ref)
What does this function do? What goes in "hz" and "ref"? Is it periodic or
one-shot?
-Scott
^ permalink raw reply
* Re: 2.6.24-mm1: ppc32: too few arguments to function 'reserve_bootmem'
From: Mariusz Kozlowski @ 2008-02-04 20:29 UTC (permalink / raw)
To: Andrew Morton, Bernhard Walle; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20080203171634.58ab668b.akpm@linux-foundation.org>
Hello,
This is from ppc32:
CC arch/powerpc/mm/mem.o
arch/powerpc/mm/mem.c: In function 'do_init_bootmem':
arch/powerpc/mm/mem.c:256: error: too few arguments to function 'reserve_bootmem'
arch/powerpc/mm/mem.c:261: error: too few arguments to function 'reserve_bootmem'
Leftover from introduce-flags-for-reserve_bootmem.patch?
Regards,
Mariusz
^ permalink raw reply
* Re: [PATCH] Fix ext4 bitops
From: Geert Uytterhoeven @ 2008-02-04 20:11 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: linux-s390, Heiko Carstens, Bastian Blank,
Linux Kernel Development, Linux/PPC Development, Andrew Morton,
linux-ext4
In-Reply-To: <20080204045025.GA7494@skywalker>
On Mon, 4 Feb 2008, Aneesh Kumar K.V wrote:
> On Sun, Feb 03, 2008 at 01:39:02PM +0100, Geert Uytterhoeven wrote:
> > On Sun, 3 Feb 2008, Heiko Carstens wrote:
> > > On Fri, Feb 01, 2008 at 10:04:04PM +0100, Bastian Blank wrote:
> > > > On Fri, Feb 01, 2008 at 12:22:57PM -0800, Andrew Morton wrote:
> > > > > On Fri, 1 Feb 2008 21:02:08 +0100
> > > > > Bastian Blank <bastian@waldi.eu.org> wrote:
> > > > > > Fix ext4 bitops.
> > > > >
> > > > > This is incomplete. Please tell us what was "fixed".
> > > > >
> > > > > If it was a build error then please quote the compile error output in the
> > > > > changelog, as well as the usual description of what the problem is, and how
> > > > > it was fixed.
> > > >
> > > > | fs/ext4/mballoc.c: In function 'ext4_mb_generate_buddy':
> > > > | fs/ext4/mballoc.c:954: error: implicit declaration of function 'generic_find_next_le_bit'
> > > >
> > > > The s390 specific bitops uses parts of the generic implementation.
> > > > Include the correct header.
> > >
> > > That doesn't work:
> > >
> > > fs/built-in.o: In function `ext4_mb_release_inode_pa':
> > > mballoc.c:(.text+0x95a8a): undefined reference to `generic_find_next_le_bit'
> > > fs/built-in.o: In function `ext4_mb_init_cache':
> > > mballoc.c:(.text+0x967ea): undefined reference to `generic_find_next_le_bit'
> > >
> > > This still needs generic_find_next_le_bit which comes
> > > from lib/find_next_bit.c. That one doesn't get built on s390 since we
> > > don't set GENERIC_FIND_NEXT_BIT.
> > > Currently we have the lengthly patch below queued.
> >
> > Similar issue on m68k. As Bastian also saw it on powerpc, I'm getting the
> > impression the ext4 people don't (compile) test on big endian machines?
>
> I have sent this patches to linux-arch expecting a review from
> different arch people. It is true that the patches are tested only on
> powerpc, x86-64, x86. That's the primary reason of me sending the
> patches to linux-arch.
>
> http://marc.info/?l=linux-arch&m=119503501127737&w=2
Sometimes it's difficult to see what can go wrong due to a single patch that
just adds a #define. Sorry, I missed the lack of prototype for
generic_find_next_le_bit() and that we don't set GENERIC_FIND_NEXT_BIT,
just like s390.
And yes, usually I rely on the -mm autocompiler to catch things like
this, but this time it didn't work out...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RFC][PATCH] PowerPC: 4xx PCIe indirect DCR spinlock fix.
From: Valentine Barshak @ 2008-02-04 18:27 UTC (permalink / raw)
To: linuxppc-dev
Since we have mfdcri() and mtdcri() as macros, we can't use constructions, such
as "mtdcri(base, reg, mfdcri(base, reg) | val)". In this case the mfdcri() stuff
is not evaluated first. It's evaluated inside the mtdcr() macro and we have
the dcr_ind_lock spinlock acquired twice. To avoid this error, I've added
set_dcri() and clr_dcri() macros which set/clear the specified bits.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 13 +++++--------
include/asm-powerpc/dcr-native.h | 22 ++++++++++++++++++++++
2 files changed, 27 insertions(+), 8 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c
--- linux-2.6.orig/arch/powerpc/sysdev/ppc4xx_pci.c 2008-02-04 20:05:37.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/ppc4xx_pci.c 2008-02-04 20:16:33.000000000 +0300
@@ -645,7 +645,7 @@ static int __init ppc440spe_pciex_core_i
int time_out = 20;
/* Set PLL clock receiver to LVPECL */
- mtdcri(SDR0, PESDR0_PLLLCT1, mfdcri(SDR0, PESDR0_PLLLCT1) | 1 << 28);
+ set_dcri(SDR0, PESDR0_PLLLCT1, 1 << 28);
/* Shouldn't we do all the calibration stuff etc... here ? */
if (ppc440spe_pciex_check_reset(np))
@@ -659,8 +659,7 @@ static int __init ppc440spe_pciex_core_i
}
/* De-assert reset of PCIe PLL, wait for lock */
- mtdcri(SDR0, PESDR0_PLLLCT1,
- mfdcri(SDR0, PESDR0_PLLLCT1) & ~(1 << 24));
+ clr_dcri(SDR0, PESDR0_PLLLCT1, 1 << 24);
udelay(3);
while (time_out) {
@@ -712,9 +711,8 @@ static int ppc440spe_pciex_init_port_hw(
mtdcri(SDR0, port->sdr_base + PESDRn_440SPE_HSSL7SET1,
0x35000000);
}
- val = mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET);
- mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
- (val & ~(1 << 24 | 1 << 16)) | 1 << 12);
+ clr_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 24 | 1 << 16)
+ set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 12);
return 0;
}
@@ -1042,8 +1040,7 @@ static int __init ppc4xx_pciex_port_init
port->link = 0;
}
- mtdcri(SDR0, port->sdr_base + PESDRn_RCSSET,
- mfdcri(SDR0, port->sdr_base + PESDRn_RCSSET) | 1 << 20);
+ set_dcri(SDR0, port->sdr_base + PESDRn_RCSSET, 1 << 20);
msleep(100);
return 0;
diff -pruN linux-2.6.orig/include/asm-powerpc/dcr-native.h linux-2.6/include/asm-powerpc/dcr-native.h
--- linux-2.6.orig/include/asm-powerpc/dcr-native.h 2008-02-04 20:06:34.000000000 +0300
+++ linux-2.6/include/asm-powerpc/dcr-native.h 2008-02-04 20:16:33.000000000 +0300
@@ -79,6 +79,28 @@ do { \
spin_unlock_irqrestore(&dcr_ind_lock, flags); \
} while (0)
+#define set_dcri(base, reg, data) \
+do { \
+ unsigned long flags; \
+ unsigned int val; \
+ spin_lock_irqsave(&dcr_ind_lock, flags); \
+ mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
+ val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
+ mtdcr(DCRN_ ## base ## _CONFIG_DATA, val | (data)); \
+ spin_unlock_irqrestore(&dcr_ind_lock, flags); \
+} while (0)
+
+#define clr_dcri(base, reg, data) \
+do { \
+ unsigned long flags; \
+ unsigned int val; \
+ spin_lock_irqsave(&dcr_ind_lock, flags); \
+ mtdcr(DCRN_ ## base ## _CONFIG_ADDR, reg); \
+ val = mfdcr(DCRN_ ## base ## _CONFIG_DATA); \
+ mtdcr(DCRN_ ## base ## _CONFIG_DATA, val & ~(data)); \
+ spin_unlock_irqrestore(&dcr_ind_lock, flags); \
+} while (0)
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DCR_NATIVE_H */
^ permalink raw reply
* Re: [PATCH 1/1] [PPC] 8xx swap bug-fix
From: Scott Wood @ 2008-02-04 18:24 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <47A45269.7080403@scram.de>
On Sat, Feb 02, 2008 at 12:22:17PM +0100, Jochen Friedrich wrote:
> Hi Yuri,
>
> > Here is the patch which makes Linux-2.6 swap routines operate correctly on
> > the ppc-8xx-based machines.
>
> is there any 8xx board left which isn't ported to ARCH=powerpc?
More importantly, is this something that is also broken in arch/powerpc? It
looks like it has the same code...
-Scott
^ permalink raw reply
* Re: Kernel oops while dumping user core.
From: Scott Wood @ 2008-02-04 18:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Nathan Lynch
In-Reply-To: <1202024064.7208.6.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Thu, 2008-01-31 at 16:10 -0600, Rune Torgersen wrote:
>> Scott Wood wrote:
>>> Changing update_mmu_cache() to always call flush_dcache_icache_page()
>>> fixes it, though a better performing fix would probably be to add an
>>> exception table entry for the dcbst.
>> I can confirm that this seems to fix it.
>
> Might be better to avoid the flush when the page isn't readable ?
Sure, that'd work. I was trying to avoid a tablewalk to determine that,
not noticing the pte argument staring me in the face. :-P
-Scott
^ permalink raw reply
* RE: build is broken
From: Bizhan Gholikhamseh (bgholikh) @ 2008-02-04 18:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded
In-Reply-To: <20080204165144.GB19264@ld0162-tx32.am.freescale.net>
=20
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]=20
> Sent: Monday, February 04, 2008 8:52 AM
> To: Bizhan Gholikhamseh (bgholikh)
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: build is broken
>=20
> On Fri, Feb 01, 2008 at 03:23:21PM -0800, Bizhan Gholikhamseh=20
> (bgholikh) wrote:
> > AS .tmp_kallsyms2.o
> > LD vmlinux
> > SYSMAP System.map
> > SYSMAP .tmp_System.map
> > BOOTCC arch/powerpc/boot/treeboot-walnut.o
> > Assembler messages:
> > Error: Internal assembler error for instruction icbt=20
> Internal error,=20
> > aborting at=20
> >=20
> /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
> > line 1300 in ppc_setup_opcodes
> > Please report this bug.
>=20
> Try using a newer toolchain.
>=20
> -Scott
>
Thanks Scott,=20
That did it, I upgraded the toolchain to the 4.1 and worked fine.
Thanks again,
Bizhan=20
^ permalink raw reply
* Re: [PATCH 4/5] ehea: fix phyp checkpatch complaints
From: Scott Wood @ 2008-02-04 18:06 UTC (permalink / raw)
To: Doug Maxey
Cc: Jan-Bernd Themann, netdev, Jeff Garzik, Linux PowerPC List,
Paul Mackerras
In-Reply-To: <19294.1201927197@bebe.enoyolf.org>
Doug Maxey wrote:
> On Fri, 01 Feb 2008 13:23:45 CST, Scott Wood wrote:
>> On Thu, Jan 31, 2008 at 08:20:50PM -0600, Doug Maxey wrote:
>>> /* input param R5 */
>>> -#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11)
> ...
>>> +#define H_ALL_RES_QP_EQPO EHEA_BMASK_IBM(9, 11)
> ...
>> This was better the way it was (before, it was readable at any tab setting);
>> checkpatch is overeager to complain on tab/space issues (it's a bit hard to
>> distinguish indentation from alignment with a regex).
>
> In emacs, with no special offsets, the lines appear to still line up.
Are you using a tab size other than 8?
> What did happen was spaces were turned to tabs where applicable.
I disagree about the applicability. :-)
> What editor shows a bad alignment?
Any editor that has been configured to a non-default tab size.
-Scott
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] qe_lib: support for gpio_set_dedicated
From: Timur Tabi @ 2008-02-04 17:38 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: David Brownell, linuxppc-dev
In-Reply-To: <20080203171009.GE28024@localhost.localdomain>
Anton Vorontsov wrote:
> +static int qe_gpio_set_dedicated(struct gpio_chip *gc, unsigned int gpio,
> + int func)
> +{
> + struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> + struct qe_gpio_chip *qe_gc = to_qe_gpio_chip(mm_gc);
> + struct port_regs __iomem *regs = mm_gc->regs;
> + struct port_regs *sregs = &qe_gc->saved_regs;
> + unsigned long flags;
> + u32 mask1 = 1 << (NUM_OF_PINS - (gpio + 1));
> + u32 mask2 = 0x3 << (NUM_OF_PINS - (gpio % (NUM_OF_PINS / 2) + 1) * 2);
> + bool second_reg = gpio > (NUM_OF_PINS / 2) - 1;
> +
> + spin_lock_irqsave(&qe_gc->lock, flags);
> +
> + if (second_reg)
> + clrsetbits_be32(®s->cpdir2, mask2, sregs->cpdir2 & mask2);
> + else
> + clrsetbits_be32(®s->cpdir1, mask2, sregs->cpdir1 & mask2);
> +
> + if (second_reg)
> + clrsetbits_be32(®s->cppar2, mask2, sregs->cppar2 & mask2);
> + else
> + clrsetbits_be32(®s->cppar1, mask2, sregs->cppar1 & mask2);
You could combine these into one if-statement.
I took a quick look at all of your QE lib patches. They generally look okay,
but I haven't examined them thoroughly enough to formally ACK them.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Moving from 2.6.14 (ppc) to 2.6.20 (powerpc): problems with PCI-PCI bridge
From: Jon Loeliger @ 2008-02-04 17:34 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: Linuxppc-dev, Linuxppc-embedded
In-Reply-To: <47A6D72D.4050100@dutchspace.nl>
Johan Borkhuis wrote:
> Hello,
>
> I was using kernel version 2.6.14 (ppc) on a MVME3100 board (MPC8540
> processor). We are planning to move to 2.6.20 (powerpc), but I have some
> problems with the initialization of a PCI-PCI bridge.
> Connected to the MVME3100 board is a PCI-PCI bridge (HiNT, PCI6150,
> 3388:0022). When using the 2.6.14 kernel this bridge is initialized
> correctly: it is setup as bus-master, memory and IO are configured, and
> the memory allocation on the PCI-bus is correct.
> When I use 2.6.20 (powerpc) the device is not configured correctly:
> bus-master, memory and IO are not set, and the memory space of the
> bridge on the PCI bus is set to the minimum value (0xfffff).
> I can correct these settings by modifying the PCI_COMMAND register to
> set the bus-master, memory and IO. I change the size of the memory space
> in pci_32.c, by forcing the size to the required setting in
> pci_relocate_bridge_resource. But to be honest, I don't like this very
> much: modifying registers like this should not be needed, so I guess
> there is something wrong in my configuration or setup.
>
> How can I fix this problem in a better way? What could be wrong with my
> configuration?
There has been a fair amount of PCI setup reworking done
somewhat recently. (.22 and .23, IIRC, and even .24).
It might be best if you can try 2.6.24.
jdl
^ permalink raw reply
* Re: compile quirk linux-2.6.24 (with workaround)
From: Grant Likely @ 2008-02-04 17:34 UTC (permalink / raw)
To: Bernhard Reiter, David Gibson; +Cc: linuxppc-dev, debian-powerpc, paulus
In-Reply-To: <200802041126.21989.bernhard@intevation.de>
On 2/4/08, Bernhard Reiter <bernhard@intevation.de> wrote:
> On Monday 04 February 2008 10:51, Sven Luther wrote:
> > You should normally not need to build the 4xx bootloader part. Make sure
> > that, i don't know why this happens. Can you look into
> > arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
> > and make sure it is disabled in the main config ?
>
> I have tried to do this, but it looks like it is just hardcoded into the
> Makefile as you can see from the patch. There is probably more that I do not
> understand - thus my report with on the workaround.
The policy decision was made early on to build all of the bootwrapper
bits regardless of whether they are needed by the configured platform
or not. AFAIK the reason for this is to increase the variety of
platforms and compilers for with the bootwrapper bits are tested on.
Unfortunately, there are bits of 4xx bootwrappers which require
processor specific instructions for manipulating the cache and DCR.
If we're supporting compilers which don't have 440 support, then we'll
need to disable the build of those bits when they aren't needed, but I
don't know the best way to go about this. David, thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: build is broken
From: Scott Wood @ 2008-02-04 16:51 UTC (permalink / raw)
To: Bizhan Gholikhamseh (bgholikh); +Cc: linuxppc-embedded
In-Reply-To: <F795765B112E7344AF36AA911279641502D1AA28@xmb-sjc-212.amer.cisco.com>
On Fri, Feb 01, 2008 at 03:23:21PM -0800, Bizhan Gholikhamseh (bgholikh) wrote:
> AS .tmp_kallsyms2.o
> LD vmlinux
> SYSMAP System.map
> SYSMAP .tmp_System.map
> BOOTCC arch/powerpc/boot/treeboot-walnut.o
> Assembler messages:
> Error: Internal assembler error for instruction icbt
> Internal error, aborting at
> /usr/src/RPM/BUILD/crosstool/source/binutils-2.15/gas/config/tc-ppc.c
> line 1300 in ppc_setup_opcodes
> Please report this bug.
Try using a newer toolchain.
-Scott
^ permalink raw reply
* Re: Build failure with 2.6.24-mm1
From: Greg KH @ 2008-02-04 16:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, Zhang Yanmin, Shaohua Li, balbir
In-Reply-To: <20080204021917.41f56303.akpm@linux-foundation.org>
On Mon, Feb 04, 2008 at 02:19:17AM -0800, Andrew Morton wrote:
> On Mon, 4 Feb 2008 15:37:43 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
> > * Balbir Singh <balbir@linux.vnet.ibm.com> [2008-02-04 15:35:09]:
> >
> > I just saw the following build failure on a power machine.
> >
> > In file included from include/acpi/platform/acenv.h:140,
> > from include/acpi/acpi.h:54,
> > from include/acpi/acpi_bus.h:31,
> > from drivers/pci/pcie/aspm.c:20:
> > include/acpi/platform/aclinux.h:59:22: error: asm/acpi.h: No such file or directory
> > In file included from include/acpi/platform/aclinux.h:120,
> > from include/acpi/platform/acenv.h:140,
> > from include/acpi/acpi.h:54,
> > from include/acpi/acpi_bus.h:31,
> > from drivers/pci/pcie/aspm.c:20:
> > include/acpi/actypes.h:130: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'UINT64'
> > include/acpi/actypes.h:131: error: expected '=', ',', ';', 'asm' or
> > '__attribute__' before 'INT64'
> > include/acpi/actypes.h:753: error: expected ')' before '*' token
> > include/acpi/actypes.h:756: error: expected ')' before '*' token
> > In file included from include/acpi/acpi.h:61,
> > from include/acpi/acpi_bus.h:31,
> > from drivers/pci/pcie/aspm.c:20:
> > include/acpi/acpiosxf.h:179: error: expected declaration specifiers or '...'
> > before 'acpi_osd_handler'
> > include/acpi/acpiosxf.h:183: error: expected declaration specifiers or '...'
> > before 'acpi_osd_handler'
> > include/acpi/acpiosxf.h:192: error: expected declaration specifiers or '...'
> > before 'acpi_osd_exec_callback'
> > make[3]: *** [drivers/pci/pcie/aspm.o] Error 1
> > make[2]: *** [drivers/pci/pcie] Error 2
> > make[2]: *** Waiting for unfinished jobs....
> > CC drivers/ps3/ps3-vuart.o
> > CC net/netlink/attr.o
> > make[1]: *** [drivers/pci] Error 2
> > make[1]: *** Waiting for unfinished jobs..
> >
> > The following config option is responsible for the build failure
> >
> > config PCIEASPM
> > bool "PCI Express ASPM support(Experimental)"
> > depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> > default y
> > help
> > This enables PCI Express ASPM (Active State Power Management) and
> > Clock Power Management. ASPM supports state L0/L0s/L1.
> >
> > When in doubt, say N.
> >
> > Here's a probable fix for the problem.
> >
> >
> > Make the build of drivers/pci/pcie/aspm.c depend on ACPI.
> >
> > NOTE, the patch has not been tested. The dependency on ACPI might be wrong,
> > but setting it to default "y" caused the build on my powerpc box to break.
> >
> > Signed-off-by: Balbir Singh <balbir@linux.vnet.ibm.com>
> > ---
> >
> > drivers/pci/pcie/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff -puN drivers/pci/pcie/Kconfig~fix-mm-ppc-build drivers/pci/pcie/Kconfig
> > --- linux-2.6.24/drivers/pci/pcie/Kconfig~fix-mm-ppc-build 2008-02-04 15:30:29.000000000 +0530
> > +++ linux-2.6.24-balbir/drivers/pci/pcie/Kconfig 2008-02-04 15:33:45.000000000 +0530
> > @@ -32,7 +32,7 @@ source "drivers/pci/pcie/aer/Kconfig"
> > #
> > config PCIEASPM
> > bool "PCI Express ASPM support(Experimental)"
> > - depends on PCI && EXPERIMENTAL && PCIEPORTBUS
> > + depends on PCI && EXPERIMENTAL && PCIEPORTBUS && ACPI
> > default y
> > help
> > This enables PCI Express ASPM (Active State Power Management) and
>
> Thanks. I think Greg is going to revert PCIEASPM altogether?
Greg did, hopefully Linus will pull the changes soon...
thanks,
greg k-h
^ permalink raw reply
* [PATCH] [POWERPC] of: add alias helper functions.
From: Grant Likely @ 2008-02-04 16:16 UTC (permalink / raw)
To: linuxppc-dev, sfr, david, davem
From: Grant Likely <grant.likely@secretlab.ca>
Add helper functions for translating back and forth between alias
properties and device tree nodes.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/of/base.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 2 +
2 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b306fef..54a7f2e 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -331,3 +331,83 @@ struct device_node *of_find_matching_node(struct device_node *from,
return np;
}
EXPORT_SYMBOL(of_find_matching_node);
+
+/**
+ * of_find_node_by_alias - Find a node from an alias name
+ * @alias: Alias to decode
+ *
+ * Returns a node pointer with refcount incremented. Use of_node_put
+ * on it when done.
+ */
+struct device_node *of_find_node_by_alias(const char *alias)
+{
+ struct device_node *np, *alias_np;
+ const char *path;
+
+ np = NULL;
+
+ /* First decode the alias into a path */
+ alias_np = of_find_node_by_path("/aliases");
+ if (!alias_np)
+ return NULL;
+
+ path = of_get_property(alias_np, alias, NULL);
+ if (!path)
+ goto exit;
+
+ /* Next find the node pointed to by the alias */
+ np = of_find_node_by_path(path);
+
+ exit:
+ of_node_put(alias_np);
+ return np;
+}
+
+/**
+ * of_node_alias - Return the alias for a node
+ * @np Pointer to device node
+ * @prefix Prefix string; if provided then this function will only
+ * match on properties which have the given prefix.
+ *
+ * returns the alias property name for the given node without the prefix
+ */
+const char *of_node_alias(struct device_node *np, const char *prefix)
+{
+ struct device_node *alias_np, *test_np;
+ struct property *pp;
+ int prefix_len;
+ const char *alias;
+
+ prefix_len = 0;
+ if (prefix)
+ prefix_len = strlen(prefix);
+
+ /* First decode the alias into a path */
+ alias_np = of_find_node_by_path("/aliases");
+ if (!alias_np)
+ return NULL;
+
+ /* Loop over the aliases looking for a match */
+ alias = NULL;
+ for (pp = alias_np->properties; pp != 0; pp = pp->next) {
+ /* Skip properties which don't begin with the prefix */
+ if (prefix && (strncmp(pp->name, prefix, prefix_len) != 0))
+ continue;
+
+ /* Skip properties which aren't a NULL terminated string */
+ if (memchr(pp->value, 0, pp->length) == NULL)
+ continue;
+
+ /* Find out what node the property points to and see if it
+ * matches. If so then we've found our alias */
+ test_np = of_find_node_by_path(pp->value);
+ if (test_np == np)
+ alias = pp->name + prefix_len;
+ of_node_put(test_np);
+ if (alias)
+ break;
+ }
+
+ of_node_put(alias_np);
+ return alias;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index b5f33ef..aae1570 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -68,5 +68,7 @@ extern int of_n_addr_cells(struct device_node *np);
extern int of_n_size_cells(struct device_node *np);
extern const struct of_device_id *of_match_node(
const struct of_device_id *matches, const struct device_node *node);
+extern struct device_node *of_find_node_by_alias(const char *alias);
+extern const char *of_node_alias(struct device_node *np, const char *prefix);
#endif /* _LINUX_OF_H */
^ permalink raw reply related
* Re: [2.6 patch] powerpc: free_property() mustn't be __init
From: Stephen Rothwell @ 2008-02-04 15:10 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20080130200313.GG29368@does.not.exist>
[-- Attachment #1: Type: text/plain, Size: 547 bytes --]
On Wed, 30 Jan 2008 22:03:13 +0200 Adrian Bunk <bunk@kernel.org> wrote:
>
> This patch fixes the following section mismatch:
>
> <-- snip -->
>
> ...
> WARNING: vmlinux.o(.text+0x55648): Section mismatch in reference from the function .free_node() to the function .init.text:.free_property()
> ...
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
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
* Re: [Virtex 4 PPC] Which Linux?
From: Grant Likely @ 2008-02-04 15:32 UTC (permalink / raw)
To: IngoM; +Cc: linuxppc-embedded
In-Reply-To: <15268468.post@talk.nabble.com>
On 2/4/08, IngoM <ingo.maindorfer@ipm.fraunhofer.de> wrote:
>
> Hello,
>
> we develop a new laser-ranging-system and our hardware freaks have choosen
> the Virtex 4 FX 12 on the "AVNET FX12 Mini-Module". The system had to
> deliver the raw data via UDP (12 Mbyte/sec) and on TCP the processed data
> (about 6 Mbyte/sec). When you get the processed data via TCP then no data
> send by UDP.
>
> I'm confused by the following:
>
> 1) Hard-TEMAC vs. Soft-TEMAC.
> Avnet provide a demo for the module which using Soft-TEMAC. If I get it
> right this core has to be licenced. But when ther is a hard-TEMAC why pay
> for it?
Use the hard TEMAC.
> 2) Linux
> I'd like to build my kernel and filesystem myself. But which way to go?
> Using OE, buildroot, ELDK...
> Can you please provide some starting points for me?
I've got buildroot working; it's probably the simplest for building
from scratch. ELDK works well too.
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
>
> 3) Boot-Concept
> The Mini-Module had only 4MB Flash. Is this enough for a root-fs?
It's tight, but doable. You kernel image will be somewhere around 1
to 1.5 MB. Depends on how big your application is.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] ehea: add memory remove hotplug support
From: Jan-Bernd Themann @ 2008-02-04 15:24 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <1202136362.7672.5.camel@concordia>
On Monday 04 February 2008 15:46, Michael Ellerman wrote:
> On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> > Add memory remove hotplug support
> > @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> > if (ret)
> > ehea_info("failed registering reboot notifier");
> >
> > + ret = register_memory_notifier(&ehea_mem_nb);
> > + if (ret)
> > + ehea_info("failed registering memory remove notifier");
> >
> > ret = crash_shutdown_register(&ehea_crash_handler);
> > if (ret)
> > ehea_info("failed registering crash handler");
>
> You don't do anything except print a message if the registration fails.
> What happens when someone tries to remove memory but the memory notifier
> wasn't registered properly? Bang?
In case the registration fails and somebody tries to free memory:
- Driver will not remove the affected memory from the eHEA memory region
--> Firmware (phyp) can not free that memory (as marked as used)
--> Therefore the removed memory could not be used in an other partition
It makes sense to allow the driver to work anyway. Having no ethernet
would not really be a good alternative.
Regards,
Jan-Bernd
^ permalink raw reply
* [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
From: Valentine Barshak @ 2008-02-04 14:57 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47A71C60.1030406@ru.mvista.com>
The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock;
but it's actually isn't defined. This patch adds a missing dcr_ind_lock.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/dcr.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c
--- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.000000000 +0300
@@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned
h.token = NULL;
}
EXPORT_SYMBOL_GPL(dcr_unmap);
-
-#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
+#else /* defined(CONFIG_PPC_DCR_NATIVE) */
+DEFINE_SPINLOCK(dcr_ind_lock);
+#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
^ permalink raw reply
* Re: [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
From: Stephen Rothwell @ 2008-02-04 14:48 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev
In-Reply-To: <20080204134617.GA10377@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Mon, 4 Feb 2008 16:46:17 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote:
> >
> > If you don't care about the returned length (argument three to
> > of_get_property), you can just pass NULL (and dispense with "size").
> > Also, what happens if prop is NULL?
>
> All this was in the old code already, I just didn't fix that.
I appreciate that, but it did need fixing.
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [POWERPC] qe_lib: fix few fluffy negligences
>
> One is intoduced by me (of_node_put() absence) and another was
> present already (not checking for NULL).
>
> Found by Stephen Rothwell.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
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
* Re: [PATCH 2/2] ehea: add memory remove hotplug support
From: Michael Ellerman @ 2008-02-04 14:46 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200802041404.49960.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]
On Mon, 2008-02-04 at 14:04 +0100, Jan-Bernd Themann wrote:
> Add memory remove hotplug support
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> ---
> Comment: This patch depends on the following patch that
> exports the symbols
> register_memory_notifier()
> unregister_memory_notifier()
>
> http://lkml.org/lkml/2008/2/1/293
>
>
> drivers/net/ehea/ehea_main.c | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 21af674..b75afcc 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -3559,6 +3578,10 @@ int __init ehea_module_init(void)
> if (ret)
> ehea_info("failed registering reboot notifier");
>
> + ret = register_memory_notifier(&ehea_mem_nb);
> + if (ret)
> + ehea_info("failed registering memory remove notifier");
>
> ret = crash_shutdown_register(&ehea_crash_handler);
> if (ret)
> ehea_info("failed registering crash handler");
You don't do anything except print a message if the registration fails.
What happens when someone tries to remove memory but the memory notifier
wasn't registered properly? Bang?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
From: Valentine Barshak @ 2008-02-04 14:08 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080201203634.GA21024@ru.mvista.com>
Oops, sorry, please discard this one.
DEFINE_SPINLOCK should be used here.
Valentine Barshak wrote:
> The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock,
> but it's actually isn't defined. This patch adds a missing dcr_ind_lock.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> arch/powerpc/sysdev/dcr.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c
> --- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.000000000 +0300
> +++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.000000000 +0300
> @@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned
> h.token = NULL;
> }
> EXPORT_SYMBOL_GPL(dcr_unmap);
> -
> -#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> +#else /* defined(CONFIG_PPC_DCR_NATIVE) */
> +spinlock_t dcr_ind_lock;
> +#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] PowerPC: add missing native dcr dcr_ind_lock spinlock
From: Valentine Barshak @ 2008-02-01 20:36 UTC (permalink / raw)
To: linuxppc-dev
The include/asm-powerpc/dcr-native.h declares extern spinlock_t dcr_ind_lock,
but it's actually isn't defined. This patch adds a missing dcr_ind_lock.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/sysdev/dcr.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/arch/powerpc/sysdev/dcr.c linux-2.6/arch/powerpc/sysdev/dcr.c
--- linux-2.6.orig/arch/powerpc/sysdev/dcr.c 2008-01-31 16:58:32.000000000 +0300
+++ linux-2.6/arch/powerpc/sysdev/dcr.c 2008-02-01 23:17:35.000000000 +0300
@@ -137,5 +137,6 @@ void dcr_unmap(dcr_host_t host, unsigned
h.token = NULL;
}
EXPORT_SYMBOL_GPL(dcr_unmap);
-
-#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
+#else /* defined(CONFIG_PPC_DCR_NATIVE) */
+spinlock_t dcr_ind_lock;
+#endif /* !defined(CONFIG_PPC_DCR_NATIVE) */
^ permalink raw reply
* [Virtex 4 PPC] Which Linux?
From: IngoM @ 2008-02-04 13:54 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
we develop a new laser-ranging-system and our hardware freaks have choosen
the Virtex 4 FX 12 on the "AVNET FX12 Mini-Module". The system had to
deliver the raw data via UDP (12 Mbyte/sec) and on TCP the processed data
(about 6 Mbyte/sec). When you get the processed data via TCP then no data
send by UDP.
I'm confused by the following:
1) Hard-TEMAC vs. Soft-TEMAC.
Avnet provide a demo for the module which using Soft-TEMAC. If I get it
right this core has to be licenced. But when ther is a hard-TEMAC why pay
for it?
2) Linux
I'd like to build my kernel and filesystem myself. But which way to go?
Using OE, buildroot, ELDK...
Can you please provide some starting points for me?
3) Boot-Concept
The Mini-Module had only 4MB Flash. Is this enough for a root-fs?
Best Regards and thanks a lot,
Ingo
--
View this message in context: http://www.nabble.com/-Virtex-4-PPC--Which-Linux--tp15268468p15268468.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] [POWERPC] qe_lib: fix few fluffy negligences (was: Re: [PATCH 1/5] [POWERPC] qe_lib and users: get rid of most device_types and model)
From: Anton Vorontsov @ 2008-02-04 13:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080205001318.5fbc60fa.sfr@canb.auug.org.au>
On Tue, Feb 05, 2008 at 12:13:18AM +1100, Stephen Rothwell wrote:
> Hi Anton,
>
> I know this is late, but a couple of comments anyway.
>
> On Thu, 24 Jan 2008 18:39:59 +0300 Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> > @@ -65,17 +65,22 @@ static phys_addr_t qebase = -1;
> > phys_addr_t get_qe_base(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const void *prop;
> >
> > if (qebase != -1)
> > return qebase;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const void *prop = of_get_property(qe, "reg", &size);
> > - qebase = of_translate_address(qe, prop);
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return qebase;
> > + }
> > +
> > + prop = of_get_property(qe, "reg", &size);
> > + qebase = of_translate_address(qe, prop);
>
> If you don't care about the returned length (argument three to
> of_get_property), you can just pass NULL (and dispense with "size").
> Also, what happens if prop is NULL?
All this was in the old code already, I just didn't fix that.
> > @@ -153,16 +158,26 @@ static unsigned int brg_clk = 0;
> > unsigned int get_brg_clk(void)
> > {
> > struct device_node *qe;
> > + unsigned int size;
> > + const u32 *prop;
> > +
> > if (brg_clk)
> > return brg_clk;
> >
> > - qe = of_find_node_by_type(NULL, "qe");
> > - if (qe) {
> > - unsigned int size;
> > - const u32 *prop = of_get_property(qe, "brg-frequency", &size);
> > - brg_clk = *prop;
> > - of_node_put(qe);
> > - };
> > + qe = of_find_compatible_node(NULL, NULL, "fsl,qe");
> > + if (!qe) {
> > + qe = of_find_node_by_type(NULL, "qe");
> > + if (!qe)
> > + return brg_clk;
> > + }
> > +
> > + prop = of_get_property(qe, "brg-frequency", &size);
> > + if (!prop || size != sizeof(*prop))
> > + return brg_clk;
>
> You need an of_node_put(qe) before the return ...
This is new. :-) Thanks.
- - - -
From: Anton Vorontsov <avorontsov@ru.mvista.com>
Subject: [POWERPC] qe_lib: fix few fluffy negligences
One is intoduced by me (of_node_put() absence) and another was
present already (not checking for NULL).
Found by Stephen Rothwell.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/qe_lib/qe.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 5ef844d..6efbd5e 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -66,7 +66,7 @@ phys_addr_t get_qe_base(void)
{
struct device_node *qe;
unsigned int size;
- const void *prop;
+ const u32 *prop;
if (qebase != -1)
return qebase;
@@ -79,7 +79,8 @@ phys_addr_t get_qe_base(void)
}
prop = of_get_property(qe, "reg", &size);
- qebase = of_translate_address(qe, prop);
+ if (prop && size >= sizeof(*prop))
+ qebase = of_translate_address(qe, prop);
of_node_put(qe);
return qebase;
@@ -172,10 +173,9 @@ unsigned int get_brg_clk(void)
}
prop = of_get_property(qe, "brg-frequency", &size);
- if (!prop || size != sizeof(*prop))
- return brg_clk;
+ if (prop && size == sizeof(*prop))
+ brg_clk = *prop;
- brg_clk = *prop;
of_node_put(qe);
return brg_clk;
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH 7/9] powerpc: add MPC837x RDB platform support
From: Stephen Rothwell @ 2008-02-04 13:41 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, D'Abbraccio, Joe
In-Reply-To: <20080124204711.02ba14f0.kim.phillips@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi Kim,
Again, a bit late but a couple of comments.
On Thu, 24 Jan 2008 20:47:11 -0600 Kim Phillips <kim.phillips@freescale.com> wrote:
>
> +static struct of_device_id mpc837x_ids[] = {
Make this __initdata, please.
> +static void __init mpc837x_rdb_init_IRQ(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,ipic");
> + if (!np)
> + return;
> +
> + ipic_init(np, 0);
You need an of_node_put(np) here.
> +static int __init mpc837x_rdb_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + return of_flat_dt_is_compatible(root, "fsl,mpc8377rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8378rdb") ||
> + of_flat_dt_is_compatible(root, "fsl,mpc8379rdb");
You need to include asm/prom.h to use the flattened device tree accessors.
--
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
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