From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hanjun Guo Subject: Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Date: Thu, 04 Jun 2015 17:28:17 +0800 Message-ID: <55701A31.808@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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20150602133215.GC23650@red-moon> Sender: linux-pci-owner@vger.kernel.org To: Lorenzo Pieralisi , Tomasz Nowicki Cc: Will Deacon , Bjorn Helgaas , Arnd Bergmann , Catalin Marinas , "Rafael J. Wysocki" , Jiang Liu , Liviu Dudau , Thomas Gleixner , Yijing Wang , "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" List-Id: linux-acpi@vger.kernel.org Hi Lorenzo, On 2015=E5=B9=B406=E6=9C=8802=E6=97=A5 21:32, Lorenzo Pieralisi wrote: > On Wed, May 27, 2015 at 09:06:26AM +0100, Tomasz Nowicki wrote: >> On 26.05.2015 19:08, Will Deacon wrote: >>> On Tue, May 26, 2015 at 01:49:18PM +0100, Hanjun Guo wrote: >>>> From: Tomasz Nowicki >>>> >>>> ECAM standard and MCFG table are architecture independent and it m= akes >>>> sense to share common code across all architectures. Both are goin= g to >>>> corresponding files - ecam.c and mcfg.c >>>> >>>> While we are here, rename pci_parse_mcfg to acpi_parse_mcfg. >>>> We already have acpi_parse_mcfg prototype which is used nowhere. >>>> At the same time, we need pci_parse_mcfg been global so acpi_parse= _mcfg >>>> can be used perfectly here. >>>> >>>> Signed-off-by: Tomasz Nowicki >>>> Signed-off-by: Hanjun Guo >>>> Tested-by: Suravee Suthikulpanit >>>> --- >>>> arch/x86/Kconfig | 3 + >>>> arch/x86/include/asm/pci_x86.h | 33 ------ >>>> arch/x86/pci/acpi.c | 1 + >>>> arch/x86/pci/mmconfig-shared.c | 244 +-------------------------= -------------- >>>> arch/x86/pci/mmconfig_32.c | 1 + >>>> arch/x86/pci/mmconfig_64.c | 1 + >>>> arch/x86/pci/numachip.c | 1 + >>>> drivers/acpi/Makefile | 1 + >>>> drivers/acpi/mcfg.c | 57 ++++++++++ >>>> drivers/pci/Kconfig | 7 ++ >>>> drivers/pci/Makefile | 5 + >>>> drivers/pci/ecam.c | 245 ++++++++++++++++++++++++++= +++++++++++++++ >>> >>> Why can't we make use of the ECAM implementation used by pci-host-g= eneric >>> 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 spac= e > up and running before a bus struct is even created ? I think the reas= on is > the PCI configuration address space format (ACPI 6.0, Table 5-27, pag= e > 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: =E2=80=A2 System I/O space =E2=80=A2 System memory space =E2=80=A2 PCI configuration space =E2=80=A2 Embedded controller space =E2=80=A2 System Management Bus (SMBus) space =E2=80=A2 CMOS =E2=80=A2 PCI BAR Target =E2=80=A2 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. Thanks Hanjun