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: [Cocci] [PATCH v3 00/17] framebuffer: simple conversions to arch_phys_wc_add()
Date: Tue, 19 May 2015 17:58:02 +0000	[thread overview]
Message-ID: <20150519175802.GJ23057@wotan.suse.de> (raw)
In-Reply-To: <20150514142645.GU23057@wotan.suse.de>

On Thu, May 14, 2015 at 04:26:45PM +0200, Luis R. Rodriguez wrote:
> 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.

Hey folks please let me know how I can be of any help with this. Not sure
what else I can do here to help further.

  Luis

  reply	other threads:[~2015-05-19 17:58 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
2015-05-19 17:58     ` Luis R. Rodriguez [this message]
2015-05-19 22:17       ` [Cocci] " 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=20150519175802.GJ23057@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).