From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Nowicki Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Date: Mon, 7 Sep 2015 11:59:44 +0200 Message-ID: <55ED6010.3020406@linaro.org> References: <1432644564-24746-1-git-send-email-hanjun.guo@linaro.org> <1432644564-24746-6-git-send-email-hanjun.guo@linaro.org> <20150526170817.GU1565@arm.com> <55657B02.5090805@linaro.org> <20150602133215.GC23650@red-moon> <55701A31.808@linaro.org> <20150604102253.GA31773@red-moon> <5570447D.3020705@linaro.org> <557504A2.3060203@linaro.org> <20150608151443.GA16151@red-moon> <55E4340D.6050004@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-lb0-f182.google.com ([209.85.217.182]:34842 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751915AbbIGJ7s (ORCPT ); Mon, 7 Sep 2015 05:59:48 -0400 Received: by lbpo4 with SMTP id o4so36761503lbp.2 for ; Mon, 07 Sep 2015 02:59:47 -0700 (PDT) In-Reply-To: <55E4340D.6050004@linaro.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Lorenzo Pieralisi , Bjorn Helgaas , "Rafael J. Wysocki" Cc: Hanjun Guo , Liviu Dudau , Yijing Wang , Will Deacon , Arnd Bergmann , Catalin Marinas , Jiang Liu , Thomas Gleixner , "suravee.suthikulpanit@amd.com" , "msalter@redhat.com" , "linux-pci@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linaro-acpi@lists.linaro.org" On 31.08.2015 13:01, Tomasz Nowicki wrote: > On 08.06.2015 17:14, Lorenzo Pieralisi wrote: >> On Mon, Jun 08, 2015 at 03:57:38AM +0100, Hanjun Guo wrote: >> >> [...] >> >>>>>>>>> Why can't we make use of the ECAM implementation used by >>>>>>>>> pci-host-generic >>>>>>>>> and drivers/pci/access.c? >>>>>>>> >>>>>>>> We had that question when I had posted MMCFG patch set separately, >>>>>>>> please see: >>>>>>>> https://lkml.org/lkml/2015/3/11/492 >>>>>>> >>>>>>> Yes, but the real question is, why do we need to have PCI config >>>>>>> space >>>>>>> up and running before a bus struct is even created ? I think the >>>>>>> reason is >>>>>>> the PCI configuration address space format (ACPI 6.0, Table 5-27, >>>>>>> page >>>>>>> 108): >>>>>>> >>>>>>> "PCI Configuration space addresses must be confined to devices on >>>>>>> PCI Segment Group 0, bus 0. This restriction exists to accommodate >>>>>>> access to fixed hardware prior to PCI bus enumeration". >>>>>>> >>>>>>> On HW reduced platforms I do not even think this is required at all, >>>>>>> we have to look into this to avoid code duplication that might well >>>>>>> turn out useless. >>>>>> >>>>>> This is only for the fixed hardware, which will be not available for >>>>>> ARM64 (reduced hardware mode), but in Generic Hardware Programming >>>>>> Model, we using OEM-provided ACPI Machine Language (AML) code to >>>>>> access >>>>>> generic hardware registers, this will be available for reduced >>>>>> hardware >>>>>> too. >>>>>> >>>>>> So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph) >>>>>> >>>>>> ACPI defines eight address spaces that may be accessed by generic >>>>>> hardware implementations. These include: >>>>>> * System I/O space >>>>>> * System memory space >>>>>> * PCI configuration space >>>>>> * Embedded controller space >>>>>> * System Management Bus (SMBus) space >>>>>> * CMOS >>>>>> * PCI BAR Target >>>>>> * IPMI space >>>>>> >>>>>> So if any device using the PCI address space for control, such >>>>>> as a system reset control device, its address space can be reside >>>>>> in PCI configuration space (who can prevent a OEM do that crazy >>>>>> thing? :) ), and it should be accessible before the PCI bus is >>>>>> created. >>>>> >>>>> Us, by changing attitude and questioning features whose usefulness >>>>> is questionable. I will look into this and raise the point, I am not >>>>> thrilled by the idea of adding another set of PCI accessor functions >>>>> and drivers because we have to access a register through PCI before >>>>> enumerating the bus (and on arm64 this is totally useless since >>>>> we are not meant to support fixed HW anyway). Maybe we can make acpica >>>>> code use a "special" stub (ACPI specific, PCI configuration space >>>>> address >>>>> space has restrictions anyway), I have to review this set in its >>>>> entirety to see how to do that (and I would kindly ask you to do >>>>> it too, before saying it is not possible to implement it). >>>> >>>> I'm willing to do that, actually, if we don't need a mechanism to >>>> access PCI config space before the bus is created, the code can be >>>> simplified a lot. >>> >>> After more investigation on the spec and the ACPI core code, I'm >>> still not convinced that accessing to PCI config space before PCI >>> bus creating is impossible, also there is no enough ARM64 hardware >>> to prove that too. But I think we can go in this way, reuse the >>> ECAM implementation by pci-host-generic for now, and implement the PCI >>> accessor functions before enumerating PCI bus when needed in the >>> future, does it make sense? >> >> You mean we rewrite the patch to make sure we can use the PCI host >> generic >> driver with MCFG and we leave the acpica PCI config call empty stubs on >> arm64 (as they are now) ? >> > > Hi Bjorn, Rafael, > > Lorenzo pointed out very important problem we are having with PCI config > space access for ARM64. Please refer to the above discussion and add > your 2 cents. Can we forget about accessing PCI config space (for > Hardware Reduced profile) before PCI bus creation? If not, do you see a > way to use drivers/pci/access.c accessors here, like acpica change? Any > opinion is very appreciated. > Kindly remainder. Thanks, Tomasz