summaryrefslogtreecommitdiff
path: root/Documentation/x86/mtrr.txt
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.com>2015-09-05 11:07:04 +0200
committerNeilBrown <neilb@suse.com>2015-09-05 11:08:32 +0200
commite89c6fdf9e0eb1b5a03574d4ca73e83eae8deb91 (patch)
treef9df292ed03a5a3c4ddc658ae3646f02a1ffafce /Documentation/x86/mtrr.txt
parentc3cce6cda162eb2b2960a85d9c8992f4f3be85d0 (diff)
parent1081230b748de8f03f37f80c53dfa89feda9b8de (diff)
Merge linux-block/for-4.3/core into md/for-linux
There were a few conflicts that are fairly easy to resolve. Signed-off-by: NeilBrown <neilb@suse.com>
Diffstat (limited to 'Documentation/x86/mtrr.txt')
-rw-r--r--Documentation/x86/mtrr.txt20
1 files changed, 16 insertions, 4 deletions
diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
index 860bc3adc223..dc3e703913ac 100644
--- a/Documentation/x86/mtrr.txt
+++ b/Documentation/x86/mtrr.txt
@@ -6,10 +6,22 @@ Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015
===============================================================================
Phasing out MTRR use
-MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
-of effective MTRR that is expected to be supported will be for write-combining.
-As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
-MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
+MTRR use is replaced on modern x86 hardware with PAT. Direct MTRR use by
+drivers on Linux is now completely phased out, device drivers should use
+arch_phys_wc_add() in combination with ioremap_wc() to make MTRR effective on
+non-PAT systems while a no-op but equally effective on PAT enabled systems.
+
+Even if Linux does not use MTRRs directly, some x86 platform firmware may still
+set up MTRRs early before booting the OS. They do this as some platform
+firmware may still have implemented access to MTRRs which would be controlled
+and handled by the platform firmware directly. An example of platform use of
+MTRRs is through the use of SMI handlers, one case could be for fan control,
+the platform code would need uncachable access to some of its fan control
+registers. Such platform access does not need any Operating System MTRR code in
+place other than mtrr_type_lookup() to ensure any OS specific mapping requests
+are aligned with platform MTRR setup. If MTRRs are only set up by the platform
+firmware code though and the OS does not make any specific MTRR mapping
+requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID.
For details refer to Documentation/x86/pat.txt.