From: Hanjun Guo <hanjun.guo@linaro.org>
To: Jiang Liu <jiang.liu@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Bjorn Helgaas <bhelgaas@google.com>,
Marc Zyngier <marc.zyngier@arm.com>,
Yijing Wang <wangyijing@huawei.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Yinghai Lu <yinghai@kernel.org>
Cc: Lv Zheng <lv.zheng@intel.com>,
"lenb @ kernel . org" <lenb@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
"x86 @ kernel . org" <x86@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org
Subject: Re: [Patch v3 2/7] ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge
Date: Fri, 22 May 2015 21:42:23 +0800 [thread overview]
Message-ID: <555F323F.3020107@linaro.org> (raw)
In-Reply-To: <1431593803-5213-3-git-send-email-jiang.liu@linux.intel.com>
On 2015年05月14日 16:56, Jiang Liu wrote:
> Use common ACPI resource parsing interface to parse ACPI resources for
> PCI host bridge, so we could share more code between IA64 and x86.
> Later we will consolidate arch specific implementations into ACPI core.
>
> Tested-by: Tony Luck <tony.luck@intel.com>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
> arch/ia64/pci/pci.c | 414 ++++++++++++++++++++++++---------------------------
> 1 file changed, 193 insertions(+), 221 deletions(-)
>
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index d4e162d35b34..23689d4c37ae 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -115,29 +115,12 @@ struct pci_ops pci_root_ops = {
> .write = pci_write,
> };
>
> -/* Called by ACPI when it finds a new root bus. */
> -
> -static struct pci_controller *alloc_pci_controller(int seg)
> -{
> - struct pci_controller *controller;
> -
> - controller = kzalloc(sizeof(*controller), GFP_KERNEL);
> - if (!controller)
> - return NULL;
> -
> - controller->segment = seg;
> - return controller;
> -}
> -
> struct pci_root_info {
> + struct pci_controller controller;
> struct acpi_device *bridge;
> - struct pci_controller *controller;
> struct list_head resources;
> - struct resource *res;
> - resource_size_t *res_offset;
> - unsigned int res_num;
> struct list_head io_resources;
> - char *name;
> + char name[16];
> };
>
> static unsigned int
> @@ -168,11 +151,11 @@ new_space (u64 phys_base, int sparse)
> return i;
> }
>
> -static u64 add_io_space(struct pci_root_info *info,
> - struct acpi_resource_address64 *addr)
> +static int add_io_space(struct device *dev, struct pci_root_info *info,
> + struct resource_entry *entry)
> {
> struct iospace_resource *iospace;
> - struct resource *resource;
> + struct resource *resource, *res = entry->res;
> char *name;
> unsigned long base, min, max, base_port;
> unsigned int sparse = 0, space_nr, len;
> @@ -180,27 +163,24 @@ static u64 add_io_space(struct pci_root_info *info,
> len = strlen(info->name) + 32;
> iospace = kzalloc(sizeof(*iospace) + len, GFP_KERNEL);
> if (!iospace) {
> - dev_err(&info->bridge->dev,
> - "PCI: No memory for %s I/O port space\n",
> - info->name);
> - goto out;
> + dev_err(dev, "PCI: No memory for %s I/O port space\n",
> + info->name);
> + return -ENOMEM;
> }
>
> - name = (char *)(iospace + 1);
> -
> - min = addr->address.minimum;
> - max = min + addr->address.address_length - 1;
> - if (addr->info.io.translation_type == ACPI_SPARSE_TRANSLATION)
> + if (res->flags & IORESOURCE_IO_SPARSE)
> sparse = 1;
> -
> - space_nr = new_space(addr->address.translation_offset, sparse);
> + space_nr = new_space(entry->offset, sparse);
> if (space_nr == ~0)
> goto free_resource;
>
> + name = (char *)(iospace + 1);
> + min = res->start - entry->offset;
> + max = res->end - entry->offset;
> base = __pa(io_space[space_nr].mmio_base);
> base_port = IO_SPACE_BASE(space_nr);
> snprintf(name, len, "%s I/O Ports %08lx-%08lx", info->name,
> - base_port + min, base_port + max);
> + base_port + min, base_port + max);
>
> /*
> * The SDM guarantees the legacy 0-64K space is sparse, but if the
> @@ -216,153 +196,195 @@ static u64 add_io_space(struct pci_root_info *info,
> resource->start = base + (sparse ? IO_SPACE_SPARSE_ENCODING(min) : min);
> resource->end = base + (sparse ? IO_SPACE_SPARSE_ENCODING(max) : max);
> if (insert_resource(&iomem_resource, resource)) {
> - dev_err(&info->bridge->dev,
> - "can't allocate host bridge io space resource %pR\n",
> - resource);
> + dev_err(dev,
> + "can't allocate host bridge io space resource %pR\n",
> + resource);
> goto free_resource;
> }
>
> + entry->offset = base_port;
> + res->start = min + base_port;
> + res->end = max + base_port;
> list_add_tail(&iospace->list, &info->io_resources);
> - return base_port;
> +
> + return 0;
>
> free_resource:
> kfree(iospace);
> -out:
> - return ~0;
> + return -ENOSPC;
> +}
> +
> +/*
> + * An IO port or MMIO resource assigned to a PCI host bridge may be
> + * consumed by the host bridge itself or available to its child
> + * bus/devices. The ACPI specification defines a bit (Producer/Consumer)
> + * to tell whether the resource is consumed by the host bridge itself,
> + * but firmware hasn't used that bit consistently, so we can't rely on it.
If we make the firmware obey to the ACPI spec, and
...
> + *
> + * On x86 and IA64 platforms, all IO port and MMIO resources are assumed
> + * to be available to child bus/devices except one special case:
> + * IO port [0xCF8-0xCFF] is consumed by the host bridge itself
> + * to access PCI configuration space.
> + *
> + * So explicitly filter out PCI CFG IO ports[0xCF8-0xCFF].
This is not going to happen on ARM64, right?
but this question is not about the patch itself, so for this patch
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
next prev parent reply other threads:[~2015-05-22 13:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 8:56 [Patch v3 0/7] Consolidate ACPI PCI root common code into ACPI core Jiang Liu
2015-05-14 8:56 ` [Patch v3 1/7] ACPI/PCI: Enhance ACPI core to support sparse IO space Jiang Liu
2015-05-22 13:35 ` Hanjun Guo
2015-05-14 8:56 ` [Patch v3 2/7] ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge Jiang Liu
2015-05-22 13:42 ` Hanjun Guo [this message]
2015-05-14 8:56 ` [Patch v3 3/7] ia64/PCI: Use common struct resource_entry to replace struct iospace_resource Jiang Liu
2015-05-22 13:46 ` Hanjun Guo
2015-05-14 8:56 ` [Patch v3 4/7] x86/PCI: Rename struct pci_sysdata as struct pci_controller Jiang Liu
2015-05-14 8:56 ` [Patch v3 5/7] PCI/ACPI: Consolidate common PCI host bridge code into ACPI core Jiang Liu
2015-05-18 13:08 ` Hanjun Guo
2015-05-20 3:16 ` Jiang Liu
2015-05-20 3:33 ` Hanjun Guo
2015-05-22 11:23 ` Hanjun Guo
2015-05-22 13:49 ` Hanjun Guo
2015-05-14 8:56 ` [Patch v3 6/7] x86/PCI/ACPI: Use common interface to support PCI host bridge Jiang Liu
2015-05-22 13:55 ` Hanjun Guo
2015-06-02 5:56 ` Jiang Liu
2015-06-02 6:29 ` Hanjun Guo
2015-05-14 8:56 ` [Patch v3 7/7] ia64/PCI/ACPI: " Jiang Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=555F323F.3020107@linaro.org \
--to=hanjun.guo@linaro.org \
--cc=bhelgaas@google.com \
--cc=fenghua.yu@intel.com \
--cc=jiang.liu@linux.intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lv.zheng@intel.com \
--cc=marc.zyngier@arm.com \
--cc=rjw@rjwysocki.net \
--cc=tony.luck@intel.com \
--cc=wangyijing@huawei.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).