You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC
Replace a WC MTRR call followed by a UC MTRR "hole" call with a
single WC MTRR call and use strong UC to protect the MMIO region
and account for the device's architecture and MTRR size
requirements.
The atyfb driver relies on two overlapping MTRRs. It does this
to account for the fact that, on some devices, it has the MMIO
region bundled together with the framebuffer on the same PCI BAR
and the hardware requirement on MTRRs on both base and size to
be powers of two.
In the worst case, the PCI BAR is of 16 MiB while the MMIO
region is on the last 4 KiB of the same PCI BAR. If we use just
one MTRR for WC, we can only end up with an 8 MiB or 16 MiB
framebuffer. Using a 16 MiB WC framebuffer area is unacceptable
since we need the MMIO region to not be write-combined. An 8 MiB
WC framebuffer option does not let use quite a bit of
framebuffer space, it would reduce the resolution capability of
the device considerably.
An alternative is to use many MTRRs but on some systems that
could mean not having enough MTRRs to cover the framebuffer. The
current solution is to issue a 16 MiB WC MTRR followed by a 4
KiB UC MTRR on the last 4 KiB. Its worth mentioning and
documenting that the current ioremap*() strategy as well: the
first ioremap() is used only for the MMIO region, a second
ioremap() call is used for the framebuffer *and* the MMIO
region, the MMIO region then ends up mmapped twice.
Two ioremap() calls are used since in some situations the
framebuffer actually ends up on a separate auxiliary PCI BAR,
but this is not always true. In the worst case, the PCI BAR is
shared for both MMIO and the framebuffer. By allowing
overlapping ioremap() calls, the driver enables two types of
devices with one simple ioremap() strategy.
See also:
2f9e897 ("x86/mm/mtrr, pat: Document Write Combining MTRR type effects on PAT / non-PAT pages")
By default, Linux today defaults both pci_mmap_page_range() and
ioremap_nocache() to use _PAGE_CACHE_MODE_UC_MINUS. On x86,
ioremap() aliases ioremap_nocache(). The preferred value for
Linux may soon change, however, the goal is to use
_PAGE_CACHE_MODE_UC by default in the future.
We can use ioremap_uc() to set PCD=1, PWT=1 on non-PAT systems
and use a PAT value of UC for PAT systems. This will ensure the
same settings are in place regardless of what Linux decides to
use by default later and to not regress our MTRR strategy since
the effective memory type will differ depending on the value
used. Using a WC MTRR on such an area will be nullified. This
technique can be used to protect the MMIO region in this
driver's case and address the restrictions of the device's
architecture as well as restrictions set upon us by powers of 2
when using MTRRs.
This allows us to replace the two MTRR calls with a single 16
MiB WC MTRR and use page-attribute settings for non-PAT and PAT
entry values for PAT systems to ensure the appropriate effective
memory type won't have a write-combining effect on the MMIO
region on both non-PAT and PAT systems. The framebuffer area
will be sure to get the write-combined effective memory type by
white-listing it with ioremap_wc().
We ensure the desired effective memory types are set by:
0) Using one ioremap_uc() for the MMIO region alone.
This will set the page attribute settings for the MMIO
region to PCD=1, PWT=1 for non-PAT systems while using a
strong UC value on PAT systems.
1) Fixing the framebuffer ioremapped area to exclude the
MMIO region and using ioremap_wc() instead to whitelist
the area we want for write-combining.
In both cases, an implementation defined (as per 2f9e897)
effective memory type of WC is used for the framebuffer for
non-PAT systems.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathias Krause <minipli@googlemail.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: arnd@arndb.de
Cc: benh@kernel.crashing.org
Cc: dan.j.williams@intel.com
Cc: geert@linux-m68k.org
Cc: hch@lst.de
Cc: hmh@hmh.eng.br
Cc: linux-fbdev@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-pci@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: mst@redhat.com
Cc: ralf@linux-mips.org
Cc: ross.zwisler@linux.intel.com
Cc: stefan.bader@canonical.com
Cc: tj@kernel.org
Cc: ville.syrjala@linux.intel.com
Link: http://lkml.kernel.org/r/1435196060-27350-3-git-send-email-mcgrof@do-not-panic.com
Link: http://lkml.kernel.org/r/1436491499-3289-4-git-send-email-mcgrof@do-not-panic.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
0 commit comments