On Saturday 23 February 2008, Paul Mackerras wrote:
> Stefan Roese writes:
> > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>
> That's a very uninformative commit message. :)
>
> How about putting a brief description of the AMCC 460 family in here?
You're right. I was a little bit lazy. :)
I'l
Stefan Roese writes:
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Put a brief description of the Canyonlands in the patch description.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Stefan Roese writes:
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
That's a very uninformative commit message. :)
How about putting a brief description of the AMCC 460 family in here?
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
htt
Stefan Roese writes:
> Tested on AMCC Canyonlands eval board.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
With 173 lines of code added, you could spend a paragraph in the patch
description telling us why the patch is doing what it's doing the way
it's doing it. Perhaps even tell us why
On Fri, Feb 22, 2008 at 03:42:03PM -0800, David Brownell wrote:
> On Monday 10 December 2007, Anton Vorontsov wrote:
> > On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
>
> > > The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> > > tell whether that programming i
David Gibson wrote:
> On Tue, Feb 19, 2008 at 08:18:19PM -0500, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day David Gibson mumbled:
In light of the recently discovered bug with NOP handling, this adds
some more testcases for NOP handling. Specifically, it adds
This patch restores the reset on restart functionality to 40x-based
platforms that was formerly provided--but not used in arch/powerpc--by
abort() in head_40x.S. This functionality is now provided by
ppc40x_reset_system(char *) in a fashion similar to that of the 44x-based
platforms.
Compiled, lin
On Monday 10 December 2007, Anton Vorontsov wrote:
> On Mon, Dec 10, 2007 at 02:55:24PM -0800, David Brownell wrote:
> > The point of CONFIG_GENERIC_GPIO is to be *the* conditional used to
> > tell whether that programming interface is available ... starting
> > from "#include ", and including all
> _However_ there are significant code changes in there, and I don't
> actually understand that code (well, I admit I haven't tried),
Yeah, it's written in 70's style C. Yuck.
> so it could definitely use a bit of a commit message explaining
> the rationale
Right. I had to fix git-send-email a
> The flag is in POSSIBLE. I now use this code in the platform probe
> function to nop out the code affected by the flag:
>
> cur_cpu_spec->cpu_features &= ~CPU_FTR_NEED_COHERENT;
> /* Patch out unwanted feature. */
> do_feature_fixups(cur_cpu_spec->cpu_features,
> PTRRELOC(&__sta
On Thu, 2008-02-21 at 21:07 +0100, Gerhard Pircher wrote:
> Hi,
>
> I'm wondering how to disable or enable CPU features based on the board the
> kernel is running on. In my case I want to disable the
> CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the machine.
> I tried to clear t
On Fri, 2008-02-22 at 21:01 +0100, Segher Boessenkool wrote:
> Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
> ---
Amen !
_However_ there are significant code changes in there, and I don't
actually understand that code (well, I admit I haven't tried),
so it could definitely use a bit of
On Friday 22 February 2008, Benjamin Herrenschmidt wrote:
> On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > the internal loopback mode. Clear these bits so that both EMACs
> > don't use loopback mode as default.
> >
> > S
On Friday 22 February 2008, Josh Boyer wrote:
> On Fri, 22 Feb 2008 09:32:12 +0100
>
> Stefan Roese <[EMAIL PROTECTED]> wrote:
> > 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> > the internal loopback mode. Clear these bits so that both EMACs
> > don't use loopback mode as defaul
On Fri, 2008-02-22 at 09:32 +0100, Stefan Roese wrote:
> 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> the internal loopback mode. Clear these bits so that both EMACs
> don't use loopback mode as default.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
> ---
> I'm not sure
On Fri, 22 Feb 2008 22:15:58 +0300
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
> >> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
> >> and because of that it can't find PHY
On Fri, 22 Feb 2008 22:28:17 +0300
Valentine Barshak <[EMAIL PROTECTED]> wrote:
> This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
> The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
> allows controlling each EMAC clock spearately as opposed to global
Signed-off-by: Segher Boessenkool <[EMAIL PROTECTED]>
---
arch/powerpc/math-emu/op-2.h | 75 -
1 files changed, 29 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/math-emu/op-2.h b/arch/powerpc/math-emu/op-2.h
index 7d6f17c..16d3e3c 100644
--- a
On Fri, 22 Feb 2008 09:32:12 +0100
Stefan Roese <[EMAIL PROTECTED]> wrote:
> 405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
> the internal loopback mode. Clear these bits so that both EMACs
> don't use loopback mode as default.
>
> Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
>
This patch adds ibm_newemac phy clock workaround for 440EP/440GR emacs.
The code is based on the previous ibm_emac driver stuff. The 440EP/440GR
allows controlling each EMAC clock spearately as opposed to global clock
selection for 440GX.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
d
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
and because of that it can't find PHY chip. The older ibm_emac driver had
a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL macros which
toggle the Ethernet Clock Select bit in the SDR0_MFR register. This patch
Move the "&& skb->ip_summed == CHECKSUM_PARTIAL" part out of
emac_has_feature parameters.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/net/ibm_newemac/core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -pruN linux-2.6.orig/drivers/net/ibm_newemac/core.c
Benjamin Herrenschmidt wrote:
> On Thu, 2008-02-21 at 17:46 +0300, Valentine Barshak wrote:
>> The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
>> and because of that it can't find PHY chip. The older ibm_emac driver had
>> a workaround for that: the EMAC_CLK_INTERNAL/EMAC
Hi,
Original-Nachricht
> Datum: Fri, 22 Feb 2008 11:24:38 -0600
> Von: Milton Miller <[EMAIL PROTECTED]>
> An: Gerhard Pircher <[EMAIL PROTECTED]>
> CC: ppcdev
> Betreff: Re: How to dynamically disable/enable CPU features?
> We handle cpu features in a couple of ways:
> (1) we
On Feb 22, 2008, at 03:50, Philippe De Muyter wrote:
> Dear list,
>
> I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
> specific gcc.
>
> I then got tan infinity of "SPE used in kernel" messages. Looking
> at the
> sources I ifdeffed out the printk call in KernelSPE, and
At Fri Feb 22 07:07:58 EST 2008, Gerhard Pircher wrote:
> I'm wondering how to disable or enable CPU features based on the board
> the
> kernel is running on. In my case I want to disable the
> CPU_FTR_NEED_COHERENT flag for 74xx CPUs, because it locks up the
> machine.
> I tried to clear the fla
So, like, the other day Scott Wood mumbled:
> >
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> I use it for embedding guest device trees in a hypervisor's device tree.
Why wouldn't we instead, say, extend the source sytax
to allow a
This patch fixes build and few warnings when ATA_VERBOSE_DEBUG
is defined:
CC drivers/ata/sata_fsl.o
drivers/ata/sata_fsl.c: In function ‘sata_fsl_fill_sg’:
drivers/ata/sata_fsl.c:338: warning: format ‘%x’ expects type ‘unsigned int’,
but argument 3 has type ‘void *’
drivers/ata/sata_fsl.c
On Fri, Feb 22, 2008 at 10:24:56AM -0600, Jon Loeliger wrote:
> So, like, the other day Scott Wood mumbled:
> > >
> > > Can I ask; what is the intended usage of such a thing? How large
> > > would a typical binary blob be?
> >
> > I use it for embedding guest device trees in a hypervisor's devic
On Thu, Feb 21, 2008 at 11:05:58PM -0700, Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> > A property's data can be populated with a file's contents
> > as follows:
> >
> > node {
> > prop = /incbin/("path/to/data");
> > };
> >
> > A subs
On Fri, Feb 22, 2008 at 2:02 AM, David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> > Can I ask; what is the intended usage of such a thing? How large
> > would a typical binary blob be?
>
> Device firmware?
That's what I was wondering abou
Marvell PHY m88e (not sure about other models, but think they too) works in
two modes: fiber and copper. In Marvell PHY driver (that we have in current
community kernels) code supported only copper mode, and this is not
configurable,
bits for copper mode are simply written in registers during
> I wonder why a kernel configured for E500 and compiled by a E500-specific gcc
> triggers this message. Is it invalid to use SPE instructions in the kernel
> or do I misunderstand the message ?
I think it's like floating point/altivec, we don't always save the FP
registers on kernel/userspace
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
> My apologies for taking so long on this. Digging through gcc history
> isn't exactly fun :)
No problem. Thanks for tackling the issue.
> Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
> has been around since 2001. See
On Fri, 22 Feb 2008 02:41:36 +0300
Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 21, 2008 at 03:20:10PM -0600, Scott Wood wrote:
> > Anton Vorontsov wrote:
> > > On Thu, Feb 21, 2008 at 02:06:58PM -0600, Scott Wood wrote:
> > >> Current u-boots don't support device trees at all on 8xx.
Dear list,
I have just compiled linux-2.6.24 for a MPC8540 target using a MPC8540
specific gcc.
I then got tan infinity of "SPE used in kernel" messages. Looking at the
sources I ifdeffed out the printk call in KernelSPE, and I now have a
silent kernel, that seems to work fine.
Is there somethi
Hi Jean,
>> +/*
>> + * Wait for patch from Jon Smirl
>> + * #include "powerpc-common.h"
>> + */
>
> It doesn't make sense to merge this comment upstream.
I know you don't like the patch from Jon Smirl and you also explained your
reasons.
Fortunately, I2c no longer uses numeric device IDs but na
Grant Likely wrote:
> On Wed, Feb 20, 2008 at 12:19 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
>> A property's data can be populated with a file's contents
>> as follows:
>>
>> node {
>> prop = /incbin/("path/to/data");
>> };
>>
>> A subset of a file can be included by passing start and
On Thu, 2008-02-21 at 23:05 -0700, Grant Likely wrote:
> Can I ask; what is the intended usage of such a thing? How large
> would a typical binary blob be?
Device firmware?
--
dwmw2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlab
Fix typos on Kconfig for PowerPC 4xx on-chip ethernet driver.
Signed-off-by: Satoru Takeuchi <[EMAIL PROTECTED]>
---
Index: 2.6.25-rc2/drivers/net/ibm_newemac/Kconfig
===
--- 2.6.25-rc2.orig/drivers/net/ibm_newemac/Kconfig 2008-0
405EX(r) has SDR0_MFR[E0CS/E1CS] set after reset. This selects
the internal loopback mode. Clear these bits so that both EMACs
don't use loopback mode as default.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
I'm not sure if this should be done here in the board platform code,
or in the newe
41 matches
Mail list logo
