Presently most of the 29-bit physical parts do P1/P2 segmentation
with a 1:1 cached/uncached mapping, jumping between the two to
control the caching behaviour. This provides the basic infrastructure
to maintain this behaviour on 32-bit physical parts that don't map
P1/P2 at all, using a shiny new linker section and corresponding
fixmap entry.
Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The extended mode TLB requires both 64-bit PTEs and a 64-bit pgprot,
correspondingly, the PGD also has to be 64-bits, so fix that up.
The kernel and user permission bits really are decoupled in early
cuts of the silicon, which means that we also have to set corresponding
kernel permissions on user pages or we end up with user pages that the
kernel simply can't touch (!).
Finally, with those things corrected, really enable MMUCR.ME and
correct the PTEA value (this simply needs to be the upper 32-bits
of the PTE, with the size and protection bit encoding).
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This reworks the cache mode configuration in Kconfig, and allows for
explicit selection of write-back/write-through/off configurations.
All of the cache flushing routines are optimized away for the off
case.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Rename the existing flush routines to local_ variants for use by
the IPI-backed global flush routines on SMP.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
This converts the lazy dcache handling to the model described in
Documentation/cachetlb.txt and drops the ptep_get_and_clear() hacks
used for the aliasing dcaches on SH-4 and SH7705 in 32kB mode. As a
bonus, this slightly cuts down on the cache flushing frequency.
With that and the PTEA handling out of the way, the update_mmu_cache()
implementations can be consolidated, and we no longer have to worry
about which configuration the cache is in for the SH7705 case.
And finally, explicitly disable the lazy writeback on SMP (SH-4A).
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Stuart Menefy