From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752402AbbDBUVq (ORCPT ); Thu, 2 Apr 2015 16:21:46 -0400 Received: from mail-qg0-f43.google.com ([209.85.192.43]:33562 "EHLO mail-qg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752318AbbDBUVn (ORCPT ); Thu, 2 Apr 2015 16:21:43 -0400 MIME-Version: 1.0 In-Reply-To: <1426893517-2511-7-git-send-email-mcgrof@do-not-panic.com> References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-7-git-send-email-mcgrof@do-not-panic.com> From: Bjorn Helgaas Date: Thu, 2 Apr 2015 15:21:22 -0500 Message-ID: Subject: Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add() To: "Luis R. Rodriguez" Cc: Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , jgross@suse.com, Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , linux-fbdev@vger.kernel.org, "x86@kernel.org" , "xen-devel@lists.xenproject.org" , "Luis R. Rodriguez" , Ingo Molnar , Daniel Vetter , Antonino Daplas , Jean-Christophe Plagniol-Villard , Tomi Valkeinen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Date: Thu, 02 Apr 2015 20:21:22 +0000 Subject: Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add() Message-Id: List-Id: References: <1426893517-2511-1-git-send-email-mcgrof@do-not-panic.com> <1426893517-2511-7-git-send-email-mcgrof@do-not-panic.com> In-Reply-To: <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 To: "Luis R. Rodriguez" Cc: Andy Lutomirski , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , jgross@suse.com, Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , linux-fbdev@vger.kernel.org, "x86@kernel.org" , "xen-devel@lists.xenproject.org" , "Luis R. Rodriguez" , Ingo Molnar , Daniel Vetter , Antonino Daplas , Jean-Christophe Plagniol-Villard , Tomi Valkeinen 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