|
@@ -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.
|
|
|
|