On Tuesday 05 February 2008 16:38, Josh Boyer wrote:
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
I agree.
Note that dropping support
On Tue, 05 Feb 2008 13:32:33 -0500 Jeff Garzik [EMAIL PROTECTED] wrote:
it's trivial enough to not matter, and faster to just... applied
(if you'll pardon the bad grammar)
Thanks.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
Josh Boyer wrote:
On Thu, 31 Jan 2008 10:14:58 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
On Wednesday 16 January 2008, Josh Boyer wrote:
On Wed, 16 Jan 2008 20:53:59 +1100
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Wednesday 06 February 2008, Jeff Garzik wrote:
Jeff, any chance this can get into .25 soon? I have another patch
queued up behind this one that requires it, and I don't see it in any
of your trees or branches.
Or, if you aren't opposed, I can take it through Paul's tree with your
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/rgmii.c |1 -
Benjamin Herrenschmidt wrote:
The e1000 driver stores the content of the PCI resources into
unsigned long's before ioremapping. This breaks on 32 bits
platforms that support 64 bits MMIO resources such as ppc 44x.
This fixes it by removing those temporary variables and passing
directly the
On Wed, 6 Feb 2008 13:21:59 +0100
Stefan Roese [EMAIL PROTECTED] wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
Acked-by:
On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the newemac driver needs an update to only rely on compatible
property.
What about systems using an older dts, such as one kexec:ing from an
older
On Wed, Feb 06, 2008 at 10:23:40AM -0600, Josh Boyer wrote:
On Wed, 6 Feb 2008 10:01:57 -0600
Olof Johansson [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
With the removal the the rgmii-interface device_type property from the
dts files, the
On 12/17/06, David Woodhouse [EMAIL PROTECTED] wrote:
You still get to 'accidentally' do 64-bit arithmetic in-kernel that way
though. Might be better just to provide __ucmpdi2, just as we have for
the other functions which are required from libgcc
It'd be better just to fix the compiler
From: Grant Likely [EMAIL PROTECTED]
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts
Grant Likely wrote:
-ifneq ($(CONFIG_DEVICE_TREE),)
-image-$(CONFIG_PPC_8xx) += cuImage.8xx
-image-$(CONFIG_PPC_EP88XC) += zImage.ep88xc
-image-$(CONFIG_EP405)+= zImage.ep405
-image-$(CONFIG_8260) += cuImage.pq2
On 2/6/08, Scott Wood [EMAIL PROTECTED] wrote:
-ifneq ($(CONFIG_REDBOOT),)
-image-$(CONFIG_PPC_8xx) += zImage.redboot-8xx
-endif
+# Board ports in arch/powerpc/platform/8xx/Kconfig
+image-$(CONFIG_PPC_MPC86XADS)+= cuImage.mpc866ads
Grant Likely wrote:
diff --git a/arch/powerpc/boot/cuboot-hpc2.c
b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
similarity index 100%
rename from arch/powerpc/boot/cuboot-hpc2.c
rename to arch/powerpc/boot/cuboot-mpc7448hpc2.c
This is not a proper patch.
No rule to make target
On 2/6/08, Geoff Levand [EMAIL PROTECTED] wrote:
Grant Likely wrote:
diff --git a/arch/powerpc/boot/cuboot-hpc2.c
b/arch/powerpc/boot/cuboot-mpc7448hpc2.c
similarity index 100%
rename from arch/powerpc/boot/cuboot-hpc2.c
rename to arch/powerpc/boot/cuboot-mpc7448hpc2.c
This is not a
From: Grant Likely [EMAIL PROTECTED]
Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built
This patch moves the selection of the default .dts
The following patches make some small corrections to allow cpu dlpar remove to
work again. Cpu dlpar remove is currently failing because the cpu we are
removing may still have irq's pinned to it or have it's CPPR reset during
the cpu teardown process.
-Nathan Fontenot
The affinity mask in the virq descriptor needs to be set before we reset the
affinity for the virq. Without doing this the call to get the new irq server
fails and we end up leaving the virq pinned to the cpu we are removing.
This does not fail the cpu remove from the kernel, but it does
This patch splits off the kexec path bits of the xics_teardown_cpu()
routine into its own xics_kexec_teardown_cpu() routine. With the
previous combined routine the CPPR for a cpu that is being removed may have its
CPPR reset in the plpar_eoi() call (which explicitly sets the CPPR to a non-zero
It appears that xics.c has its own of_get_cpu_node(). Remove this and use the
common one from prom.c.
Signed-off-by: Nathan Fontenot [EMAIL PROTECTED]
---
Index: linux-2.6/arch/powerpc/platforms/pseries/xics.c
===
---
The xics code does update the default server information when the boot cpu is
removed. This patches recognizes when the boot cpu is being removed and updates
the appropriate information based on the new 'boot cpu'.
Failure to update this information can causes us to leave irqs pinned to cpus
(resend; including the mailing list this time)
Paul,
Please pull my mpc52xx tree. It contains the MPC512x work which John
Rigby has been doing. I should have got these out to you sooner, but
I forgot about them. :-(
Cheers,
g.
The following changes since commit
Signed-off-by: Nick Spence [EMAIL PROTECTED]
Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
drivers/mtd/nand/Kconfig |9 +
drivers/mtd/nand/Makefile|1 +
drivers/mtd/nand/fsl_elbc_nand.c | 1244 ++
3 files changed, 1254 insertions(+), 0
Olof Johansson wrote:
Yep, pretty much. It's real easy to write a new backend to hvc, I've got
a couple for various bringup environments here as well.
Could you tell me which kernel options I need to set/unset in order to get my
driver to be called? My driver loads and initializes, but its
Guys,
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device should use for DMA. I'll be
needing this shortly because I need to implement swiotlb to deal with
PCI and large
Manish Ahuja writes:
Initial patch for reserving memory in early boot, and freeing it later.
If the previous boot had ended with a crash, the reserved memory would contain
a copy of the crashed kernel data.
[snip]
+static void __init reserve_crashed_mem(void)
+{
+ unsigned long base,
Badari Pulavarty writes:
Thank you for your input and suggestions. Does this look reasonable
to you ?
Thanks,
Badari
For memory remove, we need to clean up htab mappings for the
section of the memory we are removing.
This patch implements support for removing htab bolted mappings
On Wed, 2008-02-06 at 18:32 -0600, Becky Bruce wrote:
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device should use for DMA. I'll be
needing this shortly because I
On Feb 6, 2008, at 7:26 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-02-06 at 18:32 -0600, Becky Bruce wrote:
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device
On Feb 6, 2008, at 7:26 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-02-06 at 18:32 -0600, Becky Bruce wrote:
I've been looking at converting 32-bit powerpc's DMA code over to the
64-bit method, where there is a dma_ops structure inside archdata
that tells us which operations a device
On Wed, 2008-02-06 at 20:39 -0600, Kumar Gala wrote:
I'd prefer so yes.
Can you explain why? Got no issue with doing this, but its good to
know hy.
Just in case ... let's not modify 64 bits behaviour especially to
something that will ultimately go away. I prefer failing if DMA ops are
On Wed, 2008-02-06 at 10:35 -0600, Olof Johansson wrote:
On Wed, Feb 06, 2008 at 10:23:40AM -0600, Josh Boyer wrote:
On Wed, 6 Feb 2008 10:01:57 -0600
Olof Johansson [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 01:21:59PM +0100, Stefan Roese wrote:
With the removal the the
Hi,
On Wed, Feb 06, 2008 at 02:34:24PM -0700, Grant Likely wrote:
John Rigby (4):
[POWERPC] mpc512x: Basic platform support
[POWERPC] mpc512x: Device tree for MPC5121 ADS
[POWERPC] mpc512x: Factor out 5200 dependencies from 52xx psc driver
[POWERPC] mpc512x: Add
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git for-2.6.25
to get another powerpc update for 2.6.25. Various bug fixes have come
in, plus there are a few patches that I missed from the previous set.
Thanks,
Paul.
arch/powerpc/Kconfig
I just did a git pull of Josh's tree, and
arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
glossing over the linuxppc-dev emails, so forgive me if this already
came up.
It looks like, at least for the Warp, CLOCK_REALTIME_RES is not defined
so asm-offsets.c gets an error.
Ok, here is my best shot at removing the warnings. It seems to me that
functions called from a dev_init section should not be dev_exit.
Cheers,
Sean
Signed-off-by: Sean MacLennan [EMAIL PROTECTED]
---
diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
I just did a git pull of Josh's tree, and
arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
glossing over the linuxppc-dev emails, so forgive me if this already
came up.
Hmm very sorry guys. I /did/ build
Tony Breeds wrote:
Yeah it's needed, so this patch isn;t the best solution. I'll fix this
ASAP.
Great! Thanks a lot.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On 2/6/08, Paul Mackerras [EMAIL PROTECTED] wrote:
Tony Breeds (1):
[POWERPC] Use a sensible default for clock_getres() in the VDSO
Hmm, this commit breaks ppc32 (mpc5200) build with my cross compiler
(ELDK 4.1; gcc 4.0; binutils 2.16.1). Is this a bug in the code or
the compiler?
On Wed, Feb 06, 2008 at 10:26:06PM -0700, Grant Likely wrote:
On 2/6/08, Paul Mackerras [EMAIL PROTECTED] wrote:
Tony Breeds (1):
[POWERPC] Use a sensible default for clock_getres() in the VDSO
Hmm, this commit breaks ppc32 (mpc5200) build with my cross compiler
(ELDK 4.1; gcc 4.0;
On 2/6/08, Grant Likely [EMAIL PROTECTED] wrote:
On 2/6/08, Olof Johansson [EMAIL PROTECTED] wrote:
mpc52xx_defconfig no longer builds for me, and the two latter of the
above patches are the ones that touch that file:
Gah! I caused some patch damage when I rebased the patches. I'll
send
Since implementing highres timers on powerpc the clock_getres syscall
has reported different resolutions due to the vdso using the a low res
value. In the patch d7f71674ad7c3c4467e48f6ab9e85516dae2720
([POWERPC] Use a sensible default for clock_getres() in the VDSO), the
powerpc vdso was updated
Christoph Hellwig wrote:
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
I just did a git pull of Josh's tree, and
arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
glossing over the linuxppc-dev emails, so forgive me if this already
came up.
I
Sean MacLennan wrote:
Christoph Hellwig wrote:
On Thu, Feb 07, 2008 at 12:49:34AM -0600, Nathan Lynch wrote:
Christoph Hellwig wrote:
On Wed, Feb 06, 2008 at 11:43:41PM -0500, Sean MacLennan wrote:
I just did a git pull of Josh's tree, and
Nathan Lynch wrote:
CLOCK_REALTIME_RES is defined in include/asm/asm-offsets.h, which is
generated from asm-offsets.c as part of the build.
Your config builds fine here, so please post the actual error that you
are seeing during the build?
Mine is off one line from Christoph's because I
45 matches
Mail list logo
