Commit Graph

11 Commits

Author SHA1 Message Date
Paul Mundt e06c4e5775 sh: Fix fs.h removal from mm.h regressions.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-07-31 13:01:43 +09:00
Paul Mundt 8cf1a74305 sh: Add kmap_coherent()/kunmap_coherent() interface for SH-4.
This wires up kmap_coherent() and kunmap_coherent() on SH-4, and
moves away from the p3map_mutex and reserved P3 space, opting to
use fixmaps for colouring instead.

The copy_user_page()/clear_user_page() implementations are moved
to this, which fixes the nasty blowups with spinlock debugging
as a result of having some of these calls nested under the page
table lock.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-07-24 13:28:26 +09:00
Paul Mundt 39e688a94b sh: Revert lazy dcache writeback changes.
These ended up causing too many problems on older parts,
revert for now..

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-03-05 19:46:47 +09:00
Paul Mundt ea9af69481 sh: Local TLB flushing variants for SMP prep.
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>
2007-02-13 10:54:45 +09:00
Paul Mundt 11c1965687 sh: Fixup cpu_data references for the non-boot CPUs.
There are a lot of bogus cpu_data-> references that only end up working
for the boot CPU, convert these to current_cpu_data to fixup SMP.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-02-13 10:54:45 +09:00
Paul Mundt 26b7a78c55 sh: Lazy dcache writeback optimizations.
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>
2007-02-13 10:54:44 +09:00
Paul Mundt 52e27782e1 sh: p3map_sem sem2mutex conversion.
Simple sem2mutex conversion for the p3map semaphores.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-12-06 10:45:37 +09:00
Paul Mundt 21440cf04a sh: Preliminary support for SH-X2 MMU.
This adds some preliminary support for the SH-X2 MMU, used by
newer SH-4A parts (particularly SH7785).

This MMU implements a 'compat' mode with SH-X MMUs and an
'extended' mode for SH-X2 extended features. Extended features
include additional page sizes (8kB, 4MB, 64MB), as well as the
addition of page execute permissions.

The extended mode attributes are placed in a second data array,
which requires us to switch to 64-bit PTEs when in X2 mode.

With the addition of the exec perms, we also overhaul the mmap
prots somewhat, now that it's possible to handle them more
intelligently.

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-12-06 10:45:37 +09:00
Paul Mundt 8b395265f8 sh: Fix fatal oops in copy_user_page() on sh4a (SH7780).
We had a pretty interesting oops happening, where copy_user_page()
was down()'ing p3map_sem[] with a bogus offset (particularly, an
offset that hadn't been initialized with sema_init(), due to the
mismatch between cpu_data->dcache.n_aliases and what was assumed
based off of the old CACHE_ALIAS value).

Luckily, spinlock debugging caught this for us, and so we drop
the old hardcoded CACHE_ALIAS for sh4 completely and rely on the
run-time probed cpu_data->dcache.alias_mask. This in turn gets
the p3map_sem[] index right, and everything works again.

While we're at it, also convert to 4-level page tables..

Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-09-27 14:38:02 +09:00
Jörn Engel 6ab3d5624e Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-06-30 19:25:36 +02:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00