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 su
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/
pgpOGv
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 <[EMAI
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
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 |
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
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-
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, 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 newemac driver needs an update to only rely on compatible
> >
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 f
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 compil
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 f
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
> -i
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
> > +i
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 `arch/powerpc
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
>
>
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 f
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 preven
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
===
--- linux-2.6.o
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 99e139126ab2e84be67969650f92eb
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(+)
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 b
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 map
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 becau
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
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 d
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 a
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 remov
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
On Tuesday 05 February 2008, Michael Ellerman wrote:
> The fix is to add two entries to the of_device_id table, one that looks
> for type = "opb" and the other compatible = "ibm,opb".
>
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
_
Hi Paul,
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.25
to pick up some fixes that should go in for 2.6.25 and Grant's Virtex
tree.
thx,
josh
Grant Likely (2):
[POWERPC] Fix incorrectly tagged __devinitdata structures
[POWERPC] Eli
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
It appears that with the U3 northbridge, if the processor is in NAP
mode the whole time while waiting for an SMU command to complete,
then the SMU will fail. It could be related to the weird backward
mechanism the SMU uses to get to system memory via i2c to the
northbridge that doesn't operate prop
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. T
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 have the same problem with curre
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 e6c69f7
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/ buil
On 2/6/08, Olof Johansson <[EMAIL PROTECTED]> wrote:
> 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 520
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?
[E
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;
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
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
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
> > > arch/powerpc/kernel/asm-offsets.c does not compile. I have only been
> > > glossing ov
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
arch/powerpc/kernel/asm-offsets.c doe
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.
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 becaus
53 matches
Mail list logo
