* [RFC PATCH v3] 476: Set CCR2[DSTI] to prevent isync from flushing shadow TLB
From: Dave Kleikamp @ 2010-10-15 17:33 UTC (permalink / raw)
To: Josh Boyer, Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Dave Kleikamp
Josh, don't pick this up yet. It needs a bit more testing, but I think I
got it right this time.
When the DSTI (Disable Shadow TLB Invalidate) bit is set in the CCR2
register, the isync command does not flush the shadow TLB (iTLB & dTLB).
However, since the shadow TLB does not contain context information, we
want the shadow TLB flushed in situations where we are switching context.
In those situations, we explicitly clear the DSTI bit before performing
isync, and set it again afterward. We also need to do the same when we
perform isync after explicitly flushing the TLB.
The 476 requires an isync following a write to certain SPRs in order for
their changes to be effective. Such is the case with the DSTI bit, so
the first isync may not be affected by an immediate change to CCR2, but
a second isync instruction will repect the setting.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/reg_booke.h | 4 ++++
arch/powerpc/kernel/head_44x.S | 28 ++++++++++++++++++++++++++++
arch/powerpc/mm/tlb_nohash_low.S | 24 +++++++++++++++++++++++-
arch/powerpc/platforms/44x/misc_44x.S | 28 ++++++++++++++++++++++++++++
4 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 667a498..a7ecbfe 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -120,6 +120,7 @@
#define SPRN_TLB3CFG 0x2B3 /* TLB 3 Config Register */
#define SPRN_EPR 0x2BE /* External Proxy Register */
#define SPRN_CCR1 0x378 /* Core Configuration Register 1 */
+#define SPRN_CCR2_476 0x379 /* Core Configuration Register 2 (476)*/
#define SPRN_ZPR 0x3B0 /* Zone Protection Register (40x) */
#define SPRN_MAS7 0x3B0 /* MMU Assist Register 7 */
#define SPRN_MMUCR 0x3B2 /* MMU Control Register */
@@ -188,6 +189,9 @@
#define CCR1_DPC 0x00000100 /* Disable L1 I-Cache/D-Cache parity checking */
#define CCR1_TCS 0x00000080 /* Timer Clock Select */
+/* Bit definitions for CCR2. */
+#define CCR2_476_DSTI 0x08000000 /* Disable Shadow TLB Invalidate */
+
/* Bit definitions for the MCSR. */
#define MCSR_MCS 0x80000000 /* Machine Check Summary */
#define MCSR_IB 0x40000000 /* Instruction PLB Error */
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 562305b..df1ef80 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -38,6 +38,7 @@
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/synch.h>
+#include <asm/bug.h>
#include "head_booke.h"
@@ -703,8 +704,29 @@ _GLOBAL(set_context)
stw r4, 0x4(r5)
#endif
mtspr SPRN_PID,r3
+BEGIN_MMU_FTR_SECTION
+ b 1f
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
isync /* Force context change */
blr
+1:
+#ifdef CONFIG_PPC_47x
+ mfspr r10,SPRN_CCR2_476
+ rlwinm r11,r10,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r11
+ /*
+ * The first isync may not respect the change to CCR2, but its
+ * completion will ensure that the second isync does.
+ */
+ isync
+ isync /* Force context change */
+ mtspr SPRN_CCR2_476,r10
+ isync
+#else /* CONFIG_PPC_47x */
+2: trap
+ EMIT_BUG_ENTRY 2b,__FILE__,__LINE__,0;
+#endif /* CONFIG_PPC_47x */
+ blr
/*
* Init CPU state. This is called at boot time or for secondary CPUs
@@ -1083,6 +1105,12 @@ clear_utlb_entry:
isync
#endif /* CONFIG_PPC_EARLY_DEBUG_44x */
+ mfspr r3,SPRN_CCR2_476
+ /* With CCR2(DSTI) set, isync does not invalidate the shadow TLB */
+ oris r3,r3,CCR2_476_DSTI@h
+ mtspr SPRN_CCR2_476,r3
+ isync
+
/* Establish the interrupt vector offsets */
SET_IVOR(0, CriticalInput);
SET_IVOR(1, MachineCheckA);
diff --git a/arch/powerpc/mm/tlb_nohash_low.S b/arch/powerpc/mm/tlb_nohash_low.S
index b9d9fed..8e318ed 100644
--- a/arch/powerpc/mm/tlb_nohash_low.S
+++ b/arch/powerpc/mm/tlb_nohash_low.S
@@ -112,6 +112,16 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
clrrwi r4,r3,12 /* get an EPN for the hashing with V = 0 */
ori r4,r4,PPC47x_TLBE_SIZE
tlbwe r4,r7,0 /* write it */
+ mfspr r8,SPRN_CCR2_476
+ rlwinm r9,r8,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r9
+ /*
+ * The first isync may not respect the change to CCR2, but its
+ * completion will ensure that the second isync does.
+ */
+ isync
+ isync
+ mtspr SPRN_CCR2_476,r8
isync
wrtee r10
blr
@@ -180,7 +190,13 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
lwz r8,0(r10) /* Load boltmap entry */
addi r10,r10,4 /* Next word */
b 1b /* Then loop */
-1: isync /* Sync shadows */
+1: mfspr r9,SPRN_CCR2_476
+ rlwinm r10,r9,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r10
+ isync
+ isync /* Sync shadows */
+ mtspr SPRN_CCR2_476,r9
+ isync
wrtee r11
#else /* CONFIG_PPC_47x */
1: trap
@@ -203,6 +219,12 @@ _GLOBAL(_tlbivax_bcast)
isync
/* tlbivax 0,r3 - use .long to avoid binutils deps */
.long 0x7c000624 | (r3 << 11)
+ mfspr r8,SPRN_CCR2_476
+ rlwinm r9,r8,0,~CCR2_476_DSTI
+ mtspr SPRN_CCR2_476,r9
+ isync
+ isync
+ mtspr SPRN_CCR2_476,r8
isync
eieio
tlbsync
diff --git a/arch/powerpc/platforms/44x/misc_44x.S b/arch/powerpc/platforms/44x/misc_44x.S
index dc12b80..2422dd3 100644
--- a/arch/powerpc/platforms/44x/misc_44x.S
+++ b/arch/powerpc/platforms/44x/misc_44x.S
@@ -9,15 +9,40 @@
*
*/
+#include <asm/mmu.h>
#include <asm/reg.h>
#include <asm/ppc_asm.h>
.text
+#ifdef CONFIG_PPC_47x
+
+#define LOAD_CLEAR_CCR2_DSTI(REG1, REG2) \
+BEGIN_MMU_FTR_SECTION \
+ mfspr REG1,SPRN_CCR2_476; \
+ rlwinm REG2,REG1,0,~CCR2_476_DSTI; \
+ mtspr SPRN_CCR2_476,REG2; \
+ isync; \
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+
+#define RESTORE_CCR2_DSTI(REG) \
+BEGIN_MMU_FTR_SECTION \
+ mtspr SPRN_CCR2_476,REG; \
+ isync; \
+END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_47x)
+
+#else /* CONFIG_PPC_47x */
+
+#define LOAD_CLEAR_CCR2_DSTI(REG1, REG2)
+#define RESTORE_CCR2_DSTI(REG)
+
+#endif /* CONFIG_PPC_47x */
+
/*
* Do an IO access in AS1
*/
_GLOBAL(as1_readb)
+ LOAD_CLEAR_CCR2_DSTI(r8, r9)
mfmsr r7
ori r0,r7,MSR_DS
sync
@@ -29,9 +54,11 @@ _GLOBAL(as1_readb)
mtmsr r7
sync
isync
+ RESTORE_CCR2_DSTI(r8)
blr
_GLOBAL(as1_writeb)
+ LOAD_CLEAR_CCR2_DSTI(r8, r9)
mfmsr r7
ori r0,r7,MSR_DS
sync
@@ -43,4 +70,5 @@ _GLOBAL(as1_writeb)
mtmsr r7
sync
isync
+ RESTORE_CCR2_DSTI(r8)
blr
--
1.7.2.2
^ permalink raw reply related
* [PATCH] mxc_udc: add workaround for ENGcm09152 for i.MX35
From: Eric Bénard @ 2010-10-15 12:30 UTC (permalink / raw)
To: linux-usb
Cc: dbrownell, Dinh.Nguyen, gregkh, linux-kernel, linuxppc-dev,
linux-arm-kernel
this patch gives the possibility to workaround bug ENGcm09152
on i.MX35 when the hardware workaround is also implemented on
the board.
It covers the workaround described on page 25 of the following Errata :
http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
Signed-off-by: Eric Bénard <eric@eukrea.com>
---
arch/arm/mach-mx3/mach-cpuimx35.c | 1 +
drivers/usb/gadget/fsl_mxc_udc.c | 15 +++++++++++++++
include/linux/fsl_devices.h | 3 +++
3 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/mach-cpuimx35.c b/arch/arm/mach-mx3/mach-cpuimx35.c
index 6024bb9..a95ff79 100644
--- a/arch/arm/mach-mx3/mach-cpuimx35.c
+++ b/arch/arm/mach-mx3/mach-cpuimx35.c
@@ -132,6 +132,7 @@ static struct mxc_usbh_platform_data __maybe_unused usbh1_pdata = {
static struct fsl_usb2_platform_data otg_device_pdata = {
.operating_mode = FSL_USB2_DR_DEVICE,
.phy_mode = FSL_USB2_PHY_UTMI,
+ .workaround = FLS_USB2_WORKAROUND_ENGCM09152,
};
static int otg_mode_host;
diff --git a/drivers/usb/gadget/fsl_mxc_udc.c b/drivers/usb/gadget/fsl_mxc_udc.c
index eafa6d2..5bdbfe6 100644
--- a/drivers/usb/gadget/fsl_mxc_udc.c
+++ b/drivers/usb/gadget/fsl_mxc_udc.c
@@ -22,6 +22,10 @@
static struct clk *mxc_ahb_clk;
static struct clk *mxc_usb_clk;
+/* workaround ENGcm09152 for i.MX35 */
+#define USBPHYCTRL_OTGBASE_OFFSET 0x608
+#define USBPHYCTRL_EVDO (1 << 23)
+
int fsl_udc_clk_init(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata;
@@ -84,6 +88,17 @@ eenahb:
void fsl_udc_clk_finalize(struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata = pdev->dev.platform_data;
+#if defined(CONFIG_ARCH_MX35)
+ unsigned int v;
+
+ /* workaround ENGcm09152 for i.MX35 */
+ if (pdata->workaround & FLS_USB2_WORKAROUND_ENGCM09152) {
+ v = readl(MX35_IO_ADDRESS(MX35_OTG_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
+ writel(v | USBPHYCTRL_EVDO, MX35_IO_ADDRESS(MX35_OTG_BASE_ADDR +
+ USBPHYCTRL_OTGBASE_OFFSET));
+ }
+#endif
/* ULPI transceivers don't need usbpll */
if (pdata->phy_mode == FSL_USB2_PHY_ULPI) {
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 28e33fe..01a23fa 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -63,12 +63,15 @@ struct fsl_usb2_platform_data {
enum fsl_usb2_operating_modes operating_mode;
enum fsl_usb2_phy_modes phy_mode;
unsigned int port_enables;
+ unsigned int workaround;
};
/* Flags in fsl_usb2_mph_platform_data */
#define FSL_USB2_PORT0_ENABLED 0x00000001
#define FSL_USB2_PORT1_ENABLED 0x00000002
+#define FLS_USB2_WORKAROUND_ENGCM09152 (1 << 0)
+
struct spi_device;
struct fsl_spi_platform_data {
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-10-15 5:03 UTC (permalink / raw)
To: Wood Scott-B07421, Anton Vorontsov
Cc: dedekind1, Lan Chunhe-B25806, linuxppc-dev, linux-mtd, akpm,
dwmw2, Gala Kumar-B11780
In-Reply-To: <20101014110239.466072be@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, October 15, 2010 0:03 AM
> To: Zang Roy-R61911
> Cc: Anton Vorontsov; linux-mtd@lists.infradead.org;
dwmw2@infradead.org;
> dedekind1@gmail.com; akpm@linux-foundation.org; Lan Chunhe-B25806;
Wood Scott-
> B07421; Gala Kumar-B11780; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt
common
> to elbc devices
>=20
> On Wed, 13 Oct 2010 23:43:38 -0700
> "Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
> > > Plus, I think the patch is not runtime bisectable (i.e. you
> > > now do request_irq() here, but not removing it from the nand
> > > driver, so nand will fail to probe).
> > Nand driver does not need to request irq. It will use the irq
requested by
> lbc.
> > remember, other lbc device may also need to use this registered irq.
> > It should not be removed in nand driver.
>=20
> The point is that you need to make both changes in the same patch.
But according to previous discussion, if lbc driver is registered
successful, it will not be removed. (.remove function is dropped in the
patch). that is not bisectable?
nand driver will not touch the irq. all irq status process is in the lbc
driver.
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH] add icswx support v2
From: Tseng-Hui (Frank) Lin @ 2010-10-15 4:41 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <16640.1286931161@neuling.org>
On Wed, 2010-10-13 at 11:52 +1100, Michael Neuling wrote:
> In message <1286855108.14049.8.camel@flin.austin.ibm.com> you wrote:
> > icswx is a PowerPC co-processor instruction to send data to a
> > co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> > the owning process are registered in the window context of the
> > co-processor at initial time. When the icswx instruction is executed,
> > the L2 generates a cop-reg transaction on PowerBus. The transaction has
> > no address and the processor does not perform an MMU access to
> > authenticate the transaction. The coprocessor compares the LPAR_ID and
> > the PID included in the transaction and the LPAR_ID and PID held in the
> > window context to determine if the process is authorized to generate the
> > transaction.
> >
> > This patch adds icswx co-processor instruction support.
>
> Can you describe the ABI a bit?
>
> How has this changed from version 1?
>
The icswx instruction itself does nothing but generating a cop-req
transaction on PowerBus. The cop-req transaction causes 1 cache
line of data (128 bytes) sent to the co-processor. This provides
a low latency mechanism for sending small amount of data without
the co-processor becoming a master on the PowerBus.
Since the transaction has no address and the processor does not
perform an MMU access to authenticate the transaction, the
co-processor relys on the the LPAR_ID and PID to determine if
the process is authorized to generate the transaction.
The OS needs to assign a 16-bit PID for the process. This
cop-PID needs needs to be updated during context switch. The
cop-PID needs to be destroied when the context is destroied.
Change log from v1:
- Change 2'nd parameter of use_cop() from struct task_struct *task
to struct mm_struct *mm.
- Check for mm == current->active_mm before calling mtspr().
- Add a lock to guard acop related operations.
- Check for POWER7 CPU.
- Move the definition of SPRN_PID from reg_booke.h to avoid
defining SPRN_PID in two different files.
- Rename pid to acop_pid.
- Change function name disuse_cop() to drop_cop().
- Add a comment to describe the two new fields in mm_context_t.
- Moving CONFIG_ICSWX from arch/powerpc/platforms/pseries/Kconfig
to arch/powerpc/platforms/Kconfig.cputype
All other comments will be addressed in a new patch.
> Patch has been whitespace munged aswell.
>
> More comments below...
>
> >
> > Signed-off-by: Sonny Rao <sonnyrao@linux.vnet.ibm.com>
> > Signed-off-by: Tseng-Hui (Frank) Lin <thlin@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/include/asm/mmu-hash64.h | 5 ++
> > arch/powerpc/include/asm/mmu_context.h | 6 ++
> > arch/powerpc/include/asm/reg.h | 12 ++++
> > arch/powerpc/include/asm/reg_booke.h | 3 -
> > arch/powerpc/mm/mmu_context_hash64.c | 105
> > ++++++++++++++++++++++++++++++++
> > arch/powerpc/platforms/Kconfig.cputype | 16 +++++
> > 6 files changed, 144 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/mmu-hash64.h
> > b/arch/powerpc/include/asm/mmu-hash64.h
> > index acac35d..6c1ab90 100644
> > --- a/arch/powerpc/include/asm/mmu-hash64.h
> > +++ b/arch/powerpc/include/asm/mmu-hash64.h
> > @@ -423,6 +423,11 @@ typedef struct {
> > #ifdef CONFIG_PPC_SUBPAGE_PROT
> > struct subpage_prot_table spt;
> > #endif /* CONFIG_PPC_SUBPAGE_PROT */
> > +#ifdef CONFIG_ICSWX
> > + unsigned long acop; /* mask of enabled coprocessor types */
> > +#define HASH64_MAX_PID (0xFFFF)
> > + unsigned int acop_pid; /* pid value used with coprocessors */
> > +#endif /* CONFIG_ICSWX */
> > } mm_context_t;
> >
> >
> > diff --git a/arch/powerpc/include/asm/mmu_context.h
> > b/arch/powerpc/include/asm/mmu_context.h
> > index 81fb412..88118de 100644
> > --- a/arch/powerpc/include/asm/mmu_context.h
> > +++ b/arch/powerpc/include/asm/mmu_context.h
> > @@ -80,6 +80,12 @@ static inline void switch_mm(struct mm_struct *prev,
> > struct mm_struct *next,
> >
> > #define deactivate_mm(tsk,mm) do { } while (0)
> >
> > +#ifdef CONFIG_ICSWX
> > +extern void switch_cop(struct mm_struct *next);
> > +extern int use_cop(unsigned long acop, struct mm_struct *mm);
> > +extern void drop_cop(unsigned long acop, struct mm_struct *mm);
> > +#endif /* CONFIG_ICSWX */
> > +
> > /*
> > * After we have set current->mm to a new value, this activates
> > * the context for the new mm so we see the new mappings.
> > diff --git a/arch/powerpc/include/asm/reg.h
> > b/arch/powerpc/include/asm/reg.h
> > index ff0005eec..9bbf178 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -170,8 +170,19 @@
> > #define SPEFSCR_FRMC 0x00000003 /* Embedded FP rounding mode co
> ntrol
> > */
> >
> > /* Special Purpose Registers (SPRNs)*/
> > +
> > +#ifdef CONFIG_40x
> > +#define SPRN_PID 0x3B1 /* Process ID */
> > +#else
> > +#define SPRN_PID 0x030 /* Process ID */
> > +#ifdef CONFIG_BOOKE
> > +#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> > +#endif
> > +#endif
> > +
>
> Why are you moving these definitions?
>
> > #define SPRN_CTR 0x009 /* Count Register */
> > #define SPRN_DSCR 0x11
> > +#define SPRN_ACOP 0x1F /* Available Coprocessor Register */
> > #define SPRN_CTRLF 0x088
> > #define SPRN_CTRLT 0x098
> > #define CTRL_CT 0xc0000000 /* current thread */
> > @@ -879,6 +890,7 @@
> > #define PV_POWER5 0x003A
> > #define PV_POWER5p 0x003B
> > #define PV_970FX 0x003C
> > +#define PV_POWER7 0x003F
> > #define PV_630 0x0040
> > #define PV_630p 0x0041
> > #define PV_970MP 0x0044
> > diff --git a/arch/powerpc/include/asm/reg_booke.h
> > b/arch/powerpc/include/asm/reg_booke.h
> > index 667a498..5b0c781 100644
> > --- a/arch/powerpc/include/asm/reg_booke.h
> > +++ b/arch/powerpc/include/asm/reg_booke.h
> > @@ -150,8 +150,6 @@
> > * or IBM 40x.
> > */
> > #ifdef CONFIG_BOOKE
> > -#define SPRN_PID 0x030 /* Process ID */
> > -#define SPRN_PID0 SPRN_PID/* Process ID Register 0 */
> > #define SPRN_CSRR0 0x03A /* Critical Save and Restore Register 0 */
> > #define SPRN_CSRR1 0x03B /* Critical Save and Restore Register 1 */
> > #define SPRN_DEAR 0x03D /* Data Error Address Register */
> > @@ -168,7 +166,6 @@
> > #define SPRN_TCR 0x154 /* Timer Control Register */
> > #endif /* Book E */
> > #ifdef CONFIG_40x
> > -#define SPRN_PID 0x3B1 /* Process ID */
> > #define SPRN_DBCR1 0x3BD /* Debug Control Register 1 */
> > #define SPRN_ESR 0x3D4 /* Exception Syndrome Register */
> > #define SPRN_DEAR 0x3D5 /* Data Error Address Register */
> > diff --git a/arch/powerpc/mm/mmu_context_hash64.c
> > b/arch/powerpc/mm/mmu_context_hash64.c
> > index 2535828..8f432b6 100644
> > --- a/arch/powerpc/mm/mmu_context_hash64.c
> > +++ b/arch/powerpc/mm/mmu_context_hash64.c
> > @@ -18,6 +18,7 @@
> > #include <linux/mm.h>
> > #include <linux/spinlock.h>
> > #include <linux/idr.h>
> > +#include <linux/percpu.h>
> > #include <linux/module.h>
> > #include <linux/gfp.h>
> >
> > @@ -26,6 +27,103 @@
> > static DEFINE_SPINLOCK(mmu_context_lock);
> > static DEFINE_IDA(mmu_context_ida);
> >
> > +#ifdef CONFIG_ICSWX
> > +static DEFINE_SPINLOCK(mmu_context_acop_lock);
> > +static DEFINE_IDA(cop_ida);
> > +
> > +/* Lazy switch the ACOP register */
> > +static DEFINE_PER_CPU(unsigned long, acop_reg);
> > +
> > +void switch_cop(struct mm_struct *next)
> > +{
> > + if (!__is_processor(PV_POWER7))
> > + return;
> > +
> > + mtspr(SPRN_PID, next->context.acop_pid);
> > + if (next->context.acop_pid &&
> > + __get_cpu_var(acop_reg) != next->context.acop) {
> > + mtspr(SPRN_ACOP, next->context.acop);
> > + __get_cpu_var(acop_reg) = next->context.acop;
> > + }
> > +}
> > +EXPORT_SYMBOL(switch_cop);
> > +
> > +int use_cop(unsigned long acop, struct mm_struct *mm)
> > +{
> > + int acop_pid;
> > + int err;
> > +
> > + if (!__is_processor(PV_POWER7))
> > + return -ENOSYS;
>
> This should be a CPU feature.
>
> > +
> > + if (!mm)
> > + return -EINVAL;
> > +
> > + if (!mm->context.acop_pid) {
> > + if (!ida_pre_get(&cop_ida, GFP_KERNEL))
> > + return -ENOMEM;
> > +again:
> > + spin_lock(&mmu_context_acop_lock);
> > + err = ida_get_new_above(&cop_ida, 1, &acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > +
> > + if (err == -EAGAIN)
> > + goto again;
>
> Make this a do while loop. Please don't create your own loop
> prematives.
>
> > + else if (err)
> > + return err;
> > +
> > + if (acop_pid > HASH64_MAX_PID) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + return -EBUSY;
> > + }
> > + mm->context.acop_pid = acop_pid;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_PID, mm->context.acop_pid);
> > + }
> > + spin_lock(&mmu_context_acop_lock);
> > + mm->context.acop |= acop;
> > + spin_unlock(&mmu_context_acop_lock);
> > +
> > + get_cpu_var(acop_reg) = mm->context.acop;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_ACOP, mm->context.acop);
> > + put_cpu_var(acop_reg);
> > +
> > + return mm->context.acop_pid;
> > +}
> > +EXPORT_SYMBOL(use_cop);
> > +
> > +void drop_cop(unsigned long acop, struct mm_struct *mm)
> > +{
> > + if (!__is_processor(PV_POWER7))
> > + return;
> > +
> > + if (WARN_ON(!mm))
> > + return;
> > +
> > + spin_lock(&mmu_context_acop_lock);
> > + mm->context.acop &= ~acop;
> > + spin_unlock(&mmu_context_acop_lock);
> > + if (!mm->context.acop) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, mm->context.acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + mm->context.acop_pid = 0;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_PID, mm->context.acop_pid);
> > + } else {
> > + get_cpu_var(acop_reg) = mm->context.acop;
> > + if (mm == current->active_mm)
> > + mtspr(SPRN_ACOP, mm->context.acop);
> > + put_cpu_var(acop_reg);
> > + }
> > + mmput(mm);
> > +}
> > +EXPORT_SYMBOL(drop_cop);
> > +#endif /* CONFIG_ICSWX */
> > +
> > /*
> > * The proto-VSID space has 2^35 - 1 segments available for user
> > mappings.
> > * Each segment contains 2^28 bytes. Each context maps 2^44 bytes,
> > @@ -93,6 +191,13 @@ EXPORT_SYMBOL_GPL(__destroy_context);
> >
> > void destroy_context(struct mm_struct *mm)
> > {
> > +#ifdef CONFIG_ICSWX
> > + if (mm->context.acop_pid) {
> > + spin_lock(&mmu_context_acop_lock);
> > + ida_remove(&cop_ida, mm->context.acop_pid);
> > + spin_unlock(&mmu_context_acop_lock);
> > + }
> > +#endif /* CONFIG_ICSWX */
>
> Can you put this in a destroy_context_acop() and #define that funtion
> based CONFIG_ICSWX. Cleans up the #ifdefs here
>
>
> > __destroy_context(mm->context.id);
> > subpage_prot_free(mm);
> > mm->context.id = NO_CONTEXT;
> > diff --git a/arch/powerpc/platforms/Kconfig.cputype
> > b/arch/powerpc/platforms/Kconfig.cputype
> > index d361f81..9674703 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -220,6 +220,22 @@ config VSX
> >
> > If in doubt, say Y here.
> >
> > +config ICSWX
> > + bool "Support for PowerPC icswx co-processor instruction"
> > + depends on POWER4
> > + default n
> > + ---help---
> > +
> > + Enabling this option to turn on the PowerPC icswx co-processor
> > + instruction support for POWER7 processors.
> > + This option is only useful if you have a processor that supports
> > + icswx co-processor instruction. It does not have any affect on
> > + processors without icswx co-processor instruction.
> > +
> > + This support slightly increases kernel memory usage.
> > +
> > + Say N if you do not have a POWER7 processor and a PowerPC
> > co-processor.
> > +
> > config SPE
> > bool "SPE Support"
> > depends on E200 || (E500 && !PPC_E500MC)
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
> >
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 4:01 UTC (permalink / raw)
To: linasvepstas
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Nishanth Aravamudan, Thomas Gleixner, linuxppc-dev
In-Reply-To: <AANLkTinEzRpREFzDVhPS5ynqjYydHOs9iW5NM6W9Tf9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]
On Thu, 2010-10-14 at 20:54 -0500, Linas Vepstas wrote:
> On 14 October 2010 19:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> > eeh and pci_dlpar #undef DEBUG, but I think they were added before the
> > ability to control this from Kconfig. It's really annoying to only get
> > some of the debug messages from these files. Leave the lpar.c #undef
> > alone as it produces so much output as to make the kernel unusable.
> > Update the Kconfig text to indicate this particular quirk :)
> >
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> OK, ignore my last email.
>
> Acked by: Linas Vepstas <linasvepstas@gmail.com>
I guess I'll ack it too seeing I added PPC_PSERIES_DEBUG:
Acked-by: Michael Ellerman <michael@ellerman.id.au>
> > --- a/arch/powerpc/platforms/pseries/Kconfig
> > +++ b/arch/powerpc/platforms/pseries/Kconfig
> > @@ -47,6 +47,12 @@ config LPARCFG
> > config PPC_PSERIES_DEBUG
> > depends on PPC_PSERIES && PPC_EARLY_DEBUG
> > bool "Enable extra debug logging in platforms/pseries"
> > + help
> > + Say Y here if you want the pseries core to produce a bunch of
> > + debug messages to the system log. Select this if you are having a
> > + problem with the pseries core and want to see more of what is
> > + going on. This does not enable debugging in lpar.c, which must
> > + be manually done due to its verbosity.
> > default y
>
> Umm, I see "default y" and you are not changing this but ... default y
> ?? Really?
Yes, default y if early debug is enabled. Unlike DEBUG_KERNEL,
PPC_EARLY_DEBUG is a pretty good indication that you are doing some
kernel development - because you have to choose exactly which platform
you're working on.
> Also, I am guessing that the lpar spam is due only to a handful of printk's,
> while most of the rest will be infrequent. Just knock out the
> high-frequency ones...
No they're all related to the HPTE code, so you basically don't want any
of them enabled unless you're debugging that, and most people aren't.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-10-15 2:15 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: dedekind1, Hu Mingkai-B21284, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <20101014110118.11fabed5@udp111988uds.am.freescale.net>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, October 15, 2010 0:01 AM
> To: Zang Roy-R61911
> Cc: Wood Scott-B07421; Anton Vorontsov; linux-mtd@lists.infradead.org;
> dwmw2@infradead.org; dedekind1@gmail.com; akpm@linux-foundation.org;
Lan
> Chunhe-B25806; Gala Kumar-B11780; linuxppc-dev@ozlabs.org; Hu
Mingkai-B21284
> Subject: Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver
detect nand
> flash partitions
>=20
> On Wed, 13 Oct 2010 20:09:02 -0700
> "Zang Roy-R61911" <r61911@freescale.com> wrote:
>=20
> > > > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl =3D NULL;
> > > > >
> > > > > No need for =3D NULL.
> > > > Any harm? Or just personal habit or style? Can you explain about
> > why?
> > >
> > > Besides not wanting superfluous code on general principle, it
could
> > > hide a bug if in the future the real initialization is missing on
some
> > > code path. It would become a runtime NULL dereference rather than
a
> > > compiler warning.
> >
> > Not exactly.
> > Per my understand, if the pointer will definitely be assigned in
code
> > path,
> > it is not necessary to init it when define. for example,
> >
> > char c;
> > char b;
> > char *a;
> > if (condition)
> > a =3D &c;
> > else
> > a =3D &b;
> > ...
> >
> > for other case, if the path will not ensure the pointer assignment,
it
> > will be inited
> > when define to avoid warning. for example,
> >
> > char c;
> > char *a =3D NULL;
> > if (condition)
> > a =3D &c;
> > ...
>=20
> Yes, but this patch looks like the former case, not the
> latter.=20
That is right.
> Is GCC giving a warning without the initializer?
no.
we are on the same point.
Thanks.
Roy
^ permalink raw reply
* Re: [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Linas Vepstas @ 2010-10-15 1:54 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1287103733-7121-1-git-send-email-nacc@us.ibm.com>
On 14 October 2010 19:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> eeh and pci_dlpar #undef DEBUG, but I think they were added before the
> ability to control this from Kconfig. It's really annoying to only get
> some of the debug messages from these files. Leave the lpar.c #undef
> alone as it produces so much output as to make the kernel unusable.
> Update the Kconfig text to indicate this particular quirk :)
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
OK, ignore my last email.
Acked by: Linas Vepstas <linasvepstas@gmail.com>
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -47,6 +47,12 @@ config LPARCFG
> =C2=A0config PPC_PSERIES_DEBUG
> =C2=A0 =C2=A0 =C2=A0 =C2=A0depends on PPC_PSERIES && PPC_EARLY_DEBUG
> =C2=A0 =C2=A0 =C2=A0 =C2=A0bool "Enable extra debug logging in platforms/=
pseries"
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0help
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 Say Y here if you want the pseries core to =
produce a bunch of
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 debug messages to the system log. Select th=
is if you are having a
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 problem with the pseries core and want to s=
ee more of what is
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 going on. This does not enable debugging in=
lpar.c, which must
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 be manually done due to its verbosity.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0default y
Umm, I see "default y" and you are not changing this but ... default y
?? Really?
Also, I am guessing that the lpar spam is due only to a handful of printk's=
,
while most of the rest will be infrequent. Just knock out the
high-frequency ones...
--linas
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Linas Vepstas @ 2010-10-15 1:47 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Thomas Gleixner, linuxppc-dev
In-Reply-To: <1287078495-11722-1-git-send-email-nacc@us.ibm.com>
On 14 October 2010 12:48, Nishanth Aravamudan <nacc@us.ibm.com> wrote:
> These files undef DEBUG, but I think they were added before the ability
> to control this from Kconfig.
Right.
> It's really annoying to only get some of
> the debug messages!
I don't get the big picture. Will there be some CONFIG_DEBUG_EEH in Kconfig?
or just some option to turn on DEBUG for all powerpc-related files?
Or maybe I am demonstrating my utter ignorance of some new whiz-bang
Kconfig technology?
Anyway, I see no harm in the EEH portion of the patch.
--linas
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: tiejun.chen @ 2010-10-15 1:28 UTC (permalink / raw)
To: Scott Wood; +Cc: david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014105126.08da9dd7@udp111988uds.am.freescale.net>
Scott Wood wrote:
> On Thu, 14 Oct 2010 11:27:09 +0800
> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>
>> tiejun.chen wrote:
>>> Scott Wood wrote:
>>>> On Wed, 13 Oct 2010 09:17:01 +0800
>>>> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
>>>>
>>>>> Scott Wood wrote:
>>>>>> The crash is happening somewhere in mpic_set_irq_type():
>>>>> Agreed. That is just where I pointed out on my email replied for OOPS. To enable
>>>>> DBG to figure out 'src' and 'mpic->irq_count' from the file,
>>>>> arch/powerpc/sysdev/mpic.c, .
>>>>> ======
>>>>> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
>>>>> {
>>>>> ......
>>>>> if (src >= mpic->irq_count)
>>>>> return -EINVAL;
>>>>> ^
>>>>> I think this OOPS may be from here.
>>>> No, it's after that. His board code is using the mpic's "isu" remapping
>>> I means OOPS is *from* here. According to David's call trace,
>>> mpic_set_irq_type() is the last issued function. And that corresponding return
>>> value, R3, is '0xffffffea', -22, and also '-EINVAL'.
>
> Just because that value is in r3 doesn't mean that src >=
> mpic->irq_count.
>
> Consider something like:
>
> cmplw r4, r5
> li r3, -EINVAL
> bgelr
Right absolutely and got it.
Thanks again
Tiejun
> ...
>
>
> -Scott
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* [PATCH v2] pseries: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-15 0:48 UTC (permalink / raw)
To: nacc
Cc: Frans Pop, linux-kernel, Paul Mackerras, Anton Blanchard,
Brian King, Linas Vepstas, linuxppc-dev, Thomas Gleixner
eeh and pci_dlpar #undef DEBUG, but I think they were added before the
ability to control this from Kconfig. It's really annoying to only get
some of the debug messages from these files. Leave the lpar.c #undef
alone as it produces so much output as to make the kernel unusable.
Update the Kconfig text to indicate this particular quirk :)
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 6 ++++++
arch/powerpc/platforms/pseries/eeh.c | 2 --
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 --
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index c667f0f..3139814 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -47,6 +47,12 @@ config LPARCFG
config PPC_PSERIES_DEBUG
depends on PPC_PSERIES && PPC_EARLY_DEBUG
bool "Enable extra debug logging in platforms/pseries"
+ help
+ Say Y here if you want the pseries core to produce a bunch of
+ debug messages to the system log. Select this if you are having a
+ problem with the pseries core and want to see more of what is
+ going on. This does not enable debugging in lpar.c, which must
+ be manually done due to its verbosity.
default y
config PPC_SMLPAR
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 34b7dc1..17a11c8 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -21,8 +21,6 @@
* Please address comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
-#undef DEBUG
-
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/list.h>
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index 4b7a062..5fcc92a 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -25,8 +25,6 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#undef DEBUG
-
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
--
1.7.1
^ permalink raw reply related
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 0:29 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <20101015002300.GB7522@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]
On Thu, 2010-10-14 at 17:23 -0700, Nishanth Aravamudan wrote:
> On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
> > On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> > > Because the lpar and pci_dlpar code is pretty low-level & verbose,
> > > perhaps it makes sense to add another Kconfig variable for really
> > > low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> > > especially in the EEH area when doing PCI stuff.
> >
> > I really don't think you want to enable the lpar debug by default.
> > Have you tried it? It can make for a pretty unusable system, just
> > because of the console spam.
>
> Yeah, you're right. After enabling it, I had to kill my boot and start
> over w/o the lpar DEBUG on.
:)
> I assume dlpar_pci is similar?
That should be OK to enable I think. Suck it and see I guess.
> I dunno, would a patch to a least remove the EEH one be ok? Seems like
> it isn't super-verbose, and does have some handy output.
Yeah definitely. That undef was merged as part of a cleanup/fix patch
but shouldn't have been.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: msi_bitmap.c question
From: Michael Ellerman @ 2010-10-15 0:25 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <6cfa2d1c7ecd946ea4acbd3077defa92@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]
On Thu, 2010-10-14 at 15:56 -0700, Tirumala Marri wrote:
> Hi,
>
> I am trying to resubmit a patch for MSI support for ppc4xx devices.
> One of the review feedback was not to use the bit map as it is only
> for the devices which don’t have hard wired mapping between interrupt
> controller interrupts and MSI number. For example intr-ctrl0 interrupt
> 20 goes to MSI-0, interrupt 21 goes to MSI-1 ..etc. But when I checked
> freescale SoCs and cell SoCs they have interrupts hard wired to MSI
> interrupts.
>
>
>
> Why do they have to use the bitmap and create irqhost, even though
> they are one-to-one mapped between interrupt controller numbers and
> MSI ?
I'm not quite sure I understand your question.
The MSI bitmap and the irq_host are two different things.
The MSI bitmap is basically an allocator for hardware numbers that can
be used for MSI. On some interrupt controllers that might be any
interrupt that's not used, on others there are restrictions on which
numbers can be used for MSI, it depends. So it's possible you don't need
to use that code, but I don't know how your hardware works.
The irq_host is the struct that controls mapping hardware irq numbers
into linux irq numbers. The cell MSI code has no restrictions on what
the MSI value is, so it just uses the Linux irq number directly using
irq_create_direct_mapping().
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-15 0:23 UTC (permalink / raw)
To: Michael Ellerman
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1287101663.4194.5.camel@concordia>
On 15.10.2010 [11:14:23 +1100], Michael Ellerman wrote:
> On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> > These files undef DEBUG, but I think they were added before the ability
> > to control this from Kconfig.
>
> Perhaps. Some people, *cough*, have a tendency to merge those back in
> again from time to time :)
>
> > It's really annoying to only get some of the debug messages!
>
> True, but ..
>
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> >
> > ---
> > Because the lpar and pci_dlpar code is pretty low-level & verbose,
> > perhaps it makes sense to add another Kconfig variable for really
> > low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> > especially in the EEH area when doing PCI stuff.
>
> I really don't think you want to enable the lpar debug by default.
> Have you tried it? It can make for a pretty unusable system, just
> because of the console spam.
Yeah, you're right. After enabling it, I had to kill my boot and start
over w/o the lpar DEBUG on. I assume dlpar_pci is similar?
I dunno, would a patch to a least remove the EEH one be ok? Seems like
it isn't super-verbose, and does have some handy output.
> Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than
> all this, but requires setup at runtime.
True, I started looking into it, but only realized today that eeh.c had
that #undef! :)
Thanks,
Nish
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply
* Re: [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Michael Ellerman @ 2010-10-15 0:14 UTC (permalink / raw)
To: Nishanth Aravamudan
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
In-Reply-To: <1287078495-11722-1-git-send-email-nacc@us.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
On Thu, 2010-10-14 at 10:48 -0700, Nishanth Aravamudan wrote:
> These files undef DEBUG, but I think they were added before the ability
> to control this from Kconfig.
Perhaps. Some people, *cough*, have a tendency to merge those back in
again from time to time :)
> It's really annoying to only get some of the debug messages!
True, but ..
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
>
> ---
> Because the lpar and pci_dlpar code is pretty low-level & verbose,
> perhaps it makes sense to add another Kconfig variable for really
> low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
> especially in the EEH area when doing PCI stuff.
I really don't think you want to enable the lpar debug by default. Have
you tried it? It can make for a pretty unusable system, just because of
the console spam.
Also these days there is CONFIG_DYNAMIC_DEBUG which is much smarter than
all this, but requires setup at runtime.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Possible kernel stack overflow due to fast interrupts
From: Benjamin Herrenschmidt @ 2010-10-14 23:57 UTC (permalink / raw)
To: Rick Tao; +Cc: linuxppc-dev
In-Reply-To: <174398.42321.qm@web50405.mail.re2.yahoo.com>
On Thu, 2010-10-14 at 13:45 -0700, Rick Tao wrote:
> Hi, all,
.../...
> In the context of task A
> a. NIP would point to the instruction after switch_to().
> b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
> c. do something that would trigger an interrupt later on (such as timer)
> d. call schedule() for context switch to task B.
> In this step,
> task B's stack is popped INT_FRAME_SIZE size for context restore.
> Note that task B's ksp = X - INT_FRAME_SIZE
>
> In the context of task B again
> a1. similar to step "a" above
>
> b1. similar to step "b" above
> c1. interrupt occurs, go to step "1" above, and repeat!!!
>
> As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
> on each loop. It will eventually overflow.
So if I follow you correctly, you are worried that by the time execution
resumes in B, and before it pops the second frame off, it might get
another interrupt and re-preempt...
Now unless I missed something, that cannot happen because
preempt_schedule_irq() does increment the preempt count:
add_preempt_count(PREEMPT_ACTIVE);
local_irq_enable();
schedule();
local_irq_disable();
sub_preempt_count(PREEMPT_ACTIVE);
Which means that it won't preempt again in finish_task_switch, and so
will eventually come back, turn EE back off, and pop off the stack
frame.
Or am I missing something ?
Cheers,
Ben.
^ permalink raw reply
* msi_bitmap.c question
From: Tirumala Marri @ 2010-10-14 22:56 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 612 bytes --]
Hi,
I am trying to resubmit a patch for MSI support for ppc4xx devices. One of
the review feedback was not to use the bit map as it is only for the devices
which don’t have hard wired mapping between interrupt controller interrupts
and MSI number. For example intr-ctrl0 interrupt 20 goes to MSI-0, interrupt
21 goes to MSI-1 ..etc. But when I checked freescale SoCs and cell SoCs
they have interrupts hard wired to MSI interrupts.
Why do they have to use the bitmap and create irqhost, even though they are
one-to-one mapped between interrupt controller numbers and MSI ?
Thx,
Marri
[-- Attachment #2: Type: text/html, Size: 1843 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Mark Brown @ 2010-10-14 20:49 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, kumar.gala, alsa-devel mailing list
In-Reply-To: <AANLkTimWgbJ0oDsQkXxzjQ_pDxm_Vd+PJRhQJzN0BLTc@mail.gmail.com>
On Thu, Oct 14, 2010 at 01:21:33PM -0500, Timur Tabi wrote:
> Mark, can you pick up this patch for us? Because it depends on
> "powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it
> will break the build if we apply to powerpc-next.
>
> You can grab the patch from http://patchwork.ozlabs.org/patch/67095/
Done, but I had to fix up what looked like an add/add conflict with
headers in the file. Since I was editing that area of the file anyway I
also dropped the #define DEBUG as it looked like a mistake. Please send
followup patch(es) correcting things if I messed up any of that.
^ permalink raw reply
* Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: Frank Ch. Eigler @ 2010-10-14 20:46 UTC (permalink / raw)
To: divya; +Cc: linuxppc-dev, systemtap
In-Reply-To: <4CB704AC.4070203@linux.vnet.ibm.com>
divya <dipraksh@linux.vnet.ibm.com> writes:
> While running systemtap tests on the p6 machine , against the kernel
> version 2.6.36-rc7-git3 Oops occured , here are the call trace
Did the oops happen during a systemtap module startup vs. operation
vs. shutdown? stap -V version string?
> BUG: spinlock bad magic on CPU#6, stapio/20398
> -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res
> lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
> Call Trace:
> [c0000001effbfab0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
> [c0000001effbfb60] [c0000000002c9274] .spin_bug+0xb0/0xd4
> [c0000001effbfbf0] [c0000000002c953c] .do_raw_spin_lock+0x48/0x184
> [c0000001effbfc90] [c00000000054af78] ._raw_spin_lock+0x10/0x24
> [c0000001effbfd00] [d000000003015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [...]
> kernel BUG at kernel/timer.c:681!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> [...]
> [c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
> [c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
We have had occasional problems in the past with something like this:
http://sourceware.org/PR10651, but it never was tracked down to a
systemtap bug per se, as opposed to suspicions that the kernel was not
satisfying one of its guarantees w.r.t. del_timer_sync().
- FChE
^ permalink raw reply
* Possible kernel stack overflow due to fast interrupts
From: Rick Tao @ 2010-10-14 20:45 UTC (permalink / raw)
To: linuxppc-dev
Hi, all,
I am looking at the kernel source of 2.6.32. It appears to me that kernel stack can be easily getting overflowed in case of fast interrupts. Here is my observation, any comments? Thanks,
Let's assume task A triggers the fast interrupts, and task B was running when the fast interrupt occur.
In the context of task B (according to entry_32.S)
0. Assume task B's ksp = X
1. the interrupt causes exception, allocate exception frame space from
the task B'stack (ksp = X - INT_FRAME_SIZE).
2. interrupt handler is invoked
3. ret_from_except, and resume_kernel is invoked
4. then preempt_schedule_irq is called, which in trun, __schedule() and
context_switch is called. Assume it switches to task A.
In this step,
task B's stack is pushed another INT_FRAME_SIZE to save its context,
so task B's ksp = X - 2 * INT_FRAME_SIZE now.
In the context of task A
a. NIP would point to the instruction after switch_to().
b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
c. do something that would trigger an interrupt later on (such as timer)
d. call schedule() for context switch to task B.
In this step,
task B's stack is popped INT_FRAME_SIZE size for context restore.
Note that task B's ksp = X - INT_FRAME_SIZE
In the context of task B again
a1. similar to step "a" above
b1. similar to step "b" above
c1. interrupt occurs, go to step "1" above, and repeat!!!
As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
on each loop. It will eventually overflow.
Thanks for your input.
Rick
^ permalink raw reply
* [PATCH] powerpc: fix warning when compiling immap_qe.h
From: Timur Tabi @ 2010-10-14 20:15 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
Fix the warnings genereted by arch/powerpc/include/asm/immap_qe.h when
CONFIG_PHYS_ADDR_T_64BIT is defined:
immap_qe.h: In function 'immrbar_virt_to_phys':
immap_qe.h:472:8: warning: cast from pointer to integer of different size
immap_qe.h:472:24: warning: cast from pointer to integer of different size
immap_qe.h:473:5: warning: cast from pointer to integer of different size
immap_qe.h:473:21: warning: cast from pointer to integer of different size
immap_qe.h:474:36: warning: cast from pointer to integer of different size
Note that the QE does not support 36-bit physical addresses, so even when
CONFIG_PHYS_ADDR_T_64BIT is defined, the QE MURAM must be located below the
4GB boundary.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/immap_qe.h | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_qe.h b/arch/powerpc/include/asm/immap_qe.h
index 4e10f50..0edb684 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -467,13 +467,22 @@ struct qe_immap {
extern struct qe_immap __iomem *qe_immr;
extern phys_addr_t get_qe_base(void);
-static inline unsigned long immrbar_virt_to_phys(void *address)
+/*
+ * Returns the offset within the QE address space of the given pointer.
+ *
+ * Note that the QE does not support 36-bit physical addresses, so if
+ * get_qe_base() returns a number above 4GB, the caller will probably fail.
+ */
+static inline phys_addr_t immrbar_virt_to_phys(void *address)
{
- if ( ((u32)address >= (u32)qe_immr) &&
- ((u32)address < ((u32)qe_immr + QE_IMMAP_SIZE)) )
- return (unsigned long)(address - (u32)qe_immr +
- (u32)get_qe_base());
- return (unsigned long)virt_to_phys(address);
+ void *q = (void *)qe_immr;
+
+ /* Is it a MURAM address? */
+ if ((address >= q) && (address < (q + QE_IMMAP_SIZE)))
+ return get_qe_base() + (address - q);
+
+ /* It's an address returned by kmalloc */
+ return virt_to_phys(address);
}
#endif /* __KERNEL__ */
--
1.7.2.3
^ permalink raw reply related
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-14 18:44 UTC (permalink / raw)
To: Scott Wood; +Cc: tiejun.chen, david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014125010.5cfb4ee5@udp111988uds.am.freescale.net>
> Well, it was a coworker who added the workaround, so I assume we're
> already aware of the issue.
>
> The description of NIRQ is vague enough that it's hard to argue that
> Linux's expectations of what it means are justified.
>
Well, I now can actually interrupt the PPC from my host processor!
(well, it segfaulted, but's my fault for not actually initializing my work
queue structure. But I can get the interrupt into the part!)
So thanks to all.
I hope to get my code working, get past my delivery deadline on it, clean
it up so it matches The One True Way Of Laying Out Kernel Code, and post
it here for everybody to point and laugh at. Maybe around Christmas.
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Timur Tabi @ 2010-10-14 18:21 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala, alsa-devel mailing list, Mark Brown
In-Reply-To: <1286480203-28227-2-git-send-email-timur@freescale.com>
Mark, can you pick up this patch for us? Because it depends on
"powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it
will break the build if we apply to powerpc-next.
You can grab the patch from http://patchwork.ozlabs.org/patch/67095/
On Thu, Oct 7, 2010 at 2:36 PM, Timur Tabi <timur@freescale.com> wrote:
> The Freescale P1022DS has an on-chip video controller called the DIU, and=
a
> driver for this device already exists. =A0Update the platform file for th=
e
> P1022DS reference board to enable the driver, and update the defconfig fo=
r
> Freescale MPC85xx boards to add the driver.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Kumar Gala @ 2010-10-14 17:52 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev, Gala Kumar-B11780
In-Reply-To: <5610599F537DD74A8D1F5CC946A75073034793B7@az33exm25.fsl.freescale.net>
On Oct 13, 2010, at 8:39 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>>>> arch/powerpc/configs/mpc85xx_defconfig | 3 +
>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
>>>> arch/powerpc/platforms/85xx/p1022_ds.c | 213 =
+++++++++++++++++++++++++++-
>>>> 3 files changed, 217 insertions(+), 2 deletions(-)
>> I dropped this because of chicken/egg issue with guts.h
>=20
> If you pull from alsa-next, it should resolve that.
>=20
> Either that, or ask the alsa guys to apply this patch instead.
Can you ask the alsa guys to pick it up. I'm happy to ack.
- k=
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-14 17:50 UTC (permalink / raw)
To: david.hagood; +Cc: tiejun.chen, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fac55e564d1f5b7e5398354939ec3b43.squirrel@localhost>
On Thu, 14 Oct 2010 12:20:55 -0500
<david.hagood@gmail.com> wrote:
> > It comes from FRR[NIRQ]. It seems that this chip takes a
> > less-than-useful interpretation of what that field means -- it gives
> > the actual number of sources, not the size of the sparsely populated
> > array.
> Perhaps you might want to have a talk with your cow-orkers there, Scott,
> since this is a Freescale part.
Well, it was a coworker who added the workaround, so I assume we're
already aware of the issue.
The description of NIRQ is vague enough that it's hard to argue that
Linux's expectations of what it means are justified.
-Scott
^ permalink raw reply
* [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-14 17:48 UTC (permalink / raw)
To: nacc
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig. It's really annoying to only get some of
the debug messages!
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
Because the lpar and pci_dlpar code is pretty low-level & verbose,
perhaps it makes sense to add another Kconfig variable for really
low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
especially in the EEH area when doing PCI stuff.
---
arch/powerpc/platforms/pseries/eeh.c | 2 --
arch/powerpc/platforms/pseries/lpar.c | 3 ---
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 --
3 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 34b7dc1..17a11c8 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -21,8 +21,6 @@
* Please address comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
-#undef DEBUG
-
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/list.h>
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index cf79b46..4b31a66 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -19,9 +19,6 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-/* Enables debugging of low-level hash table routines - careful! */
-#undef DEBUG
-
#include <linux/kernel.h>
#include <linux/dma-mapping.h>
#include <linux/console.h>
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index 4b7a062..5fcc92a 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -25,8 +25,6 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#undef DEBUG
-
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
--
1.7.1
^ 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