From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030245AbbF0ASZ (ORCPT ); Fri, 26 Jun 2015 20:18:25 -0400 Received: from gate.crashing.org ([63.228.1.57]:52440 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752184AbbF0ASP (ORCPT ); Fri, 26 Jun 2015 20:18:15 -0400 Message-ID: <1435362871.26815.24.camel@kernel.crashing.org> Subject: Re: [Xen-devel] [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants From: Benjamin Herrenschmidt To: "Luis R. Rodriguez" Cc: Thomas Gleixner , Dave Airlie , "Michael S. Tsirkin" , Andy Lutomirski , Bjorn Helgaas , Suresh Siddha , Ingo Molnar , Antonino Daplas , "linux-pci@vger.kernel.org" , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , "linux-kernel@vger.kernel.org" , Daniel Vetter , ville.syrjala@linux.intel.com, "venkatesh.pallipadi@intel.com" , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Dave Hansen , linux-fbdev , David Vrabel , Casey Leedom , Juergen Gross , Toshi Kani , "xen-devel@lists.xensource.com" , Stefan Bader , Arnd Bergmann , Jan Beulich Date: Sat, 27 Jun 2015 09:54:31 +1000 In-Reply-To: References: <1434751712-24333-1-git-send-email-mcgrof@do-not-panic.com> <1435189081.3790.24.camel@kernel.crashing.org> <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com> <6806026.xb91q6Ad7G@wuerfel> <4985EFDD773FCB459EF7915D2A3621ADC031F8@nice.asicdesigners.com> <1435272718.3822.7.camel@kernel.crashing.org> <20150626193158.GJ3005@wotan.suse.de> <1435356258.26815.13.camel@kernel.crashing.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote: > > It wasn't nullified for the main user at the time, the fb. And I > > mentioned an IB adapter or two for which the code had been hand > tuned. > > This still means there could be some affected drivers when used on > powerpc, no? Yes. In fact what about things like ARM who also have barriers in their writel() ? Won't they also break WC ? I'm trying to work with the architect and designers here to figure out exactly where we stand and what we can do. As spelled out by our architecture, things don't look great, because basically, we only have attribute bit (garded) which when not set implies both WC and out of order (& prefetch), and unclear barrier semantics in that case as well. I *think* we might be able to settle with something along the lines of "writel_relaxed() will allow combine on a WC mapping" but how I'm going to get there is TBD. It would be interesting to clarify the semantics of using the relaxed accessors in combination with WC anyway. I wouldn't mind if the definition involved also relaxing general ordering :-) It would definitely make my life easier. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Fri, 26 Jun 2015 23:54:31 +0000 Subject: Re: [Xen-devel] [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants Message-Id: <1435362871.26815.24.camel@kernel.crashing.org> List-Id: References: <1434751712-24333-1-git-send-email-mcgrof@do-not-panic.com> <1435189081.3790.24.camel@kernel.crashing.org> <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com> <6806026.xb91q6Ad7G@wuerfel> <4985EFDD773FCB459EF7915D2A3621ADC031F8@nice.asicdesigners.com> <1435272718.3822.7.camel@kernel.crashing.org> <20150626193158.GJ3005@wotan.suse.de> <1435356258.26815.13.camel@kernel.crashing.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "Luis R. Rodriguez" Cc: Thomas Gleixner , Dave Airlie , "Michael S. Tsirkin" , Andy Lutomirski , Bjorn Helgaas , Suresh Siddha , Ingo Molnar , Antonino Daplas , "linux-pci@vger.kernel.org" , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , "linux-kernel@vger.kernel.org" , Daniel Vetter , ville.syrjala@linux.intel.com, "venkatesh.pallipadi@intel.com" , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Dave Hansen , linux-fbdev , David Vrabel , Casey Leedom , Juergen Gross , Toshi Kani , "xen-devel@lists.xensource.com" , Stefan Bader , Arnd Bergmann , Jan Beulich On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote: > > It wasn't nullified for the main user at the time, the fb. And I > > mentioned an IB adapter or two for which the code had been hand > tuned. > > This still means there could be some affected drivers when used on > powerpc, no? Yes. In fact what about things like ARM who also have barriers in their writel() ? Won't they also break WC ? I'm trying to work with the architect and designers here to figure out exactly where we stand and what we can do. As spelled out by our architecture, things don't look great, because basically, we only have attribute bit (garded) which when not set implies both WC and out of order (& prefetch), and unclear barrier semantics in that case as well. I *think* we might be able to settle with something along the lines of "writel_relaxed() will allow combine on a WC mapping" but how I'm going to get there is TBD. It would be interesting to clarify the semantics of using the relaxed accessors in combination with WC anyway. I wouldn't mind if the definition involved also relaxing general ordering :-) It would definitely make my life easier. Cheers, Ben. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH v7 5/9] PCI: Add pci_iomap_wc() variants Date: Sat, 27 Jun 2015 09:54:31 +1000 Message-ID: <1435362871.26815.24.camel@kernel.crashing.org> References: <1434751712-24333-1-git-send-email-mcgrof@do-not-panic.com> <1435189081.3790.24.camel@kernel.crashing.org> <4985EFDD773FCB459EF7915D2A3621ADC02F10@nice.asicdesigners.com> <6806026.xb91q6Ad7G@wuerfel> <4985EFDD773FCB459EF7915D2A3621ADC031F8@nice.asicdesigners.com> <1435272718.3822.7.camel@kernel.crashing.org> <20150626193158.GJ3005@wotan.suse.de> <1435356258.26815.13.camel@kernel.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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: linux-fbdev , "Michael S. Tsirkin" , "linux-pci@vger.kernel.org" , Dave Hansen , Jan Beulich , ville.syrjala@linux.intel.com, "xen-devel@lists.xensource.com" , Arnd Bergmann , Tomi Valkeinen , Daniel Vetter , Dave Airlie , Ingo Molnar , Jean-Christophe Plagniol-Villard , Casey Leedom , Antonino Daplas , Suresh Siddha , Stefan Bader , Bjorn Helgaas , Thomas Gleixner , Juergen Gross , Toshi Kani , "linux-kernel@vger.kernel.org" List-Id: xen-devel@lists.xenproject.org On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote: > > It wasn't nullified for the main user at the time, the fb. And I > > mentioned an IB adapter or two for which the code had been hand > tuned. > > This still means there could be some affected drivers when used on > powerpc, no? Yes. In fact what about things like ARM who also have barriers in their writel() ? Won't they also break WC ? I'm trying to work with the architect and designers here to figure out exactly where we stand and what we can do. As spelled out by our architecture, things don't look great, because basically, we only have attribute bit (garded) which when not set implies both WC and out of order (& prefetch), and unclear barrier semantics in that case as well. I *think* we might be able to settle with something along the lines of "writel_relaxed() will allow combine on a WC mapping" but how I'm going to get there is TBD. It would be interesting to clarify the semantics of using the relaxed accessors in combination with WC anyway. I wouldn't mind if the definition involved also relaxing general ordering :-) It would definitely make my life easier. Cheers, Ben.