From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752022AbbCTXtL (ORCPT ); Fri, 20 Mar 2015 19:49:11 -0400 Received: from mail-lb0-f169.google.com ([209.85.217.169]:32907 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750994AbbCTXtH (ORCPT ); Fri, 20 Mar 2015 19:49:07 -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: Andy Lutomirski Date: Fri, 20 Mar 2015 16:48:46 -0700 Message-ID: Subject: Re: [PATCH v1 06/47] mtrr: add __arch_phys_wc_add() To: "Luis R. Rodriguez" Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , Linux Fbdev development list , X86 ML , "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 4: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, 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. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? If so, can we ioremap + set_page_xyz instead? --Andy From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Date: Fri, 20 Mar 2015 23:48:46 +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: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Juergen Gross , Jan Beulich , Borislav Petkov , Suresh Siddha , venkatesh.pallipadi@intel.com, Dave Airlie , "linux-kernel@vger.kernel.org" , Linux Fbdev development list , X86 ML , "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 4: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, 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. What's the exact layout that this helps? I'm sceptical that this can ever be correct. Is there some awful driver that has a large ioremap that's supposed to contain multiple different memtypes? If so, can we ioremap + set_page_xyz instead? --Andy