From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add() Date: Thu, 2 Apr 2015 15:21:22 -0500 Message-ID: References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-7-git-send-email-mcgrof@do-not-panic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YdlcY-00081I-Dc for xen-devel@lists.xenproject.org; Thu, 02 Apr 2015 20:21:46 +0000 Received: by qgep97 with SMTP id p97so79264657qge.1 for ; Thu, 02 Apr 2015 13:21:43 -0700 (PDT) In-Reply-To: <1426893517-2511-7-git-send-email-mcgrof@do-not-panic.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Luis R. Rodriguez" Cc: jgross@suse.com, linux-fbdev@vger.kernel.org, "x86@kernel.org" , Suresh Siddha , Antonino Daplas , Daniel Vetter , "Luis R. Rodriguez" , venkatesh.pallipadi@intel.com, "linux-kernel@vger.kernel.org" , Andy Lutomirski , "xen-devel@lists.xenproject.org" , Ingo Molnar , Tomi Valkeinen , Jan Beulich , "H. Peter Anvin" , Dave Airlie , Thomas Gleixner , Borislav Petkov , Jean-Christophe Plagniol-Villard , Ingo Molnar List-Id: xen-devel@lists.xenproject.org On Fri, Mar 20, 2015 at 6:17 PM, Luis R. Rodriguez wrote: > From: "Luis R. Rodriguez" > > Ideally on systems using PAT we can expect a swift > transition away from MTRR. There can be a few exceptions > to this, one is where device drivers are known to exist > on PATs with errata, This probably makes sense to someone steeped in MTRR and PAT, but not otherwise. "One exception is where drivers are known to exist on PATs with errata"? The drivers exist, independent of PAT/MTRR/errata. Do you mean there are drivers that can't be converted from MTRR to PAT because some PATs are broken? I don't really know anything about MTRR or PAT; I'm just trying to figure out how to parse this paragraph. > another situation is observed on > old device drivers where devices had combined MMIO > register access with whatever area they typically > later wanted to end up using MTRR for on the same > PCI BAR. This situation can still be addressed by > splitting up ioremap'd PCI BAR into two ioremap'd > calls, one for MMIO registers, and another for whatever > is desirable for write-combining -- in order to > accomplish this though quite a bit of driver > restructuring is required. > > Device drivers which are known to require large > amount of re-work in order to split ioremap'd areas > can use __arch_phys_wc_add() to avoid regressions > when PAT is enabled. > > For a good example driver where things are neatly > split up on a PCI BAR refer the infiniband qib > driver. For a good example of a driver where good > amount of work is required refer to the infiniband > ipath driver. > > This is *only* a transitive API -- and as such no new > drivers are ever expected to use this. "transient"? Do you mean you intend to remove this API in the near future? Bjorn