* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Paul Mackerras @ 2007-04-24 4:34 UTC (permalink / raw)
To: Eric W. Biederman
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, containers, Oleg Nesterov
In-Reply-To: <m1abwyv4oq.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman writes:
> Well the basic problem is that for any piece of code that can be modular
> we need a way to ensure all threads it has running are shutdown when we
> remove the module.
The EEH code can't be modular, and wouldn't make any sense to be
modular, since it's part of the infrastructure for accessing PCI
devices.
Paul.
^ permalink raw reply
* powerpc: Prepare for splitting up mmu.h by MMU type
From: David Gibson @ 2007-04-24 4:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Currently asm-powerpc/mmu.h has definitions for the 64-bit hash based
MMU. If CONFIG_PPC64 is not set, it instead includes asm-ppc/mmu.h
which contains a particularly horrible mess of #ifdefs giving the
definitions for all the various 32-bit MMUs.
It would be nice to have the low level definitions for each MMU type
neatly in their own separate files. It would also be good to wean
arch/powerpc off dependence on the old asm-ppc/mmu.h.
This patch makes a start on such a cleanup bu moving the definitions
for the 64-bit hash MMU to their own file, asm-powerpc/mmu_hash64.h.
Definitions for the other MMUs still all come from asm-ppc/mmu.h,
however each MMU type can now be one-by-one moved over to their own
file, in the process cleaning them up stripping them of cruft no
longer necessary in arch/powerpc.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/include/asm-powerpc/mmu.h
===================================================================
--- working-2.6.orig/include/asm-powerpc/mmu.h 2007-04-24 13:51:01.000000000 +1000
+++ working-2.6/include/asm-powerpc/mmu.h 2007-04-24 13:59:05.000000000 +1000
@@ -2,407 +2,14 @@
#define _ASM_POWERPC_MMU_H_
#ifdef __KERNEL__
-#ifndef CONFIG_PPC64
-#include <asm-ppc/mmu.h>
+#if defined(CONFIG_PPC64)
+/* 64-bit classic hash table MMU */
+# include <asm/mmu_hash64.h>
#else
-
-/*
- * PowerPC memory management structures
- *
- * Dave Engebretsen & Mike Corrigan <{engebret|mikejc}@us.ibm.com>
- * PPC64 rework.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-#include <asm/asm-compat.h>
-#include <asm/page.h>
-
-/*
- * Segment table
- */
-
-#define STE_ESID_V 0x80
-#define STE_ESID_KS 0x20
-#define STE_ESID_KP 0x10
-#define STE_ESID_N 0x08
-
-#define STE_VSID_SHIFT 12
-
-/* Location of cpu0's segment table */
-#define STAB0_PAGE 0x6
-#define STAB0_OFFSET (STAB0_PAGE << 12)
-#define STAB0_PHYS_ADDR (STAB0_OFFSET + PHYSICAL_START)
-
-#ifndef __ASSEMBLY__
-extern char initial_stab[];
-#endif /* ! __ASSEMBLY */
-
-/*
- * SLB
- */
-
-#define SLB_NUM_BOLTED 3
-#define SLB_CACHE_ENTRIES 8
-
-/* Bits in the SLB ESID word */
-#define SLB_ESID_V ASM_CONST(0x0000000008000000) /* valid */
-
-/* Bits in the SLB VSID word */
-#define SLB_VSID_SHIFT 12
-#define SLB_VSID_B ASM_CONST(0xc000000000000000)
-#define SLB_VSID_B_256M ASM_CONST(0x0000000000000000)
-#define SLB_VSID_B_1T ASM_CONST(0x4000000000000000)
-#define SLB_VSID_KS ASM_CONST(0x0000000000000800)
-#define SLB_VSID_KP ASM_CONST(0x0000000000000400)
-#define SLB_VSID_N ASM_CONST(0x0000000000000200) /* no-execute */
-#define SLB_VSID_L ASM_CONST(0x0000000000000100)
-#define SLB_VSID_C ASM_CONST(0x0000000000000080) /* class */
-#define SLB_VSID_LP ASM_CONST(0x0000000000000030)
-#define SLB_VSID_LP_00 ASM_CONST(0x0000000000000000)
-#define SLB_VSID_LP_01 ASM_CONST(0x0000000000000010)
-#define SLB_VSID_LP_10 ASM_CONST(0x0000000000000020)
-#define SLB_VSID_LP_11 ASM_CONST(0x0000000000000030)
-#define SLB_VSID_LLP (SLB_VSID_L|SLB_VSID_LP)
-
-#define SLB_VSID_KERNEL (SLB_VSID_KP)
-#define SLB_VSID_USER (SLB_VSID_KP|SLB_VSID_KS|SLB_VSID_C)
-
-#define SLBIE_C (0x08000000)
-
-/*
- * Hash table
- */
-
-#define HPTES_PER_GROUP 8
-
-#define HPTE_V_AVPN_SHIFT 7
-#define HPTE_V_AVPN ASM_CONST(0xffffffffffffff80)
-#define HPTE_V_AVPN_VAL(x) (((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT)
-#define HPTE_V_COMPARE(x,y) (!(((x) ^ (y)) & HPTE_V_AVPN))
-#define HPTE_V_BOLTED ASM_CONST(0x0000000000000010)
-#define HPTE_V_LOCK ASM_CONST(0x0000000000000008)
-#define HPTE_V_LARGE ASM_CONST(0x0000000000000004)
-#define HPTE_V_SECONDARY ASM_CONST(0x0000000000000002)
-#define HPTE_V_VALID ASM_CONST(0x0000000000000001)
-
-#define HPTE_R_PP0 ASM_CONST(0x8000000000000000)
-#define HPTE_R_TS ASM_CONST(0x4000000000000000)
-#define HPTE_R_RPN_SHIFT 12
-#define HPTE_R_RPN ASM_CONST(0x3ffffffffffff000)
-#define HPTE_R_FLAGS ASM_CONST(0x00000000000003ff)
-#define HPTE_R_PP ASM_CONST(0x0000000000000003)
-#define HPTE_R_N ASM_CONST(0x0000000000000004)
-#define HPTE_R_C ASM_CONST(0x0000000000000080)
-#define HPTE_R_R ASM_CONST(0x0000000000000100)
-
-/* Values for PP (assumes Ks=0, Kp=1) */
-/* pp0 will always be 0 for linux */
-#define PP_RWXX 0 /* Supervisor read/write, User none */
-#define PP_RWRX 1 /* Supervisor read/write, User read */
-#define PP_RWRW 2 /* Supervisor read/write, User read/write */
-#define PP_RXRX 3 /* Supervisor read, User read */
-
-#ifndef __ASSEMBLY__
-
-typedef struct {
- unsigned long v;
- unsigned long r;
-} hpte_t;
-
-extern hpte_t *htab_address;
-extern unsigned long htab_size_bytes;
-extern unsigned long htab_hash_mask;
-
-/*
- * Page size definition
- *
- * shift : is the "PAGE_SHIFT" value for that page size
- * sllp : is a bit mask with the value of SLB L || LP to be or'ed
- * directly to a slbmte "vsid" value
- * penc : is the HPTE encoding mask for the "LP" field:
- *
- */
-struct mmu_psize_def
-{
- unsigned int shift; /* number of bits */
- unsigned int penc; /* HPTE encoding */
- unsigned int tlbiel; /* tlbiel supported for that page size */
- unsigned long avpnm; /* bits to mask out in AVPN in the HPTE */
- unsigned long sllp; /* SLB L||LP (exact mask to use in slbmte) */
-};
-
-#endif /* __ASSEMBLY__ */
-
-/*
- * The kernel use the constants below to index in the page sizes array.
- * The use of fixed constants for this purpose is better for performances
- * of the low level hash refill handlers.
- *
- * A non supported page size has a "shift" field set to 0
- *
- * Any new page size being implemented can get a new entry in here. Whether
- * the kernel will use it or not is a different matter though. The actual page
- * size used by hugetlbfs is not defined here and may be made variable
- */
-
-#define MMU_PAGE_4K 0 /* 4K */
-#define MMU_PAGE_64K 1 /* 64K */
-#define MMU_PAGE_64K_AP 2 /* 64K Admixed (in a 4K segment) */
-#define MMU_PAGE_1M 3 /* 1M */
-#define MMU_PAGE_16M 4 /* 16M */
-#define MMU_PAGE_16G 5 /* 16G */
-#define MMU_PAGE_COUNT 6
-
-#ifndef __ASSEMBLY__
-
-/*
- * The current system page sizes
- */
-extern struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
-extern int mmu_linear_psize;
-extern int mmu_virtual_psize;
-extern int mmu_vmalloc_psize;
-extern int mmu_io_psize;
-
-/*
- * If the processor supports 64k normal pages but not 64k cache
- * inhibited pages, we have to be prepared to switch processes
- * to use 4k pages when they create cache-inhibited mappings.
- * If this is the case, mmu_ci_restrictions will be set to 1.
- */
-extern int mmu_ci_restrictions;
-
-#ifdef CONFIG_HUGETLB_PAGE
-/*
- * The page size index of the huge pages for use by hugetlbfs
- */
-extern int mmu_huge_psize;
-
-#endif /* CONFIG_HUGETLB_PAGE */
-
-/*
- * This function sets the AVPN and L fields of the HPTE appropriately
- * for the page size
- */
-static inline unsigned long hpte_encode_v(unsigned long va, int psize)
-{
- unsigned long v =
- v = (va >> 23) & ~(mmu_psize_defs[psize].avpnm);
- v <<= HPTE_V_AVPN_SHIFT;
- if (psize != MMU_PAGE_4K)
- v |= HPTE_V_LARGE;
- return v;
-}
-
-/*
- * This function sets the ARPN, and LP fields of the HPTE appropriately
- * for the page size. We assume the pa is already "clean" that is properly
- * aligned for the requested page size
- */
-static inline unsigned long hpte_encode_r(unsigned long pa, int psize)
-{
- unsigned long r;
-
- /* A 4K page needs no special encoding */
- if (psize == MMU_PAGE_4K)
- return pa & HPTE_R_RPN;
- else {
- unsigned int penc = mmu_psize_defs[psize].penc;
- unsigned int shift = mmu_psize_defs[psize].shift;
- return (pa & ~((1ul << shift) - 1)) | (penc << 12);
- }
- return r;
-}
-
-/*
- * This hashes a virtual address for a 256Mb segment only for now
- */
-
-static inline unsigned long hpt_hash(unsigned long va, unsigned int shift)
-{
- return ((va >> 28) & 0x7fffffffffUL) ^ ((va & 0x0fffffffUL) >> shift);
-}
-
-extern int __hash_page_4K(unsigned long ea, unsigned long access,
- unsigned long vsid, pte_t *ptep, unsigned long trap,
- unsigned int local);
-extern int __hash_page_64K(unsigned long ea, unsigned long access,
- unsigned long vsid, pte_t *ptep, unsigned long trap,
- unsigned int local);
-struct mm_struct;
-extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
- unsigned long ea, unsigned long vsid, int local,
- unsigned long trap);
-
-extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
- unsigned long pstart, unsigned long mode,
- int psize);
-
-extern void htab_initialize(void);
-extern void htab_initialize_secondary(void);
-extern void hpte_init_native(void);
-extern void hpte_init_lpar(void);
-extern void hpte_init_iSeries(void);
-extern void hpte_init_beat(void);
-
-extern void stabs_alloc(void);
-extern void slb_initialize(void);
-extern void slb_flush_and_rebolt(void);
-extern void stab_initialize(unsigned long stab);
-
-#endif /* __ASSEMBLY__ */
-
-/*
- * VSID allocation
- *
- * We first generate a 36-bit "proto-VSID". For kernel addresses this
- * is equal to the ESID, for user addresses it is:
- * (context << 15) | (esid & 0x7fff)
- *
- * The two forms are distinguishable because the top bit is 0 for user
- * addresses, whereas the top two bits are 1 for kernel addresses.
- * Proto-VSIDs with the top two bits equal to 0b10 are reserved for
- * now.
- *
- * The proto-VSIDs are then scrambled into real VSIDs with the
- * multiplicative hash:
- *
- * VSID = (proto-VSID * VSID_MULTIPLIER) % VSID_MODULUS
- * where VSID_MULTIPLIER = 268435399 = 0xFFFFFC7
- * VSID_MODULUS = 2^36-1 = 0xFFFFFFFFF
- *
- * This scramble is only well defined for proto-VSIDs below
- * 0xFFFFFFFFF, so both proto-VSID and actual VSID 0xFFFFFFFFF are
- * reserved. VSID_MULTIPLIER is prime, so in particular it is
- * co-prime to VSID_MODULUS, making this a 1:1 scrambling function.
- * Because the modulus is 2^n-1 we can compute it efficiently without
- * a divide or extra multiply (see below).
- *
- * This scheme has several advantages over older methods:
- *
- * - We have VSIDs allocated for every kernel address
- * (i.e. everything above 0xC000000000000000), except the very top
- * segment, which simplifies several things.
- *
- * - We allow for 15 significant bits of ESID and 20 bits of
- * context for user addresses. i.e. 8T (43 bits) of address space for
- * up to 1M contexts (although the page table structure and context
- * allocation will need changes to take advantage of this).
- *
- * - The scramble function gives robust scattering in the hash
- * table (at least based on some initial results). The previous
- * method was more susceptible to pathological cases giving excessive
- * hash collisions.
- */
-/*
- * WARNING - If you change these you must make sure the asm
- * implementations in slb_allocate (slb_low.S), do_stab_bolted
- * (head.S) and ASM_VSID_SCRAMBLE (below) are changed accordingly.
- *
- * You'll also need to change the precomputed VSID values in head.S
- * which are used by the iSeries firmware.
- */
-
-#define VSID_MULTIPLIER ASM_CONST(200730139) /* 28-bit prime */
-#define VSID_BITS 36
-#define VSID_MODULUS ((1UL<<VSID_BITS)-1)
-
-#define CONTEXT_BITS 19
-#define USER_ESID_BITS 16
-
-#define USER_VSID_RANGE (1UL << (USER_ESID_BITS + SID_SHIFT))
-
-/*
- * This macro generates asm code to compute the VSID scramble
- * function. Used in slb_allocate() and do_stab_bolted. The function
- * computed is: (protovsid*VSID_MULTIPLIER) % VSID_MODULUS
- *
- * rt = register continaing the proto-VSID and into which the
- * VSID will be stored
- * rx = scratch register (clobbered)
- *
- * - rt and rx must be different registers
- * - The answer will end up in the low 36 bits of rt. The higher
- * bits may contain other garbage, so you may need to mask the
- * result.
- */
-#define ASM_VSID_SCRAMBLE(rt, rx) \
- lis rx,VSID_MULTIPLIER@h; \
- ori rx,rx,VSID_MULTIPLIER@l; \
- mulld rt,rt,rx; /* rt = rt * MULTIPLIER */ \
- \
- srdi rx,rt,VSID_BITS; \
- clrldi rt,rt,(64-VSID_BITS); \
- add rt,rt,rx; /* add high and low bits */ \
- /* Now, r3 == VSID (mod 2^36-1), and lies between 0 and \
- * 2^36-1+2^28-1. That in particular means that if r3 >= \
- * 2^36-1, then r3+1 has the 2^36 bit set. So, if r3+1 has \
- * the bit clear, r3 already has the answer we want, if it \
- * doesn't, the answer is the low 36 bits of r3+1. So in all \
- * cases the answer is the low 36 bits of (r3 + ((r3+1) >> 36))*/\
- addi rx,rt,1; \
- srdi rx,rx,VSID_BITS; /* extract 2^36 bit */ \
- add rt,rt,rx
-
-
-#ifndef __ASSEMBLY__
-
-typedef unsigned long mm_context_id_t;
-
-typedef struct {
- mm_context_id_t id;
- u16 user_psize; /* page size index */
- u16 sllp; /* SLB entry page size encoding */
-#ifdef CONFIG_HUGETLB_PAGE
- u16 low_htlb_areas, high_htlb_areas;
+/* 32-bit. FIXME: split up the 32-bit MMU types, and revise for
+ * arch/powerpc */
+# include <asm-ppc/mmu.h>
#endif
- unsigned long vdso_base;
-} mm_context_t;
-
-
-static inline unsigned long vsid_scramble(unsigned long protovsid)
-{
-#if 0
- /* The code below is equivalent to this function for arguments
- * < 2^VSID_BITS, which is all this should ever be called
- * with. However gcc is not clever enough to compute the
- * modulus (2^n-1) without a second multiply. */
- return ((protovsid * VSID_MULTIPLIER) % VSID_MODULUS);
-#else /* 1 */
- unsigned long x;
-
- x = protovsid * VSID_MULTIPLIER;
- x = (x >> VSID_BITS) + (x & VSID_MODULUS);
- return (x + ((x+1) >> VSID_BITS)) & VSID_MODULUS;
-#endif /* 1 */
-}
-
-/* This is only valid for addresses >= KERNELBASE */
-static inline unsigned long get_kernel_vsid(unsigned long ea)
-{
- return vsid_scramble(ea >> SID_SHIFT);
-}
-
-/* This is only valid for user addresses (which are below 2^41) */
-static inline unsigned long get_vsid(unsigned long context, unsigned long ea)
-{
- return vsid_scramble((context << USER_ESID_BITS)
- | (ea >> SID_SHIFT));
-}
-
-#define VSID_SCRAMBLE(pvsid) (((pvsid) * VSID_MULTIPLIER) % VSID_MODULUS)
-#define KERNEL_VSID(ea) VSID_SCRAMBLE(GET_ESID(ea))
-
-/* Physical address used by some IO functions */
-typedef unsigned long phys_addr_t;
-
-
-#endif /* __ASSEMBLY */
-#endif /* CONFIG_PPC64 */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MMU_H_ */
Index: working-2.6/include/asm-powerpc/mmu_hash64.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ working-2.6/include/asm-powerpc/mmu_hash64.h 2007-04-24 13:58:35.000000000 +1000
@@ -0,0 +1,399 @@
+#ifndef _ASM_POWERPC_MMU_HASH64_H_
+#define _ASM_POWERPC_MMU_HASH64_H_
+/*
+ * PowerPC64 memory management structures
+ *
+ * Dave Engebretsen & Mike Corrigan <{engebret|mikejc}@us.ibm.com>
+ * PPC64 rework.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <asm/asm-compat.h>
+#include <asm/page.h>
+
+/*
+ * Segment table
+ */
+
+#define STE_ESID_V 0x80
+#define STE_ESID_KS 0x20
+#define STE_ESID_KP 0x10
+#define STE_ESID_N 0x08
+
+#define STE_VSID_SHIFT 12
+
+/* Location of cpu0's segment table */
+#define STAB0_PAGE 0x6
+#define STAB0_OFFSET (STAB0_PAGE << 12)
+#define STAB0_PHYS_ADDR (STAB0_OFFSET + PHYSICAL_START)
+
+#ifndef __ASSEMBLY__
+extern char initial_stab[];
+#endif /* ! __ASSEMBLY */
+
+/*
+ * SLB
+ */
+
+#define SLB_NUM_BOLTED 3
+#define SLB_CACHE_ENTRIES 8
+
+/* Bits in the SLB ESID word */
+#define SLB_ESID_V ASM_CONST(0x0000000008000000) /* valid */
+
+/* Bits in the SLB VSID word */
+#define SLB_VSID_SHIFT 12
+#define SLB_VSID_B ASM_CONST(0xc000000000000000)
+#define SLB_VSID_B_256M ASM_CONST(0x0000000000000000)
+#define SLB_VSID_B_1T ASM_CONST(0x4000000000000000)
+#define SLB_VSID_KS ASM_CONST(0x0000000000000800)
+#define SLB_VSID_KP ASM_CONST(0x0000000000000400)
+#define SLB_VSID_N ASM_CONST(0x0000000000000200) /* no-execute */
+#define SLB_VSID_L ASM_CONST(0x0000000000000100)
+#define SLB_VSID_C ASM_CONST(0x0000000000000080) /* class */
+#define SLB_VSID_LP ASM_CONST(0x0000000000000030)
+#define SLB_VSID_LP_00 ASM_CONST(0x0000000000000000)
+#define SLB_VSID_LP_01 ASM_CONST(0x0000000000000010)
+#define SLB_VSID_LP_10 ASM_CONST(0x0000000000000020)
+#define SLB_VSID_LP_11 ASM_CONST(0x0000000000000030)
+#define SLB_VSID_LLP (SLB_VSID_L|SLB_VSID_LP)
+
+#define SLB_VSID_KERNEL (SLB_VSID_KP)
+#define SLB_VSID_USER (SLB_VSID_KP|SLB_VSID_KS|SLB_VSID_C)
+
+#define SLBIE_C (0x08000000)
+
+/*
+ * Hash table
+ */
+
+#define HPTES_PER_GROUP 8
+
+#define HPTE_V_AVPN_SHIFT 7
+#define HPTE_V_AVPN ASM_CONST(0xffffffffffffff80)
+#define HPTE_V_AVPN_VAL(x) (((x) & HPTE_V_AVPN) >> HPTE_V_AVPN_SHIFT)
+#define HPTE_V_COMPARE(x,y) (!(((x) ^ (y)) & HPTE_V_AVPN))
+#define HPTE_V_BOLTED ASM_CONST(0x0000000000000010)
+#define HPTE_V_LOCK ASM_CONST(0x0000000000000008)
+#define HPTE_V_LARGE ASM_CONST(0x0000000000000004)
+#define HPTE_V_SECONDARY ASM_CONST(0x0000000000000002)
+#define HPTE_V_VALID ASM_CONST(0x0000000000000001)
+
+#define HPTE_R_PP0 ASM_CONST(0x8000000000000000)
+#define HPTE_R_TS ASM_CONST(0x4000000000000000)
+#define HPTE_R_RPN_SHIFT 12
+#define HPTE_R_RPN ASM_CONST(0x3ffffffffffff000)
+#define HPTE_R_FLAGS ASM_CONST(0x00000000000003ff)
+#define HPTE_R_PP ASM_CONST(0x0000000000000003)
+#define HPTE_R_N ASM_CONST(0x0000000000000004)
+#define HPTE_R_C ASM_CONST(0x0000000000000080)
+#define HPTE_R_R ASM_CONST(0x0000000000000100)
+
+/* Values for PP (assumes Ks=0, Kp=1) */
+/* pp0 will always be 0 for linux */
+#define PP_RWXX 0 /* Supervisor read/write, User none */
+#define PP_RWRX 1 /* Supervisor read/write, User read */
+#define PP_RWRW 2 /* Supervisor read/write, User read/write */
+#define PP_RXRX 3 /* Supervisor read, User read */
+
+#ifndef __ASSEMBLY__
+
+typedef struct {
+ unsigned long v;
+ unsigned long r;
+} hpte_t;
+
+extern hpte_t *htab_address;
+extern unsigned long htab_size_bytes;
+extern unsigned long htab_hash_mask;
+
+/*
+ * Page size definition
+ *
+ * shift : is the "PAGE_SHIFT" value for that page size
+ * sllp : is a bit mask with the value of SLB L || LP to be or'ed
+ * directly to a slbmte "vsid" value
+ * penc : is the HPTE encoding mask for the "LP" field:
+ *
+ */
+struct mmu_psize_def
+{
+ unsigned int shift; /* number of bits */
+ unsigned int penc; /* HPTE encoding */
+ unsigned int tlbiel; /* tlbiel supported for that page size */
+ unsigned long avpnm; /* bits to mask out in AVPN in the HPTE */
+ unsigned long sllp; /* SLB L||LP (exact mask to use in slbmte) */
+};
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * The kernel use the constants below to index in the page sizes array.
+ * The use of fixed constants for this purpose is better for performances
+ * of the low level hash refill handlers.
+ *
+ * A non supported page size has a "shift" field set to 0
+ *
+ * Any new page size being implemented can get a new entry in here. Whether
+ * the kernel will use it or not is a different matter though. The actual page
+ * size used by hugetlbfs is not defined here and may be made variable
+ */
+
+#define MMU_PAGE_4K 0 /* 4K */
+#define MMU_PAGE_64K 1 /* 64K */
+#define MMU_PAGE_64K_AP 2 /* 64K Admixed (in a 4K segment) */
+#define MMU_PAGE_1M 3 /* 1M */
+#define MMU_PAGE_16M 4 /* 16M */
+#define MMU_PAGE_16G 5 /* 16G */
+#define MMU_PAGE_COUNT 6
+
+#ifndef __ASSEMBLY__
+
+/*
+ * The current system page sizes
+ */
+extern struct mmu_psize_def mmu_psize_defs[MMU_PAGE_COUNT];
+extern int mmu_linear_psize;
+extern int mmu_virtual_psize;
+extern int mmu_vmalloc_psize;
+extern int mmu_io_psize;
+
+/*
+ * If the processor supports 64k normal pages but not 64k cache
+ * inhibited pages, we have to be prepared to switch processes
+ * to use 4k pages when they create cache-inhibited mappings.
+ * If this is the case, mmu_ci_restrictions will be set to 1.
+ */
+extern int mmu_ci_restrictions;
+
+#ifdef CONFIG_HUGETLB_PAGE
+/*
+ * The page size index of the huge pages for use by hugetlbfs
+ */
+extern int mmu_huge_psize;
+
+#endif /* CONFIG_HUGETLB_PAGE */
+
+/*
+ * This function sets the AVPN and L fields of the HPTE appropriately
+ * for the page size
+ */
+static inline unsigned long hpte_encode_v(unsigned long va, int psize)
+{
+ unsigned long v =
+ v = (va >> 23) & ~(mmu_psize_defs[psize].avpnm);
+ v <<= HPTE_V_AVPN_SHIFT;
+ if (psize != MMU_PAGE_4K)
+ v |= HPTE_V_LARGE;
+ return v;
+}
+
+/*
+ * This function sets the ARPN, and LP fields of the HPTE appropriately
+ * for the page size. We assume the pa is already "clean" that is properly
+ * aligned for the requested page size
+ */
+static inline unsigned long hpte_encode_r(unsigned long pa, int psize)
+{
+ unsigned long r;
+
+ /* A 4K page needs no special encoding */
+ if (psize == MMU_PAGE_4K)
+ return pa & HPTE_R_RPN;
+ else {
+ unsigned int penc = mmu_psize_defs[psize].penc;
+ unsigned int shift = mmu_psize_defs[psize].shift;
+ return (pa & ~((1ul << shift) - 1)) | (penc << 12);
+ }
+ return r;
+}
+
+/*
+ * This hashes a virtual address for a 256Mb segment only for now
+ */
+
+static inline unsigned long hpt_hash(unsigned long va, unsigned int shift)
+{
+ return ((va >> 28) & 0x7fffffffffUL) ^ ((va & 0x0fffffffUL) >> shift);
+}
+
+extern int __hash_page_4K(unsigned long ea, unsigned long access,
+ unsigned long vsid, pte_t *ptep, unsigned long trap,
+ unsigned int local);
+extern int __hash_page_64K(unsigned long ea, unsigned long access,
+ unsigned long vsid, pte_t *ptep, unsigned long trap,
+ unsigned int local);
+struct mm_struct;
+extern int hash_huge_page(struct mm_struct *mm, unsigned long access,
+ unsigned long ea, unsigned long vsid, int local,
+ unsigned long trap);
+
+extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
+ unsigned long pstart, unsigned long mode,
+ int psize);
+
+extern void htab_initialize(void);
+extern void htab_initialize_secondary(void);
+extern void hpte_init_native(void);
+extern void hpte_init_lpar(void);
+extern void hpte_init_iSeries(void);
+extern void hpte_init_beat(void);
+
+extern void stabs_alloc(void);
+extern void slb_initialize(void);
+extern void slb_flush_and_rebolt(void);
+extern void stab_initialize(unsigned long stab);
+
+#endif /* __ASSEMBLY__ */
+
+/*
+ * VSID allocation
+ *
+ * We first generate a 36-bit "proto-VSID". For kernel addresses this
+ * is equal to the ESID, for user addresses it is:
+ * (context << 15) | (esid & 0x7fff)
+ *
+ * The two forms are distinguishable because the top bit is 0 for user
+ * addresses, whereas the top two bits are 1 for kernel addresses.
+ * Proto-VSIDs with the top two bits equal to 0b10 are reserved for
+ * now.
+ *
+ * The proto-VSIDs are then scrambled into real VSIDs with the
+ * multiplicative hash:
+ *
+ * VSID = (proto-VSID * VSID_MULTIPLIER) % VSID_MODULUS
+ * where VSID_MULTIPLIER = 268435399 = 0xFFFFFC7
+ * VSID_MODULUS = 2^36-1 = 0xFFFFFFFFF
+ *
+ * This scramble is only well defined for proto-VSIDs below
+ * 0xFFFFFFFFF, so both proto-VSID and actual VSID 0xFFFFFFFFF are
+ * reserved. VSID_MULTIPLIER is prime, so in particular it is
+ * co-prime to VSID_MODULUS, making this a 1:1 scrambling function.
+ * Because the modulus is 2^n-1 we can compute it efficiently without
+ * a divide or extra multiply (see below).
+ *
+ * This scheme has several advantages over older methods:
+ *
+ * - We have VSIDs allocated for every kernel address
+ * (i.e. everything above 0xC000000000000000), except the very top
+ * segment, which simplifies several things.
+ *
+ * - We allow for 15 significant bits of ESID and 20 bits of
+ * context for user addresses. i.e. 8T (43 bits) of address space for
+ * up to 1M contexts (although the page table structure and context
+ * allocation will need changes to take advantage of this).
+ *
+ * - The scramble function gives robust scattering in the hash
+ * table (at least based on some initial results). The previous
+ * method was more susceptible to pathological cases giving excessive
+ * hash collisions.
+ */
+/*
+ * WARNING - If you change these you must make sure the asm
+ * implementations in slb_allocate (slb_low.S), do_stab_bolted
+ * (head.S) and ASM_VSID_SCRAMBLE (below) are changed accordingly.
+ *
+ * You'll also need to change the precomputed VSID values in head.S
+ * which are used by the iSeries firmware.
+ */
+
+#define VSID_MULTIPLIER ASM_CONST(200730139) /* 28-bit prime */
+#define VSID_BITS 36
+#define VSID_MODULUS ((1UL<<VSID_BITS)-1)
+
+#define CONTEXT_BITS 19
+#define USER_ESID_BITS 16
+
+#define USER_VSID_RANGE (1UL << (USER_ESID_BITS + SID_SHIFT))
+
+/*
+ * This macro generates asm code to compute the VSID scramble
+ * function. Used in slb_allocate() and do_stab_bolted. The function
+ * computed is: (protovsid*VSID_MULTIPLIER) % VSID_MODULUS
+ *
+ * rt = register continaing the proto-VSID and into which the
+ * VSID will be stored
+ * rx = scratch register (clobbered)
+ *
+ * - rt and rx must be different registers
+ * - The answer will end up in the low 36 bits of rt. The higher
+ * bits may contain other garbage, so you may need to mask the
+ * result.
+ */
+#define ASM_VSID_SCRAMBLE(rt, rx) \
+ lis rx,VSID_MULTIPLIER@h; \
+ ori rx,rx,VSID_MULTIPLIER@l; \
+ mulld rt,rt,rx; /* rt = rt * MULTIPLIER */ \
+ \
+ srdi rx,rt,VSID_BITS; \
+ clrldi rt,rt,(64-VSID_BITS); \
+ add rt,rt,rx; /* add high and low bits */ \
+ /* Now, r3 == VSID (mod 2^36-1), and lies between 0 and \
+ * 2^36-1+2^28-1. That in particular means that if r3 >= \
+ * 2^36-1, then r3+1 has the 2^36 bit set. So, if r3+1 has \
+ * the bit clear, r3 already has the answer we want, if it \
+ * doesn't, the answer is the low 36 bits of r3+1. So in all \
+ * cases the answer is the low 36 bits of (r3 + ((r3+1) >> 36))*/\
+ addi rx,rt,1; \
+ srdi rx,rx,VSID_BITS; /* extract 2^36 bit */ \
+ add rt,rt,rx
+
+
+#ifndef __ASSEMBLY__
+
+typedef unsigned long mm_context_id_t;
+
+typedef struct {
+ mm_context_id_t id;
+ u16 user_psize; /* page size index */
+ u16 sllp; /* SLB entry page size encoding */
+#ifdef CONFIG_HUGETLB_PAGE
+ u16 low_htlb_areas, high_htlb_areas;
+#endif
+ unsigned long vdso_base;
+} mm_context_t;
+
+
+static inline unsigned long vsid_scramble(unsigned long protovsid)
+{
+#if 0
+ /* The code below is equivalent to this function for arguments
+ * < 2^VSID_BITS, which is all this should ever be called
+ * with. However gcc is not clever enough to compute the
+ * modulus (2^n-1) without a second multiply. */
+ return ((protovsid * VSID_MULTIPLIER) % VSID_MODULUS);
+#else /* 1 */
+ unsigned long x;
+
+ x = protovsid * VSID_MULTIPLIER;
+ x = (x >> VSID_BITS) + (x & VSID_MODULUS);
+ return (x + ((x+1) >> VSID_BITS)) & VSID_MODULUS;
+#endif /* 1 */
+}
+
+/* This is only valid for addresses >= KERNELBASE */
+static inline unsigned long get_kernel_vsid(unsigned long ea)
+{
+ return vsid_scramble(ea >> SID_SHIFT);
+}
+
+/* This is only valid for user addresses (which are below 2^41) */
+static inline unsigned long get_vsid(unsigned long context, unsigned long ea)
+{
+ return vsid_scramble((context << USER_ESID_BITS)
+ | (ea >> SID_SHIFT));
+}
+
+#define VSID_SCRAMBLE(pvsid) (((pvsid) * VSID_MULTIPLIER) % VSID_MODULUS)
+#define KERNEL_VSID(ea) VSID_SCRAMBLE(GET_ESID(ea))
+
+/* Physical address used by some IO functions */
+typedef unsigned long phys_addr_t;
+
+#endif /* __ASSEMBLY */
+
+#endif /* _ASM_POWERPC_MMU_HASH64_H_ */
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Eric W. Biederman @ 2007-04-24 4:51 UTC (permalink / raw)
To: Paul Mackerras
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, containers, Oleg Nesterov
In-Reply-To: <17965.35054.835790.275270@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Eric W. Biederman writes:
>
>> Well the basic problem is that for any piece of code that can be modular
>> we need a way to ensure all threads it has running are shutdown when we
>> remove the module.
>
> The EEH code can't be modular, and wouldn't make any sense to be
> modular, since it's part of the infrastructure for accessing PCI
> devices.
Agreed. However most kthread users are modular and make sense to
be so we need to design to handle modular users.
I don't think the idiom of go fire off a thread to handle something
is specific to non-modular users.
Eric
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Benjamin Herrenschmidt @ 2007-04-24 5:00 UTC (permalink / raw)
To: Eric W. Biederman
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, containers, Oleg Nesterov
In-Reply-To: <m1abwyv4oq.fsf@ebiederm.dsl.xmission.com>
> Further in general it doesn't make sense to grab a module reference
> and call that sufficient because we would like to request that the
> module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything else, modules should have separated the entrypoints for
- Initiating a removal request
- Releasing the module
The former is use did "rmmod", can unregister things from subsystems,
etc... (and can file if the driver decides to refuse removal requests
when it's busy doing things or whatever policy that module wants to
implement).
The later is called when all references to the modules have been
dropped, it's a bit like the kref "release" (and could be implemented as
one).
If we had done that (simple) thing back then, module refcounting would
have been much less of a problem... I remember some reasons why that was
veto'ed but I didn't and still don't agree.
Ben.
^ permalink raw reply
* powerpc: Abolish PHYS_FMT macro from arch/powerpc
From: David Gibson @ 2007-04-24 5:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
32-bit powerpc systems define a macro, PHYS_FMT, giving a printf
format string fragment for displaying physical addresses, since most
32-bit powerpc platforms use 32-bit physical addresses but a few use
64-bit physical addresses.
This macro is used in exactly one place, a rare error message, where
we can solve the problem more simply by just unconditionally casting
the address up to 64-bit quantity before formatting it.
This patch does so, meaning that as we bring MMU definitions from
asm-ppc over to asm-powerpc, cleaning them up in the process, we don't
need to implement this ugly macro (which additionally has a very bad
name for something global).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: working-2.6/arch/powerpc/mm/pgtable_32.c
===================================================================
--- working-2.6.orig/arch/powerpc/mm/pgtable_32.c 2007-04-24 14:58:10.000000000 +1000
+++ working-2.6/arch/powerpc/mm/pgtable_32.c 2007-04-24 14:58:46.000000000 +1000
@@ -183,8 +183,8 @@ __ioremap(phys_addr_t addr, unsigned lon
* mem_init() sets high_memory so only do the check after that.
*/
if (mem_init_done && (p < virt_to_phys(high_memory))) {
- printk("__ioremap(): phys addr "PHYS_FMT" is RAM lr %p\n", p,
- __builtin_return_address(0));
+ printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
+ (unsigned long long)p, __builtin_return_address(0));
return NULL;
}
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 3/4] bootwrapper: Add ppcboot.h.
From: Paul Mackerras @ 2007-04-24 5:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20070417090342.3E736352658@atlas.denx.de>
Wolfgang Denk writes:
> Shouldn't we finally get this straight and call the file "u-boot.h" as
> it is called in U-Boot?
Is it identical to the one in U-Boot?
Paul.
^ permalink raw reply
* Re: [PATCH 2/2] POWERPC: Remove global CPM mappings
From: Vitaly Bordug @ 2007-04-24 5:18 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <5AC8BD28-125C-4552-97E9-D35E85D0E555@embeddedalley.com>
On Mon, 23 Apr 2007 21:26:59 -0400
Dan Malek wrote:
>
> On Apr 23, 2007, at 6:39 PM, Vitaly Bordug wrote:
>
> >
> > Gets rid or direct IMMR accesses/dereferences for PQ SoC targets and
> > relevant drivers.
>
> Can we find a way to do this without the constant
> ioremapping and unmapping? It's a quick and
> dirty hack, but it would be nice if we could map once
> during an initialization, keep the pointer around
> and at least use it within the file context. I know it
> doesn't cost much, but all of these cycles add up,
> and someday ioremap could grow into something
> more complex. Please?
Well, I know the solution is not ideal, neither it is final,
but it is a step forward in cleaning up CPM-related stuff.
In many drivers it used to be just modifications of immr->foo,
which fills driver with pleasant board-specific ifdefs and gives hard time
to figure out with something's not working as expected.
At first I was thinking of make_everybody_happy solution,
but with the whole kernel moving forward even brilliant ideas tend to
stay at draft stage (well, you know that much better than me:) )
>
> The whole of the CPM supporting functions need this,
> it could be mapped once and shared at least among
> them. Any drivers that use the IMMR should also be
> cleaner about managing this space as they would
> any other mapped resource that is typically done
> only once for the life of the driver.
>
I know it can be more efficient. And I am looking at this way, but it just cannot
be achieved via single step. TODO list includes rehaul of GPIO (with long-time-grown
feature_call + device tree bindings that were implemented for 8360 but looks reasonable), muxing, etc.
Also I had to take care of arch/ppc since most affected cpm-related drivers (as well as targets) exist and
work both at ppc/ and powerpc/.
> There are also many different methods used that
> I don't understand the reason. Sometimes the
> mappings are hidden in macros, sometimes done
> in a function that is called, other times ioremap()
> is called explicitly. It just looks, well.... icky. :-)
>
This patch just fixes what already exist in kernel, removing the global IMMR pointer and bringing all remaining code paths to the same need_stuff->immr_map->use_it->immr_unmap model. IOW , wraps up what has began before. This ppc/powerpc scatter makes it pretty tricky to move drivers forward without ugly code to handle both
or leaving one of the ways aside, and this approach gives sane code that works in both cases. Current code is messy at some parts, and this what I am trying to address (with current patch and upcomings).
Thanks for looking at it!
-Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Eric W. Biederman @ 2007-04-24 5:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, containers, Oleg Nesterov
In-Reply-To: <1177390842.14873.94.camel@localhost.localdomain>
Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:
>> Further in general it doesn't make sense to grab a module reference
>> and call that sufficient because we would like to request that the
>> module exits.
>
> Which is, btw, I think a total misdesign of our module stuff, but heh, I
> remember that lead to some flamewars back then...
>
> Like anything else, modules should have separated the entrypoints for
>
> - Initiating a removal request
> - Releasing the module
>
> The former is use did "rmmod", can unregister things from subsystems,
> etc... (and can file if the driver decides to refuse removal requests
> when it's busy doing things or whatever policy that module wants to
> implement).
>
> The later is called when all references to the modules have been
> dropped, it's a bit like the kref "release" (and could be implemented as
> one).
>
> If we had done that (simple) thing back then, module refcounting would
> have been much less of a problem... I remember some reasons why that was
> veto'ed but I didn't and still don't agree.
The basic point is because a thread can terminate sooner if we have an
explicit request to stop, we need that in the design.
Because we need to find the threads to request that they stop we need to
have some way to track them.
Since we need to have some way to track them having an explicit data
structure that the callers manage seems to make sense.
Eric
^ permalink raw reply
* Re: [RFC/PATCH] Change 440GP platform to ppc440
From: Stefan Roese @ 2007-04-24 5:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Roland Dreier
In-Reply-To: <ada647m635h.fsf@cisco.com>
On Tuesday 24 April 2007 02:12, Roland Dreier wrote:
> > > I recall dimly that there was some user-visible difference between the
> > > 440GP and the other 440 processors, and that's why we made the
> > > platform string different. I don't recall what the difference was.
>
> FWIW, I've run the same userspace (binaries) on 405GPr, 440GP and
> 440SPe without any problems. Not that I'm a 4xx expert by any
> stretch, but I don't know of anything special about the 440GP.
I don't know of any differences either. So I'm voting to change the platform
to ppc440 too.
Best regards,
Stefan
^ permalink raw reply
* Re: [patch 1/2] powerpc: add check for initialized driver data to pmi driver
From: Heiko J Schick @ 2007-04-24 5:53 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070423202223.549bf53a@localhost>
Acked-by: Heiko J Schick <schickhj@de.ibm.com>
On 23.04.2007, at 20:22, Christian Krafft wrote:
> From: Christian Krafft <krafft@de.ibm.com>
> This patch adds a check for the private driver data to be initialized.
> The bug showed up, as the caller found a pmi device by it's type.
> Whereas the pmi driver probes for the type and the name.
> Since the name was not as the driver expected, it did not initialize.
> A more relaxed probing will be supplied with an extra patch, too.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>
> Index: sdk3/arch/powerpc/sysdev/pmi.c
> ===================================================================
> --- sdk3.orig/arch/powerpc/sysdev/pmi.c
> +++ sdk3/arch/powerpc/sysdev/pmi.c
> @@ -264,6 +264,9 @@ void pmi_register_handler(struct of_devi
> struct pmi_data *data;
> data = device->dev.driver_data;
>
> + if (!data)
> + return;
> +
> spin_lock(&data->handler_spinlock);
> list_add_tail(&handler->node, &data->handler);
> spin_unlock(&data->handler_spinlock);
> @@ -274,10 +277,12 @@ void pmi_unregister_handler(struct of_de
> struct pmi_handler *handler)
> {
> struct pmi_data *data;
> + data = device->dev.driver_data;
>
> - pr_debug("pmi: unregistering handler %p\n", handler);
> + if (!data)
> + return;
>
> - data = device->dev.driver_data;
> + pr_debug("pmi: unregistering handler %p\n", handler);
>
> spin_lock(&data->handler_spinlock);
> list_del(&handler->node);
>
>
> --
> Mit freundlichen Gruessen,
> kind regards,
>
> Christian Krafft
> IBM Systems & Technology Group,
> Linux Kernel Development
> IT Specialist
>
>
> Vorsitzender des Aufsichtsrats: Johann Weihen
> Geschaeftsfuehrung: Herbert Kircher
> Sitz der Gesellschaft: Boeblingen
> Registriergericht: Amtsgericht Stuttgart, HRB 243294
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 2/2] powerpc: pmi probe device by device-type
From: Heiko J Schick @ 2007-04-24 5:53 UTC (permalink / raw)
To: Christian Krafft; +Cc: linuxppc-dev, cbe-oss-dev
In-Reply-To: <20070423202237.0725075a@localhost>
Acked-by: Heiko J Schick <schickhj@de.ibm.com>
On 23.04.2007, at 20:22, Christian Krafft wrote:
> From: Christian Krafft <krafft@de.ibm.com>
> At the moment the pmi device driver is probing for devices with
> a given type and a given name. As there may be devices of
> the same type but with a different name, probing should be
> done also for device type only.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
>
> Index: sdk3/arch/powerpc/sysdev/pmi.c
> ===================================================================
> --- sdk3.orig/arch/powerpc/sysdev/pmi.c
> +++ sdk3/arch/powerpc/sysdev/pmi.c
> @@ -103,6 +103,7 @@ out:
>
> static struct of_device_id pmi_match[] = {
> { .type = "ibm,pmi", .name = "ibm,pmi" },
> + { .type = "ibm,pmi" },
> {},
> };
>
>
>
> --
> Mit freundlichen Gruessen,
> kind regards,
>
> Christian Krafft
> IBM Systems & Technology Group,
> Linux Kernel Development
> IT Specialist
>
>
> Vorsitzender des Aufsichtsrats: Johann Weihen
> Geschaeftsfuehrung: Herbert Kircher
> Sitz der Gesellschaft: Boeblingen
> Registriergericht: Amtsgericht Stuttgart, HRB 243294
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* MPC885 hang in a lwarx/stwcx insn crossing a page boundary
From: Heiko Schocher @ 2007-04-24 5:55 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a MPC885 and a running 2.6.16 kernel on it. I use the CPU15
Errata Patch from
(http://ozlabs.org/pipermail/linuxppc-dev/2007-April/033789.html)
Now if a lwarx/stwcx insn crossing a page boundary, the CPU hangs in
an endless loop, because the reservation allocated from the lwarx gets
cleared in the case of a tlb miss. And the CPU15 workaround invalidates
the tlbs around the page we're faulting in, so we cause a nasty infinite
loop. I started a service request at Freescale, and they are searching
why a tlbie clears the reservation or under which circumstances this
appears.
Without the CPU15 Errata patch it runs fine, but i can reproduce the
CPU15 Bug, so I need the or some CPU15 Errata patch ...
I also have a running 2.4.24-pre2 Kernel on this board, with the same
CPU15 Errata patch, and there the hang doesnt occur!! Some ideas where
the differences between 2.4.24-pre2 and 2.6.16 are?
I also didnt get this hang in userspace with the 2.6.16er Kernel.
So I see at the moment the following possibilities:
a) patching the gcc, so that the CPU15 Errata is no more necessary
My favorit.
b) upgrade the CPU15 Bug like in the MPC885 Errata Sheet from Freescale
(I think this is to much code for in an Exceptionhandler ...)
c) I made before every lwarcx a ".align" so that the insn is on one
page. This is actually running without seeing problems on the board.
But it is a "errata" for the "errata" ...
d) ...
Some suggestions, ideas? Especially, why the hang doesnt occur with a
2.4.24-pre2 kernel?
thanks
Heiko
--
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Paul Mackerras @ 2007-04-24 5:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: <Andrew Morton, linux-s390, linux-kernel, linuxppc-dev,
Eric W. Biederman, containers, Oleg Nesterov
In-Reply-To: <20070422123155.GF20763@infradead.org>
Christoph Hellwig writes:
> The first question is obviously, is this really something we want?
> spawning kernel thread on demand without reaping them properly seems
> quite dangerous.
What specifically has to be done to reap a kernel thread? Are you
concerned about the number of threads, or about having zombies hanging
around?
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Benjamin Herrenschmidt @ 2007-04-24 5:58 UTC (permalink / raw)
To: Eric W. Biederman
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, containers, Oleg Nesterov
In-Reply-To: <m1zm4ytjhg.fsf@ebiederm.dsl.xmission.com>
> Since we need to have some way to track them having an explicit data
> structure that the callers manage seems to make sense.
Oh sure, I wasn't arguing against that at all...
It might be handy to have a release() callback (optional) that gets
called after the kthread stops/exits, once we know the data structure
isn't going to be used anymore (if practical to implement, depends on
your approach).
Ben.
^ permalink raw reply
* prob on 2 ethrnet working
From: Nethra @ 2007-04-24 6:16 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
In my board(MPC8248) i have u-boot-1.1.2 configured with FCC1 as configured
ethernet port.
i m able to download the kernel and ramdisk image from tftpboot.
and after that i usually configure the ethernet port by assiging ips
eth0:192.168.33.64 and
eth1:192.168.174.231 ,subnet mask:255.255.255.0 and default gateway
:192.168.32.47 eth0 and 192.168.174.47 eth1.
an after that i enable lo (ifconfig lo 127.0.0.1) option in kernel.
Now My requiremnt is to have both the ethernet port to be working
physically.
so i ping to both board ips(192.168.33.64 & 192.168.33.66).
But what i found out is if FCC1 is configured as eth port at u-boot time
then pinging will work untill FCC1 eth cabel
is connected to RJ45 port.ie. cable connected at FCC2 port doesnot have any
effect.
and it seems to be both the port is dependent on the FCC1 port only.
Can anybody suggest what might be the issue?
--
View this message in context: http://www.nabble.com/prob-on-2-ethrnet-working-tf3636663.html#a10155023
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* SOME STUFF ABOUT REISER4
From: lkml777 @ 2007-04-24 6:17 UTC (permalink / raw)
To: Eric Hopper
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, containers, Oleg Nesterov
In-Reply-To: <m1zm4ytjhg.fsf@ebiederm.dsl.xmission.com>
On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
<hopper@omnifarious.org> said:
> I know that this whole effort has been put in disarray by the
> prosecution of Hans Reiser, but I'm curious as to its status. Is
> Reiser4 going to be going into the Linus kernel anytime soon? Is there
> somewhere I should be looking to find this out without wasting bandwidth
> here?
There was a thread the other day, that talked about Reiser4.
It took a while but I have found it (actually two)
http://lkml.org/lkml/2007/4/5/360
http://lkml.org/lkml/2007/4/9/4
You may want to check them out.
--
lkml777@123mail.org
--
http://www.fastmail.fm - Access your email from home and the web
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Cornelia Huck @ 2007-04-24 7:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Paul Mackerras, Eric W. Biederman, containers,
Oleg Nesterov
In-Reply-To: <1177390842.14873.94.camel@localhost.localdomain>
On Tue, 24 Apr 2007 15:00:42 +1000,
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Like anything else, modules should have separated the entrypoints for
>
> - Initiating a removal request
> - Releasing the module
>
> The former is use did "rmmod", can unregister things from subsystems,
> etc... (and can file if the driver decides to refuse removal requests
> when it's busy doing things or whatever policy that module wants to
> implement).
>
> The later is called when all references to the modules have been
> dropped, it's a bit like the kref "release" (and could be implemented as
> one).
That sounds quite similar to the problems we have with kobject
refcounting vs. module unloading. The patchset I posted at
http://marc.info/?l=linux-kernel&m=117679014404994&w=2 exposes the
refcount of the kobject embedded in the module. Maybe the kthread code
could use that reference as well?
^ permalink raw reply
* Re: [ofa-general] [PATCH] eHCA: Add "Modify Port" verb
From: Christoph Raisch @ 2007-04-24 21:48 UTC (permalink / raw)
To: Hal Rosenstock
Cc: LinuxPPC-Dev, general-bounces, Joachim Fenkes, LKML, OF-General
In-Reply-To: <1177347358.28021.24294.camel@hal.voltaire.com>
Hi Hal,
you are correct,
with the current firmware version it will fail later.
Christoph R.
general-bounces@lists.openfabrics.org wrote on 23.04.2007 18:55:59:
> Hi Joachim,
>
> On Mon, 2007-04-23 at 12:23, Joachim Fenkes wrote:
> > Add "Modify Port" verb support to eHCA driver.
> > ib_cm needs this to initialize properly.
>
> I didn't think IB_PORT_SM was allowed (as QP0 is not exposed) or does
> this just fail later when it is attempted to be actually set ?
>
> -- Hal
^ permalink raw reply
* Re: [RFC 2/3] PowerPC: lazy altivec enabling in kernel
From: Arnd Bergmann @ 2007-04-24 8:32 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <17965.21687.567012.175024@cargo.ozlabs.ibm.com>
On Tuesday 24 April 2007, Paul Mackerras wrote:
> It would be better to put a test and conditional branch in
> giveup_altivec to skip the mtmsrd if MSR_VEC is already set. =A0That
> would avoid adding the overhead of the trap in the case when MSR_VEC
> isn't already set, besides being much less code.
When I discussed this with Sebastian, my assumption was that even
the mfmsr is rather expensive by itself, but I may have interpreted
the profile data incorrectly.
Do you think it's safe to assume that by skipping mtmsr we can avoid
the bulk of the overhead on most CPUs?
Arnd <><
^ permalink raw reply
* Re: [PATCH] powerpc pseries eeh: Convert to kthread API
From: Christoph Hellwig @ 2007-04-24 8:37 UTC (permalink / raw)
To: Paul Mackerras
Cc: <Andrew Morton, linux-s390, linux-kernel, Christoph Hellwig,
linuxppc-dev, Eric W. Biederman, containers, Oleg Nesterov
In-Reply-To: <17965.39866.351929.349735@cargo.ozlabs.ibm.com>
On Tue, Apr 24, 2007 at 03:55:06PM +1000, Paul Mackerras wrote:
> Christoph Hellwig writes:
>
> > The first question is obviously, is this really something we want?
> > spawning kernel thread on demand without reaping them properly seems
> > quite dangerous.
>
> What specifically has to be done to reap a kernel thread? Are you
> concerned about the number of threads, or about having zombies hanging
> around?
I'm mostly concerned about number of threads and possible leakage of
threads. Linas already explained it's not a problem in this case,
so it's covered.
^ permalink raw reply
* Using Xilinx Framebuffer on ML405 and 2.6.20.4
From: Peter Mendham @ 2007-04-24 9:13 UTC (permalink / raw)
To: linuxppc-embedded
Dear all,
I am wanting to use the Xilinx TFT controller from the ML403/5 reference
project (probably from ML300 as well) under a 2.6.20.4 kernel. I have
Grant Likely's patchset applied in which there is a platform device
entry for the framebuffer. Does anyone know if there is mainline
support for the Xilinx-style framebuffer? If so, how do I enable it? I
have included framebuffer support in my kernel build, but I assume I
need a driver also? Any tips greatly appreciated.
Thanks in advance,
-- Peter
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.
^ permalink raw reply
* Re: [PATCH 6/7] MPIC MSI allocator
From: Segher Boessenkool @ 2007-04-24 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, linux-pci
In-Reply-To: <1177378169.14873.46.camel@localhost.localdomain>
>> It's time to rename BROKEN_U3. It used to be the config option to
>> enable
>> a few workarounds, but now it's used to select whenever there's a U3
>> in
>> the system. Care to do it in the scope of this patch set?
>
> Not really.... first gen G5s don't use that :-) It's wether the MPIC is
> part of U3/U4 -and- is used as a primary HT PIC.
Not really... It is whether the HT-to-MPIC interface
on the U3/U4 has the "feature" that ack-required
interrupts coming in over HT need to be acked by hand.
First-gen G5's need that just as well, they just don't
have such interrupts on the default system configuration,
as far as I remember.
Segher
^ permalink raw reply
* Re: [PATCH 6/7] MPIC MSI allocator
From: Benjamin Herrenschmidt @ 2007-04-24 9:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, linuxppc-dev, linux-pci
In-Reply-To: <f5dd623fbb338d38bc05567ee178b886@kernel.crashing.org>
On Tue, 2007-04-24 at 11:26 +0200, Segher Boessenkool wrote:
> >> It's time to rename BROKEN_U3. It used to be the config option to
> >> enable
> >> a few workarounds, but now it's used to select whenever there's a U3
> >> in
> >> the system. Care to do it in the scope of this patch set?
> >
> > Not really.... first gen G5s don't use that :-) It's wether the MPIC is
> > part of U3/U4 -and- is used as a primary HT PIC.
>
> Not really... It is whether the HT-to-MPIC interface
> on the U3/U4 has the "feature" that ack-required
> interrupts coming in over HT need to be acked by hand.
>
> First-gen G5's need that just as well, they just don't
> have such interrupts on the default system configuration,
> as far as I remember.
They didn't have an HT APIC or if they had one, they didn't enable it
(they probably did in the tunnel). They didn't use the U3 MPIC as an HT
IRQ master, thus it's irrelevant. Anyway, there is no point in this
discussion :-)
Ben.
^ permalink raw reply
* Re: [PATCH 6/7] MPIC MSI allocator
From: Segher Boessenkool @ 2007-04-24 9:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, linux-pci
In-Reply-To: <1177407551.14873.105.camel@localhost.localdomain>
>> First-gen G5's need that just as well, they just don't
>> have such interrupts on the default system configuration,
>> as far as I remember.
>
> They didn't have an HT APIC or if they had one, they didn't enable it
> (they probably did in the tunnel).
Yes, the two HT APICs on the tunnel were enabled.
> They didn't use the U3 MPIC as an HT
> IRQ master, thus it's irrelevant.
They did for the plugin PCI-X slots (well, it's chained
to another MPIC, but you still need the workaround).
> Anyway, there is no point in this
> discussion :-)
Yeah, the new name for CONFIG_BROKEN_U3 is fine
no matter what :-)
Segher
^ permalink raw reply
* Re: [PATCH 6/7] MPIC MSI allocator
From: Benjamin Herrenschmidt @ 2007-04-24 9:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Olof Johansson, linuxppc-dev, linux-pci
In-Reply-To: <dbba27bc913250681a57be91605e25f2@kernel.crashing.org>
On Tue, 2007-04-24 at 11:44 +0200, Segher Boessenkool wrote:
> >> First-gen G5's need that just as well, they just don't
> >> have such interrupts on the default system configuration,
> >> as far as I remember.
> >
> > They didn't have an HT APIC or if they had one, they didn't enable it
> > (they probably did in the tunnel).
>
> Yes, the two HT APICs on the tunnel were enabled.
>
> > They didn't use the U3 MPIC as an HT
> > IRQ master, thus it's irrelevant.
>
> They did for the plugin PCI-X slots (well, it's chained
> to another MPIC, but you still need the workaround).
No you didn't. The slots IRQ lines were physically routed to GPIOs on
the southbridge MPIC. The -only- thing the northbridge MPIC was useful
for was the NB internal interrupts (like the i2c one).
> > Anyway, there is no point in this
> > discussion :-)
>
> Yeah, the new name for CONFIG_BROKEN_U3 is fine
> no matter what :-)
>
>
> Segher
^ 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