Scott Wood <scottw...@freescale.com> wrote on 12/11/2009 22:57:59: > > Joakim Tjernlund wrote: > > Scott Wood <scottw...@freescale.com> wrote on 12/11/2009 20:45:59: > >> One other concern with pinning on 8xx -- could it cause problems with > >> uncached DMA mappings? What happens if a speculative load pulls in a > >> cache line in an area that's supposed to be uncached? > > > > hmm, why should this be a problem? > > Because then you would be accessing potentially stale DMA data -- and > more generally, the architecture prohibits such mixing. > > > Pinning has been around as a config option > > for a long time so any problems should have surfaced by now. > > It has existed as an option, which is going to get less test coverage > than something that is always on. Plus, it would not be a particularly > common failure -- easy to blame one-off weirdness on something else. > > > Secondly, I was thinking that we could just make the ITLB pinning > > mandatory and let the DTLB pinning be as is, configurable. > > That could work. We could also limit the pool of memory > dma_alloc_coherent() uses to not overlap with anything pinned.
And try using the remaing 3 ITLBs which are unused when pinning to cover the module space. Probably not going to be perfect. Anyhow, lets start simple and just do the pinned ITLB so the new TLB code can be applied. Can you confirm this works for you? >From 0c30d6c1ee45341fcfc5643bd2ba876e3c9a416e Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund <joakim.tjernl...@transmode.se> Date: Fri, 13 Nov 2009 00:26:59 +0100 Subject: [PATCH] 8xx: Always pin kernel instruction TLB --- arch/powerpc/kernel/head_8xx.S | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index adc5a32..c7a4e60 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -767,7 +767,7 @@ start_here: */ initial_mmu: tlbia /* Invalidate all TLB entries */ -#ifdef CONFIG_PIN_TLB +#ifdef 1 /* CONFIG_PIN_TLB */ lis r8, mi_rs...@h ori r8, r8, 0x1c00 #else -- 1.6.4.4 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev