linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@suse.com>
To: cocci@systeme.lip6.fr
Subject: Re: [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
Date: Thu, 14 May 2015 14:26:45 +0000	[thread overview]
Message-ID: <20150514142645.GU23057@wotan.suse.de> (raw)
In-Reply-To: <CALCETrVdAG1NFA_dYHhOyCbwKR3msHZaaVs0MZMkW33_Sw=Kqg@mail.gmail.com>

On Tue, May 05, 2015 at 06:47:31AM -0700, Andy Lutomirski wrote:
> On Mon, May 4, 2015 at 3:33 AM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > On 29/04/15 22:18, Luis R. Rodriguez wrote:
> >> On Tue, Apr 21, 2015 at 1:16 PM, Luis R. Rodriguez
> >> <mcgrof@do-not-panic.com> wrote:
> >>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>>
> >>> This series addresses simple changes to framebuffer drivers to use
> >>> arch_phys_wc_add() and ioremap_wc() as well as fixing gbefb to add
> >>> missing mtrr_del() calls. These changes are pretty straight forward.
> >>>
> >>> Luis R. Rodriguez (17):
> >>>   video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: gbefb: add missing mtrr_del() calls
> >>>   video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc()
> >>>   video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: matrox: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: neofb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: nvidia: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: savagefb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: sisfb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: aty: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: i810: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: pm2fb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: pm3fb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: rivafb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: tdfxfb: use arch_phys_wc_add() and ioremap_wc()
> >>>   video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer
> >>>   video: fbdev: geode gxfb: use ioremap_wc() for framebuffer
> >>
> >> Hey folks, these are all pretty straight forward, can anyone take them?
> >
> > I can take these to fbdev tree. Unfortunately I'm not familiar with x86
> > nor mtrr, so I can't really say much about the patches themselves.
> >
> 
> I'm on vacation and there's no way I'll be able to usefully review
> these in the next two weeks.  I can describe what's going on in case
> it helps:
> 
> On x86 there are two ways to get a write-combining MMIO mapping.  The
> sane way is ioremap_wc, and the ridiculous way is mtrr_add.
> ioremap_wc does exactly what it appears to do, whereas mtrr_add acts
> on physical addresses, requires power-of-two alignment, and is
> unreliable.
> 
> On all recent hardware, ioremap_wc works, and mtrr_add is problematic
> on all hardware even if it often works.  The silly thing is that
> mtrr_add pokes at the registers it uses even on hardware with working
> ioremap_wc.  This causes problems (those resources are a very limited
> resource).
> 
> The solution I came up with a couple years ago is a new API
> arch_phys_wc_add.  It is a hint that a physical address range should
> be write-combining.  On hardware with working ioremap_wc, it's a
> no-op.  On x86 hardware without working ioremap_wc, it just calls
> mtrr_add.
> 
> The upshot is that changing mtrr_add with a WC type to
> arch_phys_wc_add is OK as long as the driver also uses ioremap_wc or
> similar _wc APIs.  Once everything has been converted, we can unexport
> mtrr_add, which will have all kinds of benefits.

Tomi,

Any chance you can consider this series again? I realize you say you are
not familiar with MTRR but given its prevalence use on framebuffer device
drivers and since you are a framebuffer subsystem maintainer I think its
perhaps fair to ask one of you become familiar with this stuff, or ask
questions if there are any. If its of any help this patch which adds
ioremap_uc() already got merged and the logic to phase MTRR is described
there too:

https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?idäb6be33c28923d8cde53023e0888b1c5d1a9027

That patch won't even be needed on this series, this series happens to be
straight forward: if you just ioremap_nocache() once and use mtrr_add()
then conver over to ioremap_wc() and use arch_phys_wc_add(). If it already
used ioremap_wc() just convert over from mtrr_add() to arch_phys_wc_add()

Not sure if you will get an Acked-by by x86 folks on this series as they
are busy, but I'm adding bp and hpa just in case.

  Luis

  reply	other threads:[~2015-05-14 14:26 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-21 20:16 [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add() Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 01/17] video: fbdev: radeonfb: use arch_phys_wc_add() and ioremap_wc() Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 02/17] video: fbdev: gbefb: add missing mtrr_del() calls Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 03/17] video: fbdev: gbefb: use arch_phys_wc_add() and devm_ioremap_wc() Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 04/17] video: fbdev: intelfb: use arch_phys_wc_add() and ioremap_wc() Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 05/17] video: fbdev: matrox: " Luis R. Rodriguez
2015-04-23  8:20   ` Julia Lawall
2015-04-23 16:46     ` Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 06/17] video: fbdev: neofb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 07/17] video: fbdev: nvidia: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 08/17] video: fbdev: savagefb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 09/17] video: fbdev: sisfb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 10/17] video: fbdev: aty: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 11/17] video: fbdev: i810: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 12/17] video: fbdev: pm2fb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 13/17] video: fbdev: pm3fb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 14/17] video: fbdev: rivafb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 15/17] video: fbdev: tdfxfb: " Luis R. Rodriguez
2015-04-21 20:16 ` [PATCH v3 16/17] video: fbdev: atmel_lcdfb: use ioremap_wc() for framebuffer Luis R. Rodriguez
2015-04-22  7:34   ` Nicolas Ferre
2015-04-21 20:16 ` [PATCH v3 17/17] video: fbdev: geode gxfb: " Luis R. Rodriguez
2015-04-29 19:18 ` [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add() Luis R. Rodriguez
2015-05-04 10:33 ` Tomi Valkeinen
2015-05-05  0:22   ` Luis R. Rodriguez
2015-05-05 13:47 ` Andy Lutomirski
2015-05-14 14:26   ` Luis R. Rodriguez [this message]
2015-05-19 17:58     ` [Cocci] " Luis R. Rodriguez
2015-05-19 22:17       ` Dave Airlie
2015-05-20  8:45       ` Tomi Valkeinen
2015-05-20  8:50 ` Tomi Valkeinen
2015-05-20 18:58   ` 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=20150514142645.GU23057@wotan.suse.de \
    --to=mcgrof@suse.com \
    --cc=cocci@systeme.lip6.fr \
    /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).