From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: plagnioj@jcrosoft.com, bp@suse.de, hpa@zytor.com,
linux-fbdev@vger.kernel.org, luto@amacapital.net,
toshi.kani@hp.com, sbsiddha@gmail.com, mingo@elte.hu,
tglx@linutronix.de, jgross@suse.com, daniel.vetter@ffwll.ch,
airlied@redhat.com, adaplas@gmail.com, robdclark@gmail.com,
jg1.han@samsung.com, wsa@the-dreams.de,
linux-kernel@vger.kernel.org,
"Luis R. Rodriguez" <mcgrof@suse.com>
Subject: Re: [PATCH v4 3/3] video: fbdev: vesafb: use arch_phys_wc_add()
Date: Fri, 12 Jun 2015 09:04:14 +0000 [thread overview]
Message-ID: <557AA08E.6050606@ti.com> (raw)
In-Reply-To: <1433436288-16792-4-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 5383 bytes --]
On 04/06/15 19:44, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This driver uses the same area for MTRR as for the ioremap_wc(), if
> anything it just uses a smaller size in case MTRR reservation fails.
> ioremap_wc() API is already used to take advantage of architecture
> write-combining when available.
>
> Convert the driver from using the x86 specific MTRR code to
> the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> will avoid MTRR if write-combining is available.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> de33c442e titled "x86 PAT: fix performance drop for glx,
> use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
>
> The conversion done is expressed by the following Coccinelle
> SmPL patch, it additionally required manual intervention to
> address all the #ifdery and removal of redundant things which
> arch_phys_wc_add() already addresses such as verbose message
> about when MTRR fails and doing nothing when we didn't get
> an MTRR.
>
> @ mtrr_found @
> expression index, base, size;
> @@
>
> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> +index = arch_phys_wc_add(base, size);
>
> @ mtrr_rm depends on mtrr_found @
> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> @@
>
> -mtrr_del(index, base, size);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_zero_arg depends on mtrr_found @
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, 0, 0);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_fb_info depends on mtrr_found @
> struct fb_info *info;
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> +arch_phys_wc_del(index);
>
> @ ioremap_replace_nocache depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap_nocache(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> @ ioremap_replace_default depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> Generated-by: Coccinelle SmPL
> Cc: Toshi Kani <toshi.kani@hp.com>
> 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: Andy Lutomirski <luto@amacapital.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
> drivers/video/fbdev/vesafb.c | 29 ++++++++---------------------
> 1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index 3db3908..528fe91 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -19,10 +19,9 @@
> #include <linux/init.h>
> #include <linux/platform_device.h>
> #include <linux/screen_info.h>
> +#include <linux/io.h>
>
> #include <video/vga.h>
> -#include <asm/io.h>
> -#include <asm/mtrr.h>
>
> #define dac_reg (0x3c8)
> #define dac_val (0x3c9)
> @@ -180,16 +179,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
>
> static void vesafb_destroy(struct fb_info *info)
> {
> -#ifdef CONFIG_MTRR
> struct vesafb_par *par = info->par;
> -#endif
>
> fb_dealloc_cmap(&info->cmap);
> -
> -#ifdef CONFIG_MTRR
> - if (par->wc_cookie >= 0)
> - mtrr_del(par->wc_cookie, 0, 0);
> -#endif
> + arch_phys_wc_del(par->wc_cookie);
> if (info->screen_base)
> iounmap(info->screen_base);
> release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
> @@ -420,7 +413,6 @@ static int vesafb_probe(struct platform_device *dev)
> request_region(0x3c0, 32, "vesafb");
>
> if (mtrr == 3) {
> -#ifdef CONFIG_MTRR
> unsigned int temp_size = size_total;
>
> /* Find the largest power-of-two */
> @@ -428,18 +420,16 @@ static int vesafb_probe(struct platform_device *dev)
>
> /* Try and find a power of two to add */
> do {
> - par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
> - temp_size,
> - MTRR_TYPE_WRCOMB, 1);
> + par->wc_cookie =
> + arch_phys_wc_add(vesafb_fix.smem_start,
> + temp_size);
> temp_size >>= 1;
> - } while (temp_size >= PAGE_SIZE && par->wc_cookie == -EINVAL);
> -#endif
> + } while (temp_size >= PAGE_SIZE && par->wc_cookie < 0);
> +
Looks like arch_phys_wc_add prints a warning if it fails, and the above
loop may retry it many (?) times. Probably not a big issue, but may be
somewhat confusing.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2015-06-12 9:04 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-04 16:44 [PATCH v4 0/3] vesafb: remove theoretical MTRR uses Luis R. Rodriguez
2015-06-04 16:44 ` [PATCH v4 1/3] video: fbdev: vesafb: only support MTRR_TYPE_WRCOMB Luis R. Rodriguez
2015-06-04 16:44 ` [PATCH v4 2/3] video: fbdev: vesafb: add missing mtrr_del() for added MTRR Luis R. Rodriguez
2015-06-04 16:44 ` [PATCH v4 3/3] video: fbdev: vesafb: use arch_phys_wc_add() Luis R. Rodriguez
2015-06-12 9:04 ` Tomi Valkeinen [this message]
2015-06-15 22:27 ` Luis R. Rodriguez
2015-06-16 6:43 ` Tomi Valkeinen
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=557AA08E.6050606@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=adaplas@gmail.com \
--cc=airlied@redhat.com \
--cc=bp@suse.de \
--cc=daniel.vetter@ffwll.ch \
--cc=hpa@zytor.com \
--cc=jg1.han@samsung.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=mingo@elte.hu \
--cc=plagnioj@jcrosoft.com \
--cc=robdclark@gmail.com \
--cc=sbsiddha@gmail.com \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--cc=wsa@the-dreams.de \
/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).