On 10/29/07, Dale Farnsworth <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> > This commit made an incorrect assumption:
> > --
> > Author: Lennert Buytenhek <[EMAIL PROTECTED]>
> > Date: Fri Oct 19 04:10:10 2007 +0200
> >
> > mv643xx_eth: Mo
Andreas Schwab wrote:
> Jan Dittmer <[EMAIL PROTECTED]> writes:
>
>> Same error, you write above that a newer compiler version should
>> not need -m32 or --with-cpu=default32 any more?
>
> ??? Where did I say that?
Your mail from 2007-10-29 4:39 pm (CET)
>> Your compiler still needs -m32 to ge
thanks for your reply.
> >
> > WARNING: vmlinux.o(.text+0x10f5c): Section mismatch: reference
> > to .init.text:cpm_muram_init (between 'cpm2_reset' and
> > 'cpm2_smc_clk_setup')
> >
> It should be fixed, but its highly unlikely you'll see a problem
> unless you start trying to build core parts o
On 10/29/07, David Gibson <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote:
> > It's probably more appropriate to have the flash partition layout in
> > the u-boot environment and have u-boot populate the partition
> > information in the device tree.
>
> Tha
The 44x family has an interesting "feature" which is a virtually
tagged instruction cache (yuck !). So far, we haven't dealt with
it properly, which means we've been mostly lucky or people didn't
report the problems, unless people have been running custom patches
in their distro...
This is an atte
On Mon, 2007-10-29 at 13:32 -0500, Will Schmidt wrote:
> [Powerpc V2] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb().A new hel
Without this patch I get the following build failure
CC arch/powerpc/platforms/celleb/setup.o
arch/powerpc/platforms/celleb/setup.c:151: error: 'generic_calibrate_decr'
undeclared here (not in a function)
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/celleb/set
On Oct 28, 2007, at 9:57 PM, Paul Mackerras wrote:
> The decrementer in Book E and 4xx processors interrupts on the
> transition from 1 to 0, rather than on the 0 to -1 transition as on
> 64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
>
> This fixes the problem by making set_dec su
On Oct 29, 2007, at 5:46 PM, Benjamin Herrenschmidt wrote:
> On 4xx CPUs, the current implementation of flush_tlb_page() uses
> a low level _tlbie() assembly function that only works for the
> current PID. Thus, invalidations caused by, for example, a COW
> fault triggered by get_user_pages() fro
If future dtb version > 17 are defined, that are still backwards
compatible with v16, libfdt will of course be able to read and
understand them. However, when modifying such a tree, it can't
guarantee that it won't clobber additional structure from the new
version which it doesn't know about. The
The mangle-layout testcase/utility had a leftover debugging printf().
This patch removes it.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: dtc/tests/mangle-layout.c
===
--- dtc.orig/tests/mangle-layout.c 2007-10-29 15:5
On Mon, 29 Oct 2007, Valentine Barshak wrote:
> This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
> The code is based on the original NDFC driver by Thomas Gleixner, but
> since it's been changed much and has initialization/clean-up completely
> reworked it's been put into a s
On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote:
> On 10/29/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
> > David Gibson wrote:
> > > On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> > >> Grant Likely wrote:
> > >>> On 10/25/07, Martin Krause <[EMAIL PROTECTED]
On Mon, Oct 29, 2007 at 04:22:13PM -0500, Olof Johansson wrote:
[snip]
> I don't see how switching the property name from "device_type" to
> "class" is going to stop people from misunderstanding it's intended
> use. There's nothing inherently more understandable in calling it
> "class" -- it also i
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
>
> Here's an example of what I'm trying to get at-- take
> a node from a FSL device tree. The ideas I've heard
> for expressing the class are like this--
>
> #1 don't express any class at all:
>
> [EMAIL PROTECTED] {
>
On Mon, Oct 29, 2007 at 10:27:24AM -0700, Dale Farnsworth wrote:
> Scott wrote:
> > Personally, I'm fine with just using name and compatible, but others such as
> > Stuart have expressed a desire for something to formally indicate compliance
> > with a standard binding. I don't think we should exp
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
> > I think device_type, compatible and model properties fulfil
> > this already, they simply aren't being used correctly.
>
> device_type has a few drawbacks, though:
>
> 1.
On Mon, Oct 29, 2007 at 11:29:02PM +0300, Valentine Barshak wrote:
> Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell
> and remove add_mtd_partitions from parse_partitions to avoid duplicate
> mtd device registration for RedBoot partitions.
>
> Signed-off-by: Valentin
Jan Dittmer <[EMAIL PROTECTED]> writes:
> Same error, you write above that a newer compiler version should
> not need -m32 or --with-cpu=default32 any more?
??? Where did I say that?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnb
Hi Will,
Just a trivial comment ...
On Mon, 29 Oct 2007 13:32:19 -0500 Will Schmidt <[EMAIL PROTECTED]> wrote:
>
> +static inline int esids_match(unsigned long addr1, unsigned long addr2)
> +{
> + int esid_1t_count;
> +
> + /* System is not 1T segment size capable. */
> + if (!cpu_has
> Nice, I like it! I wonder if it would make sense to (space) pad the
> ESID/VSID fields so they line up, it'd make output just a little tidier.
>
> (If you end up changing that, please also break the long printf lines
> in two.)
>
> Beside that it looks good to me! :)
Can you also print out th
This commit made an incorrect assumption:
--
Author: Lennert Buytenhek <[EMAIL PROTECTED]>
Date: Fri Oct 19 04:10:10 2007 +0200
mv643xx_eth: Move ethernet register definitions into private header
Move the mv643xx's ethernet-related register definitions from
include/linux/mv643x
Andreas Schwab wrote:
> Anton Blanchard <[EMAIL PROTECTED]> writes:
>
>> One way to make this go away would be to build binutils as biarch:
>>
>> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
>
> If you configure your toolchain for powerpc64-linux you get a biarch
> tool
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
> #4 use "compatible"
>
> [EMAIL PROTECTED] {
> compatible = "fsl,ucc_geth","[official spec],network";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
>
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <[EMAIL PROTECTED]>
> Date: Fri Oct 19 04:10:10 2007 +0200
>
> mv643xx_eth: Move ethernet register definitions into private header
>
> Mo
On 4xx CPUs, the current implementation of flush_tlb_page() uses
a low level _tlbie() assembly function that only works for the
current PID. Thus, invalidations caused by, for example, a COW
fault triggered by get_user_pages() from a different context will
not work properly, causing among other thi
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <[EMAIL PROTECTED]>
> Date: Fri Oct 19 04:10:10 2007 +0200
>
> mv643xx_eth: Move ethernet register definitions into private header
>
> Mov
Andreas Schwab wrote:
> Jan Dittmer <[EMAIL PROTECTED]> writes:
>
>> Andreas Schwab wrote:
>>> Jan Dittmer <[EMAIL PROTECTED]> writes:
>>>
$ powerpc64-linux-gcc-4.0.4 -v
Using built-in specs.
Target: powerpc64-linux
Configured with: ../configure --prefix=/usr/cc217
--exec-
[adding back gdb list]
On Tue, Oct 30, 2007 at 07:35:06AM +1100, Benjamin Herrenschmidt wrote:
>
> > Did a boot test on my ebony board with this patch included. It seems
> > to be happy about things so far. If Matt gets around to trying this
> > out and it works, we should probably look at gett
Jan Dittmer <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote:
>> Jan Dittmer <[EMAIL PROTECTED]> writes:
>>
>>> $ powerpc64-linux-gcc-4.0.4 -v
>>> Using built-in specs.
>>> Target: powerpc64-linux
>>> Configured with: ../configure --prefix=/usr/cc217
>>> --exec-prefix=/usr/cc217/powerpc64 --targ
On Mon, Oct 29, 2007 at 07:37:04AM -0700, Yoder Stuart-B08248 wrote:
>
> We've had some discussions internally here at Freescale among
> various PPC Linux developers about the device_type property
> and how 'classes' of devices should be represented in the
> device tree.
>
> Taking a long term v
> Did a boot test on my ebony board with this patch included. It seems
> to be happy about things so far. If Matt gets around to trying this
> out and it works, we should probably look at getting this into 2.6.24.
>
> Oh, and I'd need a signed-off-by for it Ben :)
Sure, I'll send you a cleaned
On Mon, Oct 29, 2007 at 02:59:27PM -0500, Will Schmidt wrote:
>
> [powerpc] update xmon slb code
>
> adds a bit more detail to the xmon SLB output. When the valid bit is
> set, This displays the ESID and VSID values, as well as decoding the
> segment size. (1T or 256M). This supresses the outpu
On Oct 29, 2007, at 2:38 PM, Phil Terry wrote:
> Can anyone tell me what the status of these are? What kernel
> release are
> they targetted for? Currently I'm trying to work with 2.6.23 plus
> these
> patches locally.
hopefully 2.6.25. I'd like to get the documentation updates in
2.6.24
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, October 29, 2007 2:44 PM
> To: Yoder Stuart-B08248
> Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>
> Yoder Stuart-B08248 wrote:
> > Here's an
On Mon, 29 Oct 2007 07:08:24 -0500
Josh Boyer <[EMAIL PROTECTED]> wrote:
> On Sat, 27 Oct 2007 17:32:02 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > Allright, so Matt, let me know if that fixes your problem with gdb, and
> > I'll clean the patch up a bit and submit it. I want t
Andreas Schwab wrote:
> Jan Dittmer <[EMAIL PROTECTED]> writes:
>
>> $ powerpc64-linux-gcc-4.0.4 -v
>> Using built-in specs.
>> Target: powerpc64-linux
>> Configured with: ../configure --prefix=/usr/cc217
>> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
>> --disable-shared --disable-
[powerpc] update xmon slb code
adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
I debated a bit on whether
Can anyone tell me what the status of these are? What kernel release are
they targetted for? Currently I'm trying to work with 2.6.23 plus these
patches locally.
Cheers
Phil
On Thu, 2007-07-26 at 16:42 +0800, Zhang Wei wrote:
> These patches are the version 3 patches for RapidIO with dts update a
Yoder Stuart-B08248 wrote:
> Here's an example of what I'm trying to get at-- take
> a node from a FSL device tree. The ideas I've heard
> for expressing the class are like this--
>
> #1 don't express any class at all:
>
> [EMAIL PROTECTED] {
> compatible = "fsl,ucc_geth";
>
Use of_get_next_child for proper ref counting as suggested by Stephen Rothwell
and remove add_mtd_partitions from parse_partitions to avoid duplicate
mtd device registration for RedBoot partitions.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
drivers/mtd/maps/physmap_of.c | 13 +
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = "fsl,ucc_geth";
model = "UCC";
device-id = <3>;
Matt Sealey wrote:
> I don't see how this makes anything any better.
>
> Under Open Firmware, if device_type is "display", then it had better
> act as a display through the client interface, interpose it's framebuffer
> methods properly and suchlike.
>
> In FDT, what is the purpose of the binding
NDFC DTS entry for PowerPC 440EPx Sequoia board.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts | 23 +++
1 files changed, 23 insertions(+)
diff -pruN linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts
linux-2.6/arch/powerpc/boot/d
PowerPC 44x NanD Flash Controller (NDFC) bindings.
Signed-off-by: Valentine Barshak <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 64 +++
1 files changed, 64 insertions(+)
--- linux-2.6.orig/Documentation/powerpc/booting-without-of.txt 2007-10-2
[Powerpc] include udbg.h when using udbg_printf
this fixes the error
error: implicit declaration of function ‘udbg_printf’
We have a few spots where we reference udbg_printf() without #including
udbg.h. These are within #ifdef DEBUG blocks, so unnoticed until we do
a #define DEBUG or #d
This adds support of the built-in PowerPC 44x NanD Flash Controller (NDFC)
based on the OF description. This version supports both separate mtd devices on
each NDFC bank and mtd devices spread across identical chips attached to NDFC
banks depending on the device tree settings. This is based on the
Matt Sealey wrote:
> Scott Wood wrote:
>> On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
>>> I think device_type, compatible and model properties fulfil this
>>> already, they simply aren't being used correctly.
>>
>> device_type has a few drawbacks, though:
>>
>> 1. You can only sp
This adds a device-tree aware PowerPC 44x NanD Flash Controller driver
The code is based on the original NDFC driver by Thomas Gleixner, but
since it's been changed much and has initialization/clean-up completely
reworked it's been put into a separate ndfc_of.c file. This version
supports both sepa
Dale Farnsworth wrote:
> Scott wrote:
>> Personally, I'm fine with just using name and compatible, but others such as
>> Stuart have expressed a desire for something to formally indicate compliance
>> with a standard binding. I don't think we should expand the use of
>> device_type in any case.
>
Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
>> I think device_type, compatible and model properties fulfil
>> this already, they simply aren't being used correctly.
>
> device_type has a few drawbacks, though:
>
> 1. You can only specify one type, whereas with
[Powerpc V2] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb().A new helper function called
esids_match() contains the logic for deciding
Scott wrote:
> Personally, I'm fine with just using name and compatible, but others such as
> Stuart have expressed a desire for something to formally indicate compliance
> with a standard binding. I don't think we should expand the use of
> device_type in any case.
I agree that the existing comp
Hello.
Paul Mackerras wrote:
> The decrementer in Book E and 4xx processors interrupts on the
> transition from 1 to 0, rather than on the 0 to -1 transition as on
> 64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors.
> This fixes the problem by making set_dec subtract 1 from the count
On Mon, Oct 29, 2007 at 03:20:56PM +, Matt Sealey wrote:
> I think device_type, compatible and model properties fulfil
> this already, they simply aren't being used correctly.
device_type has a few drawbacks, though:
1. You can only specify one type, whereas with a new property we could
defin
On 10/29/07, Marian Balakowicz <[EMAIL PROTECTED]> wrote:
> David Gibson wrote:
> > On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
> >> Grant Likely wrote:
> >>> On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
> > [snip]
> On a board with 16 MiB FLASH for example the
Jan Dittmer <[EMAIL PROTECTED]> writes:
> $ powerpc64-linux-gcc-4.0.4 -v
> Using built-in specs.
> Target: powerpc64-linux
> Configured with: ../configure --prefix=/usr/cc217
> --exec-prefix=/usr/cc217/powerpc64 --target=powerpc64-linux
> --disable-shared --disable-werror --disable-nls --disable-t
On 10/29/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Domen Puncer wrote:
> > drivers/net/Kconfig | 24
> > drivers/net/Makefile |4
> > drivers/net/fec_mpc52xx.c | 1112
> > ++
> > drivers/net/fec_mpc52xx.h | 313 +
Yoder Stuart-B08248 wrote:
> We've had some discussions internally here at Freescale among
> various PPC Linux developers about the device_type property
> and how 'classes' of devices should be represented in the
> device tree.
>
> The initial list of official classes would be small--
> "cpu","me
Hi,
> If you configure your toolchain for powerpc64-linux you get a biarch
> toolchain by default.
I was wondering about people using pre biarch gcc toolchains. But I take
your point - I'm guessing binutils has been biarch for a long time.
Since we are only calling binutils functions in boot/wr
David Gibson wrote:
> On Thu, Oct 25, 2007 at 05:46:19PM +0200, Marian Balakowicz wrote:
>> Grant Likely wrote:
>>> On 10/25/07, Martin Krause <[EMAIL PROTECTED]> wrote:
> [snip]
On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
partition could not be used. "big-fs",
Anton Blanchard <[EMAIL PROTECTED]> writes:
> One way to make this go away would be to build binutils as biarch:
>
> # configure --target=powerpc-linux --enable-targets=powerpc64-linux ...
If you configure your toolchain for powerpc64-linux you get a biarch
toolchain by default.
Andreas.
--
An
We've had some discussions internally here at Freescale among
various PPC Linux developers about the device_type property
and how 'classes' of devices should be represented in the
device tree.
Taking a long term view, the question I'd like to pose is
how should classes of device should be identi
Thomas Gleixner wrote:
> On Fri, 26 Oct 2007, Valentine Barshak wrote:
>> The major difference is that the original implements each chip connected
>> NDFC banks as a
>> separate MTD device. Here I try to have one MTD device spread on all chips
>> found.
>> However, the chips should have equal ID'
Hi,
Jan is seeing the following fail:
WRAParch/powerpc/boot/zImage.pmac
powerpc-linux-objcopy: vmlinux: File format not recognized
He is using a cross compile toolchain invoked with the following command
line:
# make HOSTCC=gcc-4.0 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-
CROSS32_COMPI
Hello.
Paul Mackerras wrote:
> Currently, process user and system times are advancing twice as fast
> as they should because they are being accounted in two places - in the
> generic code and in timer_interrupt. This fixes it by removing the
> call to account_process_time in timer_interrupt.
On Mon, Oct 29, 2007 at 02:12:07PM +0800, Li Yang-r58472 wrote:
[...]
> > > > +#ifdef CONFIG_NET_POLL_CONTROLLER
> > > > +/*
> > > > + * Polling 'interrupt' - used by things like netconsole to send
> > > > +skbs
> > > > + * without having to re-enable interrupts. It's not called while
> > > > + *
On Sat, 27 Oct 2007 17:32:02 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> Allright, so Matt, let me know if that fixes your problem with gdb, and
> I'll clean the patch up a bit and submit it. I want to double check if
> something similar may be needed for freescale booke.
>
> Basica
Domen Puncer wrote:
> On 26/10/07 07:18 -0700, Dale Farnsworth wrote:
>> On Fri, Oct 26, 2007 at 01:59:09PM +0200, Domen Puncer wrote:
>>> +static irqreturn_t mpc52xx_fec_tx_interrupt(int irq, void *dev_id)
>>> +{
>>> + struct net_device *dev = dev_id;
>>> + struct mpc52xx_fec_priv *priv = netd
Jan-Bernd Themann wrote:
> eHEA resources that are allocated via H_CALLs have a unique identifier each.
> These identifiers are necessary to free the resources. A reboot notifier
> is used to free all eHEA resources before the indentifiers get lost, i.e
> before kexec starts a new kernel.
>
> Sign
On Mon, 29 Oct 2007, Benjamin Herrenschmidt wrote:
> On Sun, 2007-10-28 at 22:06 -0500, Olof Johansson wrote:
> > > And I don't care, I will continue adding them because the opposite
> > is
> > > fugly :-)
> >
> > Yeah , I know what you mean . This looks so much more natural .
>
> Who said it has
> OK then let's play safe and don't touch fountains at all. How about the
> patch below?
Looks fine to me, works with my fountain touchpad and should fix
Joseph's error too.
> Input: appletouch - idle reset logic broke older Fountains
>
> Fountains do not support change mode request and theref
72 matches
Mail list logo
