* [patch 1/4] autoselect optimal -mcpu= flag by platform
From: Arnd Bergmann @ 2007-08-29 23:11 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <20070829231122.406817286@arndb.de>
We can choose the -mcpu= gcc flags for compiling the kernel
based on the platform that we build for. In case of multiplatform
kernels, this chooses a setting for a common subset.
When using a platform type that can use different CPUs, a
new option CONFIG_PPC_CPU_SELECTION can be enabled to select
more specifically which CPUs the kernel will be able to
run on.
This replaces the CONFIG_POWER4_ONLY option with an much more
generic approach.
Also, when CONFIG_PPC_CPU_SELECTION is set, it is now possible
to select a CPU to tune for by means of the -mtune= option.
I tried to be very careful when coding the specific rules into
the Kconfig language, but it would be good to have a few
people sanity-checking them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Index: linux-2.6/arch/powerpc/platforms/52xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/52xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/52xx/Kconfig
@@ -25,12 +25,14 @@ config PPC_EFIKA
select RTAS_PROC
select PPC_MPC52xx
select PPC_NATIVE
+ select CPU_603e
default n
config PPC_LITE5200
bool "Freescale Lite5200 Eval Board"
depends on PPC_MULTIPLATFORM && PPC32
select PPC_MPC5200
+ select CPU_603e
default n
Index: linux-2.6/arch/powerpc/platforms/82xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/82xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/82xx/Kconfig
@@ -10,6 +10,7 @@ config MPC82xx_ADS
select 8272
select 8260
select FSL_SOC
+ select CPU_603e
help
This option enables support for the MPC8272 ADS board
Index: linux-2.6/arch/powerpc/platforms/83xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/83xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/83xx/Kconfig
@@ -6,6 +6,7 @@ choice
config MPC8313_RDB
bool "Freescale MPC8313 RDB"
select DEFAULT_UIMAGE
+ select CPU_603e
help
This option enables support for the MPC8313 RDB board.
@@ -13,6 +14,7 @@ config MPC832x_MDS
bool "Freescale MPC832x MDS"
select DEFAULT_UIMAGE
select QUICC_ENGINE
+ select CPU_603e
help
This option enables support for the MPC832x MDS evaluation board.
@@ -20,12 +22,14 @@ config MPC832x_RDB
bool "Freescale MPC832x RDB"
select DEFAULT_UIMAGE
select QUICC_ENGINE
+ select CPU_603e
help
This option enables support for the MPC8323 RDB board.
config MPC834x_MDS
bool "Freescale MPC834x MDS"
select DEFAULT_UIMAGE
+ select CPU_603e
help
This option enables support for the MPC 834x MDS evaluation board.
@@ -37,6 +41,7 @@ config MPC834x_MDS
config MPC834x_ITX
bool "Freescale MPC834x ITX"
select DEFAULT_UIMAGE
+ select CPU_603e
help
This option enables support for the MPC 834x ITX evaluation board.
@@ -47,6 +52,7 @@ config MPC836x_MDS
bool "Freescale MPC836x MDS"
select DEFAULT_UIMAGE
select QUICC_ENGINE
+ select CPU_603e
help
This option enables support for the MPC836x MDS Processor Board.
Index: linux-2.6/arch/powerpc/platforms/86xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/86xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/86xx/Kconfig
@@ -8,6 +8,7 @@ config MPC8641_HPCN
select PPC_I8259
select DEFAULT_UIMAGE
select FSL_ULI1575
+ select CPU_7450
help
This option enables support for the MPC8641 HPCN board.
Index: linux-2.6/arch/powerpc/platforms/Kconfig.cputype
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/Kconfig.cputype
+++ linux-2.6/arch/powerpc/platforms/Kconfig.cputype
@@ -53,14 +53,352 @@ config E200
endchoice
-config POWER4_ONLY
- bool "Optimize for POWER4"
+config PPC_CPU_SELECTION
+ bool "Advanced CPU selection"
+ help
+ The kernel can be built for a range of CPU types, which it
+ normally determines automatically from the platform types that
+ have been enabled. In order to optimized leaving out support
+ for the older CPUs or selecting the exact -mtune= option that
+ is passed to gcc, you can further optimize the kernel for a
+ particular system.
+
+ Selecting this option will not cause changes directly, but will
+ reveal further options.
+
+ If unsure, say N.
+
+config CPU_DEFAULT
+ bool "Don't specify -mcpu= to gcc" if PPC_CPU_SELECTION
+ help
+ When this option is selected, gcc is called without
+ any specific -mcpu= argument, regardless of which
+ CPUs are enabled in the next options.
+
+config CPU_RS64
+ bool "RS64" if PPC_CPU_SELECTION
depends on PPC64
- default n
- ---help---
- Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
- The resulting binary will not work on POWER3 or RS64 processors
- when compiled with binutils 2.15 or later.
+ default y if PPC_PSERIES || PPC_ISERIES
+ help
+ Select this if you want to have support for the first
+ generation of 64 bit PowerPC CPUs used in the late
+ 1990s in IBM RS/6000 and AS/400 machines.
+
+config CPU_POWER3
+ bool "IBM Power3" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ help
+ Select this if you want to have support for the
+ Power3 chip used in IBM RS/6000 and early pSeries
+ machines.
+
+config CPU_POWER4
+ bool "IBM Power4" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES || PPC_ISERIES
+ help
+ Select this if you want to have support for the Power 4
+ processor used in IBM pSeries and iSeries machines.
+
+config CPU_POWER5
+ bool "IBM Power5" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ help
+ Select this if you want to have support for the Power 5
+ processor used in IBM System p and System i machines.
+
+config CPU_POWER6
+ bool "IBM Power6" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ select ALTIVEC
+ help
+ Select this if you want to have support for the Power 6
+ processor used in the latest IBM System p and System i
+ machines.
+
+config CPU_970
+ bool "IBM PowerPC 970 (G5)" if PPC_CPU_SELECTION
+ depends on PPC64
+ default y if PPC_PSERIES
+ select ALTIVEC
+ help
+ Select this if you want to have support for the PowerPC 970
+ processor used in Apple Power Macintosh G5 and IBM JS2x blade
+ servers and other systems.
+
+config CPU_CELL
+ bool "Sony/Toshiba/IBM Cell Broadband Engine" if PPC_CPU_SELECTION
+ depends on PPC64
+ select ALTIVEC
+ help
+ Select this if you want to have support for the Cell Broadband
+ Engine processor used the Sony Playstation 3, the IBM QS2x
+ blade servers and other systems.
+
+config CPU_PA6T
+ bool "PA Semi PA6T-1682M" if PPC_CPU_SELECTION
+ depends on PPC64
+ select ALTIVEC
+ help
+ Select this if you want to have support for the PA6T-1682M
+ processor from PA Semi.
+
+config CPU_601
+ bool "PowerPC 601 (G1)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default PPC_CHRP || PPC_PREP
+ help
+ Select this if you really wish to have support for ancient PowerPC
+ 601 processors used in very early Power Macintosh machines and
+ some CHRP boards.
+ Most people will want to disable this option to get better
+ performance on modern machines.
+
+config CPU_603e
+ bool "PowerPC 603e, 604, 604e, 52xx, 82xx, 83xx (G2)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default PPC_CHRP || PPC_PREP || PPC_PMAC
+ help
+ The 603e processor line is the most widespread implementation of
+ the PowerPC ISA, so you most likely want to enable this if you are
+ building a kernel for multiple platforms.
+
+config CPU_750
+ bool "PowerPC 740, 750 (G3)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default PPC_PMAC
+ help
+ Select this for the G3 PowerPC 750 processor used in Apple
+ Power Macintosh and a number of embedded boards.
+
+config CPU_7400
+ bool "PowerPC 7400, 7410 (G4)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default PPC_PMAC
+ select ALTIVEC
+ help
+ Select this for the early G4 PowerPC 7400 processor used in
+ a few Apple Power Macintosh and other machines.
+
+config CPU_7450
+ bool "PowerPC 744x, 745x, 86xx (G4)" if PPC_CPU_SELECTION
+ depends on 6xx
+ default PPC_PMAC
+ select ALTIVEC
+ help
+ Select this for the later G4 PowerPC 7450 processor and its
+ derivatives used in most of the late Apple Power Macintosh
+ machines and some high-performance embedded boards.
+
+config CPU_8540
+ bool "Freescale e500v1 (MPC8540 compatible)" if PPC_CPU_SELECTION
+ depends on PPC_85xx
+ help
+ Select this for the older version 1 of the e500 core used in
+ the earlier MPC85xx processors.
+
+config CPU_8548
+ bool "Freescale e500v2 (MPC8548 compatible)" if PPC_CPU_SELECTION
+ depends on PPC_85xx
+ help
+ Select this for the newer version 2 of the e500 core that was
+ first used in the MPC8548 processor.
+ Some versions of gcc don't know about this yet, so you may
+ also have to enable 8540 to get the best performance with
+ your compiler.
+
+config CPU_403
+ bool "IBM 403" if PPC_CPU_SELECTION
+ depends on 40x
+ help
+ The PowerPC 403 core is used in the first generation Tivo and
+ some other old machines. Select this only if you are sure that
+ you want to run your kernel on one of these machines.
+
+config CPU_405
+ bool "IBM/AMCC 405" if PPC_CPU_SELECTION
+ depends on 40x
+ default y
+ help
+ Practically all PowerPC 40x based platforms supported by Linux use
+ a 405 core, so you should enable this option.
+
+config CPU_440
+ bool "IBM/AMCC 440" if PPC_CPU_SELECTION
+ depends on 44x
+ default y
+ help
+ If you are building for a PowerPC 440 based, you don't really
+ have a choice here, say Y.
+
+choice
+ prompt "Tune for processor type" if PPC_CPU_SELECTION
+ default TUNE_POWER4 if PPC64
+ default TUNE_DEFAULT
+ help
+ This will choose the gcc flag to use for the -mtune= parameter.
+ See the above list for a description of the invidual options.
+
+ If unsure, select TUNE_DEFAULT, gcc will tune for the oldest
+ CPU that the kernel supports in that case, which usually
+ gives reasonable results on newer CPUs as well.
+
+config TUNE_DEFAULT
+ bool "Don't specify -mtune= to gcc"
+
+config TUNE_RS64
+ bool "RS64"
+ depends on CPU_RS64
+
+config TUNE_POWER3
+ bool "IBM Power3"
+ depends on CPU_POWER3
+
+config TUNE_POWER4
+ bool "IBM Power4"
+ depends on CPU_POWER4
+
+config TUNE_POWER5
+ bool "IBM Power5"
+ depends on CPU_POWER5
+
+config TUNE_POWER6
+ bool "IBM Power6"
+ depends on CPU_POWER6
+
+config TUNE_970
+ bool "IBM PowerPC 970 (G5)"
+ depends on CPU_970
+
+config TUNE_CELL
+ bool "Sony/Toshiba/IBM Cell Broadband Engine"
+ depends on CPU_CELL
+
+config TUNE_PA6T
+ bool "PA Semi PA6T-1682M"
+ depends on CPU_PA6T
+
+config TUNE_601
+ bool "PowerPC 601 (G1)"
+ depends on CPU_601
+
+config TUNE_603e
+ bool "PowerPC 603e, 604, 604e, 52xx, 82xx, 83xx (G2)"
+ depends on CPU_603e
+
+config TUNE_750
+ bool "PowerPC 740/750 (G3)"
+ depends on CPU_750
+
+config TUNE_7400
+ bool "PowerPC 7400, 7410 (G4)"
+ depends on CPU_7400
+
+config TUNE_7450
+ bool "PowerPC 744x, 745x, 86xx (G4)"
+ depends on CPU_7450
+
+config TUNE_821
+ bool "Freescale MPC821"
+ depends on 8xx
+
+config TUNE_823
+ bool "Freescale MPC823"
+ depends on 8xx
+
+config TUNE_860
+ bool "Freescale MPC860"
+ depends on 8xx
+
+config TUNE_403
+ bool "IBM 403"
+ depends on CPU_403
+
+config TUNE_405
+ bool "IBM/AMCC 405"
+ depends on CPU_405
+
+config TUNE_440
+ bool "IBM/AMCC 440"
+ depends on CPU_440
+
+config TUNE_8540
+ bool "Freescale e500v1"
+ depends on CPU_8540
+
+config TUNE_8548
+ bool "Freescale e500v2"
+ depends on CPU_8548
+
+config TUNE_E200
+ bool "Freescale e200"
+ depends on E200
+
+endchoice
+
+config PPC_MCPU
+ string
+ default "" if CPU_DEFAULT
+ default "-mcpu=power3" if CPU_POWER3 || CPU_RS64
+ default "-mcpu=power4" if (CPU_POWER5 || CPU_POWER6) && (CPU_970 || CPU_CELL || CPU_PA6T)
+ default "-mcpu=power4" if CPU_POWER4
+ default "-mcpu=power5" if CPU_POWER5
+ default "-mcpu=power6" if CPU_POWER6
+ default "-mcpu=970" if CPU_970
+ default "-mcpu=cell" if CPU_CELL
+ default "-mcpu=pa6t" if CPU_PA6T
+ default "-mcpu=power3" if PPC64
+ default "-mcpu=powerpc" if CPU_601 && (CPU_603e || CPU_750 || CPU_7400 || CPU_7450)
+ default "-mcpu=601" if CPU_601
+ default "-mcpu=603e" if CPU_603e
+ default "-mcpu=750" if CPU_750
+ default "-mcpu=7400" if CPU_7400
+ default "-mcpu=7450" if CPU_7450
+ default "-mcpu=8540" if CPU_8540
+ default "-mcpu=8548" if CPU_8548
+ default "-mcpu=powerpc" if (CPU_403 && CPU_405)
+ default "-mcpu=powerpc" if (CPU_403 || CPU_405) && CPU_440
+ default "-mcpu=403" if CPU_403
+ default "-mcpu=405" if CPU_405
+ default "-mcpu=440" if CPU_440
+ default "-mcpu=860" if PPC_8xx
+ default "-mcpu=e200" if E200
+ default "-mcpu=powerpc"
+
+config PPC_MTUNE
+ string
+ default "" if TUNE_DEFAULT
+ default "-mtune=power3" if TUNE_POWER3
+ default "-mtune=rs64a" if TUNE_RS64
+ default "-mtune=power4" if TUNE_POWER4
+ default "-mtune=power5" if TUNE_POWER5
+ default "-mtune=power6" if TUNE_POWER6
+ default "-mtune=970" if TUNE_970
+ default "-mtune=cell" if TUNE_CELL
+ default "-mtune=pa6t" if TUNE_PA6T
+ default "-mtune=601" if TUNE_601
+ default "-mtune=603e" if TUNE_603e
+ default "-mtune=750" if TUNE_750
+ default "-mtune=7400" if TUNE_7400
+ default "-mtune=7450" if TUNE_7450
+ default "-mtune=8540" if TUNE_8540
+ default "-mtune=8548" if TUNE_8548
+ default "-mtune=403" if TUNE_403
+ default "-mtune=405" if TUNE_405
+ default "-mtune=440" if TUNE_440
+ default "-mtune=821" if TUNE_821
+ default "-mtune=823" if TUNE_823
+ default "-mtune=860" if TUNE_860
+ default "-mtune=e200" if TUNE_E200
+ default "-mtune=power4" if PPC64
+
+# The next three options should probably go away
+config POWER4_ONLY
+ def_bool y
+ depends on PPC64 && !CPU_POWER3 && !CPU_RS64
config POWER3
bool
Index: linux-2.6/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/Kconfig
+++ linux-2.6/arch/powerpc/platforms/cell/Kconfig
@@ -20,6 +20,7 @@ config PPC_IBM_CELL_BLADE
select MMIO_NVRAM
select PPC_UDBG_16550
select UDBG_RTAS_CONSOLE
+ select CPU_CELL
menu "Cell Broadband Engine options"
depends on PPC_CELL
Index: linux-2.6/arch/powerpc/platforms/celleb/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/celleb/Kconfig
+++ linux-2.6/arch/powerpc/platforms/celleb/Kconfig
@@ -2,6 +2,7 @@ config PPC_CELLEB
bool "Toshiba's Cell Reference Set 'Celleb' Architecture"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
+ select CPU_CELL
select PPC_OF_PLATFORM_PCI
select HAS_TXX9_SERIAL
select PPC_UDBG_BEAT
Index: linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/embedded6xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -8,6 +8,7 @@ config LINKSTATION
select FSL_SOC
select PPC_UDBG_16550 if SERIAL_8250
select DEFAULT_UIMAGE
+ select CPU_603e
help
Select LINKSTATION if configuring for one of PPC- (MPC8241)
based NAS systems from Buffalo Technology. So far only
@@ -20,6 +21,7 @@ config MPC7448HPC2
select TSI108_BRIDGE
select DEFAULT_UIMAGE
select PPC_UDBG_16550
+ select CPU_7450
help
Select MPC7448HPC2 if configuring for Freescale MPC7448HPC2 (Taiga)
platform
@@ -29,6 +31,7 @@ config PPC_HOLLY
select TSI108_BRIDGE
select PPC_UDBG_16550
select WANT_DEVICE_TREE
+ select CPU_750
help
Select PPC_HOLLY if configuring for an IBM 750GX/CL Eval
Board with TSI108/9 bridge (Hickory/Holly)
@@ -38,6 +41,7 @@ config PPC_PRPMC2800
select MV64X60
select NOT_COHERENT_CACHE
select WANT_DEVICE_TREE
+ select CPU_7450
help
This option enables support for the Motorola PrPMC2800 board
endchoice
Index: linux-2.6/arch/powerpc/platforms/maple/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/maple/Kconfig
+++ linux-2.6/arch/powerpc/platforms/maple/Kconfig
@@ -11,6 +11,7 @@ config PPC_MAPLE
select PPC_RTAS
select MMIO_NVRAM
select ATA_NONSTANDARD if ATA
+ select CPU_970
default n
help
This option enables support for the Maple 970FX Evaluation Board.
Index: linux-2.6/arch/powerpc/platforms/pasemi/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pasemi/Kconfig
+++ linux-2.6/arch/powerpc/platforms/pasemi/Kconfig
@@ -2,6 +2,7 @@ config PPC_PASEMI
depends on PPC_MULTIPLATFORM && PPC64
bool "PA Semi SoC-based platforms"
default n
+ select CPU_PA6T
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
Index: linux-2.6/arch/powerpc/platforms/powermac/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/Kconfig
+++ linux-2.6/arch/powerpc/platforms/powermac/Kconfig
@@ -16,6 +16,7 @@ config PPC_PMAC64
select MPIC_U3_HT_IRQS
select GENERIC_TBSYNC
select PPC_970_NAP
+ select CPU_970
default y
Index: linux-2.6/arch/powerpc/platforms/ps3/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/ps3/Kconfig
+++ linux-2.6/arch/powerpc/platforms/ps3/Kconfig
@@ -2,6 +2,7 @@ config PPC_PS3
bool "Sony PS3"
depends on PPC_MULTIPLATFORM && PPC64
select PPC_CELL
+ select CPU_CELL
select USB_ARCH_HAS_OHCI
select USB_OHCI_LITTLE_ENDIAN
select USB_OHCI_BIG_ENDIAN_MMIO
Index: linux-2.6/arch/powerpc/Makefile
===================================================================
--- linux-2.6.orig/arch/powerpc/Makefile
+++ linux-2.6/arch/powerpc/Makefile
@@ -74,24 +74,23 @@ CPP = $(CC) -E $(CFLAGS)
CHECKFLAGS += -m$(SZ) -D__powerpc__ -D__powerpc$(SZ)__
+OPTFLAGS := $(call cc-option,$(CONFIG_PPC_MCPU)) $(call cc-option,$(CONFIG_PPC_MTUNE))
+
+# compilers older than 4.0.0 can only set -maltivec in 64 bit mode
+# when compiling for 970
ifeq ($(CONFIG_PPC64),y)
GCC_BROKEN_VEC := $(shell if [ $(call cc-version) -lt 0400 ] ; then echo "y"; fi)
-
ifeq ($(CONFIG_POWER4_ONLY),y)
ifeq ($(CONFIG_ALTIVEC),y)
ifeq ($(GCC_BROKEN_VEC),y)
- CFLAGS += $(call cc-option,-mcpu=970)
-else
- CFLAGS += $(call cc-option,-mcpu=power4)
+ OPTFLAGS := $(call cc-option,-mcpu=970) $(call cc-option,$(CONFIG_PPC_MTUNE))
endif
-else
- CFLAGS += $(call cc-option,-mcpu=power4)
endif
-else
- CFLAGS += $(call cc-option,-mtune=power4)
endif
endif
+CFLAGS += $(OPTFLAGS)
+
# No AltiVec instruction when building kernel
CFLAGS += $(call cc-option,-mno-altivec)
@@ -103,10 +102,6 @@ CFLAGS += $(call cc-option,-funit-at-a-t
# often slow when they are implemented at all
CFLAGS += -mno-string
-ifeq ($(CONFIG_6xx),y)
-CFLAGS += -mcpu=powerpc
-endif
-
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
Index: linux-2.6/arch/powerpc/platforms/85xx/Kconfig
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/85xx/Kconfig
+++ linux-2.6/arch/powerpc/platforms/85xx/Kconfig
@@ -6,12 +6,14 @@ choice
config MPC8540_ADS
bool "Freescale MPC8540 ADS"
select DEFAULT_UIMAGE
+ select CPU_8540
help
This option enables support for the MPC 8540 ADS board
config MPC8560_ADS
bool "Freescale MPC8560 ADS"
select DEFAULT_UIMAGE
+ select CPU_8548
help
This option enables support for the MPC 8560 ADS board
@@ -19,6 +21,7 @@ config MPC85xx_CDS
bool "Freescale MPC85xx CDS"
select DEFAULT_UIMAGE
select PPC_I8259
+ select CPU_8548
help
This option enables support for the MPC85xx CDS board
@@ -26,6 +29,7 @@ config MPC85xx_MDS
bool "Freescale MPC85xx MDS"
select DEFAULT_UIMAGE
# select QUICC_ENGINE
+ select CPU_8548
help
This option enables support for the MPC85xx MDS board
@@ -34,6 +38,7 @@ config MPC8544_DS
select PPC_I8259
select DEFAULT_UIMAGE
select FSL_ULI1575
+ select CPU_8548
help
This option enables support for the MPC8544 DS board
--
^ permalink raw reply
* Re: [PATCH] ppc32/8xx: Fix r3 trashing due to 8MB TLB page instantiation
From: Kumar Gala @ 2007-08-29 23:08 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linux-kernel, linuxppc-embedded
In-Reply-To: <46D40510.3060805@scram.de>
On Aug 28, 2007, at 6:20 AM, Jochen Friedrich wrote:
> Instantiation of 8MB pages on the TLB cache for the kernel static
> mapping trashes r3 register on !CONFIG_8xx_CPU6 configurations.
> This ensures r3 gets saved and restored.
>
> This has been posted to linuxppc-embedded by Marcelo Tosatti
> <marcelo@kvack.org>, but only an incomplete version of the patch
> has been applied in c51e078f82096a7d35ac8ec2416272e843a0e1c4.
> This patch adds the rest of the fix.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/ppc/kernel/head_8xx.S | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> This can be pulled from git://git.bocc.de/dbox2.git ppc-fixes
> diff --git a/arch/ppc/kernel/head_8xx.S b/arch/ppc/kernel/head_8xx.S
> index 944c35c..eb8d26f 100644
> --- a/arch/ppc/kernel/head_8xx.S
> +++ b/arch/ppc/kernel/head_8xx.S
> @@ -495,9 +495,7 @@ LoadLargeDTLB:
> lwz r11, 4(r0)
>
> lwz r12, 16(r0)
> -#ifdef CONFIG_8xx_CPU6
> lwz r3, 8(r0)
> -#endif
> rfi
>
> /* This is the data TLB error on the MPC8xx. This could be due to
do we need this in arch/powerpc as well?
- k
^ permalink raw reply
* Re: [PATCH] Move serial_dev_init to device_initcall()
From: Olof Johansson @ 2007-08-29 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070823002637.GA24332@lixom.net>
On Wed, Aug 22, 2007 at 07:26:37PM -0500, Olof Johansson wrote:
> With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
> initcall is now called before I/O space is setup, but it's dependent on
> it being available.
>
> Since there's no way to make dependencies between initcalls, we'll just
> have to move it to device_initcall(). Yes, it's suboptimal but I'm not
> aware of any better solution at this time.
Paul, could we get this into 2.6.23? It's a regression from before.
Andy Fleming reported no problems on the MMIO-based UART board he tested
with, and Milton said the patch didn't break qemu/prep that has PIO UART
(he hasn't yet tested to see if it's really required there though).
-Olof
^ permalink raw reply
* Re: [PATCH 8/9] mpc82xx: Update mpc8272ads, and factor out PCI and reset.
From: Kumar Gala @ 2007-08-29 22:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201929.GH24329@ld0162-tx32.am.freescale.net>
On Aug 28, 2007, at 3:19 PM, Scott Wood wrote:
> 1. PCI and reset are factored out into pq2.c. I renamed them from
> m82xx
> to pq2 because they won't work on the Integrated Host Processor
> line of
> 82xx chips (i.e. 8240, 8245, and such).
>
> 2. The PCI PIC, which is nominally board-specific, is used on multiple
> boards, and thus is used into pq2ads-pci-pic.c.
>
> 3. The new CPM binding is used.
>
> 4. General cleanup.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/boot/dts/mpc8272ads.dts | 321 +++++++------
> arch/powerpc/configs/mpc8272_ads_defconfig | 380 ++++++++-------
> arch/powerpc/platforms/82xx/Kconfig | 5 +
> arch/powerpc/platforms/82xx/Makefile | 2 +
> arch/powerpc/platforms/82xx/mpc8272_ads.c | 671 ++++
> +---------------------
> arch/powerpc/platforms/82xx/pq2.c | 93 ++++
> arch/powerpc/platforms/82xx/pq2.h | 20 +
> arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 202 ++++++++
> arch/powerpc/platforms/82xx/pq2ads.h | 2 -
> 10 files changed, 816 insertions(+), 882 deletions(-)
> create mode 100644 arch/powerpc/platforms/82xx/pq2.c
> create mode 100644 arch/powerpc/platforms/82xx/pq2.h
> create mode 100644 arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
NACK.
I don't want pq2 to be the only platform that has the PCI bus
separate from the PCI controller.
- k
^ permalink raw reply
* Re: [PATCH] powerpc: linkstation updates
From: Kumar Gala @ 2007-08-29 22:35 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0708252358440.3809@poirot.grange>
On Sun, 26 Aug 2007, Guennadi Liakhovetski wrote:
> 1. Fix RTC type - it is a rs5c372a, not rs5c372b
> 2. Configure both UART interrupts edge-triggered
> 3. Add a license header to ls_uart.c
> 4. Check for running on linkstation in a late_initcall() function. Needed
> for multiplatform builds, even though linkstation doesn't support them
> yet
> 5. Remove unneeded #include from linkstation.c
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>
> ---
>
> Nothing critical - just queue this for .24, please.
>
> Thanks
> Guennadi
>
> boot/dts/kuroboxHD.dts | 4 ++--
> boot/dts/kuroboxHG.dts | 4 ++--
> platforms/embedded6xx/linkstation.c | 1 -
> platforms/embedded6xx/ls_uart.c | 14 ++++++++++++++
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 4/4] fsl_soc.c cleanup
From: Kumar Gala @ 2007-08-29 22:33 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070820163812.GC29912@ld0162-tx32.am.freescale.net>
On Mon, 20 Aug 2007, Scott Wood wrote:
> 1. Fix get_immrbase() to use ranges, rather than reg.
>
> It is not always the case that the SoC's first reg property points
> to the beginning of the entire SoC block.
>
> 2. Update the way get_brgfreq() finds things in the device tree.
>
> It now uses names that are less namespace polluting. The old names
> are supported until all boards are converted.
>
> 3. "size" is changed from unsigned int to int, to match what
> of_get_property() expects.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 38 +++++++++++++++++++++++++++-----------
> 1 files changed, 27 insertions(+), 11 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PATCH 2/5] 85xx: Remove unnecessary loops_per_jiffy initialization code.
From: Kumar Gala @ 2007-08-29 22:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560685.8055.175.camel@ld0161-tx32>
On Fri, 27 Jul 2007, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 13 -------------
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 -----------
> 3 files changed, 0 insertions(+), 37 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH 1/5] 86xx: Remove unnecessary loops_per_jiffy initialization code.
From: Kumar Gala @ 2007-08-29 22:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1185560676.8055.173.camel@ld0161-tx32>
On Fri, 27 Jul 2007, Jon Loeliger wrote:
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
>
> Note -- This is a rebased version of an earlier patch
> from July 17. That one can be dropped.
>
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 14 ++------------
> 1 files changed, 2 insertions(+), 12 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: [PATCH] Update mpc7448hpc2 device tree to be compatible for tsi109 chip
From: Kumar Gala @ 2007-08-29 22:32 UTC (permalink / raw)
To: Zang Roy-r61911; +Cc: linuxppc-dev list, Paul Mackerras
In-Reply-To: <1184299081.30789.9.camel@localhost.localdomain>
On Thu, 13 Jul 2007, Zang Roy-r61911 wrote:
> From: Roy Zang <tie-fei.zang@freescale.com>
>
> Update mpc7448hpc2 device tree to be compatible for tsi109 chip.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> Based on previous patch
> http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038957.html
>
> arch/powerpc/boot/dts/mpc7448hpc2.dts | 15 ++++++++-------
> 1 files changed, 8 insertions(+), 7 deletions(-)
>
applied.
- k
^ permalink raw reply
* Re: ppc/powerpc, remote debugging (ptrace), floating point variables
From: Kumar Gala @ 2007-08-29 22:31 UTC (permalink / raw)
To: Visser, Udo RD-IS-E23; +Cc: linuxppc-embedded
In-Reply-To: <40D0BF15B1434F469B8639BF3A31D6F20B5F28@wiems02014.ceu.corp.heidelberg.com>
On Aug 28, 2007, at 4:40 AM, Visser, Udo RD-IS-E23 wrote:
>
> Hello world, ;-)
>
> when stepping through my own software, which is using floating =20
> point variables, gdb showed weird results (mostly NAN=B4s) for these =20=
> variables. Running the software without gdb did not show any =20
> problems. The software is compiled with floating point instructions =20=
> and the results (without gdb) are OK.
>
> My setup:
>
> MPC8349 target, "home grown", much like the MPC8349EMDS, running =20
> 2.6.16 (ppc)
> GDB, gdbserver 6.3 connected via ethernet with my Linux Host.
>
>
> What I did to get rid of the described problem:
>
> In module: arch/powerpc/kernel/process.c
> In function: void flush_fp_to_thread(struct tast_struct *tsk)
>
> I changed the line: giveup_fpu(current);
> to: giveup_fpu(tsk);
>
>
> Now my questions: Has anybody else had such problems?
> Have I found a bug, or will I encounter any yet =20
> unknown problems in the near future?
>
> I would appreciate any comment on my changes, especially from the =20
> maintainers.
I have a patch to fix just this issue.
take a look at:
http://patchwork.ozlabs.org/linuxppc/patch?id=3D13219
- k
^ permalink raw reply
* Please pull from 'for-2.6.23'
From: Kumar Gala @ 2007-08-29 22:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.23' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.23
to receive the following updates:
arch/powerpc/configs/linkstation_defconfig | 219 ++----
arch/powerpc/configs/lite5200_defconfig | 191 +----
arch/powerpc/configs/mpc7448_hpc2_defconfig | 202 +-----
arch/powerpc/configs/mpc8272_ads_defconfig | 193 +----
arch/powerpc/configs/mpc8313_rdb_defconfig | 224 ++----
arch/powerpc/configs/mpc832x_mds_defconfig | 209 +-----
arch/powerpc/configs/mpc832x_rdb_defconfig | 211 +-----
arch/powerpc/configs/mpc834x_itx_defconfig | 206 +-----
arch/powerpc/configs/mpc834x_itxgp_defconfig | 203 +-----
arch/powerpc/configs/mpc834x_mds_defconfig | 205 +-----
arch/powerpc/configs/mpc836x_mds_defconfig | 209 +-----
arch/powerpc/configs/mpc8540_ads_defconfig | 183 +----
arch/powerpc/configs/mpc8544_ds_defconfig | 459 ++++++++++++--
arch/powerpc/configs/mpc8560_ads_defconfig | 196 +-----
arch/powerpc/configs/mpc8568mds_defconfig | 43 -
arch/powerpc/configs/mpc85xx_cds_defconfig | 198 +-----
arch/powerpc/configs/mpc8641_hpcn_defconfig | 880 +++++++++++++++++++++------
arch/powerpc/configs/mpc866_ads_defconfig | 174 +----
arch/powerpc/configs/mpc885_ads_defconfig | 174 +----
arch/powerpc/configs/prpmc2800_defconfig | 213 +-----
arch/powerpc/kernel/process.c | 6
21 files changed, 2134 insertions(+), 2664 deletions(-)
Kumar Gala (2):
[POWERPC] Flush registers to proper task context
[POWERPC] Update defconfigs
commit 5cc44e086d7a4e20035997ec612678ca91f426e7
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:46:53 2007 -0500
[POWERPC] Update defconfigs
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 0ee6c15e7ba7b36a217cdadb292eeaf32a057a59
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Tue Aug 28 21:15:53 2007 -0500
[POWERPC] Flush registers to proper task context
When we flush register state for FP, Altivec, or SPE in flush_*_to_thread
we need to respect the task_struct that the caller has passed to us.
Most cases we are called with current, however sometimes (ptrace) we may
be passed a different task_struct.
This showed up when using gdbserver debugging a simple program that used
floating point. When gdb tried to show the FP regs they all showed up as
0, because the child's FP registers were never properly flushed to memory.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index a83727b..e477c9d 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -83,7 +83,7 @@ void flush_fp_to_thread(struct task_struct *tsk)
*/
BUG_ON(tsk != current);
#endif
- giveup_fpu(current);
+ giveup_fpu(tsk);
}
preempt_enable();
}
@@ -143,7 +143,7 @@ void flush_altivec_to_thread(struct task_struct *tsk)
#ifdef CONFIG_SMP
BUG_ON(tsk != current);
#endif
- giveup_altivec(current);
+ giveup_altivec(tsk);
}
preempt_enable();
}
@@ -182,7 +182,7 @@ void flush_spe_to_thread(struct task_struct *tsk)
#ifdef CONFIG_SMP
BUG_ON(tsk != current);
#endif
- giveup_spe(current);
+ giveup_spe(tsk);
}
preempt_enable();
}
^ permalink raw reply related
* Re: Network is blocked till ping is issued
From: Florian A. Voegel @ 2007-08-29 23:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EA18695@aquib01a>
Hi Antonio,
sounds to me like it could be a classical ARP problem. Have you checked the ARP cache on the non-Linux machine?
On Wed, 29 Aug 2007 19:27:19 +0200
"DI BACCO ANTONIO - technolabs" <Antonio.DiBacco@technolabs.it> wrote:
> I have two hosts 100.1.0.1 (NotLinux) and 100.1.0.2 (linux-2.6.19.2) on
> a vlan.
> On the linux box the vlan interface is created with vconfig and is
> attached to a Virtual PHY (fixed PHY).
> When Linux box starts up, NotLinux wants to setup a TCP connection with
> "Linux box" and sends a SYN packet receiving no answer from "Linux box".
> If from the console of "Linux box" I issue a ping to NotLinux then,
> after a while, the linux box starts responding to Windows.
>
> Bye,
> Antonio.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: Wolfgang Reissnegger @ 2007-08-29 21:40 UTC (permalink / raw)
To: melinda develey; +Cc: linuxppc-embedded
In-Reply-To: <177333.15506.qm@web63904.mail.re1.yahoo.com>
Hi Melinda,
depending on how your kernel is configured spin_locks will compileinto
nothing. For example, if you are compiling a kernel for a single
processor platform without preemptive scheduling then the spin_lock()
calls will be compiled into no-op as they are unnecessary on a non-SMP,
non-preemptive system.
You should still put the spin_lock calls into your code because you
never know if someone else will compile it and for another target. If
someone would, for example, compile the same code for a SMP machine then
the spin_lock will actually lock.
Cheers,
Wolfgang
melinda develey wrote:
> I discovered that I called spin_lock two times consecutively without
> calling spin_unlock but my code didn't lock (I was managing an ioctl).
> Probably I didn't understand how spin_lock works!!!!
>
> Any help?
>
> ------------------------------------------------------------------------
> Need a vacation? Get great deals to amazing places
> <http://us.rd.yahoo.com/evt=48256/*http://travel.yahoo.com/;_ylc=X3oDMTFhN2hucjlpBF9TAzk3NDA3NTg5BHBvcwM1BHNlYwNncm91cHMEc2xrA2VtYWlsLW5jbQ-->on
> Yahoo! Travel.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: spin_lock doesn't work?!?
From: Scott Wood @ 2007-08-29 21:38 UTC (permalink / raw)
To: melinda develey; +Cc: linuxppc-embedded
In-Reply-To: <177333.15506.qm@web63904.mail.re1.yahoo.com>
On Wed, Aug 29, 2007 at 02:26:15PM -0700, melinda develey wrote: I
> discovered that I called spin_lock two times consecutively without
> calling spin_unlock but my code didn't lock (I was managing an ioctl).
> Probably I didn't understand how spin_lock works!!!!
spinlocks are no-ops on uniprocessor without preemption.
-Scott
^ permalink raw reply
* spin_lock doesn't work?!?
From: melinda develey @ 2007-08-29 21:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
I discovered that I called spin_lock two times consecutively without calling spin_unlock but my code didn't lock (I was managing an ioctl).
Probably I didn't understand how spin_lock works!!!!
Any help?
---------------------------------
Need a vacation? Get great deals to amazing places on Yahoo! Travel.
[-- Attachment #2: Type: text/html, Size: 468 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] Add early debug console for CPM serial ports.
From: Scott Wood @ 2007-08-29 19:58 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070829140239.GC30184@ld0162-tx32.am.freescale.net>
On Wed, Aug 29, 2007 at 09:02:39AM -0500, Scott Wood wrote:
> > > # Temporary hack until we have migrated to asm-powerpc
> > > ifeq ($(ARCH),powerpc)
> > > +obj-$(CONFIG_CPM1)$(CONFIG_CPM2) += cpm_common.o
> >
> > Uh.. I don't think this will work properly. If CONFIG_CPM1 and
> > CONFIG_CPM2 are both enabled, it will set obj-yy rather than obj-y.
>
> The assumption was that CPM1 and CPM2 are never going to both be enabled,
> as CPM1 only exists on hardware with a unique MMU.
>
> I could add an obj-y += $(obj-yy) if you like, though.
On second thought, I'll just add a CONFIG_CPM that CPM1 and CPM2 select;
that'll make things easier for further consolidation.
-Scott
^ permalink raw reply
* Re: wmb vs mmiowb
From: Brent Casavant @ 2007-08-29 18:53 UTC (permalink / raw)
To: Nick Piggin; +Cc: linuxppc-dev, linux-ia64
In-Reply-To: <20070829005904.GB25335@wotan.suse.de>
On Wed, 29 Aug 2007, Nick Piggin wrote:
> On Tue, Aug 28, 2007 at 03:56:28PM -0500, Brent Casavant wrote:
> > The simplistic method to solve this is a lock around the section
> > issuing IOs, thereby ensuring serialization of access to the IO
> > device. However, as SN2 does not enforce an ordering between normal
> > memory transactions and memory-mapped IO transactions, you cannot
> > be sure that an IO transaction will arrive at the IO fabric "on the
> > correct side" of the unlock memory transaction using this scheme.
>
> Hmm. So what if you had the following code executed by a single CPU:
>
> writel(data, ioaddr);
> wmb();
> *mem = 10;
>
> Will the device see the io write before the store to mem?
Not necessarily. There is no guaranteed ordering between the IO write
arriving at the device and the order of the normal memory reference,
regardless of the intervening wmb(), at least on SN2. I believe the
missing component in the mental model is the effect of the platform
chipset.
Perhaps this will help. Uncached writes (i.e. IO writes) are posted
to the SN2 SHub ASIC and placed in their own queue which the SHub chip
then routes to the appropriate target. This uncached write queue is
independent of the NUMA cache-coherency maintained by the SHub ASIC
for system memory; the relative order in which the uncached writes
and the system memory traffic appear at their respective targets is
undefined with respect to eachother.
wmb() does not address this situation as it only guarantees that
the writes issued from the CPU have been posted to the chipset,
not that the chipset itself has posted the write to the final
destination. mmiowb() guarantees that all outstanding IO writes
have been issued to the IO fabric before proceeding.
I like to think of it this way (probably not 100% accurate, but it
helps me wrap my brain around this particular point):
wmb(): Ensures preceding writes have issued from the CPU.
mmiowb(): Ensures preceding IO writes have issued from the
system chipset.
mmiowb() on SN2 polls a register in SHub that reports the length
of the outstanding uncached write queue. When the queue has emptied,
it is known that all subsequent normal memory writes will therefore
arrive at their destination after all preceding IO writes have arrived
at the IO fabric.
Thus, typical mmiowb() usage, for SN2's purpose, is to ensure that
all IO traffic from a CPU has made it out to the IO fabric before
issuing the normal memory transactions which release a RAM-based
lock. The lock in this case is the one used to serialize access
to a particular IO device.
> > mmiowb() causes SN2 to drain the pending IOs from the current CPU's
> > node. Once the IOs are drained the CPU can safely unlock a normal
> > memory based lock without fear of the unlock's memory write passing
> > any outstanding IOs from that CPU.
>
> mmiowb needs to have the disclaimer that it's probably wrong if called
> outside a lock, and it's probably wrong if called between two io writes
> (need a regular wmb() in that case). I think some drivers are getting
> this wrong.
There are situations where mmiowb() can be pressed into service to
some other end, but those are rather rare. The only instance I am
personally familiar with is synchronizing a free-running counter on
a PCI device as closely as possible to the execution of a particular
line of driver code. A write of the new counter value to the device
and subsequent mmiowb() synchronizes that execution point as closely
as practical to the IO write arriving at the device. Not perfect, but
good enough for my purposes. (This was a hack, by the way, pressing
a bit of hardware into a purpose for which it wasn't really designed,
ideally the hardware would have had a better mechanism to accomplish
this goal.)
But in the normal case, I believe you are 100% correct -- wmb() would
ensure that the memory-mapped IO writes arrive at the chipset in a
particular order, and thus should arrive at the IO hardware in a particular
order. mmiowb() would not necessarily accomplish this goal, and is
incorrectly used wherever that is the intention. At least for SN2.
Brent
--
Brent Casavant All music is folk music. I ain't
bcasavan@sgi.com never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
^ permalink raw reply
* Register MII_SPEED periodically set to 0 (who is it?)
From: DI BACCO ANTONIO - technolabs @ 2007-08-29 18:38 UTC (permalink / raw)
To: linuxppc-embedded
I had to add a setting of mii_speed register of MPC880 in mdio_read and
mdio_write of mii-fec.c because it was periodically set to 0.
My fs_enet is bind to a Virtual PHY and I don't understand who touches
this register.
=20
Bye,
Antonio.
^ permalink raw reply
* Re: Network is blocked till ping is issued(update)
From: DI BACCO ANTONIO - technolabs @ 2007-08-29 18:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <F1F6EC0C8B75034F9E3A79FC85122E8EA18695@aquib01a>
I have two hosts 100.1.0.1 (NotLinux) and 100.1.0.2 (linux-2.6.19.2 on
MPC880) on
a vlan.
On the linux box the vlan interface is created with vconfig on the eth1
and is
attached to a Virtual PHY (fixed PHY).
When Linux box starts up, NotLinux wants to setup a TCP connection with
"Linux box" and sends a SYN packet receiving no answer from "Linux box".
If from the console of "Linux box" I issue a ping to NotLinux then,
after a while, the linux box starts responding to Windows.
Bye,
Antonio.
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: jschopp @ 2007-08-29 18:33 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Klein, Jan-Bernd Themann, Paul Mackerras, LKML,
LinuxPPC-Dev, Christoph Raisch, Paul Mackerras, Nathan Lynch,
Stefan Roscher
In-Reply-To: <200708291815.18197.fenkes@de.ibm.com>
> + len = strlen(dn->full_name + 1);
> + bus_len = min(len, BUS_ID_SIZE - 1);
> + memcpy(dev->ofdev.dev.bus_id, dn->full_name + 1
> + + (len - bus_len), bus_len);
> + for (i = 0; i < bus_len; i++)
> + if (dev->ofdev.dev.bus_id[i] == '/')
> + dev->ofdev.dev.bus_id[i] = '_';
>
> /* Register with generic device framework. */
> if (ibmebus_register_device_common(dev, dn->name) != 0) {
What happens when the full name is > 31 characters? It looks to me that it
will be truncated, which takes away the uniqueness guarantee.
There must be an individual property that is guaranteed to be unique and
less than 32 characters. How about "ibm,my-drc-index"? That looks like a
good candidate.
^ permalink raw reply
* Re: [PATCH 2.6.23] ibmebus: Prevent bus_id collisions
From: Nathan Lynch @ 2007-08-29 18:12 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Klein, Jan-Bernd Themann, LKML, LinuxPPC-Dev,
Christoph Raisch, Paul Mackerras, Stefan Roscher
In-Reply-To: <200708291815.18197.fenkes@de.ibm.com>
Hi-
Joachim Fenkes wrote:
> Previously, ibmebus derived a device's bus_id from its location code. The
> location code is not guaranteed to be unique, so we might get bus_id
> collisions if two devices share the same location code. The OFDT full_name,
> however, is unique, so we use that instead.
This is a userspace-visible change, but I guess it's unavoidable.
Will anything break?
Also, I dislike this approach of duplicating the firmware device tree
path in sysfs. Are GX/ibmebus devices guaranteed to be children of
the same node in the OF device tree? If so, their unit addresses will
be unique, and therefore suitable values for bus_id. I believe this
is what the powerpc vio bus code does.
^ permalink raw reply
* Network is blocked till ping is issued
From: DI BACCO ANTONIO - technolabs @ 2007-08-29 17:27 UTC (permalink / raw)
To: linuxppc-embedded
I have two hosts 100.1.0.1 (NotLinux) and 100.1.0.2 (linux-2.6.19.2) on
a vlan.
On the linux box the vlan interface is created with vconfig and is
attached to a Virtual PHY (fixed PHY).
When Linux box starts up, NotLinux wants to setup a TCP connection with
"Linux box" and sends a SYN packet receiving no answer from "Linux box".
If from the console of "Linux box" I issue a ping to NotLinux then,
after a while, the linux box starts responding to Windows.
Bye,
Antonio.
^ permalink raw reply
* [PATCH] Fix CPM1 uart console
From: Jochen Friedrich @ 2007-08-29 17:04 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 646 bytes --]
The powerpc version of commproc.c doesn't export cpm_dpram_phys due to
a typo. The ppc version of cpm_dpram_addr returns a usable virtual address
mapped to a physical address at the same location. cpm_dpram_phys returns
complete garbage as it tries to calculate an offset based on an otherwise
unused virtual adress returned by ioremap.
This patch fixes the typo for powerpc and removes the unnecessary ioremap
and corresponding virtual address for ppc.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/sysdev/commproc.c | 2 +-
arch/ppc/8xx_io/commproc.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
[-- Attachment #2: 60d3d5feb1e51a5c0d839c4b7b2b683b82b43fee.diff --]
[-- Type: text/x-patch, Size: 1161 bytes --]
diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/commproc.c
index 4f67b89..dd5417a 100644
--- a/arch/powerpc/sysdev/commproc.c
+++ b/arch/powerpc/sysdev/commproc.c
@@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
{
return (dpram_pbase + (uint)(addr - dpram_vbase));
}
-EXPORT_SYMBOL(cpm_dpram_addr);
+EXPORT_SYMBOL(cpm_dpram_phys);
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
index 7088428..593b939 100644
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -379,14 +379,12 @@ static rh_block_t cpm_boot_dpmem_rh_block[16];
static rh_info_t cpm_dpmem_info;
#define CPM_DPMEM_ALIGNMENT 8
-static u8* dpram_vbase;
static uint dpram_pbase;
void m8xx_cpm_dpinit(void)
{
spin_lock_init(&cpm_dpmem_lock);
- dpram_vbase = immr_map_size(im_cpm.cp_dpmem, CPM_DATAONLY_BASE + CPM_DATAONLY_SIZE);
dpram_pbase = (uint)&((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem;
/* Initialize the info header */
@@ -465,6 +463,6 @@ EXPORT_SYMBOL(cpm_dpram_addr);
uint cpm_dpram_phys(u8* addr)
{
- return (dpram_pbase + (uint)(addr - dpram_vbase));
+ return (uint)addr;
}
EXPORT_SYMBOL(cpm_dpram_phys);
^ permalink raw reply related
* [PATCH 9/9] bootwrapper: Use fsl_get_immr() in cuboot-pq2.c.
From: Scott Wood @ 2007-08-29 16:47 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070829164534.GA31585@ld0162-tx32.am.freescale.net>
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/cuboot-pq2.c | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/cuboot-pq2.c b/arch/powerpc/boot/cuboot-pq2.c
index 8021fd4..9d12ddd 100644
--- a/arch/powerpc/boot/cuboot-pq2.c
+++ b/arch/powerpc/boot/cuboot-pq2.c
@@ -15,6 +15,7 @@
#include "stdio.h"
#include "cuboot.h"
#include "io.h"
+#include "fsl-soc.h"
#define TARGET_CPM2
#define TARGET_HAS_ETH1
@@ -139,23 +140,20 @@ static void fixup_pci(void)
u32 *pci_regs[3];
u8 *soc_regs;
int i, len;
- void *ctrl_node, *bus_node, *parent_node, *soc_node;
+ void *ctrl_node, *bus_node, *parent_node;
u32 naddr, nsize, bus_ph, mem_log2;
ctrl_node = finddevice("/soc/pci");
if (!ctrl_node || !dt_is_compatible(ctrl_node, "fsl,pq2-pci"))
return;
- soc_node = finddevice("/soc");
- if (!soc_node || !dt_is_compatible(soc_node, "fsl,pq2-soc"))
- goto err;
-
for (i = 0; i < 3; i++)
if (!dt_xlate_reg(ctrl_node, i,
(unsigned long *)&pci_regs[i], NULL))
goto err;
- if (!dt_xlate_reg(soc_node, 0, (unsigned long *)&soc_regs, NULL))
+ soc_regs = (u8 *)fsl_get_immr();
+ if (!soc_regs)
goto err;
len = getprop(ctrl_node, "fsl,bus", &bus_ph, 4);
--
1.5.0.3
^ permalink raw reply related
* [PATCH 8/9] bootwrapper: Add fsl_get_immr() and 8xx/pq2 clock functions.
From: Scott Wood @ 2007-08-29 16:47 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070829164534.GA31585@ld0162-tx32.am.freescale.net>
fsl_get_immr() is equivalent to the kernel's get_immrbase() function.
mpc885_get_clock() transforms a crystal frequency into a system frequency
according to the PLL register settings.
pq2_get_clocks() does the same as the above for the PowerQUICC II,
except that it produces several different clocks.
The mpc8xx/pq2 set_clocks() functions modify common properties in
the device tree based on the given clock data.
The mpc885/pq2 fixup_clocks() functions call get_clocks(), and
pass the results to set_clocks().
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/boot/Makefile | 2 +-
arch/powerpc/boot/fsl-soc.c | 47 ++++++++++++++++++++
arch/powerpc/boot/fsl-soc.h | 8 +++
arch/powerpc/boot/mpc8xx.c | 80 ++++++++++++++++++++++++++++++++++
arch/powerpc/boot/mpc8xx.h | 11 +++++
arch/powerpc/boot/pq2.c | 100 +++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/pq2.h | 11 +++++
7 files changed, 258 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/fsl-soc.c
create mode 100644 arch/powerpc/boot/fsl-soc.h
create mode 100644 arch/powerpc/boot/mpc8xx.c
create mode 100644 arch/powerpc/boot/mpc8xx.h
create mode 100644 arch/powerpc/boot/pq2.c
create mode 100644 arch/powerpc/boot/pq2.h
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 27f5772..d96b06a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -45,7 +45,7 @@ src-wlib := string.S crt0.S stdio.c main.c flatdevtree.c flatdevtree_misc.c \
ns16550.c serial.c simple_alloc.c div64.S util.S \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
- cpm-serial.c stdlib.c planetcore.c
+ cpm-serial.c stdlib.c planetcore.c fsl-soc.c mpc8xx.c pq2.c
src-plat := of.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c \
diff --git a/arch/powerpc/boot/fsl-soc.c b/arch/powerpc/boot/fsl-soc.c
new file mode 100644
index 0000000..e86a1fa
--- /dev/null
+++ b/arch/powerpc/boot/fsl-soc.c
@@ -0,0 +1,47 @@
+/*
+ * Freescale SOC support functions
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "fsl-soc.h"
+#include "stdio.h"
+
+static u32 prop_buf[MAX_PROP_LEN / 4];
+
+u32 *fsl_get_immr(void)
+{
+ void *soc;
+ unsigned long ret;
+
+ soc = find_node_by_devtype(NULL, "soc");
+ if (soc) {
+ int size;
+ u32 naddr;
+
+ size = getprop(soc, "#address-cells", prop_buf, MAX_PROP_LEN);
+ if (size == 4)
+ naddr = prop_buf[0];
+ else
+ naddr = 2;
+
+ size = getprop(soc, "ranges", prop_buf, MAX_PROP_LEN);
+ if (size >= 12) {
+ if (!dt_xlate_addr(soc, prop_buf + naddr, 8, &ret)) {
+ printf("fsl_get_immr: Can't xlate %x\r\n",
+ prop_buf[naddr]);
+ ret = 0;
+ }
+ }
+ } else printf("fsl_get_immr: No SOC node\r\n");
+
+ return (u32 *)ret;
+}
diff --git a/arch/powerpc/boot/fsl-soc.h b/arch/powerpc/boot/fsl-soc.h
new file mode 100644
index 0000000..5da26fc
--- /dev/null
+++ b/arch/powerpc/boot/fsl-soc.h
@@ -0,0 +1,8 @@
+#ifndef _PPC_BOOT_FSL_SOC_H_
+#define _PPC_BOOT_FSL_SOC_H_
+
+#include "types.h"
+
+u32 *fsl_get_immr(void);
+
+#endif
diff --git a/arch/powerpc/boot/mpc8xx.c b/arch/powerpc/boot/mpc8xx.c
new file mode 100644
index 0000000..652e581
--- /dev/null
+++ b/arch/powerpc/boot/mpc8xx.c
@@ -0,0 +1,80 @@
+/*
+ * MPC8xx support functions
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "fsl-soc.h"
+#include "mpc8xx.h"
+#include "stdio.h"
+#include "io.h"
+
+#define MPC8XX_PLPRCR (0x284/4) /* PLL and Reset Control Register */
+
+/* Return system clock from crystal frequency */
+u32 mpc885_get_clock(u32 crystal)
+{
+ u32 *immr;
+ u32 plprcr;
+ int mfi, mfn, mfd, pdf, div;
+ u32 ret;
+
+ immr = fsl_get_immr();
+ if (!immr) {
+ printf("mpc885_get_clock: Couldn't get IMMR base.\r\n");
+ return 0;
+ }
+
+ plprcr = in_be32(&immr[MPC8XX_PLPRCR]);
+
+ mfi = (plprcr >> 16) & 15;
+ if (mfi < 5) {
+ printf("Warning: PLPRCR[MFI] value of %d out-of-bounds\r\n",
+ mfi);
+ mfi = 5;
+ }
+
+ pdf = (plprcr >> 1) & 0xf;
+ div = (plprcr >> 20) & 3;
+ mfd = (plprcr >> 22) & 0x1f;
+ mfn = (plprcr >> 27) & 0x1f;
+
+ ret = crystal * mfi;
+
+ if (mfn != 0)
+ ret += crystal * mfn / (mfd + 1);
+
+ return ret / (pdf + 1);
+}
+
+/* Set common device tree fields based on the given clock frequencies. */
+void mpc8xx_set_clocks(u32 sysclk)
+{
+ void *node;
+
+ dt_fixup_cpu_clocks(sysclk, sysclk / 16, sysclk);
+
+ node = finddevice("/soc/cpm");
+ if (node) {
+ setprop(node, "clock-frequency", &sysclk, 4);
+ setprop(node, "fsl,brg-frequency", &sysclk, 4);
+ }
+}
+
+int mpc885_fixup_clocks(u32 crystal)
+{
+ u32 sysclk = mpc885_get_clock(crystal);
+ if (!sysclk)
+ return 0;
+
+ mpc8xx_set_clocks(sysclk);
+ return 1;
+}
diff --git a/arch/powerpc/boot/mpc8xx.h b/arch/powerpc/boot/mpc8xx.h
new file mode 100644
index 0000000..3f59901
--- /dev/null
+++ b/arch/powerpc/boot/mpc8xx.h
@@ -0,0 +1,11 @@
+#ifndef _PPC_BOOT_MPC8xx_H_
+#define _PPC_BOOT_MPC8xx_H_
+
+#include "types.h"
+
+void mpc8xx_set_clocks(u32 sysclk);
+
+u32 mpc885_get_clock(u32 crystal);
+int mpc885_fixup_clocks(u32 crystal);
+
+#endif
diff --git a/arch/powerpc/boot/pq2.c b/arch/powerpc/boot/pq2.c
new file mode 100644
index 0000000..7ef5c91
--- /dev/null
+++ b/arch/powerpc/boot/pq2.c
@@ -0,0 +1,100 @@
+/*
+ * PowerQUICC II support functions
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "types.h"
+#include "fsl-soc.h"
+#include "pq2.h"
+#include "stdio.h"
+#include "io.h"
+
+#define PQ2_SCCR (0x10c80/4) /* System Clock Configuration Register */
+#define PQ2_SCMR (0x10c88/4) /* System Clock Mode Register */
+
+static int pq2_corecnf_map[] = {
+ 3, 2, 2, 2, 4, 4, 5, 9, 6, 11, 8, 10, 3, 12, 7, -1,
+ 6, 5, 13, 2, 14, 4, 15, 9, 0, 11, 8, 10, 16, 12, 7, -1
+};
+
+/* Get various clocks from crystal frequency.
+ * Returns zero on failure and non-zero on success.
+ */
+int pq2_get_clocks(u32 crystal, u32 *sysfreq, u32 *corefreq,
+ u32 *timebase, u32 *brgfreq)
+{
+ u32 *immr;
+ u32 sccr, scmr, mainclk, busclk;
+ int corecnf, busdf, plldf, pllmf, dfbrg;
+
+ immr = fsl_get_immr();
+ if (!immr) {
+ printf("pq2_get_clocks: Couldn't get IMMR base.\r\n");
+ return 0;
+ }
+
+ sccr = in_be32(&immr[PQ2_SCCR]);
+ scmr = in_be32(&immr[PQ2_SCMR]);
+
+ dfbrg = sccr & 3;
+ corecnf = (scmr >> 24) & 0x1f;
+ busdf = (scmr >> 20) & 0xf;
+ plldf = (scmr >> 12) & 1;
+ pllmf = scmr & 0xfff;
+
+ mainclk = crystal * (pllmf + 1) / (plldf + 1);
+ busclk = mainclk / (busdf + 1);
+
+ if (sysfreq)
+ *sysfreq = mainclk / 2;
+ if (timebase)
+ *timebase = busclk / 4;
+ if (brgfreq)
+ *brgfreq = mainclk / (1 << ((dfbrg + 1) * 2));
+
+ if (corefreq) {
+ int coremult = pq2_corecnf_map[corecnf];
+
+ if (coremult < 0)
+ *corefreq = mainclk / 2;
+ else if (coremult == 0)
+ return 0;
+ else
+ *corefreq = busclk * coremult / 2;
+ }
+
+ return 1;
+}
+
+/* Set common device tree fields based on the given clock frequencies. */
+void pq2_set_clocks(u32 sysfreq, u32 corefreq, u32 timebase, u32 brgfreq)
+{
+ void *node;
+
+ dt_fixup_cpu_clocks(corefreq, timebase, sysfreq);
+
+ node = finddevice("/soc/cpm");
+ if (node) {
+ setprop(node, "clock-frequency", &sysfreq, 4);
+ setprop(node, "fsl,brg-frequency", &brgfreq, 4);
+ }
+}
+
+int pq2_fixup_clocks(u32 crystal)
+{
+ u32 sysfreq, corefreq, timebase, brgfreq;
+
+ if (pq2_get_clocks(crystal, &sysfreq, &corefreq, &timebase, &brgfreq))
+ return 0;
+
+ pq2_set_clocks(sysfreq, corefreq, timebase, brgfreq);
+ return 1;
+}
diff --git a/arch/powerpc/boot/pq2.h b/arch/powerpc/boot/pq2.h
new file mode 100644
index 0000000..481698c
--- /dev/null
+++ b/arch/powerpc/boot/pq2.h
@@ -0,0 +1,11 @@
+#ifndef _PPC_BOOT_PQ2_H_
+#define _PPC_BOOT_PQ2_H_
+
+#include "types.h"
+
+int pq2_get_clocks(u32 crystal, u32 *sysfreq, u32 *corefreq,
+ u32 *timebase, u32 *brgfreq);
+void pq2_set_clocks(u32 sysfreq, u32 corefreq, u32 timebase, u32 brgfreq);
+int pq2_fixup_clocks(u32 crystal);
+
+#endif
--
1.5.0.3
^ permalink raw reply related
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