Re: next/mmotm unbootable on G5: irqdomain
On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
I have to revert the patch below from mmotm 2012-07-20-16-30 or
next-20120720 in order to boot on the PowerPC G5: otherwise it
freezes before switching to the framebuffer console - but I'm
not certain where because that initial console doesn't scroll
(there are mpic messages at bottom and at top of screen, probably
later messages at the top but I don't know the sequence).
Remind me your G5 variant ? (/proc/cpuinfo will do). I'll have a look
tomorrow (and thanks for testing !).
Cheers,
Ben.
Hugh
commit 94f036a1f242f98cc30700b7676c07270a9c5c27
Author: Grant Likely grant.lik...@secretlab.ca
Date: Sun Jun 3 22:04:39 2012 -0700
irqdomain: eliminate slow-path revmap lookups
With the current state of irq_domain, the reverse map is always updated
when new IRQs get mapped. This means that the irq_find_mapping() function
can be simplified to execute the revmap lookup functions unconditionally
This patch adds lookup functions for the revmaps that don't yet have one
and removes the slow path lookup code path.
v8: Broke out unrelated changes into separate patches. Rebased on Paul's irq
association patches.
v7: Rebased to irqdomain/next for v3.4 and applied before the removal of
'hint'
v6: Remove the slow path entirely. The only place where the slow path
could get called is for a linear mapping if the hwirq number is larger
than the linear revmap size. There shouldn't be any interrupt
controllers that do that.
v5: rewrite to not use a -revmap() callback. It is simpler, smaller,
safer and faster to open code each of the revmap lookups directly into
irq_find_mapping() via a switch statement.
v4: Fix build failure on incorrect variable reference.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Milton Miller milt...@bga.com
Cc: Paul Mundt let...@linux-sh.org
Cc: Rob Herring rob.herr...@calxeda.com
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index c0e638b..a9b810e 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -686,16 +686,11 @@ EXPORT_SYMBOL_GPL(irq_dispose_mapping);
* irq_find_mapping() - Find a linux irq from an hw irq number.
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
- *
- * This is a slow path, for use by generic code. It's expected that an
- * irq controller implementation directly calls the appropriate low level
- * mapping function.
*/
unsigned int irq_find_mapping(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int i;
- unsigned int hint = hwirq % nr_irqs;
+ struct irq_data *data;
/* Look for default domain if nececssary */
if (domain == NULL)
@@ -703,22 +698,27 @@ unsigned int irq_find_mapping(struct irq_domain *domain,
if (domain == NULL)
return 0;
- /* legacy - bail early */
- if (domain-revmap_type == IRQ_DOMAIN_MAP_LEGACY)
+ switch (domain-revmap_type) {
+ case IRQ_DOMAIN_MAP_LEGACY:
return irq_domain_legacy_revmap(domain, hwirq);
-
- /* Slow path does a linear search of the map */
- if (hint == 0)
- hint = 1;
- i = hint;
- do {
- struct irq_data *data = irq_get_irq_data(i);
+ case IRQ_DOMAIN_MAP_LINEAR:
+ return irq_linear_revmap(domain, hwirq);
+ case IRQ_DOMAIN_MAP_TREE:
+ rcu_read_lock();
+ data = radix_tree_lookup(domain-revmap_data.tree, hwirq);
+ rcu_read_unlock();
+ if (data)
+ return data-irq;
+ break;
+ case IRQ_DOMAIN_MAP_NOMAP:
+ data = irq_get_irq_data(hwirq);
if (data (data-domain == domain) (data-hwirq == hwirq))
- return i;
- i++;
- if (i = nr_irqs)
- i = 1;
- } while(i != hint);
+ return hwirq;
+ break;
+ }
+
+ WARN(1, ERROR: irq revmap went horribly wrong. revmap_type=%i\n,
+ domain-revmap_type);
return 0;
}
EXPORT_SYMBOL_GPL(irq_find_mapping);
@@ -728,32 +728,19 @@ EXPORT_SYMBOL_GPL(irq_find_mapping);
* @domain: domain owning this hardware interrupt
* @hwirq: hardware irq number in that domain space
*
- * This is a fast path, for use by irq controller code that uses linear
- * revmaps. It does fallback to the slow path if the revmap doesn't exist
- * yet and will create the revmap entry with appropriate locking
+ * This is a fast path that can be called directly by irq controller code to
+ * save a handful of instructions.
*/
unsigned int irq_linear_revmap(struct irq_domain *domain,
irq_hw_number_t hwirq)
{
- unsigned int
Re: next/mmotm unbootable on G5: irqdomain
On Sun, 22 Jul 2012, Benjamin Herrenschmidt wrote: On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote: I have to revert the patch below from mmotm 2012-07-20-16-30 or next-20120720 in order to boot on the PowerPC G5: otherwise it freezes before switching to the framebuffer console - but I'm not certain where because that initial console doesn't scroll (there are mpic messages at bottom and at top of screen, probably later messages at the top but I don't know the sequence). Remind me your G5 variant ? (/proc/cpuinfo will do). I'll have a look tomorrow (and thanks for testing !). commit 94f036a1f242f98cc30700b7676c07270a9c5c27 Author: Grant Likely grant.lik...@secretlab.ca Date: Sun Jun 3 22:04:39 2012 -0700 irqdomain: eliminate slow-path revmap lookups Thanks, Ben - here's my /proc/cpuinfo: processor : 0 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 2 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) processor : 3 cpu : PPC970MP, altivec supported clock : 2500.00MHz revision: 1.1 (pvr 0044 0101) timebase: platform: PowerMac model : PowerMac11,2 machine : PowerMac11,2 motherboard : PowerMac11,2 MacRISC4 Power Macintosh detected as : 337 (PowerMac G5 Dual Core) pmac flags : L2 cache: 1024K unified pmac-generation : NewWorld Hugh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: SMT priority (PPR) save and restore
Haren Myneni ha...@linux.vnet.ibm.com wrote: On Mon, 2012-07-16 at 13:41 +1000, Michael Neuling wrote: Heaven Myneni ha...@linux.vnet.ibm.com wrote: powerpc: SMT priority (PPR) save and restore snip Can you break this patch into a few parts that are easier to review than one giant patch. Start by adding the PPR ftr bits, then the extra space in the paca, then the new macros, then use the new infrastructure. I'm sure you can get 5 or so patches which will be much easier to review. Also this has been white space munged. See here: http://patchwork.ozlabs.org/patch/170993/ All the #defines are broken. Also, do you know what the impacts of this are on null syscall/page faults etc on machines which need the PPR switched? If it's big, we might want to have this as a CONFIG option for those who don't care and want the speed bump. Thanks for your comments. Sure will split this patch in to 5/6 patches. With Anton's num_syscall test - http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead. As you suggested, will add CONFIG option for this feature. Eek.. 6%.. yes, definitely a CONFIG option then. Sorry, my e-mail client messed-up some tabs. will post next time properly. Please see my responses below. ok + #define __EXCEPTION_PROLOG_1(area, extra, vec) \ GET_PACA(r13); \ - std r9,area+EX_R9(r13); /* save r9 - r12 */ \ - std r10,area+EX_R10(r13); \ + std r9,area+EX_R9(r13); /* save r9 */ \ + HMT_FTR_HAS_PPR(area,r9); \ + std r10,area+EX_R10(r13); /* save r10 - r12 */\ BEGIN_FTR_SECTION_NESTED(66); \ mfspr r10,SPRN_CFAR; \ std r10,area+EX_CFAR(r13); \ @@ -176,8 +213,10 @@ do_kvm_##n: \ std r10,0(r1); /* make stack chain pointer */ \ std r0,GPR0(r1);/* save r0 in stackframe*/ \ std r10,GPR1(r1); /* save r1 in stackframe*/ \ + beq 4f;\ ACCOUNT_CPU_USER_ENTRY(r9, r10); \ - std r2,GPR2(r1);/* save r2 in stackframe*/ \ + SAVE_PPR(area, r9, r10); \ +4: std r2,GPR2(r1);/* save r2 in stackframe */ \ why are we no longer doing ACCOUNT_CPU_USER_ENTRY here? No, we still doing ACCOUNT_CPU_USER_ENTRY for the user level exceptions. The existing code (ACCOUNT_CPU_USER_ENTRY macro) has the same branch instruction and skipping for exceptions coming from kernel. I just removed 'beq' in ACCOUNT_CPU_USER_ENTRY macro and added here since PPR saving will be done only for user level exceptions. Adding comment for this branch instruction and create a separate patch just for the related changes should make it more clear. OK. This is why it's good to split the patch into multiple parts so that you can explain these in the associated checking comments. - HMT_MEDIUM; + HMT_FTR_NO_PPR Can we call this something else like HMT_MEDIUM_NO_PPR? I will make the change. Similarly HMT_FTR_HAS_PPR should be changed to HMT_MEDIUM_HAS_PPR. Cool, bike shedding complete :-) Mikey SET_SCRATCH0(r13) #ifdef CONFIG_PPC_P7_NAP BEGIN_FTR_SECTION @@ -94,7 +94,7 @@ machine_check_pSeries_1: . = 0x300 .globl data_access_pSeries data_access_pSeries: - HMT_MEDIUM + HMT_FTR_NO_PPR SET_SCRATCH0(r13) BEGIN_FTR_SECTION b data_access_check_stab @@ -106,7 +106,7 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB) . = 0x380 .globl data_access_slb_pSeries data_access_slb_pSeries: - HMT_MEDIUM + HMT_FTR_NO_PPR SET_SCRATCH0(r13) EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST, 0x380) std r3,PACA_EXSLB+EX_R3(r13) @@ -137,7 +137,7 @@ data_access_slb_pSeries: . = 0x480 .globl instruction_access_slb_pSeries instruction_access_slb_pSeries: - HMT_MEDIUM + HMT_FTR_NO_PPR SET_SCRATCH0(r13) EXCEPTION_PROLOG_1(PACA_EXSLB, KVMTEST_PR, 0x480) std r3,PACA_EXSLB+EX_R3(r13) @@ -197,7 +197,7 @@ hardware_interrupt_hv: . = 0xc00 .globl system_call_pSeries system_call_pSeries: - HMT_MEDIUM + HMT_FTR_NO_PPR #ifdef CONFIG_KVM_BOOK3S_64_HANDLER SET_SCRATCH0(r13) GET_PACA(r13) @@ -213,6 +213,7 @@ BEGIN_FTR_SECTION END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE) mr r9,r13 GET_PACA(r13) + HMT_FTR_HAS_PPR(PACA_EXGEN,r10) mfspr r11,SPRN_SRR0 mfspr r12,SPRN_SRR1 ld
Re: [PATCH] powerpc: SMT priority (PPR) save and restore
Can you break this patch into a few parts that are easier to review than one giant patch. Start by adding the PPR ftr bits, then the extra space in the paca, then the new macros, then use the new infrastructure. I'm sure you can get 5 or so patches which will be much easier to review. Also this has been white space munged. See here: http://patchwork.ozlabs.org/patch/170993/ All the #defines are broken. Also, do you know what the impacts of this are on null syscall/page faults etc on machines which need the PPR switched? If it's big, we might want to have this as a CONFIG option for those who don't care and want the speed bump. Thanks for your comments. Sure will split this patch in to 5/6 patches. With Anton's num_syscall test - http://ozlabs.org/~anton/junkcode/null_syscall.c, noticed 6% overhead. As you suggested, will add CONFIG option for this feature. Eek.. 6%.. yes, definitely a CONFIG option then. ... maybe even a boot time option so we can turn it on and off easily for distros. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 06/11] arch/powerpc: Make KERN_VIRT_SIZE not dependend on PGTABLE_RANGE
On Mon, Jul 09, 2012 at 06:43:36PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com As we keep increasing PGTABLE_RANGE we need not increase the virual map area for kernel. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Reviewed-by: Paul Mackerras pau...@samba.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 10/11] arch/powerpc: Use 32bit array for slb cache
On Mon, Jul 09, 2012 at 06:43:40PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com With larger vsid we need to track more bits of ESID in slb cache for slb invalidate. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Minor comment below, but apart from that... Reviewed-by: Paul Mackerras pau...@samba.org - sldir11,r3,1/* r11 = offset * sizeof(u16) */ - rldicl r10,r10,36,28 /* get low 16 bits of the ESID */ - add r11,r11,r13 /* r11 = (u16 *)paca + offset */ - sth r10,PACASLBCACHE(r11) /* paca-slb_cache[offset] = esid */ + sldir11,r3,2/* r11 = offset * sizeof(u32) */ + rldicl r10,r10,36,28 /* get the 36 bits of the ESID */ You're correct that the rldicl instruction produces 36 bits of result, and in fact it is equivalent to srdi r10,r10,28. If you're changing the line you might as well change the instruction to the simpler form too. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 04/11] arch/powerpc: Rename va to vpn
On Mon, Jul 09, 2012 at 06:43:34PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Rename the variable to better reflect the values. No functional change in this patch. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com I think you missed a couple: kernel_map_linear_page and kernel_unmap_linear_page are now broken since you change va to vpn in the declaration but not in the uses, and you change host_va to host_vpn in struct hpte_cache but don't fix up the use in kvmppc_mmu_invalidate_pte. How many configs did you compile-test this with? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 02/11] arch/powerpc: Simplify hpte_decode
On Mon, Jul 09, 2012 at 06:43:32PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This patch simplify hpte_decode for easy switching of virtual address to virtual page number in the later patch Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com I'm not convinced your version is simpler than what was there before. It's certainly longer now. But it does seem to do the same calculation as before, so: Reviewed-by: Paul Mackerras pau...@samba.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 01/11] arch/powerpc: Use hpt_va to compute virtual address
On Mon, Jul 09, 2012 at 06:43:31PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Don't open code the same Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Reviewed-by: Paul Mackerras pau...@samba.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 09/11] arch/powerpc: Use 50 bits of VSID in slbmte
On Mon, Jul 09, 2012 at 06:43:39PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Increase the number of valid VSID bits in slbmte instruction. We will use the new bits when we increase valid VSID bits. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/mm/slb_low.S |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S index c355af6..c1fc81c 100644 --- a/arch/powerpc/mm/slb_low.S +++ b/arch/powerpc/mm/slb_low.S @@ -226,7 +226,7 @@ _GLOBAL(slb_allocate_user) */ slb_finish_load: ASM_VSID_SCRAMBLE(r10,r9,256M) - rldimi r11,r10,SLB_VSID_SHIFT,16 /* combine VSID and flags */ + rldimi r11,r10,SLB_VSID_SHIFT,2/* combine VSID and flags */ You can't do that without either changing ASM_VSID_SCRAMBLE or masking the VSID it generates to 36 bits, since the logic in ASM_VSID_SCRAMBLE can leave non-zero bits in the high 28 bits of the result. Similarly for the 1T case. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 07/11] arch/powerpc: Increase the slice range to 64TB
On Mon, Jul 09, 2012 at 06:43:37PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch makes the high psizes mask as an unsigned char array
so that we can have more than 16TB. Currently we support upto
64TB
Some comments inline...
@@ -804,16 +804,19 @@ unsigned int hash_page_do_lazy_icache(unsigned int pp,
pte_t pte, int trap)
#ifdef CONFIG_PPC_MM_SLICES
unsigned int get_paca_psize(unsigned long addr)
{
- unsigned long index, slices;
+ u64 lpsizes;
+ unsigned char *hpsizes;
+ unsigned long index, mask_index;
if (addr SLICE_LOW_TOP) {
- slices = get_paca()-context.low_slices_psize;
+ lpsizes = get_paca()-context.low_slices_psize;
index = GET_LOW_SLICE_INDEX(addr);
- } else {
- slices = get_paca()-context.high_slices_psize;
- index = GET_HIGH_SLICE_INDEX(addr);
+ return (lpsizes (index * 4)) 0xF;
}
- return (slices (index * 4)) 0xF;
+ hpsizes = get_paca()-context.high_slices_psize;
+ index = GET_HIGH_SLICE_INDEX(addr) 1;
+ mask_index = GET_HIGH_SLICE_INDEX(addr) - (index 1);
+ return (hpsizes[index] (mask_index * 4)) 0xF;
The last 3 lines here feel awkward. How about:
+ index = GET_HIGH_SLICE_INDEX(addr);
+ mask_index = index 1;
+ return (hpsizes[index 1] (mask_index * 4)) 0xF;
static struct slice_mask slice_mask_for_size(struct mm_struct *mm, int psize)
{
+ unsigned char *hpsizes;
+ int index, mask_index;
struct slice_mask ret = { 0, 0 };
unsigned long i;
- u64 psizes;
+ u64 lpsizes;
- psizes = mm-context.low_slices_psize;
+ lpsizes = mm-context.low_slices_psize;
for (i = 0; i SLICE_NUM_LOW; i++)
- if (((psizes (i * 4)) 0xf) == psize)
+ if (((lpsizes (i * 4)) 0xf) == psize)
ret.low_slices |= 1u i;
- psizes = mm-context.high_slices_psize;
- for (i = 0; i SLICE_NUM_HIGH; i++)
- if (((psizes (i * 4)) 0xf) == psize)
+ hpsizes = mm-context.high_slices_psize;
+ for (i = 0; i SLICE_NUM_HIGH; i++) {
+ index = i 1;
+ mask_index = i - (index 1);
Again, seems like a complicated way to do mask_index = i 1 (or
even i % 2, if you prefer, but then make i an unsigned type).
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn
On Mon, Jul 09, 2012 at 06:43:33PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch convert different functions to take virtual page number
instead of virtual address. Virtual page number is virtual address
shifted right by VPN_SHIFT (12) bits. This enable us to have an
address range of upto 76 bits.
Some comments inline below...
+/*
+ * encode page number shift.
+ * Inorder to fit the 78 bit va in a 64 bit variable we shift the va by
^ in order
+ * 12 bits. This enable us to address upto 76 bit va.
^ up to
+ * For hpt hash from a va we can ignore the page size bits of va and for
+ * hpte encoding we ignore upto 23 bits of va. So ignoring lower 12 bits
ensure
+ * we work in all cases including 4k page size.
+ */
+#define VPN_SHIFT12
This can't be more than 12 bits because we sometimes use 4k pages even
in a kernel configured for 64k pages (e.g. with the subpage_protection
system call).
+static inline unsigned long hpte_encode_avpn(unsigned long vpn, int psize,
+ int ssize)
+{
+ unsigned long v;
+ /*
+ * The AVA field omits the low-order 23 bits of the 78 bits VA.
+ * These bits are not needed in the PTE, because the
+ * low-order b of these bits are part of the byte offset
+ * into the virtual page and, if b 23, the high-order
+ * 23-b of these bits are always used in selecting the
+ * PTEGs to be searched
+ */
+ BUG_ON(VPN_SHIFT 23);
I don't think we need this. If VPN_SHIFT was computed by some complex
expression whose value is not obvious, then BUG_ON (or BUILD_BUG_ON)
would be appropriate, but since it's just a #define, a comment at the
site of the definition will suffice.
static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
int ssize)
{
+ int mask;
unsigned long hash, vsid;
+ BUG_ON(shift VPN_SHIFT);
So VPN_SHIFT can be at most 12, since 12 is the smallest shift value
possible here.
-static inline void __tlbiel(unsigned long va, int psize, int ssize)
+static inline void __tlbiel(unsigned long vpn, int psize, int ssize)
{
+ unsigned long va;
unsigned int penc;
+ BUG_ON((77 - 65) VPN_SHIFT);
+ va = vpn VPN_SHIFT;
So VPN_SHIFT has to be at least 12. What is the significance of 77
and 65 here?
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 11/11] arch/powerpc: Add 64TB support
On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Increase max addressable range to 64TB. This is not tested on real hardware yet. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/include/asm/mmu-hash64.h|8 arch/powerpc/include/asm/pgtable-ppc64-4k.h |2 +- arch/powerpc/include/asm/pgtable-ppc64-64k.h |2 +- arch/powerpc/include/asm/processor.h |4 ++-- arch/powerpc/include/asm/sparsemem.h |4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h index aa0d560..a227ba7 100644 --- a/arch/powerpc/include/asm/mmu-hash64.h +++ b/arch/powerpc/include/asm/mmu-hash64.h @@ -374,16 +374,16 @@ extern void slb_set_size(u16 size); */ #define VSID_MULTIPLIER_256M ASM_CONST(200730139)/* 28-bit prime */ -#define VSID_BITS_256M 36 +#define VSID_BITS_256M 38 #define VSID_MODULUS_256M((1ULVSID_BITS_256M)-1) With these settings, the multiplication in ASM_VSID_SCRAMBLE could overflow, leading to incorrect results (which would cause occasional corruption of user processes under heavy load). You will need to reduce the multiplier to be less than 2^26, and it will need to be co-prime with 2^38 - 1. (Probably, the same value as we use in the 1T case would be OK.) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 08/11] arch/powerpc: Make some of the PGTABLE_RANGE dependency explicit
On Mon, Jul 09, 2012 at 06:43:38PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
slice array size and slice mask size depend on PGTABLE_RANGE. We
can't directly include pgtable.h in these header because there is
a circular dependency. So add compile time check for these values.
Some comments below...
struct slice_mask {
u16 low_slices;
/*
- * This should be derived out of PGTABLE_RANGE. For the current
- * max 64TB, u64 should be ok.
+ * We do this as a union so that we can verify
+ * SLICE_MASK_SIZE against PGTABLE_RANGE
*/
- u64 high_slices;
+ union {
+ u64 high_slices;
+ unsigned char not_used[SLICE_MASK_SIZE];
+ };
Seems ugly to have to have a union just for that. Can't we do
something like BUILD_BUG_ON(sizeof(u64) SLICE_MASK_SIZE) instead?
@@ -73,7 +73,7 @@ static struct slice_mask slice_range_to_mask(unsigned long
start,
unsigned long len)
{
unsigned long end = start + len - 1;
- struct slice_mask ret = { 0, 0 };
+ struct slice_mask ret = { 0, {0} };
Wouldn't { 0 } suffice? Similarly in several places below.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
On Mon, Jul 09, 2012 at 06:43:35PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com ISA doc doesn't talk about this. As per ISA doc for a 4K page tlbie RB RS The Abbreviated Virtual Address (AVA) field in register RB must contain bits 14:65 of the virtual address translated by the TLB entry to be invalidated. That indicate we should not mask the top 16 bits. So remove the same. Older versions of the architecture (2.02 and earler) require the masking, so we can't just unconditionally remove it, since that would potentially break POWER5 and PPC970. People are definitely still running Linux bare-metal on PPC970s (though arguably not on POWER5). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote: That indicate we should not mask the top 16 bits. So remove the same. Older versions of the architecture (2.02 and earler) require the masking, so we can't just unconditionally remove it, since that would potentially break POWER5 and PPC970. People are definitely still running Linux bare-metal on PPC970s (though arguably not on POWER5). Are you sure ? I couldn't convince myself ... the old architectures say that it only uses some of the bits but it doesn't mark the other ones as reserved (as in must be 0). (At least 1.x, I haven't looked at 2.x with x 03) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: require a match on all fields of of_device_id
On 07/18/2012 11:04 AM, Scott Wood wrote: On 07/17/2012 09:38 PM, Rob Herring wrote: On 07/17/2012 08:11 PM, Scott Wood wrote: Commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6 (of: match by compatible property first) breaks the gianfar ethernet driver found on various Freescale PPC chips. You do know this is reverted, right? No, I didn't. I got it via Kumar's next branch, and saw that it was still in your fixes-for-grant branch, and didn't see any revert-related e-mail activity on the devicetree-discuss list about it. I now see that it was reverted directly in Linus's tree (I didn't see either the original or the revert in Linus's tree when I checked, but apparently I hadn't fetched that as recently as I thought). Here's my fix (untested) which is a bit simpler. I'm assuming if we care about which compatible string we are matching to, then we require name and type are blank and we only care about compatible strings. Any particular reason for making that assumption? We should be avoiding the need for .name or .type matching in new bindings, but this seems like unnecessarily inconsistent behavior. Only to ensure we don't change existing behavior and I think trying to cover all possibilities will be nearly impossible. For example, what if we match on both a specific compatible prop alone and a less specific compatible prop plus name and/or type. Which one do we pick as the better match? Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: next/mmotm unbootable on G5: irqdomain
On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote: I have to revert the patch below from mmotm 2012-07-20-16-30 or next-20120720 in order to boot on the PowerPC G5: otherwise it freezes before switching to the framebuffer console - but I'm not certain where because that initial console doesn't scroll (there are mpic messages at bottom and at top of screen, probably later messages at the top but I don't know the sequence). This fixes it (Grant, how do we avoid bisection breakage here ? I can put that in -powerpc and we can make sure that gets merged before your tree ?) powerpc/mpic: Create a revmap with enough entries for IPIs and timers The current mpic code creates a linear revmap just big enough for all the sources, which happens to miss the IPIs and timers on some machines. This will in turn break when the irqdomain code loses the fallback of doing a linear search when the revmap fails (and really slows down IPIs otherwise). This happens for example on the U4 based Apple machines such as the dual core PowerMac G5s. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c index 906f29c..bfc6211 100644 --- a/arch/powerpc/sysdev/mpic.c +++ b/arch/powerpc/sysdev/mpic.c @@ -1376,7 +1376,7 @@ struct mpic * __init mpic_alloc(struct device_node *node, mpic-isu_mask = (1 mpic-isu_shift) - 1; mpic-irqhost = irq_domain_add_linear(mpic-node, - last_irq + 1, + intvec_top, mpic_host_ops, mpic); /* ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Update g5_defconfig
This updates the g5 defconfig to include nouveau instead of nvidiafb (which works much better nowadays, in fact the latter crashes on modern distros), and to set CONFIG_VT_HW_CONSOLE_BINDING without which takeover from the firmware offb by nouveau doesn't work properly (and leads to unexplained black screens for some users). The rest is churn of going through defconfig / savedefconfig Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig index 07b7f2a..1513006 100644 --- a/arch/powerpc/configs/g5_defconfig +++ b/arch/powerpc/configs/g5_defconfig @@ -1,10 +1,8 @@ -CONFIG_PPC64=y -CONFIG_ALTIVEC=y -CONFIG_SMP=y -CONFIG_NR_CPUS=4 CONFIG_EXPERIMENTAL=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_BLK_DEV_INITRD=y @@ -15,16 +13,15 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y -# CONFIG_PPC_PSERIES is not set +CONFIG_PARTITION_ADVANCED=y +CONFIG_MAC_PARTITION=y +CONFIG_SMP=y +CONFIG_NR_CPUS=4 +CONFIG_KEXEC=y +# CONFIG_RELOCATABLE is not set CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_GOV_POWERSAVE=y CONFIG_CPU_FREQ_GOV_USERSPACE=y -CONFIG_CPU_FREQ_PMAC64=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y -CONFIG_KEXEC=y -CONFIG_IRQ_ALL_CPUS=y -# CONFIG_MIGRATION is not set CONFIG_PCI_MSI=y CONFIG_NET=y CONFIG_PACKET=y @@ -52,7 +49,6 @@ CONFIG_NF_CT_NETLINK=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_IP_NF_QUEUE=m CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y @@ -60,8 +56,6 @@ CONFIG_BLK_DEV_RAM_SIZE=65536 CONFIG_CDROM_PKTCDVD=m CONFIG_IDE=y CONFIG_BLK_DEV_IDECD=y -CONFIG_BLK_DEV_IDE_PMAC=y -CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST=y CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_BLK_DEV_SR=y @@ -85,33 +79,24 @@ CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m -CONFIG_IEEE1394=y -CONFIG_IEEE1394_OHCI1394=y -CONFIG_IEEE1394_SBP2=m -CONFIG_IEEE1394_ETH1394=m -CONFIG_IEEE1394_RAWIO=y -CONFIG_IEEE1394_VIDEO1394=m -CONFIG_IEEE1394_DV1394=m -CONFIG_ADB_PMU=y -CONFIG_PMAC_SMU=y +CONFIG_MACINTOSH_DRIVERS=y CONFIG_MAC_EMUMOUSEBTN=y -CONFIG_THERM_PM72=y -CONFIG_WINDFARM=y -CONFIG_WINDFARM_PM81=y -CONFIG_WINDFARM_PM91=y -CONFIG_WINDFARM_PM112=y -CONFIG_WINDFARM_PM121=y CONFIG_NETDEVICES=y -CONFIG_DUMMY=m CONFIG_BONDING=m -CONFIG_TUN=m -CONFIG_NET_ETHERNET=y +CONFIG_DUMMY=m CONFIG_MII=y -CONFIG_SUNGEM=y +CONFIG_TUN=m CONFIG_ACENIC=m CONFIG_ACENIC_OMIT_TIGON_I=y -CONFIG_E1000=y CONFIG_TIGON3=y +CONFIG_E1000=y +CONFIG_SUNGEM=y +CONFIG_PPP=m +CONFIG_PPP_BSDCOMP=m +CONFIG_PPP_DEFLATE=m +CONFIG_PPPOE=m +CONFIG_PPP_ASYNC=m +CONFIG_PPP_SYNC_TTY=m CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m @@ -121,36 +106,24 @@ CONFIG_USB_USBNET=m # CONFIG_USB_NET_NET1080 is not set # CONFIG_USB_NET_CDC_SUBSET is not set # CONFIG_USB_NET_ZAURUS is not set -CONFIG_PPP=m -CONFIG_PPP_ASYNC=m -CONFIG_PPP_SYNC_TTY=m -CONFIG_PPP_DEFLATE=m -CONFIG_PPP_BSDCOMP=m -CONFIG_PPPOE=m # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=y -# CONFIG_KEYBOARD_ATKBD is not set # CONFIG_MOUSE_PS2 is not set -# CONFIG_SERIO_I8042 is not set # CONFIG_SERIO_SERPORT is not set +CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_HW_RANDOM is not set CONFIG_GEN_RTC=y CONFIG_RAW_DRIVER=y CONFIG_I2C_CHARDEV=y # CONFIG_HWMON is not set -CONFIG_AGP=m -CONFIG_AGP_UNINORTH=m +CONFIG_AGP=y +CONFIG_DRM=y +CONFIG_DRM_NOUVEAU=y CONFIG_VIDEO_OUTPUT_CONTROL=m -CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_TILEBLITTING=y -CONFIG_FB_OF=y -CONFIG_FB_NVIDIA=y -CONFIG_FB_NVIDIA_I2C=y CONFIG_FB_RADEON=y -# CONFIG_VGA_CONSOLE is not set -CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_LOGO=y CONFIG_SOUND=m CONFIG_SND=m @@ -158,15 +131,7 @@ CONFIG_SND_SEQUENCER=m CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_SEQUENCER_OSS=y -CONFIG_SND_POWERMAC=m -CONFIG_SND_AOA=m -CONFIG_SND_AOA_FABRIC_LAYOUT=m -CONFIG_SND_AOA_ONYX=m -CONFIG_SND_AOA_TAS=m -CONFIG_SND_AOA_TOONIE=m CONFIG_SND_USB_AUDIO=m -CONFIG_HID_PID=y -CONFIG_USB_HIDDEV=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y CONFIG_HID_PANTHERLORD=y @@ -174,13 +139,12 @@ CONFIG_HID_PETALYNX=y CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_HID_SUNPLUS=y +CONFIG_HID_PID=y +CONFIG_USB_HIDDEV=y CONFIG_USB=y -CONFIG_USB_DEVICEFS=y CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y -# CONFIG_USB_EHCI_HCD_PPC_OF is not set CONFIG_USB_OHCI_HCD=y -CONFIG_USB_OHCI_HCD_PPC_OF_BE=y CONFIG_USB_ACM=m CONFIG_USB_PRINTER=y CONFIG_USB_STORAGE=y @@ -244,8 +208,6 @@ CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_XFS_FS=m CONFIG_XFS_POSIX_ACL=y -CONFIG_INOTIFY=y -CONFIG_AUTOFS_FS=m CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y @@ -259,14 +221,12 @@ CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_CRAMFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y
Re: [PATCH -V3 05/11] arch/powerpc: remove masking top 16 bit of va in tlb invalidate
On Mon, Jul 23, 2012 at 11:22:08AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2012-07-23 at 09:56 +1000, Paul Mackerras wrote: That indicate we should not mask the top 16 bits. So remove the same. Older versions of the architecture (2.02 and earler) require the masking, so we can't just unconditionally remove it, since that would potentially break POWER5 and PPC970. People are definitely still running Linux bare-metal on PPC970s (though arguably not on POWER5). Are you sure ? I couldn't convince myself ... the old architectures say that it only uses some of the bits but it doesn't mark the other ones as reserved (as in must be 0). (At least 1.x, I haven't looked at 2.x with x 03) 2.01 and 2.02 say bits 0..15 must be zero. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Hi Linus ! Here's the powerpc batch for 3.6 merge window. Notable highlights: - iommu improvements from Anton removing the per-iommu global lock in favor of dividing the DMA space into pools, each with its own lock, and hashed on the CPU number. Along with making the locking more fine grained, this gives significant improvements in multiqueue networking scalability. - Still from Anton, we know provide a vdso based variant of getcpu which makes sched_getcpu with the appropriate glibc patch something like 18 times faster. - More anton goodness (he's been busy !) in other areas such as a faster __clear_user and copy_page on P7, various perf fixes to improve sampling quality, etc... - One more step toward removing legacy i2c interfaces by using new device-tree based probing of platform devices for the AOA audio drivers - A nice series of patches from Michael Neuling that helps avoiding confusion between register numbers and litterals in assembly code, trying to enforce the use of %rN register names in gas rather than plain numbers. - A pile of FSL updates - The usual bunch of small fixes, cleanups etc... You may spot a change to drivers/char/mem. The patch got no comment or ack from outside, it's a trivial patch to allow the architecture to skip creating /dev/port, which we use to disable it on ppc64 that don't have a legacy brige. On those, IO ports 0...64K are not mapped in kernel space at all, so accesses to /dev/port cause oopses (and yes, distros -still- ship userspace that bangs hard coded ports such as kbdrate). Cheers, Ben. The following changes since commit 50fb31cfed9218b439360caf7c0399b00042da15: tty/hvc_opal: Fix debug function name (2012-07-10 19:16:25 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to 574ce79cea9d3fda109ffcc82f81733de4740e5c: powerpc/mpic: Create a revmap with enough entries for IPIs and timers (2012-07-23 14:20:42 +1000) Andreas Schwab (1): sound/aoa: Adapt to new i2c probing scheme Anton Blanchard (24): powerpc: Enable jump label support powerpc: tracing: Avoid tracepoint duplication with DECLARE_EVENT_CLASS powerpc: 64bit optimised __clear_user powerpc: Use enhanced touch instructions in POWER7 copy_to_user/copy_from_user powerpc: Clear RI and EE at the same time in system call exit powerpc: Rename copyuser_power7_vmx.c to vmx-helper.c powerpc: POWER7 optimised copy_page using VMX and enhanced prefetch powerpc: Use enhanced touch instructions in POWER7 copy_to_user/copy_from_user powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch powerpc/pseries: Disable interrupts around IOMMU percpu data accesses powerpc/iommu: Reduce spinlock coverage in iommu_alloc and iommu_free powerpc/iommu: Reduce spinlock coverage in iommu_free powerpc/iommu: Push spinlock into iommu_range_alloc and __iommu_free powerpc/iommu: Implement IOMMU pools to improve multiqueue adapter performance powerpc: Optimise the 64bit optimised __clear_user powerpc/perf: Create mmcra_sihv/mmcra_sipv helpers powerpc/perf: Move code to select SIAR or pt_regs into perf_read_regs powerpc/perf: Always use pt_regs for userspace samples powerpc/perf: Use perf_instruction_pointer in callchains powerpc/vio: Remove dma not supported warnings powerpc/vio: Separate vio bus probe and device probe powerpc: Call dma_debug_add_bus for PCI and VIO buses powerpc: IOMMU fault injection powerpc: Add VDSO version of getcpu Benjamin Herrenschmidt (8): Merge branch 'merge' into next powerpc: Move and fix MTMSR_EERI definition powerpc: Fixup oddity in entry_32.S i2c/powermac: Improve detection of devices from device-tree Merge remote-tracking branch 'kumar/next' into next powerpc/iommu: Fix iommu pool initialization Remove stale .rej file powerpc/mpic: Create a revmap with enough entries for IPIs and timers Bharat Bhushan (1): powerpc: Fix assmption of end_of_DRAM() returns end address Christian Herzig (1): powerpc/83xx: fix RGMII AC values workaround for km83xx Deepthi Dharwar (2): powerpc/pseries/cpuidle: Replace pseries_notify_cpuidle_add call with notifier powerpc/cpuidle: Fixes for pseries_idle hotplug notifier Dong Aisheng (1): of: Improve prom_update_property() function Gavin Shan (2): powerpc/numa: Fix OF node refcounting bug powerpc/pci: cleanup on duplicate assignment Gustavo Zacarias (1): powerpc/p1010rdb: add EEPROMs to device tree Haren Myneni (1): powerpc: Disable /dev/port interface on systems without an ISA bridge Holger Brunck (3): powerpc/83xx: use for_each_node_by_name for km83xx.c powerpc/83xx: update defconfig for kmeter1 powerpc/82xx: add
Re: [PATCH -V3 02/11] arch/powerpc: Simplify hpte_decode
Paul Mackerras pau...@samba.org writes: On Mon, Jul 09, 2012 at 06:43:32PM +0530, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com This patch simplify hpte_decode for easy switching of virtual address to virtual page number in the later patch Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com I'm not convinced your version is simpler than what was there before. It's certainly longer now. But it does seem to do the same calculation as before, so: This actually make patch 3 arch/powerpc: Convert virtual address to vpn simpler. The hpte_decode hunk is a one line change after this Reviewed-by: Paul Mackerras pau...@samba.org -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V3 03/11] arch/powerpc: Convert virtual address to vpn
Paul Mackerras pau...@samba.org writes:
On Mon, Jul 09, 2012 at 06:43:33PM +0530, Aneesh Kumar K.V wrote:
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
This patch convert different functions to take virtual page number
instead of virtual address. Virtual page number is virtual address
shifted right by VPN_SHIFT (12) bits. This enable us to have an
address range of upto 76 bits.
Some comments inline below...
+/*
+ * encode page number shift.
+ * Inorder to fit the 78 bit va in a 64 bit variable we shift the va by
^ in order
+ * 12 bits. This enable us to address upto 76 bit va.
^ up to
+ * For hpt hash from a va we can ignore the page size bits of va and for
+ * hpte encoding we ignore upto 23 bits of va. So ignoring lower 12 bits
ensure
+ * we work in all cases including 4k page size.
+ */
+#define VPN_SHIFT 12
This can't be more than 12 bits because we sometimes use 4k pages even
in a kernel configured for 64k pages (e.g. with the subpage_protection
system call).
Yes, I wanted to make that explicit, ie this is not a virtual page
number and hence all these BUG_ON. I actually updated few of them
to BUILD_BUG_ON() based of earlier review.
+static inline unsigned long hpte_encode_avpn(unsigned long vpn, int psize,
+ int ssize)
+{
+unsigned long v;
+/*
+ * The AVA field omits the low-order 23 bits of the 78 bits VA.
+ * These bits are not needed in the PTE, because the
+ * low-order b of these bits are part of the byte offset
+ * into the virtual page and, if b 23, the high-order
+ * 23-b of these bits are always used in selecting the
+ * PTEGs to be searched
+ */
+BUG_ON(VPN_SHIFT 23);
I don't think we need this. If VPN_SHIFT was computed by some complex
expression whose value is not obvious, then BUG_ON (or BUILD_BUG_ON)
would be appropriate, but since it's just a #define, a comment at the
site of the definition will suffice.
static inline unsigned long hpt_hash(unsigned long va, unsigned int shift,
int ssize)
{
+int mask;
unsigned long hash, vsid;
+BUG_ON(shift VPN_SHIFT);
So VPN_SHIFT can be at most 12, since 12 is the smallest shift value
possible here.
-static inline void __tlbiel(unsigned long va, int psize, int ssize)
+static inline void __tlbiel(unsigned long vpn, int psize, int ssize)
{
+unsigned long va;
unsigned int penc;
+BUG_ON((77 - 65) VPN_SHIFT);
+va = vpn VPN_SHIFT;
So VPN_SHIFT has to be at least 12. What is the significance of 77
and 65 here?
It is the other way around . I updated that in
77guccfav@skywalker.in.ibm.com
BUILD_BUG_ON(VPN_SHIFT (77 - 65));
tlbiel says we can only ignore bits above 65 of va. hence the math of 77- 65.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
