From patchwork Mon Dec 9 13:05:40 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 22185 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-yh0-f69.google.com (mail-yh0-f69.google.com [209.85.213.69]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 72CAB23FBA for ; Mon, 9 Dec 2013 13:07:07 +0000 (UTC) Received: by mail-yh0-f69.google.com with SMTP id a41sf7974786yho.0 for ; Mon, 09 Dec 2013 05:07:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe:content-type :content-transfer-encoding; bh=528/wrX8sn/USyGQgVmbsVlM7cRNK2MaQx09b9YdHZk=; b=joqqsDsjE+ZuP243C64flp31XOMkuU/2ujfjp97yLiBetAlj+I+WmEBv45tk/3hKyf SLtYk48N9QNHHIOADhUznFWpZYgnsQwD1f4IosCRq7KL0d5aO5Xm6TOFNv1iFDW8lhIe La4sHwJlR3yl9nWmlb2MpJSMROdAc+2N2TiG9wTD3yG77DwHb1HtuxgItxQaei+GE51j Em+RiIDDZPeNQVcWUiqDmPFDLCSaBMHuF8nb8bw+gufPVU8Kuxf0UBFy5duGUCtQPMjN 9tiAgL3piK/vLJrPIMd7pT4cxR+0EQMuZYPSvSuHS41yp+ysoFu3zALa3ABq4EPMFFmR oBpg== X-Gm-Message-State: ALoCoQncvR3QrycRrdBUWFrTveqcZuqpySqoQlydjo1YQp/4qiQ1GbBAwEzlcDnR9i4yaBLU6JCI X-Received: by 10.236.127.199 with SMTP id d47mr41903586yhi.29.1386594426834; Mon, 09 Dec 2013 05:07:06 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.85.162 with SMTP id i2ls2006722qez.39.gmail; Mon, 09 Dec 2013 05:07:06 -0800 (PST) X-Received: by 10.221.40.10 with SMTP id to10mr1623705vcb.22.1386594426624; Mon, 09 Dec 2013 05:07:06 -0800 (PST) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by mx.google.com with ESMTPS id bq2si3801532vcb.115.2013.12.09.05.07.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 05:07:06 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.179 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.179; Received: by mail-ve0-f179.google.com with SMTP id jw12so3478179veb.38 for ; Mon, 09 Dec 2013 05:07:06 -0800 (PST) X-Received: by 10.220.58.1 with SMTP id e1mr11108344vch.0.1386594426469; Mon, 09 Dec 2013 05:07:06 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patches@linaro.org Received: by 10.220.174.196 with SMTP id u4csp105268vcz; Mon, 9 Dec 2013 05:07:05 -0800 (PST) X-Received: by 10.68.130.234 with SMTP id oh10mr20812733pbb.0.1386594425402; Mon, 09 Dec 2013 05:07:05 -0800 (PST) Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by mx.google.com with ESMTPS id ws5si7277416pab.93.2013.12.09.05.07.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 05:07:05 -0800 (PST) Received-SPF: neutral (google.com: 209.85.192.182 is neither permitted nor denied by best guess record for domain of hanjun.guo@linaro.org) client-ip=209.85.192.182; Received: by mail-pd0-f182.google.com with SMTP id v10so5265540pde.27 for ; Mon, 09 Dec 2013 05:07:05 -0800 (PST) X-Received: by 10.66.189.229 with SMTP id gl5mr4222886pac.47.1386594424889; Mon, 09 Dec 2013 05:07:04 -0800 (PST) Received: from [192.168.204.184] ([218.17.215.175]) by mx.google.com with ESMTPSA id vh3sm17999953pbc.8.2013.12.09.05.05.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 05:07:03 -0800 (PST) Message-ID: <52A5C024.5050702@linaro.org> Date: Mon, 09 Dec 2013 21:05:40 +0800 From: Hanjun Guo User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Catalin Marinas CC: Arnd Bergmann , Tomasz Nowicki , Mark Rutland , Matthew Garrett , "linaro-kernel@lists.linaro.org" , Russell King - ARM Linux , "patches@linaro.org" , Olof Johansson , Linus Walleij , Daniel Lezcano , "Rafael J. Wysocki" , "linux-kernel@vger.kernel.org" , Will Deacon , "linaro-acpi@lists.linaro.org" , "linux-acpi@vger.kernel.org" , "rob.herring@calxeda.com" , Bjorn Helgaas , "linux-arm-kernel@lists.infradead.org" Subject: Re: [Linaro-acpi] [RFC part1 PATCH 1/7] ACPI: Make ACPI core running without PCI on ARM64 References: <1386088611-2801-1-git-send-email-hanjun.guo@linaro.org> <201312052304.22302.arnd@arndb.de> <52A1E794.1040008@linaro.org> <201312061823.26481.arnd@arndb.de> <52A54328.3000709@linaro.org> <20131209115050.GA19163@arm.com> In-Reply-To: <20131209115050.GA19163@arm.com> X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: hanjun.guo@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.179 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Precedence: list Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org List-ID: X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 2013-12-9 19:50, Catalin Marinas wrote: > On Mon, Dec 09, 2013 at 04:12:24AM +0000, Hanjun Guo wrote: >> On 2013-12-7 1:23, Arnd Bergmann wrote: >>> On Friday 06 December 2013, Tomasz Nowicki wrote: >>>> On 05.12.2013 23:04, Arnd Bergmann wrote: >>>>> On Wednesday 04 December 2013, Hanjun Guo wrote: >>>>>> On 2013年12月04日 00:41, Matthew Garrett wrote: >>>>>>> Given the number of #ifdefs you're adding, wouldn't it make more sense >>>>>>> to just add stub functions to include/linux/pci.h? >>>>>> >>>>>> Thanks for the suggestion :) >>>>>> >>>>>> I can add stub functions in include/linux/pci.h for raw_pci_read()/ >>>>>> raw_pci_write(), then can remove #ifdefs for acpi_os_read/write_pci_configuration(). >>>>> >>>>> Actually I wonder about the usefulness of this patch in either form: Since ACPI >>>>> on ARM64 is only for servers, I would very much expect them to always come with >>>>> PCI, either physical host bridges with attached devices, or logical PCI functions >>>>> used to describe the on-SoC I/O devices. Even in case of virtual machines, you'd >>>>> normally use PCI as the method to communicate data about the virtio channels. >>>>> >>>>> Can you name a realistic use-case where you'd want ACPI but not PCI? >>>> >>>> Yes you can describe SoC I/O devices using logical PCI functions only if >>>> they are on PCI, correct me if I am wrong. Also, devices can be placed >>>> only on IOMEM (like for ARM SoC) and it is hard to predict which way >>>> vendors chose. So way don't let it be configurable? ACPI spec says >>>> nothing like PCI is needed for ACPI, AFAIK. >>> >>> You are right that today's ARM SoCs basically never use PCI to describe >>> internal devices (IIRC VIA VT8500 is an exception, but their PCI was >>> just a software fabrication). >>> >>> However, when we're talking about ACPI on ARM64, that is nothing like classic >>> ARM SoCs: As Jon Masters mentioned, this is about new server hardware following >>> a (still secret, but hopefully not much longer) hardware specification that is >>> explicitly designed to allow interoperability between vendors, so they >>> must have put some thought into how to make the hardware discoverable. It >>> seems that they are modeling things after how it's done on x86, and the >>> only sensible way to have discoverable hardware there is PCI. This is >>> also what all x86 SoCs do. >> >> I think the concern here is that ACPI is only for server platform or not. >> >> Since ACPI has lots of content related to power management, I think ACPI >> can be used for mobile devices and other platform too, not only for ARM >> servers, and with this patch, we can support both requirement. > > 'Can be used' is one thing, will it really be used is another? I don't > think so, it was (well, is) difficult enough to make the transition to > FDT, I don't see how ACPI would solve the current issues. > > I see ACPI as a server distro requirement and there are indeed benefits > in abstracting the hardware behind standard description, AML. Of course, > this would work even better with probe-able buses like PCIe and I'm > pretty sure this would be the case on high-end servers. But even if a > server distro like RHEL supports a SoC without PCIe, I would expect them > to only provide a single binary Image with CONFIG_PCI enabled. > > This patch is small enough and allows ACPI build with !CONFIG_PCI for > the time being but longer term I would expect such SoCs without PCI to > be able to run on a kernel with CONFIG_PCI enabled. Yes, we will support PCI in ACPI in the long run, and we just make PCI optional for ACPI in this patch. Actually, I had reworked this patch and make the code with minimal changes to ACPI code: Not all the ARM64 targets that are using ACPI have PCI, so introduce some stub functions to make ACPI core run without CONFIG_PCI on ARM64. pcibios_penalize_isa_irq() is arch dependent, introduce asm/pci.h to include it. Since ACPI on X86 and IA64 depends on PCI, it will not break X86 and IA64 with this patch. Signed-off-by: Graeme Gregory Signed-off-by: Al Stone Signed-off-by: Hanjun Guo --- arch/arm64/include/asm/pci.h | 13 +++++++++++++ drivers/acpi/Makefile | 2 +- drivers/acpi/internal.h | 5 +++++ include/linux/pci.h | 32 +++++++++++++++++++++++--------- 4 files changed, 42 insertions(+), 10 deletions(-) create mode 100644 arch/arm64/include/asm/pci.h -- Hanjun diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h new file mode 100644 index 0000000..e682c25 --- /dev/null +++ b/arch/arm64/include/asm/pci.h @@ -0,0 +1,13 @@ +#ifndef ASMARM_PCI_H +#define ASMARM_PCI_H + +#ifdef __KERNEL__ + +static inline void pcibios_penalize_isa_irq(int irq, int active) +{ + /* We don't do dynamic PCI IRQ allocation */ +} + +#endif /* __KERNEL__ */ + +#endif diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index 0331f91..d8cebe3 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -38,7 +38,7 @@ acpi-y += acpi_processor.o acpi-y += processor_core.o acpi-y += ec.o acpi-$(CONFIG_ACPI_DOCK) += dock.o -acpi-y += pci_root.o pci_link.o pci_irq.o +acpi-$(CONFIG_PCI) += pci_root.o pci_link.o pci_irq.o acpi-$(CONFIG_X86_INTEL_LPSS) += acpi_lpss.o acpi-y += acpi_platform.o acpi-y += power.o diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h index b125fdb..b1ef8fa 100644 --- a/drivers/acpi/internal.h +++ b/drivers/acpi/internal.h @@ -26,8 +26,13 @@ acpi_status acpi_os_initialize1(void); int init_acpi_device_notify(void); int acpi_scan_init(void); +#ifdef CONFIG_PCI void acpi_pci_root_init(void); void acpi_pci_link_init(void); +#else +static inline void acpi_pci_root_init(void) {} +static inline void acpi_pci_link_init(void) {} +#endif /* CONFIG_PCI */ void acpi_processor_init(void); void acpi_platform_init(void); int acpi_sysfs_init(void); diff --git a/include/linux/pci.h b/include/linux/pci.h index 1084a15..28334dd 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -541,15 +541,6 @@ struct pci_ops { int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val); }; -/* - * ACPI needs to be able to access PCI config space before we've done a - * PCI bus scan and created pci_bus structures. - */ -int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn, - int reg, int len, u32 *val); -int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn, - int reg, int len, u32 val); - struct pci_bus_region { resource_size_t start; resource_size_t end; @@ -1280,6 +1271,15 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode, unsigned int command_bits, u32 flags); void pci_register_set_vga_state(arch_set_vga_state_t func); +/* + * ACPI needs to be able to access PCI config space before we've done a + * PCI bus scan and created pci_bus structures. + */ +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn, + int reg, int len, u32 *val); +int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn, + int reg, int len, u32 val); + #else /* CONFIG_PCI is not enabled */ /* @@ -1476,6 +1476,20 @@ static inline int pci_domain_nr(struct pci_bus *bus) static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; } +static inline struct pci_bus *pci_find_bus(int domain, int busnr) +{ return NULL; } + +static inline int pci_bus_write_config_byte(struct pci_bus *bus, + unsigned int devfn, int where, u8 val); +{ return -ENODEV; } + +static inline int raw_pci_read(unsigned int domain, unsigned int bus, + unsigned int devfn, int reg, int len, u32 *val); +{ return -EINVAL; } +static inline int raw_pci_write(unsigned int domain, unsigned int bus, + unsigned int devfn, int reg, int len, u32 val); +{return -EINVAL; } + #define dev_is_pci(d) (false) #define dev_is_pf(d) (false) #define dev_num_vf(d) (0)