linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com, bp@suse.de,
	plagnioj@jcrosoft.com, tomi.valkeinen@ti.com,
	daniel.vetter@intel.com, airlied@linux.ie, dledford@redhat.com,
	awalls@md.metrocast.net, syrjala@sci.fi, luto@amacapital.net,
	mst@redhat.com, cocci@systeme.lip6.fr,
	linux-kernel@vger.kernel.org,
	"Luis R. Rodriguez" <mcgrof@suse.com>,
	Toshi Kani <toshi.kani@hp.com>, Jonathan Corbet <corbet@lwn.net>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Suresh Siddha <sbsiddha@gmail.com>,
	Juergen Gross <jgross@suse.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Dave Airlie <airlied@redhat.com>,
	Antonino Daplas <adaplas@gmail.com>, Mel Gorman <mgorman@suse.de>,
	Vlastimil Babka <vbabka@suse.cz>,
	Davidlohr Bueso <dbueso@suse.de>,
	linux-fbdev@vger.kernel.org
Subject: Re: [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages
Date: Mon, 04 May 2015 12:23:03 +0000	[thread overview]
Message-ID: <20150504122303.GD4096@pd.tnic> (raw)
In-Reply-To: <1430343851-967-3-git-send-email-mcgrof@do-not-panic.com>

On Wed, Apr 29, 2015 at 02:44:07PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> As part of the effort to phase out MTRR use document
> write-combining MTRR effects on pages with different
> non-PAT page attributes flags and different PAT entry
> values. Extend arch_phys_wc_add() documentation to
> clarify power of two sizes / boundary requirements as
> we phase out mtrr_add() use.
> 
> Lastly hint towards ioremap_uc() for corner cases on
> device drivers working with devices with mixed regions
> where MTRR size requirements would otherwise not
> enable write-combining effective memory types.
> 
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Suresh Siddha <sbsiddha@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Ville Syrjälä <syrjala@sci.fi>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Borislav Petkov <bp@suse.de>
> Cc: Davidlohr Bueso <dbueso@suse.de>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  Documentation/x86/mtrr.txt      | 18 +++++++++++++++---
>  Documentation/x86/pat.txt       | 40 +++++++++++++++++++++++++++++++++++++++-
>  arch/x86/kernel/cpu/mtrr/main.c |  3 +++
>  3 files changed, 57 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/x86/mtrr.txt b/Documentation/x86/mtrr.txt
> index cc071dc..a111a6c 100644
> --- a/Documentation/x86/mtrr.txt
> +++ b/Documentation/x86/mtrr.txt
> @@ -1,7 +1,19 @@
>  MTRR (Memory Type Range Register) control
> -3 Jun 1999
> -Richard Gooch
> -<rgooch@atnf.csiro.au>
> +
> +Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999
> +Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015
> +
> +=======================================> +Phasing MTRR use

"Phasing out...".

> +
> +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.
> +
> +For details refer to Documentation/x86/pat.txt.
> +
> +=======================================>  
>    On Intel P6 family processors (Pentium Pro, Pentium II and later)
>    the Memory Type Range Registers (MTRRs) may be used to control
> diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
> index cf08c9f..7e183e3 100644
> --- a/Documentation/x86/pat.txt
> +++ b/Documentation/x86/pat.txt
> @@ -34,6 +34,8 @@ ioremap                |    --    |    UC-     |       UC-        |
>                         |          |            |                  |
>  ioremap_cache          |    --    |    WB      |       WB         |
>                         |          |            |                  |
> +ioremap_uc             |    --    |    UC      |       UC         |
> +                       |          |            |                  |
>  ioremap_nocache        |    --    |    UC-     |       UC-        |
>                         |          |            |                  |
>  ioremap_wc             |    --    |    --      |       WC         |
> @@ -102,7 +104,43 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
>  as step 0 above and also track the usage of those pages and use set_memory_wb()
>  before the page is freed to free pool.
>  
> -
> +MTRR effects on PAT / non-PAT systems
> +-------------------------------------
> +
> +The following table provides the effects of using write-combining MTRRs when
> +using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
> +mtrr_add() usage will be phased in favor of arch_phys_wc_add() which will

				out

> +be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
> +is made should already have be ioremap'd with write-combining page attributes

	 , 		have been ioremapped with WC attributes...

> +or PAT entries, this can be done by using ioremap_wc() / or respective helpers.
> +Devices which combine areas of IO memory desired to remain uncachable with
> +areas where write-combining is desirable and are restricted by the size
> +requirements of MTRRs should consider splitting up their IO memory space
> +cleanly with ioremap_uc() and ioremap_wc() followed by an arch_phys_wc_add()
> +encompassing both regions. Such use is nevertheless heavily discouraged as
> +the effective memory type is considered implementation defined. This strategy
> +should only be used as last resort on devices with size-contrained regions
> +where otherwise MTRR write-combining would not be effective.
> +
> +Note that you cannot use set_memory_wc() to override / whitelist IO remapped
> +memory space mapped with ioremap*() calls, set_memory_wc() can only be used
> +on RAM.
> +
> +----------------------------------------------------------------------
> +MTRR Non-PAT   PAT    Linux ioremap value        Effective memory type
> +----------------------------------------------------------------------
> +                                                  Non-PAT |  PAT
> +     PAT
> +     |PCD
> +     ||PWT
> +     |||
> +WC   000      WB      _PAGE_CACHE_MODE_WB            WC   |   WC
> +WC   001      WC      _PAGE_CACHE_MODE_WC            WC*  |   WC
> +WC   010      UC-     _PAGE_CACHE_MODE_UC_MINUS      WC*  |   WC
> +WC   011      UC      _PAGE_CACHE_MODE_UC            UC   |   UC
> +----------------------------------------------------------------------
> +
> +(*) denotes implementation defined and is discouraged
>  
>  Notes:
>  
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index ea5f363..12abdbe 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
>   * attempts to add a WC MTRR covering size bytes starting at base and
>   * logs an error if this fails.
>   *
> + * The caller should expect to need to provide a power of two size on an
> + * equivalent power of two boundary.
> + *
>   * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
>   * but drivers should not try to interpret that return value.
>   */
> -- 
> 2.3.2.209.gd67f9d5.dirty
> 

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  parent reply	other threads:[~2015-05-04 12:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1430343851-967-1-git-send-email-mcgrof@do-not-panic.com>
2015-04-29 21:44 ` [PATCH v4 1/6] x86: add ioremap_uc() - force strong UC, PCD=1, PWT=1 Luis R. Rodriguez
2015-04-30 10:18   ` Borislav Petkov
2015-04-29 21:44 ` [PATCH v4 2/6] x86: document WC MTRR effects on PAT / non-PAT pages Luis R. Rodriguez
2015-04-30 22:01   ` Randy Dunlap
2015-05-05  0:45     ` Luis R. Rodriguez
2015-05-05  7:22       ` Borislav Petkov
2015-05-05  7:46         ` Luis R. Rodriguez
2015-05-05  7:53           ` Borislav Petkov
2015-05-05  7:31     ` Luis R. Rodriguez
2015-05-04 12:23   ` Borislav Petkov [this message]
2015-05-05  7:35     ` Luis R. Rodriguez
2015-04-29 21:44 ` [PATCH v4 3/6] video: fbdev: atyfb: move framebuffer length fudging to helper Luis R. Rodriguez
2015-04-29 21:44 ` [PATCH v4 4/6] video: fbdev: atyfb: clarify ioremap() base and length used Luis R. Rodriguez
2015-04-29 21:44 ` [PATCH v4 5/6] video: fbdev: atyfb: replace MTRR UC hole with strong UC Luis R. Rodriguez
2015-04-29 21:44 ` [PATCH v4 6/6] video: fbdev: atyfb: use arch_phys_wc_add() and ioremap_wc() Luis R. Rodriguez
2015-05-20 19:53   ` Luis R. Rodriguez
2015-05-20 20:57     ` Luis R. Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150504122303.GD4096@pd.tnic \
    --to=bp@alien8.de \
    --cc=adaplas@gmail.com \
    --cc=airlied@linux.ie \
    --cc=airlied@redhat.com \
    --cc=awalls@md.metrocast.net \
    --cc=bp@suse.de \
    --cc=cocci@systeme.lip6.fr \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dbueso@suse.de \
    --cc=dledford@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=mgorman@suse.de \
    --cc=mingo@elte.hu \
    --cc=mst@redhat.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=sbsiddha@gmail.com \
    --cc=syrjala@sci.fi \
    --cc=tglx@linutronix.de \
    --cc=tomi.valkeinen@ti.com \
    --cc=toshi.kani@hp.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).