From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lorenzo Pieralisi Subject: Re: [PATCH 05/20] ARM: implement pci_remap_cfgspace() interface Date: Tue, 21 Mar 2017 15:26:36 +0000 Message-ID: <20170321152636.GA4799@red-moon> References: <20170227151436.18698-1-lorenzo.pieralisi@arm.com> <20170227151436.18698-6-lorenzo.pieralisi@arm.com> <20170320164354.GQ21222@n2100.armlinux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20170320164354.GQ21222@n2100.armlinux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Russell King - ARM Linux Cc: Wenrui Li , Gabriele Paoloni , linux-pci@vger.kernel.org, Shawn Lin , Will Deacon , Thierry Reding , Tanmay Inamdar , linux-arch@vger.kernel.org, Joao Pinto , Pratyush Anand , Michal Simek , Jon Mason , Murali Karicheri , Catalin Marinas , Arnd Bergmann , Bharat Kumar Gogada , Ray Jui , John Garry , Bjorn Helgaas , Mingkai Hu , linux-arm-kernel@lists.infradead.org, Thomas Petazzoni , Jingoo Han List-Id: linux-arch.vger.kernel.org Hi Russell, On Mon, Mar 20, 2017 at 04:43:55PM +0000, Russell King - ARM Linux wrote: > On Mon, Feb 27, 2017 at 03:14:16PM +0000, Lorenzo Pieralisi wrote: > > The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering > > and Posting") define rules for PCI configuration space transactions > > ordering and posting, that state that configuration writes have to > > be non-posted transactions. > > > > Current ioremap interface on ARM provides mapping functions that > > provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE > > memory type) aka posted writes, so PCI host controller drivers have > > no arch interface to remap PCI configuration space with memory > > attributes that comply with the PCI specifications for configuration > > space. > > > > Implement an ARM specific pci_remap_cfgspace() interface that allows to > > map PCI config memory regions with MT_UNCACHED memory type (ie strongly > > ordered - non-posted writes), providing a remap function that complies > > with PCI specifications for config space transactions. > > Doesn't this have the side effect that configuration writes can bypass > writes to device memory if there isn't an intervening dsb? (They > probably can do on some CPUs today anyway.) I assumed that in plain terms, the difference between MT_DEVICE and MT_UNCACHED is write posting (aka bufferable) behaviour (across CPU architecture versions) and that does not affect write ordering rules. You and Catalin have more insights into ARM 32-bit memory types so I definitely need your input here to be comprehensive and avoid pitfalls, let me know if you have some specific CPUs in mind on which this may trigger a regression. > So, in any case, this looks like an improvement: > > Acked-by: Russell King Thank you ! Lorenzo From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com ([217.140.101.70]:54388 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757923AbdCUP32 (ORCPT ); Tue, 21 Mar 2017 11:29:28 -0400 Date: Tue, 21 Mar 2017 15:26:36 +0000 From: Lorenzo Pieralisi Subject: Re: [PATCH 05/20] ARM: implement pci_remap_cfgspace() interface Message-ID: <20170321152636.GA4799@red-moon> References: <20170227151436.18698-1-lorenzo.pieralisi@arm.com> <20170227151436.18698-6-lorenzo.pieralisi@arm.com> <20170320164354.GQ21222@n2100.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170320164354.GQ21222@n2100.armlinux.org.uk> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Russell King - ARM Linux Cc: linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Arnd Bergmann , Will Deacon , Catalin Marinas , Pratyush Anand , Jingoo Han , Bjorn Helgaas , Mingkai Hu , John Garry , Tanmay Inamdar , Murali Karicheri , Bharat Kumar Gogada , Ray Jui , Wenrui Li , Shawn Lin , Minghuan Lian , Jon Mason , Gabriele Paoloni , Thomas Petazzoni , Joao Pinto , Thierry Reding , Michal Simek , Stanimir Varbanov , Zhou Wang , Roy Zang Message-ID: <20170321152636.DXLIeymLeItGMBn6F5E-kGrgvDhaMGU-qrHX5C8JeOA@z> Hi Russell, On Mon, Mar 20, 2017 at 04:43:55PM +0000, Russell King - ARM Linux wrote: > On Mon, Feb 27, 2017 at 03:14:16PM +0000, Lorenzo Pieralisi wrote: > > The PCI bus specifications (rev 3.0, 3.2.5 "Transaction Ordering > > and Posting") define rules for PCI configuration space transactions > > ordering and posting, that state that configuration writes have to > > be non-posted transactions. > > > > Current ioremap interface on ARM provides mapping functions that > > provide "bufferable" writes transactions (ie ioremap uses MT_DEVICE > > memory type) aka posted writes, so PCI host controller drivers have > > no arch interface to remap PCI configuration space with memory > > attributes that comply with the PCI specifications for configuration > > space. > > > > Implement an ARM specific pci_remap_cfgspace() interface that allows to > > map PCI config memory regions with MT_UNCACHED memory type (ie strongly > > ordered - non-posted writes), providing a remap function that complies > > with PCI specifications for config space transactions. > > Doesn't this have the side effect that configuration writes can bypass > writes to device memory if there isn't an intervening dsb? (They > probably can do on some CPUs today anyway.) I assumed that in plain terms, the difference between MT_DEVICE and MT_UNCACHED is write posting (aka bufferable) behaviour (across CPU architecture versions) and that does not affect write ordering rules. You and Catalin have more insights into ARM 32-bit memory types so I definitely need your input here to be comprehensive and avoid pitfalls, let me know if you have some specific CPUs in mind on which this may trigger a regression. > So, in any case, this looks like an improvement: > > Acked-by: Russell King Thank you ! Lorenzo