* Re: RFC: replace device_type with new "class" property?
From: Olof Johansson @ 2007-10-29 21:22 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359F9BB@az33exm25.fsl.freescale.net>
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 view, the question I'd like to pose is
> how should classes of device should be identified in the
> flat device tree model? A device class, as I'm using it,
> refers basically to general categories of devices-- devices
> that share common properties. Examples in current device
> would be "cpu", "memory", "pci", "network", "serial".
>
> Today the device_type property serves this purpose to some
> degree. However, the original meaning of device_type in
> Open Firmware is related to the method interface of a node
> it has a recent history of abuse in the Linux kernel DTS
> files, with a plethora of types made up in an ad hoc way.
> In addition, an OS can match on "compatible" and in the
> absence of method interfaces really doesn't need
> device_type anyway.
>
> However, one good thing about device_type (if properly used)
> is that it could identify which device nodes follow an official
> binding, vs proprietary devices or one-off device node definitions.
> Without something like device_type the _human_ reader of a DTS
> file has to infer from the name or compatible what the device
> type is. So, device class identifiers like "memory", "cpu",
> "serial", "pci", "network" provide that clarity.
>
> So, what should the long term approach be? Here are a couple
> of options:
>
> 1. Keep device_type, with it's use specifically defined to
> mean that the node with that property implements an
> 'official' binding. In the flat device tree model a
> binding is just a defined set of required (and optional
> properties.
>
> 2. Get rid of device_type and create a _new_ property like
> "class". The only nodes permitted to have this property
> are those with 'official' bindings. These nodes would
> have a set of required (and optional) properties.
>
> The benefit of a new property is cutting all baggage
> associated with the old device_type property.
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 invites people to make up their own class names
as they go along, just as what happened to "device_type".
I also don't understand the people wanting to use "compatible"
for _everything_. It's just mashing together two separate pieces of
information into one property, and I seriously don't see how that helps
anything or anyone. It's absolutely useless for a driver to be able to
bind to a compatible field of "standard,network" or whatever it might be,
since there's no way that "standard," will imply that the register layout
and programming model is somehow the same as all other standard-labelled
devices.
So yes, there is a problem with the device trees and how people build
them, and it requires education on how to properly craft one. I don't
think changing the layout to either be flatter (only using compatible),
or changing names of a property (device_type->class) will help anything
at all.
I actually prefer keeping device_type myself, since it means existing
OF-based device trees will already have some of the labels.
-Olof
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 21:15 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <47263830.2010009@l4x.org>
Jan Dittmer <jdi@l4x.org> writes:
> Andreas Schwab wrote:
>> Jan Dittmer <jdittmer@ppp0.net> 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-threads
>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>> --with-gnu-ld --enable-languages=c
>>> Thread model: single
>>> gcc version 4.0.4
>>>
>>> g5_defconfig:
>>>
>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-
>>> CROSS32_COMPILE=powerpc64-linux-
>>
>> Your compiler still needs -m32 to generate 32-bit code (or use
>> --with-cpu=default32 to make that the default).
>
> 4.1.2 exhibits the same behavior.
What do you mean with "the same behavior"?
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Luis R. Rodriguez @ 2007-10-29 21:27 UTC (permalink / raw)
To: netdev, linuxppc-dev; +Cc: Tzachi Perelstein, Lennert Buytenhek, Jeff Garzik
This commit made an incorrect assumption:
--
Author: Lennert Buytenhek <buytenh@wantstofly.org>
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/mv643xx.h into drivers/net/mv643xx_eth.h, since
they aren't of any use outside the ethernet driver.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Tzachi Perelstein <tzachi@marvell.com>
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
--
arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
mcgrof@pogo:~/devel/wireless-2.6$ git-describe
v2.6.24-rc1-138-g0119130
This patch fixes this by internalizing 3 defines onto pegasos which are
simply no longer available elsewhere. Without this your compile will fail
whenever you enable 'Common Hardware Reference Platform (CHRP) based machines',
(CONFIG_PPC_CHRP) as the Makefile for chrp adds it always:
obj-y += setup.o time.o pegasos_eth.o pci.o
If these defines are platform specific then they should later just be added
back to include/linux/mv643xx.h.
Compile error:
CC arch/powerpc/platforms/chrp/pegasos_eth.o
arch/powerpc/platforms/chrp/pegasos_eth.c: In function 'Enable_SRAM':
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: 'MV643XX_ETH_BAR_4'
undeclared (first use in this function)
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: (Each undeclared
identifier is reported only once
arch/powerpc/platforms/chrp/pegasos_eth.c:150: error: for each function it
appears in.)
arch/powerpc/platforms/chrp/pegasos_eth.c:152: error:
'MV643XX_ETH_SIZE_REG_4' undeclared (first use in this function)
arch/powerpc/platforms/chrp/pegasos_eth.c:154: error:
'MV643XX_ETH_BASE_ADDR_ENABLE_REG' undeclared (first use in this function)
make[2]: *** [arch/powerpc/platforms/chrp/pegasos_eth.o] Error 1
make[1]: *** [arch/powerpc/platforms/chrp] Error 2
make: *** [arch/powerpc/platforms] Error 2
Signed-off-by: Luis R. Rodriguez <mcgrof@gmail.com>
---
arch/powerpc/platforms/chrp/pegasos_eth.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
index 5bcc58d..1fc9e8c 100644
--- a/arch/powerpc/platforms/chrp/pegasos_eth.c
+++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
@@ -24,6 +24,9 @@
#define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
#define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
+#define PEGASOS2_ETH_BAR_4 0x2220
+#define PEGASOS2_ETH_SIZE_REG_4 0x2224
+#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG 0x2290
#define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
#define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
@@ -147,13 +150,13 @@ static int Enable_SRAM(void)
ALong = 0x02;
ALong |= PEGASOS2_SRAM_BASE & 0xffff0000;
- MV_WRITE(MV643XX_ETH_BAR_4, ALong);
+ MV_WRITE(PEGASOS2_ETH_BAR_4, ALong);
- MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
+ MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
- MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
ALong &= ~(1 << 4);
- MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
+ MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
#ifdef BE_VERBOSE
printk("Pegasos II/Marvell MV64361: register unmapped\n");
^ permalink raw reply related
* Re: [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Matt Mackall @ 2007-10-29 21:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, gdb, Kumar Gala, linuxppc-embedded
In-Reply-To: <1193690106.9928.32.camel@pasglop>
[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 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 up version (the version I posted for test
> breaks 64 bits builds :-)
>
> But I'm also waiting for Matt to test first.
Ok, just backported the 405 bits of this to my client's sad sad MV
2.6.10 kernel and it appears to work fine. Only tricky bit was
context.id -> context. So:
Tested-by: Matt Mackall <mpm@selenic.com>
And here's my backported patch, just for reference:
Index: k/arch/ppc/kernel/misc.S
===================================================================
--- k.orig/arch/ppc/kernel/misc.S 2007-10-29 15:33:03.000000000 -0500
+++ k/arch/ppc/kernel/misc.S 2007-10-29 15:34:29.000000000 -0500
@@ -496,7 +496,13 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
Index: k/arch/ppc/mm/fault.c
===================================================================
--- k.orig/arch/ppc/mm/fault.c 2007-10-29 15:30:04.000000000 -0500
+++ k/arch/ppc/mm/fault.c 2007-10-29 16:11:10.000000000 -0500
@@ -234,7 +234,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context);
pte_unmap(ptep);
up_read(&mm->mmap_sem);
ltt_ev_trap_exit();
Index: k/arch/ppc/mm/mmu_decl.h
===================================================================
--- k.orig/arch/ppc/mm/mmu_decl.h 2007-10-29 15:34:48.000000000 -0500
+++ k/arch/ppc/mm/mmu_decl.h 2007-10-29 16:11:25.000000000 -0500
@@ -54,7 +54,7 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
Index: k/include/asm-ppc/tlbflush.h
===================================================================
--- k.orig/include/asm-ppc/tlbflush.h 2007-10-29 15:31:29.000000000 -0500
+++ k/include/asm-ppc/tlbflush.h 2007-10-29 16:11:32.000000000 -0500
@@ -13,7 +13,7 @@
#include <linux/config.h>
#include <linux/mm.h>
-extern void _tlbie(unsigned long address);
+extern void _tlbie(unsigned long address, unsigned int pid);
extern void _tlbia(void);
#if defined(CONFIG_4xx)
@@ -28,10 +28,10 @@ static inline void flush_tlb_mm(struct m
{ __tlbia(); }
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma->vm_mm->context); }
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
- { _tlbie(vmaddr); }
+ { _tlbie(vmaddr, vma->vm_mm->context); }
static inline void flush_tlb_range(struct vm_area_struct *vma,
unsigned long start, unsigned long end)
{ __tlbia(); }
--
Mathematics is the supreme nostalgia of our time.
^ permalink raw reply
* Re: boot/wrap assumes a biarch toolchain?
From: Jan Dittmer @ 2007-10-29 21:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <jebqahei70.fsf@sykes.suse.de>
Andreas Schwab wrote:
> Jan Dittmer <jdi@l4x.org> writes:
>
>> Andreas Schwab wrote:
>>> Jan Dittmer <jdittmer@ppp0.net> 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-threads
>>>> --disable-werror --disable-libmudflap --with-newlib --with-gnu-as
>>>> --with-gnu-ld --enable-languages=c
>>>> Thread model: single
>>>> gcc version 4.0.4
>>>>
>>>> g5_defconfig:
>>>>
>>>> $ make ARCH=powerpc HOSTCC=gcc-4.0 CROSS_COMPILE=powerpc64-linux-
>>>> CROSS32_COMPILE=powerpc64-linux-
>>> Your compiler still needs -m32 to generate 32-bit code (or use
>>> --with-cpu=default32 to make that the default).
>> 4.1.2 exhibits the same behavior.
>
> What do you mean with "the same behavior"?
Same error, you write above that a newer compiler version should
not need -m32 or --with-cpu=default32 any more? But I still get:
CC arch/powerpc/kernel/signal.o
LDS arch/powerpc/kernel/vdso32/vdso32.lds
VDSO32A arch/powerpc/kernel/vdso32/sigtramp.o
VDSO32A arch/powerpc/kernel/vdso32/gettimeofday.o
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:
Assembler messages:
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:33:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:37:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:95:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:103:
Error: junk at end of line: `@local'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130:
Error: syntax error; found `@' but expected `,'
/usr/src/xtest/linux-2.6/arch/powerpc/kernel/vdso32/gettimeofday.S:130:
Error: junk at end of line: `@local'
make[3]: *** [arch/powerpc/kernel/vdso32/gettimeofday.o] Error 1
make[2]: *** [arch/powerpc/kernel/vdso32] Error 2
make[1]: *** [arch/powerpc/kernel] Error 2
make: *** [sub-make] Error 2
Jan
>
> Andreas.
>
^ permalink raw reply
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Dale Farnsworth @ 2007-10-29 22:39 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Tzachi Perelstein, Jeff Garzik, netdev, linuxppc-dev,
Lennert Buytenhek
In-Reply-To: <20071029212729.GA4074@pogo>
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <buytenh@wantstofly.org>
> 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/mv643xx.h into drivers/net/mv643xx_eth.h, since
> they aren't of any use outside the ethernet driver.
>
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> --
>
> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>
> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>
> v2.6.24-rc1-138-g0119130
>
> This patch fixes this by internalizing 3 defines onto pegasos which are
> simply no longer available elsewhere. Without this your compile will fail
That compile failure was fixed in commit
30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
However, as I examine that commit, I see that it defines offsets from
the eth block in the chip, rather than the full chip registeri block
as the Pegasos 2 code expects. So, I think it fixes the compile
failure, but leaves the Pegasos 2 broken.
Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
the following patch is needed for the Pegasos 2?
Thanks,
-Dale
---------------------------------
mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2
In the mv643xx_eth driver, we now use offsets from the ethernet
register block within the chip, but the pegasos 2 platform still
needs offsets from the full chip's register base address.
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
---
include/linux/mv643xx_eth.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 8df230a..30e11aa 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -8,9 +8,9 @@
#define MV643XX_ETH_NAME "mv643xx_eth"
#define MV643XX_ETH_SHARED_REGS 0x2000
#define MV643XX_ETH_SHARED_REGS_SIZE 0x2000
-#define MV643XX_ETH_BAR_4 0x220
-#define MV643XX_ETH_SIZE_REG_4 0x224
-#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290
+#define MV643XX_ETH_BAR_4 0x2220
+#define MV643XX_ETH_SIZE_REG_4 0x2224
+#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290
struct mv643xx_eth_platform_data {
int port_number;
^ permalink raw reply related
* [PATCH] powerpc: Fix 4xx flush_tlb_page()
From: Benjamin Herrenschmidt @ 2007-10-29 22:46 UTC (permalink / raw)
To: linuxppc-dev
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 things, gdb breakpoints
to fail.
This patch adds a "pid" argument to _tlbie() on 4xx processors,
and uses it to flush entries in the right context. FSL BookE
also gets the argument but it seems they don't need it (their
tlbivax form ignores the PID when invalidating according to the
document I have).
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/misc_32.S | 23 ++++++++++++++++-------
arch/powerpc/mm/fault.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 4 ++--
arch/ppc/kernel/misc.S | 22 +++++++++++++++-------
arch/ppc/mm/fault.c | 2 +-
arch/ppc/mm/mmu_decl.h | 4 ++--
arch/ppc/platforms/4xx/ebony.c | 2 +-
arch/ppc/platforms/4xx/ocotea.c | 2 +-
arch/ppc/platforms/4xx/taishan.c | 2 +-
include/asm-powerpc/tlbflush.h | 12 ++++++------
10 files changed, 46 insertions(+), 29 deletions(-)
Index: linux-work/arch/powerpc/mm/fault.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/fault.c 2007-10-25 13:15:47.000000000 +1000
+++ linux-work/arch/powerpc/mm/fault.c 2007-10-29 10:13:11.000000000 +1100
@@ -309,7 +309,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/include/asm-powerpc/tlbflush.h
===================================================================
--- linux-work.orig/include/asm-powerpc/tlbflush.h 2007-10-25 13:15:52.000000000 +1000
+++ linux-work/include/asm-powerpc/tlbflush.h 2007-10-29 10:13:57.000000000 +1100
@@ -1,5 +1,6 @@
#ifndef _ASM_POWERPC_TLBFLUSH_H
#define _ASM_POWERPC_TLBFLUSH_H
+
/*
* TLB flushing:
*
@@ -16,9 +17,6 @@
*/
#ifdef __KERNEL__
-struct mm_struct;
-struct vm_area_struct;
-
#if defined(CONFIG_4xx) || defined(CONFIG_8xx) || defined(CONFIG_FSL_BOOKE)
/*
* TLB flushing for software loaded TLB chips
@@ -28,7 +26,9 @@ struct vm_area_struct;
* specific tlbie's
*/
-extern void _tlbie(unsigned long address);
+#include <linux/mm.h>
+
+extern void _tlbie(unsigned long address, unsigned int pid);
#if defined(CONFIG_40x) || defined(CONFIG_8xx)
#define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct m
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-29 10:13:11.000000000 +1100
@@ -288,7 +288,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -297,23 +306,23 @@ _GLOBAL(_tlbie)
tlbwe r3, r3, TLB_TAG
isync
10:
+
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-10-29 10:13:11.000000000 +1100
@@ -61,12 +61,12 @@ extern unsigned long total_lowmem;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/kernel/misc.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/misc.S 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/kernel/misc.S 2007-10-29 10:13:11.000000000 +1100
@@ -224,7 +224,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -234,22 +243,21 @@ _GLOBAL(_tlbie)
isync
10:
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/ppc/mm/fault.c
===================================================================
--- linux-work.orig/arch/ppc/mm/fault.c 2007-10-25 13:15:47.000000000 +1000
+++ linux-work/arch/ppc/mm/fault.c 2007-10-29 10:13:11.000000000 +1100
@@ -227,7 +227,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/arch/ppc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/ppc/mm/mmu_decl.h 2007-07-27 13:44:42.000000000 +1000
+++ linux-work/arch/ppc/mm/mmu_decl.h 2007-10-29 10:13:11.000000000 +1100
@@ -54,12 +54,12 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/platforms/4xx/ebony.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ebony.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ebony.c 2007-10-29 10:13:11.000000000 +1100
@@ -236,7 +236,7 @@ ebony_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GP_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/ocotea.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ocotea.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ocotea.c 2007-10-29 10:13:11.000000000 +1100
@@ -259,7 +259,7 @@ ocotea_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/taishan.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/taishan.c 2007-09-28 11:42:05.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/taishan.c 2007-10-29 10:13:11.000000000 +1100
@@ -316,7 +316,7 @@ taishan_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
^ permalink raw reply
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Lennert Buytenhek @ 2007-10-29 22:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: netdev, Tzachi Perelstein, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071029212729.GA4074@pogo>
On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
> This commit made an incorrect assumption:
> --
> Author: Lennert Buytenhek <buytenh@wantstofly.org>
> 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/mv643xx.h into drivers/net/mv643xx_eth.h, since
> they aren't of any use outside the ethernet driver.
>
> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> --
>
> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>
> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>
> v2.6.24-rc1-138-g0119130
>
> This patch fixes this by internalizing 3 defines onto pegasos which are
> simply no longer available elsewhere. Without this your compile will fail
> whenever you enable 'Common Hardware Reference Platform (CHRP) based machines',
>
> [...]
>
> diff --git a/arch/powerpc/platforms/chrp/pegasos_eth.c b/arch/powerpc/platforms/chrp/pegasos_eth.c
> index 5bcc58d..1fc9e8c 100644
> --- a/arch/powerpc/platforms/chrp/pegasos_eth.c
> +++ b/arch/powerpc/platforms/chrp/pegasos_eth.c
> @@ -24,6 +24,9 @@
> #define PEGASOS2_SRAM_BASE_ETH0 (PEGASOS2_SRAM_BASE)
> #define PEGASOS2_SRAM_BASE_ETH1 (PEGASOS2_SRAM_BASE_ETH0 + (PEGASOS2_SRAM_SIZE / 2) )
>
> +#define PEGASOS2_ETH_BAR_4 0x2220
> +#define PEGASOS2_ETH_SIZE_REG_4 0x2224
> +#define PEGASOS2_ETH_BASE_ADDR_ENABLE_REG 0x2290
>
> #define PEGASOS2_SRAM_RXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
> #define PEGASOS2_SRAM_TXRING_SIZE (PEGASOS2_SRAM_SIZE/4)
> @@ -147,13 +150,13 @@ static int Enable_SRAM(void)
>
> ALong = 0x02;
> ALong |= PEGASOS2_SRAM_BASE & 0xffff0000;
> - MV_WRITE(MV643XX_ETH_BAR_4, ALong);
> + MV_WRITE(PEGASOS2_ETH_BAR_4, ALong);
>
> - MV_WRITE(MV643XX_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
> + MV_WRITE(PEGASOS2_ETH_SIZE_REG_4, (PEGASOS2_SRAM_SIZE-1) & 0xffff0000);
>
> - MV_READ(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
> + MV_READ(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
> ALong &= ~(1 << 4);
> - MV_WRITE(MV643XX_ETH_BASE_ADDR_ENABLE_REG, ALong);
> + MV_WRITE(PEGASOS2_ETH_BASE_ADDR_ENABLE_REG, ALong);
>
> #ifdef BE_VERBOSE
> printk("Pegasos II/Marvell MV64361: register unmapped\n");
Al Viro sent a patch for this breakage a couple of days ago:
http://marc.info/?l=linux-kernel&m=119351541706811&w=2
(FWIW, I think that code outside of mv643xx_eth.c should not be poking
into the mv643xx's registers directly. Ideally, this info should just
be passed by pegasos_eth into mv643xx_eth via platform data, and then
mv643xx_eth can write the relevant hardware registers.)
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Dale Farnsworth @ 2007-10-29 23:03 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
On Mon, Oct 29, 2007 at 12:34:40PM -0700, Yoder Stuart-B08248 wrote:
> #4 use "compatible"
>
> ucc@2200 {
> compatible = "fsl,ucc_geth","[official spec],network";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
> };
>
> > I don't like this...we are overloading "compatible" with
> > stuff that is not specifying a programming interface. compatible
> > is supposed to be specifying a programming interface which
> > the device complies to.
If your proposed class property doesn't specify a programming interface,
then I agree that we shouldn't put that info in compatible. My point
was that compatible is the one and only property that a driver should
look at to find a node with a suitable programming interface.
But, that begs the question: How will the code use your class property?
Another post implied that it's for human-readable purposes. If that's
all, I'd leave it out, or use a comment instead.
-Dale
^ permalink raw reply
* Re: [PATCH] [powerpc] update xmon slb code
From: Benjamin Herrenschmidt @ 2007-10-29 23:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Will Schmidt, paulus
In-Reply-To: <20071029205254.GA27544@lixom.net>
> 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 the LLP bits ? (I won't ask you to also decode
the page size though that would be useful :-)
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
From: Stephen Rothwell @ 2007-10-29 23:33 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071029183218.19914.51410.stgit@farscape.rchland.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
Hi Will,
Just a trivial comment ...
On Mon, 29 Oct 2007 13:32:19 -0500 Will Schmidt <will_schmidt@vnet.ibm.com> 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_feature(CPU_FTR_1T_SEGMENT))
> + return (GET_ESID(addr1) == GET_ESID(addr2));
> +
> + esid_1t_count = (((addr1>>SID_SHIFT_1T)!=0) + ((addr2>>SID_SHIFT_1T)!=0));
Please use spaces around binary operators (as you have elsewhere). Even
if it pushes the line slightly over 80 characters ...
--
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: boot/wrap assumes a biarch toolchain?
From: Andreas Schwab @ 2007-10-29 23:34 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linuxppc-dev, Jan Dittmer, Anton Blanchard
In-Reply-To: <47265586.1050701@l4x.org>
Jan Dittmer <jdi@l4x.org> 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, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] MTD: small physmap_of partition parsing fixes
From: David Gibson @ 2007-10-30 0:10 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <20071029202902.GA2200@ru.mvista.com>
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: Valentine Barshak <vbarshak@ru.mvista.com>
Oops, yes. I think the extra add_mtd_partitions() was left over from
an earlier version which always did the add_mtd_partitions() from
within the probe function.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 0:23 UTC (permalink / raw)
To: Scott Wood; +Cc: Yoder Stuart-B08248, linuxppc-dev
In-Reply-To: <20071029161140.GA4358@loki.buserror.net>
On Mon, Oct 29, 2007 at 11:11:40AM -0500, Scott Wood wrote:
> On Mon, Oct 29, 2007 at 03:20:56PM +0000, 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
> define it as a list (similar to compatible). It's possible for one node to
> comply with multiple class bindings, such as when there's a binding for
> clients of the type of bus it's on as well as the type of device it is, or
> when there are multiple levels of detail (such as complying with both
> simple-bus and some specific bus binding).
>
> 2. We want to avoid any confusion with OF bindings and abused device_type
> entries that have been allowed to become existing practice.
>
> 3. It's the only standard property (AFAIK) with an underscore in it. :-)
>
> > Remember that, while you may want to make FDTs easier to
> > design, OpenFirmware and the requirement on device interfaces
> > through the client interface still exist and are still
> > implemented (from time to time).
>
> Sure -- and we don't want to risk the code thinking it can call into OF
> based on what we put in a flat device tree, right?
>
> > For readability, the name of the device needn't match device_type;
> > for instance on the 5121E it may be that the 'diu' unit be
> > called diu, but be of device_type 'display'
>
> I don't think that's more readable than setting the name to display.
> Something containing "diu" will be in the compatible list.
>
> > Further differentiation should be done through the 'model'
> > property in my opinion. This is optional in the OpenFirmware
> > spec, but that does not mean it should be important. It is
> > currently defined as something to determine the exact model
> > of a chip in order to enable quirks, bugfixes and suchlike,
> > but most implementations switch on something else entirely
> > (like SVR or a heuristic behaviour).
> >
> > Selecting the "model" would be no different to, for example,
> > having a list of PCI IDs that will work with a driver.
>
> It's what we currently do with compatible. Why break it into two
> properties?
>
> The PCI ID thing can be quite a headache, BTW, when you get a new PCI device
> that won't work with the existing driver, for no reason other than that it
> hasn't been updated with the new ID.
Indeed. Replacing the flexible string based matching we have already,
with a limited ID based matching is just silly.
> > There was a little discussion at bplan once that it would be
> > easier to implement a kind of vendor/device id system much
> > like PCI, USB etc. implements in hardware in order to match
> > hardware. I suppose you could use a "class" property to
> > implement this -
>
> No, you should use compatible for that.
Yes. Driver binding should be based on compatible. Period. Drivers
can enable quirks based on 'model' or any other information available
to them (either from the device tree or direct from the hardware).
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 0:26 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Linuxppc-dev
In-Reply-To: <20071029172724.11354.qmail@farnsworth.org>
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 expand the use of
> > device_type in any case.
>
> I agree that the existing compatible property is sufficient to do
> what Stuart wants. All that is required is to define some standard
> bindings and give them well-known names for the compatible property.
> If needed, we could define a prefix that indicates that a compatible
> entry refers to a standards-compliant binding. For example,
> "standard,network", or "standard,display". I don't see the benefit
> of creating a new property similar to device_type.
That would overload the meaning of compatible. A driver which matches
any compatible entry should be able to drive the device, even if it
can't use all the devices features. You can't do that if all you know
is that something is a display.
So, standardised or defacto-standard hardware-level interfaces belong
in compatible, e.g. ohci, uhci, ns16550. The mere fact that something
is a display or network interface (and has *general* properties
related to such devices) doesn't let you drive it.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 0:29 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA30359FB6A@az33exm25.fsl.freescale.net>
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:
>
> ucc@2200 {
> compatible = "fsl,ucc_geth";
> model = "UCC";
> device-id = <3>;
> reg = <2200 200>;
> interrupts = <22>;
> interrupt-parent = < &qeic >;
> mac-address = [ 00 00 00 00 00 00 ];
> local-mac-address = [ 00 00 00 00 00 00 ];
> rx-clock = <19>;
> tx-clock = <1a>;
> phy-handle = < &phy3 >;
> pio-handle = < &pio3 >;
>
>
> > This is bad IMHO because the human reader has to
> > infer the class of device. Can the human reader
> > tell if it implements a standardized binding or
> > not??
Well... except that by the generic names convention, the node should
be called "ethernet@2200", which makes it rather clearer to a human
reader.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 0:51 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Yoder Stuart-B08248
In-Reply-To: <20071029212213.GA28073@lixom.net>
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 invites people to make up their own class names
> as they go along, just as what happened to "device_type".
>
> I also don't understand the people wanting to use "compatible"
> for _everything_. It's just mashing together two separate pieces of
> information into one property, and I seriously don't see how that helps
> anything or anyone. It's absolutely useless for a driver to be able to
> bind to a compatible field of "standard,network" or whatever it might be,
> since there's no way that "standard," will imply that the register layout
> and programming model is somehow the same as all other standard-labelled
> devices.
>
> So yes, there is a problem with the device trees and how people build
> them, and it requires education on how to properly craft one. I don't
> think changing the layout to either be flatter (only using compatible),
> or changing names of a property (device_type->class) will help anything
> at all.
>
> I actually prefer keeping device_type myself, since it means existing
> OF-based device trees will already have some of the labels.
Yeah.. what he said.
The *only* substantive change with the "class" proposal is the fact
that multiple classes can be specified. That's nice, but I don't
think it's worth the trouble of attempting to define a whole new chunk
of standard for.
Stuart, I think you overestimate the value of this class property to a
human reader. The generic names convention (not followed as much as
it should be) means the name should give the reader some idea of what
the device is, in most cases. For trickier cases, if we really want
something for humans reading the tree, we could add an optional
"comment" or "description" property with purely human readable
information.
I think we should leave existing IEEE1275 defined uses of device_type,
in order not to make flat trees gratuitously different from real-OF
trees, but we should avoid any new use of device_type.
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a "duck" class device node, and it
quacks^Whas the properties of a "duck" class device node, it's "duck"
class compliant.
Or to look at it another way, "class bindings" aren't really bindings,
but rather a set of conventions that device bindings for specific
devices in that class ought to follow.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 05/11] [POWERPC] TQM5200 DTS
From: David Gibson @ 2007-10-30 0:58 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Marian Balakowicz, Martin Krause
In-Reply-To: <fa686aa40710290840w41e2ffeo38b9497ce76e155@mail.gmail.com>
On Mon, Oct 29, 2007 at 09:40:23AM -0600, Grant Likely wrote:
> On 10/29/07, Marian Balakowicz <m8@semihalf.com> 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 <Martin.Krause@tqs.de> wrote:
> > > [snip]
> > >>>> On a board with 16 MiB FLASH for example the "big-fs" _and_ the "misc"
> > >>>> partition could not be used. "big-fs", because the memory is too small
> > >>>> (which is OK) and "misc", because it overlaps 1 MiB over the physikal
> > >>>> flash border. So only the first 9 MiB of the flash could be used in Linux.
> > >>>> The remaining 7 MiB couldn't be accessed.
> > >>> Perhaps it would be better to drop the flash layout from the in-kernel
> > >>> dts files entirely since flash layout can be a fluid thing.
> > >> Well, but that would not be really user friendly, I'd rather stick
> > >> with some default config.
> > >
> > > Strictly speaking the device-tree is not the right place for flash
> > > partitioning information. We put it there because it's preferable to
> > > having hardcoded per-board flash layouts in the code itself.
> > >
> > > It only really works well, though, when there are strong conventions
> > > (shared with the firmware) about how to partition the flash.
> > >
> > > Where it's really up to the user to determine how they want to lay out
> > > their flash, putting things in the device tree isn't a really good
> > > idea.
> >
> > In principle, you are right, we should not be putting a user dependent
> > configuration into .dts files. But on the other hand, bindings have
> > been defined for flash-like devices and their partition layouts and
> > physmap_of device driver is expecting to get this information from the
> > blob. So, it is the place for it. But if we are not to put partition
> > layouts into the default kernel .dts files then we should
> > provide/maintain some examples an that may be a even bigger mess.
> >
> > > Incidentally, it's not required that *all* the flash address space be
> > > in partitions, so it is possible only give partitions for those flash
> > > chunks which the firmware needs to know about.
> >
> > That might be nicer solution but different variants of TQM5200 boards
> > do not share the same subset of partitions (default u-boot partitions
> > at least), so it will not help much.
>
> 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.
That sounds like a reasonable idea.
But if the flash partition layout is *not* fixed - but selectable by
the board installer, then it should certainly not be hardcoded into a
fixed dts.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 0/3] Add device-tree aware NDFC driver
From: Thomas Gleixner @ 2007-10-30 1:49 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <20071029201738.GA2022@ru.mvista.com>
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 separate ndfc_of.c file. This version
> supports both separate mtd devices on each chip attached to NDFC banks and
> single mtd device spread across identical chips (not using mtdconcat) as well.
> The choice is selected with device tree settings. This has been tested
> on PowerPC 440EPx Sequoia board.
> Any comments are greatly appreciated.
Did I express myself not clear enough in my first reply or is this
just a repeated epiphany in my inbox ?
You got plenty of comments to your patches, but you decided to ignore
them silently.
Darn, fix it the right way once and forever and please don't try to
tell me another heartrending "why I did it my way" story.
This all can be done with a nice series of incremental patches
including a fixup to the existing users.
We have enough dump and run shit in the kernel already.
No thanks,
tglx
^ permalink raw reply
* dtc: Remove leftover debugging printf() from mangle-layout
From: David Gibson @ 2007-10-30 2:17 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
The mangle-layout testcase/utility had a leftover debugging printf().
This patch removes it.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/tests/mangle-layout.c
===================================================================
--- dtc.orig/tests/mangle-layout.c 2007-10-29 15:58:55.000000000 +1100
+++ dtc/tests/mangle-layout.c 2007-10-29 15:59:16.000000000 +1100
@@ -96,8 +96,6 @@ void add_block(struct bufstate *buf, int
}
offset = ALIGN(buf->size, align);
- fprintf(stderr, "Moving block %c from %p, to offset %d, size %d\n",
- block, src, offset, size);
expand_buf(buf, offset+size);
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* libfdt: Correctly handle versions > 17
From: David Gibson @ 2007-10-30 2:22 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
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. Therefore, before making
modifications to a tree of version >17, we must change it's version to
be exactly 17.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/libfdt/fdt_rw.c
===================================================================
--- dtc.orig/libfdt/fdt_rw.c 2007-10-29 16:09:23.000000000 +1100
+++ dtc/libfdt/fdt_rw.c 2007-10-29 16:34:37.000000000 +1100
@@ -61,7 +61,7 @@ static int rw_check_header(void *fdt)
if ((err = fdt_check_header(fdt)))
return err;
- if (fdt_version(fdt) < 0x11)
+ if (fdt_version(fdt) < 17)
return -FDT_ERR_BADVERSION;
if (fdt_off_mem_rsvmap(fdt) < ALIGN(sizeof(struct fdt_header), 8))
return -FDT_ERR_BADLAYOUT;
@@ -74,6 +74,9 @@ static int rw_check_header(void *fdt)
if (fdt_totalsize(fdt) <
(fdt_off_dt_strings(fdt) + fdt_size_dt_strings(fdt)))
return -FDT_ERR_BADLAYOUT;
+ if (fdt_version(fdt) > 17)
+ fdt_set_version(fdt, 17);
+
return 0;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 4xx flush_tlb_page()
From: Kumar Gala @ 2007-10-30 3:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071029224624.68205DE157@ozlabs.org>
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() from a different context will
> not work properly, causing among other things, gdb breakpoints
> to fail.
>
> This patch adds a "pid" argument to _tlbie() on 4xx processors,
> and uses it to flush entries in the right context. FSL BookE
> also gets the argument but it seems they don't need it (their
> tlbivax form ignores the PID when invalidating according to the
> document I have).
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/kernel/misc_32.S | 23 ++++++++++++++++-------
> arch/powerpc/mm/fault.c | 2 +-
> arch/powerpc/mm/mmu_decl.h | 4 ++--
> arch/ppc/kernel/misc.S | 22 +++++++++++++++-------
> arch/ppc/mm/fault.c | 2 +-
> arch/ppc/mm/mmu_decl.h | 4 ++--
> arch/ppc/platforms/4xx/ebony.c | 2 +-
> arch/ppc/platforms/4xx/ocotea.c | 2 +-
> arch/ppc/platforms/4xx/taishan.c | 2 +-
> include/asm-powerpc/tlbflush.h | 12 ++++++------
> 10 files changed, 46 insertions(+), 29 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Kumar Gala @ 2007-10-30 3:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18213.19469.827909.663373@cargo.ozlabs.ibm.com>
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 subtract 1 from the count for
> server and classic processors. Since set_dec already had a bunch of
> ifdefs to handle different processor types, there is no net increase
> in ugliness. :)
>
> This also removes a redundant call to set the decrementer to
> 0x7fffffff - it was already set to that earlier in timer_interrupt.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
...
> diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
> index f058955..eed64bd 100644
> --- a/include/asm-powerpc/time.h
> +++ b/include/asm-powerpc/time.h
> @@ -183,6 +183,7 @@ static inline void set_dec(int val)
> #elif defined(CONFIG_8xx_CPU6)
> set_dec_cpu6(val);
> #else
> + --val; /* classic decrementer interrupts when dec goes negative */
> #ifdef CONFIG_PPC_ISERIES
> int cur_dec;
>
Unless I'm reading set_dec() you are getting --val on booke.
- k
^ permalink raw reply
* [PATCH] Fix build failure in platforms/celleb/setup.c which CONFIG_VIRT_CPU_ACCOUNTING is not defined.
From: Tony Breeds @ 2007-10-30 3:55 UTC (permalink / raw)
To: LinuxPPC-dev, cbe-oss-dev
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 <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/celleb/setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/setup.c b/arch/powerpc/platforms/celleb/setup.c
index 1769d75..ddfb35a 100644
--- a/arch/powerpc/platforms/celleb/setup.c
+++ b/arch/powerpc/platforms/celleb/setup.c
@@ -49,6 +49,7 @@
#include <asm/machdep.h>
#include <asm/cputable.h>
#include <asm/irq.h>
+#include <asm/time.h>
#include <asm/spu_priv1.h>
#include <asm/firmware.h>
#include <asm/of_platform.h>
--
1.5.3.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] [Powerpc V2] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-30 4:17 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071029183218.19914.51410.stgit@farscape.rchland.ibm.com>
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 helper function called
> esids_match() contains the logic for deciding when to call GET_ESID
> and GET_ESID_1T.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
> ---
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ 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