* [RFC PATCH 07/17] powerpc/e200: Rename CONFIG_E200 => CONFIG_FSL_E200
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexander Graf, Baruch Siach, Lucas De Marchi, Timur Tabi,
linux-kernel, Paul Gortmaker, Michael Neuling, Paul Mackerras,
Anton Blanchard, Kyle Moffett, Scott Wood, Paul Bolle, Sonny Rao,
David Gibson
In-Reply-To: <4E42AB6F.1050900@freescale.com>
Match the config symbols for FreeScale e500/e5500 chips by using "FSL"
in the name of the config symbol.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/Kconfig | 2 +-
arch/powerpc/Makefile | 2 +-
arch/powerpc/include/asm/cputable.h | 2 +-
arch/powerpc/include/asm/reg.h | 2 +-
arch/powerpc/include/asm/reg_booke.h | 2 +-
arch/powerpc/kernel/cputable.c | 4 ++--
arch/powerpc/kernel/head_fsl_booke.S | 10 +++++-----
arch/powerpc/kernel/traps.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype | 12 ++++--------
9 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 27e31c5..e3412a1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -288,7 +288,7 @@ config HUGETLB_PAGE_SIZE_VARIABLE
config MATH_EMULATION
bool "Math emulation"
- depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
+ depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || E500
---help---
Some PowerPC chips designed for embedded applications do not have
a floating-point unit and therefore do not implement the
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 57af16e..c17bc29 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -134,7 +134,7 @@ cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_6xx) += -Wa,-maltivec
cpu-as-$(CONFIG_POWER4) += -Wa,-maltivec
cpu-as-$(CONFIG_E500) += -Wa,-me500
-cpu-as-$(CONFIG_E200) += -Wa,-me200
+cpu-as-$(CONFIG_FSL_E200) += -Wa,-me200
KBUILD_AFLAGS += $(cpu-as-y)
KBUILD_CFLAGS += $(cpu-as-y)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index e30442c..b69f255 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -522,7 +522,7 @@ enum {
#ifdef CONFIG_44x
CPU_FTRS_44X & CPU_FTRS_440x6 &
#endif
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
CPU_FTRS_E200 &
#endif
#ifdef CONFIG_E500
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..f5b4f457 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -893,7 +893,7 @@
#define SPRN_SPRG_WSCRATCH_MC SPRN_SPRG1
#define SPRN_SPRG_RSCRATCH4 SPRN_SPRG7R
#define SPRN_SPRG_WSCRATCH4 SPRN_SPRG7W
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
#define SPRN_SPRG_RSCRATCH_DBG SPRN_SPRG6R
#define SPRN_SPRG_WSCRATCH_DBG SPRN_SPRG6W
#else
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 28cdbd9..81cd987 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -237,7 +237,7 @@
#define MCSR_BSL2_ERR 0x00000001UL /* Backside L2 cache error */
#endif
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
#define MCSR_MCP 0x80000000UL /* Machine Check Input Pin */
#define MCSR_CP_PERR 0x20000000UL /* Cache Push Parity Error */
#define MCSR_CPERR 0x10000000UL /* Cache Parity Error */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e35f4fb..e5b142c 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1871,7 +1871,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.platform = "ppc440",
}
#endif /* CONFIG_44x */
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
{ /* e200z5 */
.pvr_mask = 0xfff00000,
.pvr_value = 0x81000000,
@@ -1915,7 +1915,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_e200,
.platform = "ppc5554",
}
-#endif /* CONFIG_E200 */
+#endif /* CONFIG_FSL_E200 */
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_E500
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 9f5d210..134b2b8 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -137,7 +137,7 @@ _ENTRY(__early_start)
/* Setup the defaults for TLB entries */
li r2,(MAS4_TSIZED(BOOK3E_PAGESZ_4K))@l
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
oris r2,r2,MAS4_TLBSELD(1)@h
#endif
mtspr SPRN_MAS4, r2
@@ -304,7 +304,7 @@ interrupt_base:
CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
/* Machine Check Interrupt */
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
/* no RFMCI, MCSRRs on E200 */
CRITICAL_EXCEPTION(0x0200, MachineCheck, machine_check_exception)
#else
@@ -340,7 +340,7 @@ interrupt_base:
#ifdef CONFIG_PPC_FPU
FP_UNAVAILABLE_EXCEPTION
#else
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
/* E200 treats 'normal' floating point instructions as FP Unavail exception */
EXCEPTION(0x0800, FloatingPointUnavailable, program_check_exception, EXC_XFER_EE)
#else
@@ -694,7 +694,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
#endif
3: mtspr SPRN_MAS2, r12
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
/* Round robin TLB1 entries assignment */
mfspr r12, SPRN_MAS0
@@ -717,7 +717,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
rlwimi r12, r13, 0, 20, 31
7:
mtspr SPRN_MAS0,r12
-#endif /* CONFIG_E200 */
+#endif /* CONFIG_FSL_E200 */
tlb_write_entry:
tlbwe
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e3113341..81b6afd 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -560,7 +560,7 @@ int machine_check_e500(struct pt_regs *regs)
return 0;
}
#endif
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
int machine_check_e200(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 1108586..9770564 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -28,7 +28,6 @@ config PPC_BOOK3S_32
config FSL_E200
bool "Freescale e200 (also known as MPC5xx/MPC55xx)"
- select E200
config FSL_E500_V1_V2
bool "Freescale e500v1/e500v2 (also known as MPC85xx)"
@@ -141,9 +140,6 @@ config TUNE_CELL
config 8xx
bool
-config E200
- bool
-
config PPC_85xx
bool
@@ -186,12 +182,12 @@ config 4xx
config BOOKE
bool
- depends on E200 || E500 || 44x || PPC_BOOK3E
+ depends on FSL_E200 || E500 || 44x || PPC_BOOK3E
default y
config FSL_BOOKE
bool
- depends on (E200 || E500) && PPC32
+ depends on FSL_E200 || (E500 && PPC32)
select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
default y
@@ -284,7 +280,7 @@ config PPC_ICSWX
config SPE
bool "SPE Support"
- depends on E200 || (E500 && !PPC_E500MC)
+ depends on FSL_E200 || (E500 && !PPC_E500MC)
default y
---help---
This option enables kernel support for the Signal Processing
@@ -375,7 +371,7 @@ config NR_CPUS
config NOT_COHERENT_CACHE
bool
- depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
+ depends on 4xx || 8xx || FSL_E200 || PPC_MPC512x || GAMECUBE_COMMON
default n if PPC_47x
default y
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 06/17] powerpc/e500: Split FreeScale e500v1/v2 and e500mc config options
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Sonny Rao, Timur Tabi, linux-kernel, Paul Gortmaker,
Paul Mackerras, Kyle Moffett, Scott Wood, Paul Bolle
In-Reply-To: <4E42AB6F.1050900@freescale.com>
Kernels built for e500 and e500mc are fundamentally incompatible with
each other due to different cacheline sizes, support for SPE
instructions, etc.
Unfortuantely, there is a lot of support code with a morass of config
options which mostly mean the same things (E500/E500MC/PPC_85xx/etc).
As preparation for fixing up all the support code, split the config
options into two separate parts.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/platforms/Kconfig.cputype | 34 +++++++++++++++++++++++--------
1 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 0ab01b0..1108586 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -10,13 +10,15 @@ choice
prompt "Processor Type"
depends on PPC32
help
- There are five families of 32 bit PowerPC chips supported.
+ There are six families of 32 bit PowerPC chips supported.
+
The most common ones are the desktop and server CPUs (601, 603,
604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
embedded 512x/52xx/82xx/83xx/86xx counterparts.
- The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
- (85xx) each form a family of their own that is not compatible
- with the others.
+
+ The other embedded parts, namely 4xx, 8xx, e200, e500, and e500mc
+ each form a family of their own that is not compatible with the
+ others.
If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
@@ -24,10 +26,21 @@ config PPC_BOOK3S_32
bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
select PPC_FPU
-config PPC_85xx
- bool "Freescale 85xx"
+config FSL_E200
+ bool "Freescale e200 (also known as MPC5xx/MPC55xx)"
+ select E200
+
+config FSL_E500_V1_V2
+ bool "Freescale e500v1/e500v2 (also known as MPC85xx)"
select PHYS_64BIT_SUPPORTED
select E500
+ select PPC_85xx
+
+config FSL_E500MC
+ bool "Freescale e500mc (also e5500 in 32-bit mode)"
+ select PHYS_64BIT_SUPPORTED
+ select E500
+ select PPC_85xx
config PPC_8xx
bool "Freescale 8xx"
@@ -51,9 +64,6 @@ config 44x
select PHYS_64BIT_SUPPORTED
select PHYS_64BIT_DT_REQUIRED
-config E200
- bool "Freescale e200"
-
endchoice
choice
@@ -131,6 +141,12 @@ config TUNE_CELL
config 8xx
bool
+config E200
+ bool
+
+config PPC_85xx
+ bool
+
config E500
select FSL_EMB_PERFMON
select PPC_FSL_BOOK3E
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 05/17] powerpc/e500: Remove unused "default e500" from CPU table
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Timur Tabi, linux-kernel, Paul Gortmaker,
Michael Neuling, Paul Mackerras, Kyle Moffett, Scott Wood
In-Reply-To: <4E42AB6F.1050900@freescale.com>
As the 3 "e500" variants are generally incompatible with each other,
(32bit-spe, 32bit-classic-fpu, 64bit-classic-fpu), there is no such
thing as a "default e500" processor.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/kernel/cputable.c | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index edae5bb..e35f4fb 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1992,22 +1992,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_e500mc,
.platform = "ppce5500",
},
-#ifdef CONFIG_PPC32
- { /* default match */
- .pvr_mask = 0x00000000,
- .pvr_value = 0x00000000,
- .cpu_name = "(generic E500 PPC)",
- .cpu_features = CPU_FTRS_E500,
- .cpu_user_features = COMMON_USER_BOOKE |
- PPC_FEATURE_HAS_SPE_COMP |
- PPC_FEATURE_HAS_EFP_SINGLE_COMP,
- .mmu_features = MMU_FTR_TYPE_FSL_E,
- .icache_bsize = 32,
- .dcache_bsize = 32,
- .machine_check = machine_check_e500,
- .platform = "powerpc",
- }
-#endif /* CONFIG_PPC32 */
#endif /* CONFIG_E500 */
#ifdef CONFIG_PPC_A2
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Timur Tabi, linux-kernel, Paul Gortmaker,
Paul Mackerras, Anton Blanchard, Kyle Moffett, Scott Wood
In-Reply-To: <4E42AB6F.1050900@freescale.com>
Certain processor types are co-supportable, and their machine-check
handlers will be referenced if the entries in cputable.c are actually
generated, so allow more than one machine-check handler to be built in.
This fixes a bug where configuring FreeScale E5500 support (P5020DS)
into the kernel would break machine-check handling on PPC64 A2 systems
by using a bogus machine_check_generic() handler that does nothing.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/kernel/traps.c | 18 ++++++++----------
1 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4e59082..e3113341 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -418,7 +418,8 @@ int machine_check_47x(struct pt_regs *regs)
return 0;
}
-#elif defined(CONFIG_E500)
+#endif
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
int machine_check_e500mc(struct pt_regs *regs)
{
unsigned long mcsr = mfspr(SPRN_MCSR);
@@ -517,7 +518,8 @@ silent_out:
mtspr(SPRN_MCSR, mcsr);
return mfspr(SPRN_MCSR) == 0 && recoverable;
}
-
+#endif
+#ifdef CONFIG_FSL_E500_V1_V2
int machine_check_e500(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
@@ -557,12 +559,8 @@ int machine_check_e500(struct pt_regs *regs)
return 0;
}
-
-int machine_check_generic(struct pt_regs *regs)
-{
- return 0;
-}
-#elif defined(CONFIG_E200)
+#endif
+#ifdef CONFIG_E200
int machine_check_e200(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
@@ -587,7 +585,8 @@ int machine_check_e200(struct pt_regs *regs)
return 0;
}
-#else
+#endif
+
int machine_check_generic(struct pt_regs *regs)
{
unsigned long reason = get_mc_reason(regs);
@@ -623,7 +622,6 @@ int machine_check_generic(struct pt_regs *regs)
}
return 0;
}
-#endif /* everything else */
void machine_check_exception(struct pt_regs *regs)
{
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 03/17] fsl_rio: Remove FreeScale e500 conditionals
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Shaohui Xie, Alexandre Bounine, Timur Tabi,
linux-kernel, Paul Gortmaker, Liu Gang, Paul Mackerras,
Kyle Moffett, Scott Wood, Andrew Morton
In-Reply-To: <4E42AB6F.1050900@freescale.com>
The "CONFIG_E500" conditional should be unnecessary. The fsl_rio
hardware is only present on MPC85xx (e500/e500mc) anyways, although it
should build everywhere for better compile-test coverage.
The conditionally-defined fsl_rio_mcheck_exception() function lost its
two e500-specific constants in commit 82a9a4809f:
powerpc/e500: fix breakage with fsl_rio_mcheck_exception
Specifically, the references to SPRN_MCSR and MCSR_BUS_RBERR were moved
to an e500-specific file.
This patch just removes the unnecessary #ifdef, as the entire file is
effectively dead code on non-e500 platforms anyways.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/sysdev/fsl_rio.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index de170fd..783e25c 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -281,7 +281,6 @@ struct rio_priv {
static void __iomem *rio_regs_win;
-#ifdef CONFIG_E500
int fsl_rio_mcheck_exception(struct pt_regs *regs)
{
const struct exception_table_entry *entry;
@@ -308,7 +307,6 @@ int fsl_rio_mcheck_exception(struct pt_regs *regs)
return 0;
}
EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
-#endif
/**
* fsl_rio_doorbell_send - Send a MPC85xx doorbell message
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues
From: Kyle Moffett @ 2011-11-10 0:07 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Sonny Rao, Timur Tabi, linux-kernel, Paul Gortmaker,
Paul Mackerras, Kyle Moffett, Scott Wood, Anatolij Gustschin,
Paul Bolle
In-Reply-To: <4E42AB6F.1050900@freescale.com>
The "CONFIG_PHYS_64BIT" option violates the Kconfig best-practices in
various colorful ways. It has explicit dependencies, but it is also
"select"ed by various CPUs and platforms. It is not set on 64-bit
systems, but it is used by a number of pieces of powerpc code to enable
or disable 64-bit physical address support.
To resolve these issues, the option has now been split into 3:
CONFIG_PHYS_64BIT_SUPPORTED:
This hidden option should be selected by any CPU type which supports
64-bit physical addresses. This will enable the PHYS_64BIT option
to be selected. It is (obviously) always set on PPC64.
CONFIG_PHYS_64BIT_DT_REQUIRED:
This hidden option should be selected by any board or platform which
has >32-bit physical devices present in hardware. If this is set
then the CONFIG_PHYS_64BIT option will be forcibly enabled and
hidden from the user. It is (obviously) always set on PPC64.
CONFIG_PHYS_64BIT:
This option is user-controllable, where allowed by CPU and platform
settings, and should never be pointed at with a "select" statement.
Due to the values of the above two options, this is never visible on
PPC64.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/Kconfig | 4 ++--
arch/powerpc/platforms/82xx/Kconfig | 2 +-
arch/powerpc/platforms/83xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/Kconfig | 12 ++++++------
arch/powerpc/platforms/86xx/Kconfig | 1 +
arch/powerpc/platforms/Kconfig.cputype | 25 ++++++++++++++++++-------
6 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b177caa..27e31c5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -18,10 +18,10 @@ config WORD_SIZE
default 32 if !PPC64
config ARCH_PHYS_ADDR_T_64BIT
- def_bool PPC64 || PHYS_64BIT
+ def_bool PHYS_64BIT
config ARCH_DMA_ADDR_T_64BIT
- def_bool ARCH_PHYS_ADDR_T_64BIT
+ def_bool PHYS_64BIT
config MMU
bool
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 7c7df40..849d403 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -1,6 +1,6 @@
menuconfig PPC_82xx
bool "82xx-based boards (PQ II)"
- depends on 6xx
+ depends on 6xx && !PHYS_64BIT
if PPC_82xx
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 670a033..1ed8877 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -1,6 +1,6 @@
menuconfig PPC_83xx
bool "83xx-based boards"
- depends on 6xx
+ depends on 6xx && !PHYS_64BIT
select PPC_UDBG_16550
select PPC_PCI_CHOICE
select FSL_PCI if PCI
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 9088381..37f9de7 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,7 @@ config P1010_RDB
config P1022_DS
bool "Freescale P1022 DS"
select DEFAULT_UIMAGE
- select PHYS_64BIT # The DTS has 36-bit addresses
+ select PHYS_64BIT_DT_REQUIRED # The DTS has 36-bit addresses
select SWIOTLB
help
This option enables support for the Freescale P1022DS reference board.
@@ -175,7 +175,7 @@ config P2041_RDB
bool "Freescale P2041 RDB"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
+ select PHYS_64BIT_DT_REQUIRED
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
select GPIO_MPC8XXX
@@ -189,7 +189,7 @@ config P3041_DS
bool "Freescale P3041 DS"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
+ select PHYS_64BIT_DT_REQUIRED
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
select GPIO_MPC8XXX
@@ -203,7 +203,7 @@ config P3060_QDS
bool "Freescale P3060 QDS"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
+ select PHYS_64BIT_DT_REQUIRED
select SWIOTLB
select MPC8xxx_GPIO
select HAS_RAPIDIO
@@ -216,7 +216,7 @@ config P4080_DS
bool "Freescale P4080 DS"
select DEFAULT_UIMAGE
select PPC_E500MC
- select PHYS_64BIT
+ select PHYS_64BIT_DT_REQUIRED
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
select GPIO_MPC8XXX
@@ -233,7 +233,7 @@ config P5020_DS
select DEFAULT_UIMAGE
select E500
select PPC_E500MC
- select PHYS_64BIT
+ select PHYS_64BIT_DT_REQUIRED
select SWIOTLB
select ARCH_REQUIRE_GPIOLIB
select GPIO_MPC8XXX
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 8d6599d..576eb43 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -5,6 +5,7 @@ menuconfig PPC_86xx
select FSL_SOC
select ALTIVEC
select ARCH_WANT_OPTIONAL_GPIOLIB
+ select PHYS_64BIT_SUPPORTED
help
The Freescale E600 SoCs have 74xx cores.
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 9210e94..0ab01b0 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -26,6 +26,7 @@ config PPC_BOOK3S_32
config PPC_85xx
bool "Freescale 85xx"
+ select PHYS_64BIT_SUPPORTED
select E500
config PPC_8xx
@@ -47,7 +48,8 @@ config 44x
select PPC_UDBG_16550
select 4xx_SOC
select PPC_PCI_CHOICE
- select PHYS_64BIT
+ select PHYS_64BIT_SUPPORTED
+ select PHYS_64BIT_DT_REQUIRED
config E200
bool "Freescale e200"
@@ -187,14 +189,20 @@ config PPC_FSL_BOOK3E
select PPC_SMP_MUXED_IPI
default y if FSL_BOOKE
-config PTE_64BIT
- bool
- depends on 44x || E500 || PPC_86xx
- default y if PHYS_64BIT
+## Only some 32-bit CPUs support 64-bit physical addresses
+config PHYS_64BIT_SUPPORTED
+ def_bool PPC64
+
+## Some 32-bit system device trees have >32-bit physical addresses, and so
+## the kernel won't boot unless those are supported.
+config PHYS_64BIT_DT_REQUIRED
+ def_bool PPC64
+## DO NOT "select" this user-visible symbol, select the two above instead!
config PHYS_64BIT
- bool 'Large physical address support' if E500 || PPC_86xx
- depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
+ def_bool PHYS_64BIT_DT_REQUIRED
+ prompt 'Large physical address support' if !PHYS_64BIT_DT_REQUIRED
+ depends on PHYS_64BIT_SUPPORTED
---help---
This option enables kernel support for larger than 32-bit physical
addresses. This feature may not be available on all cores.
@@ -205,6 +213,9 @@ config PHYS_64BIT
If in doubt, say N here.
+config PTE_64BIT
+ def_bool PHYS_64BIT
+
config ALTIVEC
bool "AltiVec Support"
depends on 6xx || POWER4
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 01/17] powerpc/mpic: Fix bogus CONFIG_BOOKE conditional
From: Kyle Moffett @ 2011-11-10 0:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Sonny Rao, Timur Tabi, linux-kernel, Milton Miller,
Paul Gortmaker, Paul Mackerras, Kyle Moffett, Scott Wood,
Timur Tabi, Paul Bolle
In-Reply-To: <4E42AB6F.1050900@freescale.com>
The code inside the conditional is only used by 85xx CoreNet fabric
platforms, so add a new config define and use it where necessary.
Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
arch/powerpc/platforms/85xx/Kconfig | 5 +++++
arch/powerpc/platforms/85xx/Makefile | 11 ++++++-----
arch/powerpc/platforms/Kconfig.cputype | 3 +++
arch/powerpc/sysdev/mpic.c | 6 ++----
4 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 45023e2..9088381 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -181,6 +181,7 @@ config P2041_RDB
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select FSL_CORENET
help
This option enables support for the P2041 RDB board
@@ -194,6 +195,7 @@ config P3041_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select FSL_CORENET
help
This option enables support for the P3041 DS board
@@ -206,6 +208,7 @@ config P3060_QDS
select MPC8xxx_GPIO
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select FSL_CORENET
help
This option enables support for the P3060 QDS board
@@ -219,6 +222,7 @@ config P4080_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select FSL_CORENET
help
This option enables support for the P4080 DS board
@@ -235,6 +239,7 @@ config P5020_DS
select GPIO_MPC8XXX
select HAS_RAPIDIO
select PPC_EPAPR_HV_PIC
+ select FSL_CORENET
help
This option enables support for the P5020 DS board
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index bc5acb9..c6d1334 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -13,11 +13,12 @@ obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
obj-$(CONFIG_P1010_RDB) += p1010rdb.o
obj-$(CONFIG_P1022_DS) += p1022_ds.o
obj-$(CONFIG_P1023_RDS) += p1023_rds.o
-obj-$(CONFIG_P2041_RDB) += p2041_rdb.o corenet_ds.o
-obj-$(CONFIG_P3041_DS) += p3041_ds.o corenet_ds.o
-obj-$(CONFIG_P3060_QDS) += p3060_qds.o corenet_ds.o
-obj-$(CONFIG_P4080_DS) += p4080_ds.o corenet_ds.o
-obj-$(CONFIG_P5020_DS) += p5020_ds.o corenet_ds.o
+obj-$(CONFIG_P2041_RDB) += p2041_rdb.o
+obj-$(CONFIG_P3041_DS) += p3041_ds.o
+obj-$(CONFIG_P3060_QDS) += p3060_qds.o
+obj-$(CONFIG_P4080_DS) += p4080_ds.o
+obj-$(CONFIG_P5020_DS) += p5020_ds.o
+obj-$(CONFIG_FSL_CORENET) += corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8560) += sbc8560.o
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index fbecae0..9210e94 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -177,6 +177,9 @@ config FSL_BOOKE
select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
default y
+config FSL_CORENET
+ bool
+
# this is for common code between PPC32 & PPC64 FSL BOOKE
config PPC_FSL_BOOK3E
bool
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 0842c6f..1a3d84a 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1642,9 +1642,9 @@ unsigned int mpic_get_irq(void)
return mpic_get_one_irq(mpic);
}
+#ifdef CONFIG_FSL_CORENET
unsigned int mpic_get_coreint_irq(void)
{
-#ifdef CONFIG_BOOKE
struct mpic *mpic = mpic_primary;
u32 src;
@@ -1664,10 +1664,8 @@ unsigned int mpic_get_coreint_irq(void)
}
return irq_linear_revmap(mpic->irqhost, src);
-#else
- return NO_IRQ;
-#endif
}
+#endif
unsigned int mpic_get_mcirq(void)
{
--
1.7.2.5
^ permalink raw reply related
* [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
From: Kyle Moffett @ 2011-11-10 0:06 UTC (permalink / raw)
To: linuxppc-dev
Cc: Baruch Siach, Timur Tabi, linux-kernel, Paul Gortmaker,
Scott Wood
In-Reply-To: <4E42AB6F.1050900@freescale.com>
(Sorry for the repost, I accidentally omitted Baruch's email).
Hello,
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguous "CONFIG_E500" means.
In order to fix the issue at the fundamental level, I created the
following 17-patch series loosely based on Baruch's patch.
=== High-Level Summary ===
The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
each other, yet they share the same "CONFIG_E500" Kconfig option.
The following patch series splits the 32-bit CPU support into two
separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
Additionally, the 64-bit e5500 support is separated to its own config
option ("CONFIG_FSL_E5500") which is automatically combined with
either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
is enabled.
I based the patches on v3.2-rc1, please let me know if I should
update the patches against a different tree.
The first 4 patches stand on their own merits; they are generic code
cleanups necessary to support the later patches.
I'd like to know what you all think.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply
* [stable 3.1] [PATCH] powerpc/kvm: Fix build failure with HV KVM and CBE
From: Michael Neuling @ 2011-11-10 0:04 UTC (permalink / raw)
To: stable; +Cc: Alexander Graf, linuxppc-dev
From: Alexander Graf <agraf@suse.de>
powerpc/kvm: Fix build failure with HV KVM and CBE
When running with HV KVM and CBE config options enabled, I get
build failures like the following:
arch/powerpc/kernel/head_64.o: In function `cbe_system_error_hv':
(.text+0x1228): undefined reference to `do_kvm_0x1202'
arch/powerpc/kernel/head_64.o: In function `cbe_maintenance_hv':
(.text+0x1628): undefined reference to `do_kvm_0x1602'
arch/powerpc/kernel/head_64.o: In function `cbe_thermal_hv':
(.text+0x1828): undefined reference to `do_kvm_0x1802'
This is because we jump to a KVM handler when HV is enabled, but we
only generate the handler with PR KVM mode.
Upstream commit 5ccf55dd8177295813b68780f0a3c85e47306be1
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Neuling <mikey@neuling.org>
CC: stable@kernel.org (3.1 only)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index a54d92f..cf9c69b 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -267,7 +267,7 @@ vsx_unavailable_pSeries_1:
#ifdef CONFIG_CBE_RAS
STD_EXCEPTION_HV(0x1200, 0x1202, cbe_system_error)
- KVM_HANDLER_PR_SKIP(PACA_EXGEN, EXC_HV, 0x1202)
+ KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1202)
#endif /* CONFIG_CBE_RAS */
STD_EXCEPTION_PSERIES(0x1300, 0x1300, instruction_breakpoint)
@@ -275,7 +275,7 @@ vsx_unavailable_pSeries_1:
#ifdef CONFIG_CBE_RAS
STD_EXCEPTION_HV(0x1600, 0x1602, cbe_maintenance)
- KVM_HANDLER_PR_SKIP(PACA_EXGEN, EXC_HV, 0x1602)
+ KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1602)
#endif /* CONFIG_CBE_RAS */
STD_EXCEPTION_PSERIES(0x1700, 0x1700, altivec_assist)
@@ -283,7 +283,7 @@ vsx_unavailable_pSeries_1:
#ifdef CONFIG_CBE_RAS
STD_EXCEPTION_HV(0x1800, 0x1802, cbe_thermal)
- KVM_HANDLER_PR_SKIP(PACA_EXGEN, EXC_HV, 0x1802)
+ KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0x1802)
#endif /* CONFIG_CBE_RAS */
. = 0x3000
^ permalink raw reply related
* [stable 3.1] [PATCH] KVM: PPC: Assemble book3s{, _hv}_rmhandlers.S separately
From: Michael Neuling @ 2011-11-10 0:04 UTC (permalink / raw)
To: stable; +Cc: linuxppc-dev, Paul Mackerras, Alexander Graf
From: Paul Mackerras <paulus@samba.org>
KVM: PPC: Assemble book3s{,_hv}_rmhandlers.S separately
This makes arch/powerpc/kvm/book3s_rmhandlers.S and
arch/powerpc/kvm/book3s_hv_rmhandlers.S be assembled as
separate compilation units rather than having them #included in
arch/powerpc/kernel/exceptions-64s.S. We no longer have any
conditional branches between the exception prologs in
exceptions-64s.S and the KVM handlers, so there is no need to
keep their contents close together in the vmlinux image.
In their current location, they are using up part of the limited
space between the first-level interrupt handlers and the firmware
NMI data area at offset 0x7000, and with some kernel configurations
this area will overflow (e.g. allyesconfig), leading to an
"attempt to .org backwards" error when compiling exceptions-64s.S.
Moving them out requires that we add some #includes that the
book3s_{,hv_}rmhandlers.S code was previously getting implicitly
via exceptions-64s.S.
Upstream commit 177339d7f7c99a25ecfdb6baeea6a2508fb2349f
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Michael Neuling <mikey@neuling.org>
CC: stable@kernel.org (3.1 only)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 41b02c7..29ddd8b 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -427,16 +427,6 @@ slb_miss_user_pseries:
b . /* prevent spec. execution */
#endif /* __DISABLED__ */
-/* KVM's trampoline code needs to be close to the interrupt handlers */
-
-#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
-#ifdef CONFIG_KVM_BOOK3S_PR
-#include "../kvm/book3s_rmhandlers.S"
-#else
-#include "../kvm/book3s_hv_rmhandlers.S"
-#endif
-#endif
-
.align 7
.globl __end_interrupts
__end_interrupts:
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 4c66d51..3688aee 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -50,12 +50,15 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
book3s_64_mmu_host.o \
book3s_64_mmu.o \
book3s_32_mmu.o
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
+ book3s_rmhandlers.o
kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
book3s_hv.o \
book3s_hv_interrupts.o \
book3s_64_mmu_hv.o
kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
+ book3s_hv_rmhandlers.o \
book3s_hv_rm_mmu.o \
book3s_64_vio_hv.o \
book3s_hv_builtin.o
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index de29501..bc6ade9 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -20,7 +20,10 @@
#include <asm/ppc_asm.h>
#include <asm/kvm_asm.h>
#include <asm/reg.h>
+#include <asm/mmu.h>
#include <asm/page.h>
+#include <asm/ptrace.h>
+#include <asm/hvcall.h>
#include <asm/asm-offsets.h>
#include <asm/exception-64s.h>
diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
index c1f877c..5ee66ed 100644
--- a/arch/powerpc/kvm/book3s_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_rmhandlers.S
@@ -20,6 +20,7 @@
#include <asm/ppc_asm.h>
#include <asm/kvm_asm.h>
#include <asm/reg.h>
+#include <asm/mmu.h>
#include <asm/page.h>
#include <asm/asm-offsets.h>
@@ -39,6 +40,7 @@
#define MSR_NOIRQ MSR_KERNEL & ~(MSR_IR | MSR_DR)
#define FUNC(name) GLUE(.,name)
+ .globl kvmppc_skip_interrupt
kvmppc_skip_interrupt:
/*
* Here all GPRs are unchanged from when the interrupt happened
@@ -51,6 +53,7 @@ kvmppc_skip_interrupt:
rfid
b .
+ .globl kvmppc_skip_Hinterrupt
kvmppc_skip_Hinterrupt:
/*
* Here all GPRs are unchanged from when the interrupt happened
^ permalink raw reply related
* [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc
From: Kyle Moffett @ 2011-11-10 0:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Paul Gortmaker, Timur Tabi, linux-kernel
In-Reply-To: <4E42AB6F.1050900@freescale.com>
Hello,
I saw Baruch Siach's patch:
powerpc: 85xx: separate e500 from e500mc
Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguous "CONFIG_E500" means.
In order to fix the issue at the fundamental level, I created the
following 17-patch series loosely based on Baruch's patch.
=== High-Level Summary ===
The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
each other, yet they share the same "CONFIG_E500" Kconfig option.
The following patch series splits the 32-bit CPU support into two
separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
Additionally, the 64-bit e5500 support is separated to its own config
option ("CONFIG_FSL_E5500") which is automatically combined with
either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
is enabled.
I based the patches on v3.2-rc1, please let me know if I should
update the patches against a different tree.
The first 4 patches stand on their own merits; they are generic code
cleanups necessary to support the later patches.
I'd like to know what you all think.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
^ permalink raw reply
* Re: [PATCH] net: fsl_pq_mdio: fix oops when using uninitialized mutex
From: Andy Fleming @ 2011-11-09 20:10 UTC (permalink / raw)
To: Baruch Siach; +Cc: netdev, linuxppc-dev, Andy Fleming
In-Reply-To: <59b050a97a9b5382918b66f2850a80c86e52f409.1320736936.git.baruch@tkos.co.il>
> Fix this by moving the of_mdiobus_register() call earlier.
>
> Cc: Andy Fleming <afleming@freescale.com>
> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> ---
> =A0drivers/net/ethernet/freescale/fsl_pq_mdio.c | =A0 14 +++++++-------
> =A01 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/e=
thernet/freescale/fsl_pq_mdio.c
> index 52f4e8a..e17fd2f 100644
> --- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
> +++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
> @@ -385,6 +385,13 @@ static int fsl_pq_mdio_probe(struct platform_device =
*ofdev)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tbiaddr =3D *prop;
> =A0 =A0 =A0 =A0}
>
> + =A0 =A0 =A0 err =3D of_mdiobus_register(new_bus, np);
> + =A0 =A0 =A0 if (err) {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 printk (KERN_ERR "%s: Cannot register as MD=
IO bus\n",
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 new_bus->na=
me);
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_free_irqs;
> + =A0 =A0 =A0 }
> +
This fix totally breaks the point of setting tbipa beforehand.
mdiobus_register will cause the bus to be scanned, and if any of the
PHYs are at the default address for tbipa, they won't be found. I have
a different fix which I will (re)submit today.
> =A0 =A0 =A0 =A0if (tbiaddr =3D=3D -1) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0out_be32(tbipa, 0);
Andy
^ permalink raw reply
* RE: [PATCH v14 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
From: Tirumala Marri @ 2011-11-09 18:02 UTC (permalink / raw)
To: Pratyush Anand; +Cc: greg, linux-usb, Mark Miesfeld, linuxppc-dev, Fushen Chen
In-Reply-To: <CAHM4w1=OiZA4S4TBE_Hgx3yBptcWdtLu2iQiy17wb2=NaSjwZw@mail.gmail.com>
>-----Original Message-----
>From: linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+tmarri=amcc.com@lists.ozlabs.org] On Behalf
>Of Pratyush Anand
>Sent: Thursday, October 20, 2011 2:12 AM
>To: tmarri@apm.com
>Cc: Mark Miesfeld; greg@kroah.com; linux-usb@vger.kernel.org; linuxppc-
>dev@lists.ozlabs.org; Fushen Chen
>Subject: Re: [PATCH v14 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core
>Interface Layer (CIL)
>
>On Fri, Oct 7, 2011 at 8:00 AM, <tmarri@apm.com> wrote:
>> From: Tirumala Marri <tmarri@apm.com>
>>
>
>[...]
>
>> + * Do core a soft reset of the core. Be careful with this because it
>> + * resets all the internal state machines of the core.
>> + */
>> +static void dwc_otg_core_reset(struct core_if *core_if)
>> +{
>> + ulong global_regs = core_if->core_global_regs;
>> + u32 greset = 0;
>> + int count = 0;
>> +
>> + /* Wait for AHB master IDLE state. */
>> + do {
>> + udelay(10);
>> + greset = dwc_reg_read(global_regs, DWC_GRSTCTL);
>> + if (++count > 100000) {
>> + pr_warning("%s() HANG! AHB Idle
>GRSTCTL=%0x\n",
>> + __func__, greset);
>> + return;
>> + }
>> + } while (greset & DWC_RSTCTL_AHB_IDLE);
>
>As per sepcs:
>Bit 31: AHB Master Idle (AHBIdle): Indicates that the AHB Master State
>Machine is in the IDLE condition.
>So when this bit is 1 , AHB would be idle. So, what do you want here?
>If AHB is idle, control wil return from above loop rather going ahead to
>execute
>this function.
What we are trying to do is waiting for the idle before we reset the core.
We want to make sure state machine is settle down and all the transactions
Are finished before reset.
>
>> + nptxsize =
>> + DWC_RX_FIFO_START_ADDR_WR(nptxsize,
>> + params-
>>dev_rx_fifo_size);
>> + dwc_reg_write(regs, DWC_GNPTXFSIZ, nptxsize);
>> +
>> + ptxsize = DWC_RX_FIFO_START_ADDR_WR(ptxsize,
>> +
>(DWC_RX_FIFO_START_ADDR_RD
>> + (nptxsize) +
>> +
>DWC_RX_FIFO_DEPTH_RD
>> + (nptxsize)));
>> + for (i = 0;
>> + i < DWC_HWCFG4_NUM_DEV_PERIO_IN_EP_RD(core_if-
>>hwcfg4);
>> + i++) {
>
>
>Reading hwcfg4 will give you maximum nuber of fifos provided by
>hardware.
>But, a particular application (platform) may not need all those fifo.
>Since, you
>have a vriable fifo_num in your param list, so why not use that?
>
I am not sure about that. I think it should come from device tree
Based on how board is going to be configured.
^ permalink raw reply
* Re: [PATCH 5/7] fsl_pmc: update device bindings
From: Scott Wood @ 2011-11-09 17:15 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BD6F1@039-SN1MPN1-004.039d.mgd.msft.net>
On Wed, Nov 09, 2011 at 04:59:16AM -0600, Li Yang-R58472 wrote:
> >>> Do we have any chips that have ethernet controller support for wake
> >>> on user-defined packet, but a sleep mode that doesn't let it be used?
> >>
> >> I think it is more a PMC feature cause Ethernet controller on many
> >> SoCs have the filer feature, but only very limited SoCs can support
> >> using it as a wake-up source. The differences should be mostly in the
> >> PM controller block.
> >
> >Have you tried waking from sleep with it on those other SoCs?
>
> We have tried and it's not working.
OK.
> AFAIKT, the purpose of defining the clock binding is used to describe
> the topology of clocks in a system. And then used for runtime control
> of enabling/disabling clocks or getting/changing clock frequencies.
>
> But in this PM case, we just set the wakeup capability
Where "wakeup capability" means deciding whether to turn off the clock
during a low-power state. The basic information you need from the device
tree is the same -- a connection from here to there.
> and provide little runtime control of the clocks for on-chip devices.
My original intent for the binding you replaced was that it could be used
for other clock management as well -- you could use it to describe
DEVDISR or 83xx SCCR mappings as well. It was when I sent that binding
out that I recall being asked to use the clock binding.
That said, Grant has recently said he's unhappy with the current state of
the clock binding, so I'm not sure what the right thing to do here is.
> And it doesn't get any benefit of using this binding. If your concern
> is the confusion with the already existing clock binding, we can remove
> the clk in the name of the PM binding.
My concern, besides unnecessary duplication of ways to express something,
is a loss of generality.
> If we are to use the clock binding, I think adding the CSB clock, DDR
> clock, core clock, and etc with this binding is more appropriate.
That would be another use of it, but one doesn't need to imply the other.
-Scott
^ permalink raw reply
* Re: [PATCH 4/7] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Scott Wood @ 2011-11-09 16:13 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: Jerry Huang, linuxppc-dev
In-Reply-To: <20111109113813.GB3303@localhost.localdomain>
On Wed, Nov 09, 2011 at 07:38:13PM +0800, Zhao Chenhui wrote:
> On Mon, Nov 07, 2011 at 12:50:24PM -0600, Scott Wood wrote:
> > On 11/07/2011 04:27 AM, Zhao Chenhui wrote:
> > > There is only one ppc_proc_freq. no lock.
> >
> > I realize there's only one.
> >
> > I'm asking whether CPUs can have their frequencies set indpendently --
> > if the answer is no, and this function is not specific to a CPU, my only
> > concern is the lock. Either this function can be called multiple times
> > in parallel, in which case the ppc_proc_freq update should be inside the
> > lock, or it can't, in which case why do we need the lock at all?
> >
> > -Scott
>
> Yes. They can be changed independently.
> I will set ppc_proc_freq inside the lock.
If they can be changed independently, what does the global ppc_proc_freq
mean?
-Scott
^ permalink raw reply
* Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
From: Scott Wood @ 2011-11-09 16:12 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Zhao Chenhui-B35336
In-Reply-To: <3F607A5180246847A760FD34122A1E052BD4A4@039-SN1MPN1-004.039d.mgd.msft.net>
On Wed, Nov 09, 2011 at 02:31:23AM -0600, Li Yang-R58472 wrote:
> >-----Original Message-----
> >From: Wood Scott-B07421
> >Sent: Wednesday, November 09, 2011 4:58 AM
> >To: Li Yang-R58472
> >Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
> >Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
> >
> >On 11/08/2011 04:05 AM, Li Yang-R58472 wrote:
> >>> Subject: Re: [PATCH 2/7] powerpc/85xx: add HOTPLUG_CPU support
> >>>
> >>>> + flush_disable_L1();
> >>>
> >>> You'll also need to take down L2 on e500mc.
> >>
> >> Right. E500mc support is beyond this patch series. We will work on it
> >after the e500v2 support is finalized.
> >
> >I saw some support with "is_corenet"... If we don't support e500mc, make
> >sure the code doesn't try to run on e500mc.
>
> The is_corenet code is just a start of the e500mc support and is far from complete.
>
> >
> >This isn't an e500v2-only BSP you're putting the code into. :-)
>
> Yes, I know. But it will take quite some time to perfect the support
> for different type of cores.
That's fine, I'm just asking for it to be clearer that e500mc/corenet is TODO,
and ideally for the code to reject hotplug if is_corenet is set, until it's
supported.
> >>>> +static int __cpuinit smp_85xx_map_bootpg(u32 page) {
> >>>> + __iomem u32 *bootpg_ptr;
> >>>> + u32 bptr;
> >>>> +
> >>>> + /* Get the BPTR */
> >>>> + bootpg_ptr = ioremap(get_immrbase() + MPC85xx_BPTR_OFF, 4);
> >>>> +
> >>>> + /* Set the BPTR to the secondary boot page */
> >>>> + bptr = MPC85xx_BPTR_EN | (page & MPC85xx_BPTR_BOOT_PAGE_MASK);
> >>>> + out_be32(bootpg_ptr, bptr);
> >>>> +
> >>>> + iounmap(bootpg_ptr);
> >>>> + return 0;
> >>>> +}
> >>>
> >>> Shouldn't the boot page already be set by U-Boot?
> >>
> >> The register should be lost after a deep sleep. Better to do it again.
> >
> >How can it be lost after a deep sleep if we're relying on it to hold our
> >wakeup code?
>
> In order to wake up from deep sleep, the boot page has been set to the
> deep sleep restoration function. We need to set it back to the
> bootpage from u-boot.
Ah. That deserves a code comment.
> >It's not "better to do it again" if we're making a bad assumption about
> >the code and the table being in the same page.
>
> Currently we are reusing the whole boot page including the spin-table
> from u-boot. Are you suggesting to move just the boot page to kernel?
Just that it might be better to make sure that we put the same value in
BPTR that was in it when Linux booted, rather than assume that the page
that holds the spin table itself is the right one.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for PCIe
From: Kumar Gala @ 2011-11-09 15:49 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev
In-Reply-To: <1320654778-3294-1-git-send-email-tie-fei.zang@freescale.com>
How did you come by this information?
- k
On Nov 7, 2011, at 2:32 AM, Roy Zang wrote:
> P1023 external IRQ[4:6, 11] do not pin out, but the interrupts are
> shared with PCIe controller.
> The silicon internally ties the interrupts to L, so change the
> IRQ[4:6,11] to high level sensitive for PCIe.
>=20
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> arch/powerpc/boot/dts/p1023rds.dts | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/p1023rds.dts =
b/arch/powerpc/boot/dts/p1023rds.dts
> index d9b7767..66bf804 100644
> --- a/arch/powerpc/boot/dts/p1023rds.dts
> +++ b/arch/powerpc/boot/dts/p1023rds.dts
> @@ -490,9 +490,9 @@
> interrupt-map-mask =3D <0xf800 0 0 7>;
> interrupt-map =3D <
> /* IDSEL 0x0 */
> - 0000 0 0 1 &mpic 4 1
> - 0000 0 0 2 &mpic 5 1
> - 0000 0 0 3 &mpic 6 1
> + 0000 0 0 1 &mpic 4 2
> + 0000 0 0 2 &mpic 5 2
> + 0000 0 0 3 &mpic 6 2
> 0000 0 0 4 &mpic 7 1
> >;
> ranges =3D <0x2000000 0x0 0xa0000000
> @@ -532,7 +532,7 @@
> 0000 0 0 1 &mpic 8 1
> 0000 0 0 2 &mpic 9 1
> 0000 0 0 3 &mpic 10 1
> - 0000 0 0 4 &mpic 11 1
> + 0000 0 0 4 &mpic 11 2
> >;
> ranges =3D <0x2000000 0x0 0x80000000
> 0x2000000 0x0 0x80000000
> --=20
> 1.6.0.6
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: Export PIR data through sysfs
From: Scott Wood @ 2011-11-09 15:48 UTC (permalink / raw)
To: Ananth N Mavinakayanahalli; +Cc: linuxppc-dev, Anton Blanchard, mahesh
In-Reply-To: <20111109044124.GA10961@in.ibm.com>
On Wed, Nov 09, 2011 at 10:11:24AM +0530, Ananth N Mavinakayanahalli wrote:
> On Tue, Nov 08, 2011 at 10:59:46AM -0600, Scott Wood wrote:
> > On 11/08/2011 12:58 AM, Ananth N Mavinakayanahalli wrote:
> > > On Mon, Nov 07, 2011 at 11:18:32AM -0600, Scott Wood wrote:
> > >> What use does userspace have for this? If you want to return the
> > >> currently executing CPU (which unless you're pinned could change as soon
> > >> as the value is read...), why not just return smp_processor_id() or
> > >> hard_smp_processor_id()?
> > >
> > > Its not just the current cpu. Decoding PIR can tell you the core id,
> > > thread id in case of SMT, and this information can be used by userspace
> > > apps to set affinities, etc.
> >
> > Wouldn't it make more sense to expose the thread to core mappings in a
> > general way, not tied to hardware or what thread we're currently running on?
>
> AFAIK, the information encoding in PIR is platform dependent. There is
> no general way to expose this information unless you want have a
> per-platform ifdef. Even then, I am not sure if that information will
> generally be available or provided.
>
> > What's the use case for knowing this information only about the current
> > thread (or rather the state the current thread was in a few moments ago)?
>
> Its not information about the thread but about the cpu. Unless you have
> a shared LPAR environment, the data will be consistent and can be used
> by applications with knowledge of the platform.
I'm not sure what a "shared LPAR environment" is, but unless you're
pinned there's no guarantee the CPU you're running on once the read()
syscall returns is the same as the one that PIR was read on. Do you mean
you're expecting this to be run from inside a partition that runs only on
one CPU, and thus whichever thread you'll be migrated to will have the
other data remain the same?
> > > +#if defined(CONFIG_SMP) && defined(SPRN_PIR)
> > > +SYSFS_PMCSETUP(pir, SPRN_PIR);
> > > +static SYSDEV_ATTR(pir, 0400, show_pir, NULL);
> > > +#endif
> >
> > This only helps on architectures such as 8xx where you can't build as
> > SMP -- and I don't think #ifdef SPRN_PIR excludes any builds.
> >
> > It doesn't help on chips like 750 or e300 where you can run a normal 6xx
> > SMP build, you just won't have multiple CPUs, and thus won't run things
> > like the secondary entry code.
>
> Ugh! Booke builds seem to be fun :-)
Those aren't booke.
> I think this calls for a CPU_FTR_PIR. What do you suggest?
Unless someone wants to test what actually happens when you read PIR on
all these CPUs...
What platform is this meant to be useful for? Perhaps it could just be a
platform-specific sysfs entry?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for PCIe
From: Scott Wood @ 2011-11-09 15:38 UTC (permalink / raw)
To: Zang Roy-R61911; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <2239AC579C7D3646A720227A37E0268120EC83@039-SN1MPN1-004.039d.mgd.msft.net>
On Wed, Nov 09, 2011 at 09:27:02AM -0600, Zang Roy-R61911 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, November 09, 2011 0:54 AM
> > To: Zang Roy-R61911
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for
> > PCIe
> >
> > Just a note that there's magic to allow the PCIe block to output these
> > interrupts as either active-high or active-low, depending on how they're
> > configured at the mpic.
> I do not think there is any magic.
> On the contrary, it is the mpic/device tree needs to comply with the hardware setting for the interrupt polarity.
The magic is that the PCIe block can generate the interrupt in either
polarity depending on the MPIC setting (or perhaps it bases it on
sampling the pin status during/after reset, but that seems fragile).
> > > IRQ 4,5,6, 11 are internally tie to low by silicon. To use these interrupts
> > for PCIe, they need to set high level sensitive.
> > > It is clear enough for this patch.
> >
> > It's odd enough that I felt the need to go reading through the docs to
> > see why such a thing would work at all.
> If you consider the normal case, the shared irq pulls up, the PCIe interrupt set to low level sensitive. Anything odd?
The oddity is that active-high works at all for a PCI interrupt, and that
not all the PCIe interrupts have the same polarity.
-Scott
^ permalink raw reply
* RE: [PATCH] powerpc/p1023: set IRQ[4:6, 11] to high level sensitive for PCIe
From: Zang Roy-R61911 @ 2011-11-09 15:27 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4EB95EBC.8010808@freescale.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwOSwgMjAxMSAwOjU0IEFNDQo+IFRvOiBa
YW5nIFJveS1SNjE5MTENCj4gQ2M6IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBwYy1kZXZAbGlz
dHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENIXSBwb3dlcnBjL3AxMDIzOiBzZXQg
SVJRWzQ6NiwgMTFdIHRvIGhpZ2ggbGV2ZWwgc2Vuc2l0aXZlIGZvcg0KPiBQQ0llDQo+IA0KPiBP
biAxMS8wNy8yMDExIDExOjUxIFBNLCBaYW5nIFJveS1SNjE5MTEgd3JvdGU6DQo+ID4NCj4gPg0K
PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBXb29kIFNjb3R0LUIw
NzQyMQ0KPiA+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAwOCwgMjAxMSAyOjQ0IEFNDQo+ID4+
IFRvOiBaYW5nIFJveS1SNjE5MTENCj4gPj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMu
b3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBvd2VycGMvcDEwMjM6IHNldCBJUlFbNDo2
LCAxMV0gdG8gaGlnaCBsZXZlbCBzZW5zaXRpdmUNCj4gZm9yDQo+ID4+IFBDSWUNCj4gPj4NCj4g
Pj4gT24gMTEvMDcvMjAxMSAwMjozMiBBTSwgUm95IFphbmcgd3JvdGU6DQo+ID4+PiBQMTAyMyBl
eHRlcm5hbCBJUlFbNDo2LCAxMV0gZG8gbm90IHBpbiBvdXQsIGJ1dCB0aGUgaW50ZXJydXB0cyBh
cmUNCj4gPj4+IHNoYXJlZCB3aXRoIFBDSWUgY29udHJvbGxlci4NCj4gPj4+IFRoZSBzaWxpY29u
IGludGVybmFsbHkgdGllcyB0aGUgaW50ZXJydXB0cyB0byBMLCBzbyBjaGFuZ2UgdGhlDQo+ID4+
PiBJUlFbNDo2LDExXSB0byBoaWdoIGxldmVsIHNlbnNpdGl2ZSBmb3IgUENJZS4NCj4gPj4NCj4g
Pj4gU29tZSBleHRyYSBjb21tZW50YXJ5IG9uIHdoeSB0aGlzIHdvcmtzIHdvdWxkIGJlIG5pY2Uu
DQo+ID4gSSBkbyBub3Qga25vdyB3aGF0IGtpbmQgb2YgZXh0cmEgY29tbWVudGFyeSB5b3UgcmVx
dWVzdC4NCj4gDQo+IEp1c3QgYSBub3RlIHRoYXQgdGhlcmUncyBtYWdpYyB0byBhbGxvdyB0aGUg
UENJZSBibG9jayB0byBvdXRwdXQgdGhlc2UNCj4gaW50ZXJydXB0cyBhcyBlaXRoZXIgYWN0aXZl
LWhpZ2ggb3IgYWN0aXZlLWxvdywgZGVwZW5kaW5nIG9uIGhvdyB0aGV5J3JlDQo+IGNvbmZpZ3Vy
ZWQgYXQgdGhlIG1waWMuDQpJIGRvIG5vdCB0aGluayB0aGVyZSBpcyBhbnkgbWFnaWMuDQpPbiB0
aGUgY29udHJhcnksIGl0IGlzIHRoZSBtcGljL2RldmljZSB0cmVlIG5lZWRzIHRvIGNvbXBseSB3
aXRoIHRoZSBoYXJkd2FyZSBzZXR0aW5nIGZvciB0aGUgaW50ZXJydXB0IHBvbGFyaXR5Lg0KDQo+
IA0KPiA+IElSUSA0LDUsNiwgMTEgYXJlIGludGVybmFsbHkgdGllIHRvIGxvdyBieSBzaWxpY29u
LiBUbyB1c2UgdGhlc2UgaW50ZXJydXB0cw0KPiBmb3IgUENJZSwgdGhleSBuZWVkIHRvIHNldCBo
aWdoIGxldmVsIHNlbnNpdGl2ZS4NCj4gPiBJdCBpcyBjbGVhciBlbm91Z2ggZm9yIHRoaXMgcGF0
Y2guDQo+IA0KPiBJdCdzIG9kZCBlbm91Z2ggdGhhdCBJIGZlbHQgdGhlIG5lZWQgdG8gZ28gcmVh
ZGluZyB0aHJvdWdoIHRoZSBkb2NzIHRvDQo+IHNlZSB3aHkgc3VjaCBhIHRoaW5nIHdvdWxkIHdv
cmsgYXQgYWxsLg0KSWYgeW91IGNvbnNpZGVyIHRoZSBub3JtYWwgY2FzZSwgdGhlIHNoYXJlZCBp
cnEgcHVsbHMgdXAsIHRoZSBQQ0llIGludGVycnVwdCBzZXQgdG8gbG93IGxldmVsIHNlbnNpdGl2
ZS4gQW55dGhpbmcgb2RkPw0KDQo+IA0KPiA+PiBUaGUgbWFudWFsIHNheXM6DQo+ID4+DQo+ID4+
PiBJZiBhIFBDSSBFeHByZXNzIElOVHggaW50ZXJydXB0IGlzIGJlaW5nIHVzZWQsIHRoZW4gdGhl
IFBJQyBtdXN0IGJlDQo+IGNvbmZpZ3VyZWQNCj4gPj4gc28gdGhhdCBleHRlcm5hbCBpbnRlcnJ1
cHRzDQo+ID4+PiBhcmUgbGV2ZWwtc2Vuc2l0aXZlIChFSVZQUm5bU10gPSAxKS4NCj4gPiBUaGF0
IGlzIHRydWUgZm9yIGFsbCBGU0wgcG93ZXJwYyBzaWxpY29uIHdpdGggUENJZSBjb250cm9sbGVy
IGJlc2lkZSBQMTAyMy4NCj4gDQo+IFN1cmUsIG15IHBvaW50IHdhcyBtb3JlIHRoYXQgaXQgZGlk
bid0IHNheSBhbnl0aGluZyB0aGVyZSBhYm91dCBob3cgdG8NCj4gY29uZmlndXJlIEVJVlBSbltQ
XS4NCkl0IGRlcGVuZHMgb24gdGhlIGlycSBwdWxscyB1cCBvciBkb3duIGJ5IGhhcmR3YXJlLg0K
Um95DQo=
^ permalink raw reply
* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Josh Poimboeuf @ 2011-11-09 14:53 UTC (permalink / raw)
To: Suzuki Poulose
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <20111109120303.51ac3b1b@suzukikp.in.ibm.com>
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf <jpoimboe@linux.vnet.ibm.com> wrote:
>
> > On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> > > What I was suggesting is, instead of flushing the cache in
> > > relocate(), lets do it like:
> > >
> > > for e.g, on 440x, (in head_44x.S :)
> > >
> > > #ifdef CONFIG_RELOCATABLE
> > > ...
> > > bl relocate
> > >
> > > #Flush the d-cache and invalidate the i-cache here
> > > #endif
> > >
> > >
> > > This would let the different platforms do the the cache
> > > invalidation in their own way.
> > >
> > > Btw, I didn't find an instruction to flush the entire d-cache in
> > > PPC440 manual. We have instructions to flush only a block
> > > corresponding to an address.
> > >
> > > However, we have 'iccci' which would invalidate the entire i-cache
> > > which, which I think is better than 80,000 i-cache invalidates.
> >
> > In misc_32.S there are already some platform-independent cache
> > management functions. If we use those, then relocate() could simply
> > call them. Then the different platforms calling relocate() wouldn't
> > have to worry about flushing/invalidating caches.
> >
> > For example, there's a clean_dcache_range() function. Given any range
> > twice the size of the d-cache, it should flush the entire d-cache.
> > But the only drawback is that it would require the caller to know the
> > size of the d-cache.
> >
> > Instead, I think it would be preferable to create a new clean_dcache()
> > (or clean_dcache_all()?) function in misc_32.S, which could call
> > clean_dcache_range() with the appropriate args for flushing the entire
> > d-cache. relocate() could then call the platform-independent
> > clean_dcache().
> >
>
>
> How about using clean_dcache_range() to flush the range runtime
> address range [ _stext, _end ] ? That would flush the entire
> instructions.
Wouldn't that result in more cache flushing than the original solution?
For example, my kernel is 3.5MB. Assuming a 32 byte cache line size,
clean_dcache_range(_stext, _end) would result in about 115,000 dcbst's
(3.5MB / 32).
>
>
> > For i-cache invalidation there's already the (incorrectly named?)
> > flush_instruction_cache(). It uses the appropriate platform-specific
> > methods (e.g. iccci for 44x) to invalidate the entire i-cache.
>
> Agreed. The only thing that worries me is the use of KERNELBASE in the
> flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
> implementations ignore the arguments passed to iccci ?
Good question. I don't know the answer. :-)
That also may suggest a bigger can of worms. A grep of the powerpc code
shows many uses of KERNELBASE. For a relocatable kernel, nobody should
be relying on KERNELBASE except for the early relocation code. Are we
sure that all the other usages of KERNELBASE are "safe"?
For example -- the DEBUG_CRIT_EXCEPTION macro, which head_44x.S uses,
relies on KERNELBASE. That doesn't seem right to me.
Josh
^ permalink raw reply
* Re: [PATCH 4/7] powerpc/85xx: add support to JOG feature using cpufreq interface
From: Zhao Chenhui @ 2011-11-09 11:38 UTC (permalink / raw)
To: Scott Wood; +Cc: Jerry Huang, linuxppc-dev
In-Reply-To: <4EB82870.1090907@freescale.com>
On Mon, Nov 07, 2011 at 12:50:24PM -0600, Scott Wood wrote:
> On 11/07/2011 04:27 AM, Zhao Chenhui wrote:
> > On Fri, Nov 04, 2011 at 02:42:54PM -0500, Scott Wood wrote:
> >> On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
> >>> + cpufreq_frequency_table_target(policy,
> >>> + mpc85xx_freqs,
> >>> + target_freq,
> >>> + relation,
> >>> + &new);
> >>> +
> >>> + freqs.old = policy->cur;
> >>> + freqs.new = mpc85xx_freqs[new].frequency;
> >>> + freqs.cpu = policy->cpu;
> >>> +
> >>> + mutex_lock(&mpc85xx_switch_mutex);
> >>> + cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> >>> +
> >>> + pr_info("Setting frequency for core %d to %d kHz, " \
> >>> + "PLL ratio is %d/2\n",
> >>> + policy->cpu,
> >>> + mpc85xx_freqs[new].frequency,
> >>> + mpc85xx_freqs[new].index);
> >>> +
> >>> + set_pll(mpc85xx_freqs[new].index, policy->cpu);
> >>> +
> >>> + cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
> >>> + mutex_unlock(&mpc85xx_switch_mutex);
> >>> +
> >>> + ppc_proc_freq = freqs.new * 1000ul;
> >>
> >> ppc_proc_freq is global -- can CPUs not have their frequencies adjusted
> >> separately?
> >>
> >> It should be under the lock, if the lock is needed at all.
> >>
> >
> > There is only one ppc_proc_freq. no lock.
>
> I realize there's only one.
>
> I'm asking whether CPUs can have their frequencies set indpendently --
> if the answer is no, and this function is not specific to a CPU, my only
> concern is the lock. Either this function can be called multiple times
> in parallel, in which case the ppc_proc_freq update should be inside the
> lock, or it can't, in which case why do we need the lock at all?
>
> -Scott
Yes. They can be changed independently.
I will set ppc_proc_freq inside the lock.
-chenhui
^ permalink raw reply
* RE: [PATCH 5/7] fsl_pmc: update device bindings
From: Li Yang-R58472 @ 2011-11-09 10:59 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Zhao Chenhui-B35336
In-Reply-To: <4EB9939E.8070800@freescale.com>
>-----Original Message-----
>From: Wood Scott-B07421
>Sent: Wednesday, November 09, 2011 4:40 AM
>To: Li Yang-R58472
>Cc: Wood Scott-B07421; Zhao Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
>Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings
>
>On 11/08/2011 04:56 AM, Li Yang-R58472 wrote:
>>>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>> b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>>> index 07256b7..d84b4f8 100644
>>>> --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>>>> @@ -9,22 +9,27 @@ Properties:
>>>>
>>>> "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
>>>> compatible. "fsl,mpc8536-pmc" should also be listed for any chip
>>>> - whose PMC is compatible, and implies deep-sleep capability.
>>>> + whose PMC is compatible, and implies deep-sleep capability and
>>>> + wake on user defined packet(wakeup on ARP).
>>>
>>> Why does the PMC care? This is an ethernet controller feature, the
>>> PMC is just keeping the wakeup-relevant parts of the ethernet
>>> controller alive (whatever they happen to be).
>>>
>>> Do we have any chips that have ethernet controller support for wake
>>> on user-defined packet, but a sleep mode that doesn't let it be used?
>>
>> I think it is more a PMC feature cause Ethernet controller on many
>> SoCs have the filer feature, but only very limited SoCs can support
>> using it as a wake-up source. The differences should be mostly in the
>> PM controller block.
>
>Have you tried waking from sleep with it on those other SoCs?
We have tried and it's not working. Although the filer is an eTSEC feature=
, waking up on it is really a complex system wide change including eTSEC, D=
DR, ECM, PIC, and etc. And currently it's tied up to deep sleep feature. =
So I would like it to be part of the SoC integration domain i.e. PMC.
>
>> Also the wake on user-defined packet feature was never mentioned in the
>Ethernet controller part of UM.
>
>AFAICT all this "feature" is, is programming the Ethernet controller to
>filter out some packets that we don't want to wake us up, and then
>refraining from entering magic packet mode. What PMC registers are
>programmed any differently for this?
>
>It's in the PM part of the manual because that's where they generally
>describe issues related to PM. They describe magic packet there too.
>
>The set of devices which are still active during sleep is a different
>issue from the conditions on which a device will request a wake.
>
>I also don't trust our PM documentation very much. It's ambiguous just
>what gets shut down in ordinary sleep mode. E.g. the mpc8544 manual talks
>about "external interrupts", but in one place it looks like it means
>external to the SoC:
>
>> In sleep mode, all clocks internal to the e500 core are turned off,
>> including the timer facilities clock. All I/O interfaces in the device
>> logic are also shut down. Only the clocks to the MPC8544E PIC are still
>running so that an external interrupt can wake up the device.
>
>But the note immediately below that seems to imply they're talking about
>external to the core:
>
>> Only external interrupts can wake the MPC8544E from sleep mode.
>> Internal interrupt sources like the core interval timer or watchdog
>> timer depend on an active clock for their operation and these are
>disabled in sleep mode.
>
>
>
>>> Normally that shouldn't matter, but we already an unused binding for
>>> this. :-)
>>>
>>> Please provide rationale for doing it this way. Ideally it should
>>> probably use whatever http://devicetree.org/ClockBindings ends up being=
.
>>
>> I have looked into that binding. The binding was primarily defined for
>the Linux clock API which is not same as what we are doing here(set wakeup
>source).
>> If in the future the clock API also covers wakeup related features, we
>can change to use it.
>
>While Linux APIs can serve as an inspiration, they're not the basis of
>device tree bindings. The device tree is not Linux-specific, and should
>not change just because Linux changes, but rather should describe the
>hardware. We want to get this right the first time.
>
>What we are describing here is how a device's clock is connected to the
>PMC.
AFAIKT, the purpose of defining the clock binding is used to describe the t=
opology of clocks in a system. And then used for runtime control of enabli=
ng/disabling clocks or getting/changing clock frequencies.
But in this PM case, we just set the wakeup capability and provide little r=
untime control of the clocks for on-chip devices. And it doesn't get any b=
enefit of using this binding. If your concern is the confusion with the al=
ready existing clock binding, we can remove the clk in the name of the PM b=
inding.
If we are to use the clock binding, I think adding the CSB clock, DDR clock=
, core clock, and etc with this binding is more appropriate.
- Leo
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/ps3: Fix lost SMP IPIs
From: Peter Zijlstra @ 2011-11-09 9:53 UTC (permalink / raw)
To: Geoff Levand; +Cc: cbe-oss-dev, Andre Heider, linuxppc-dev
In-Reply-To: <E1RNxlN-0000wq-1P@casper.infradead.org>
On Tue, 2011-11-08 at 14:37 -0800, Geoff Levand wrote:
> Fixes the PS3 bootup hang introduced in 3.0-rc1 by:
>=20
> commit 317f394160e9beb97d19a84c39b7e5eb3d7815a
> sched: Move the second half of ttwu() to the remote cpu
>=20
> Move the PS3's LV1 EOI call lv1_end_of_interrupt_ext() from ps3_chip_eoi(=
)
> to ps3_get_irq() for IPI messages.
>=20
> If lv1_send_event_locally() is called between a previous call to
> lv1_send_event_locally() and the coresponding call to
> lv1_end_of_interrupt_ext() the second event will not be delivered to the
> target cpu.
>=20
> The PS3's SMP IPIs are implemented using lv1_send_event_locally(), so if =
two
> IPI messages of the same type are sent to the same target in a relatively
> short period of time the second IPI event can become lost when
> lv1_end_of_interrupt_ext() is called from ps3_chip_eoi().=20
Ah glad you found it! I'm not going to ack it since PPC guts are way
beyond me.
^ permalink raw reply
* Re: [PATCH v2 1/5] [ppc] Process dynamic relocations for kernel
From: Suzuki Poulose @ 2011-11-09 8:42 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Nathan Miller, Josh Poimboeuf, Dave Hansen, Alan Modra,
Scott Wood, Paul Mackerras, linuxppc-dev
In-Reply-To: <20111109120303.51ac3b1b@suzukikp.in.ibm.com>
On 11/09/11 12:03, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf<jpoimboe@linux.vnet.ibm.com> wrote:
>
>> On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
>>> What I was suggesting is, instead of flushing the cache in
>>> relocate(), lets do it like:
>>>
>>> for e.g, on 440x, (in head_44x.S :)
>>>
>>> #ifdef CONFIG_RELOCATABLE
>>> ...
>>> bl relocate
>>>
>>> #Flush the d-cache and invalidate the i-cache here
>>> #endif
>>>
>>>
>>> This would let the different platforms do the the cache
>>> invalidation in their own way.
>>>
>>> Btw, I didn't find an instruction to flush the entire d-cache in
>>> PPC440 manual. We have instructions to flush only a block
>>> corresponding to an address.
>>>
>>> However, we have 'iccci' which would invalidate the entire i-cache
>>> which, which I think is better than 80,000 i-cache invalidates.
>>
>> In misc_32.S there are already some platform-independent cache
>> management functions. If we use those, then relocate() could simply
>> call them. Then the different platforms calling relocate() wouldn't
>> have to worry about flushing/invalidating caches.
>>
>> For example, there's a clean_dcache_range() function. Given any range
>> twice the size of the d-cache, it should flush the entire d-cache.
>> But the only drawback is that it would require the caller to know the
>> size of the d-cache.
>>
>> Instead, I think it would be preferable to create a new clean_dcache()
>> (or clean_dcache_all()?) function in misc_32.S, which could call
>> clean_dcache_range() with the appropriate args for flushing the entire
>> d-cache. relocate() could then call the platform-independent
>> clean_dcache().
>>
>
>
> How about using clean_dcache_range() to flush the range runtime
> address range [ _stext, _end ] ? That would flush the entire
> instructions.
>
>
>> For i-cache invalidation there's already the (incorrectly named?)
>> flush_instruction_cache(). It uses the appropriate platform-specific
>> methods (e.g. iccci for 44x) to invalidate the entire i-cache.
>
> Agreed. The only thing that worries me is the use of KERNELBASE in the
> flush_instruction_cache() for CONFIG_4xx. Can we safely assume all 4xx
> implementations ignore the arguments passed to iccci ?
>>
>> Suzuki, if you agree with this direction, I could work up a new patch
>> if needed.
>>
>
> I have the following (untested) patch which uses clean_dcache_range()
> and flush_instruction_cache(): I will send the next version soon
> with those changes and the DYNAMIC_MEMSTART config for oldstyle
> relocatoin, if every one agrees to this.
>
>
> diff --git a/arch/powerpc/kernel/reloc_32.S
> b/arch/powerpc/kernel/reloc_32.S index 045d61e..cce0510 100644
> --- a/arch/powerpc/kernel/reloc_32.S
> +++ b/arch/powerpc/kernel/reloc_32.S
> @@ -33,10 +33,9 @@ R_PPC_RELATIVE = 22
>
> _GLOBAL(relocate)
>
> - mflr r0
> + mflr r14 /* Save our LR */
> bl 0f /* Find our current runtime
> address */ 0: mflr r12 /* Make it
> accessible */
> - mtlr r0
>
> lwz r11, (p_dyn - 0b)(r12)
> add r11, r11, r12 /* runtime address of .dynamic
> section */ @@ -87,18 +86,19 @@ eodyn: /*
> End of Dyn Table scan */
> * Work out the current offset from the link time address
> of .rela
> * section.
> * cur_offset[r7] = rela.run[r9] - rela.link [r7]
> - * _stext.link[r10] = _stext.run[r10] - cur_offset[r7]
> - * final_offset[r3] = _stext.final[r3] - _stext.link[r10]
> + * _stext.link[r12] = _stext.run[r10] - cur_offset[r7]
> + * final_offset[r3] = _stext.final[r3] - _stext.link[r12]
> */
> subf r7, r7, r9 /* cur_offset */
> - subf r10, r7, r10
> - subf r3, r10, r3 /* final_offset */
> + subf r12, r7, r10
> + subf r3, r12, r3 /* final_offset */
>
> subf r8, r6, r8 /* relaz -= relaent */
> /*
> * Scan through the .rela table and process each entry
> * r9 - points to the current .rela table entry
> * r13 - points to the symbol table
> + * r10 - holds the runtime address of _stext
> */
>
> /*
> @@ -180,12 +180,23 @@ store_half:
>
> nxtrela:
> cmpwi r8, 0 /* relasz = 0 ? */
> - ble done
> + ble flush
> add r9, r9, r6 /* move to next entry in
> the .rela table */ subf r8, r6, r8 /* relasz -= relaent */
> b applyrela
>
> -done: blr
> + /* Flush the d-cache'd instructions */
> +flush:
> + mr r3, r10
> + lis r4, (_end - _stext)@h
> + ori r4, r4, (_end - _stext)@l
Err ! This doesn't compile :
arch/powerpc/kernel/reloc_32.S: Assembler messages:
arch/powerpc/kernel/reloc_32.S:191: Error: can't resolve `_end' {*UND* section} - `_stext' {*UND* section}
I will fix it, but the idea remains the same.
Thanks
Suzuki
^ 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