mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 11:11:45 -04:00
Merge branch 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 mm updates from Ingo Molnar: "The dominant change in this cycle was the continued work to isolate kernel drivers from MTRR legacies: this tree gets rid of all kernel internal driver interfaces to MTRRs (mostly by rewriting it to proper PAT interfaces), the only access left is the /proc/mtrr ABI. This work was done by Luis R Rodriguez. There's also some related PCI interface additions for which I've Cc:-ed Bjorn" * 'x86-mm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (21 commits) x86/mm/mtrr: Remove kernel internal MTRR interfaces: unexport mtrr_add() and mtrr_del() s390/io: Add pci_iomap_wc() and pci_iomap_wc_range() drivers/dma/iop-adma: Use dma_alloc_writecombine() kernel-style drivers/video/fbdev/vt8623fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/s3fb: Use arch_phys_wc_add() and pci_iomap_wc() drivers/video/fbdev/arkfb.c: Use arch_phys_wc_add() and pci_iomap_wc() PCI: Add pci_iomap_wc() variants drivers/video/fbdev/gxt4500: Use pci_ioremap_wc_bar() to map framebuffer drivers/video/fbdev/kyrofb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() drivers/video/fbdev/i740fb: Use arch_phys_wc_add() and pci_ioremap_wc_bar() PCI: Add pci_ioremap_wc_bar() x86/mm: Make kernel/check.c explicitly non-modular x86/mm/pat: Make mm/pageattr[-test].c explicitly non-modular x86/mm/pat: Add comments to cachemode translation tables arch/*/io.h: Add ioremap_uc() to all architectures drivers/video/fbdev/atyfb: Use arch_phys_wc_add() and ioremap_wc() drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC drivers/video/fbdev/atyfb: Clarify ioremap() base and length used drivers/video/fbdev/atyfb: Carve out framebuffer length fudging into a helper x86/mm, asm-generic: Add IOMMU ioremap_uc() variant default ...
This commit is contained in:
commit
25525bea46
32 changed files with 254 additions and 222 deletions
|
|
@ -6,10 +6,22 @@ Luis R. Rodriguez <[email protected]> - 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.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue