From: Tanmay Inamdar <tinamdar@apm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linaro-kernel <linaro-kernel@lists.linaro.org>,
linux-pci <linux-pci@vger.kernel.org>,
Will Deacon <Will.Deacon@arm.com>,
LKML <linux-kernel@vger.kernel.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] pci: Add support for creating a generic host_bridge from device tree
Date: Wed, 5 Feb 2014 14:26:27 -0800 [thread overview]
Message-ID: <CACoXjckKRQfR3CbC1JpgbhOumED+OqiMh1_Y73-h6q=ByMNanw@mail.gmail.com> (raw)
In-Reply-To: <7398333.9L5KlyFggU@wuerfel>
Hello Liviu,
I did not get the first email of this particular patch on any of
subscribed mailing lists (don't know why), hence replying here.
+struct pci_host_bridge *
+pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
+ void *host_data, struct list_head *resources)
+{
+ struct pci_bus *root_bus;
+ struct pci_host_bridge *bridge;
+
+ /* first parse the host bridge bus ranges */
+ if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
+ return NULL;
+
+ /* then create the root bus */
+ root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
+ if (!root_bus)
+ return NULL;
+
+ bridge = to_pci_host_bridge(root_bus->bridge);
+
+ return bridge;
+}
You are keeping the domain_nr inside pci_host_bridge structure. In
above API, domain_nr is required in 'pci_find_bus' function called
from 'pci_create_root_bus'. Since the bridge is allocated after
creating root bus, 'pci_find_bus' always gets domain_nr as 0. This
will cause problem for scanning multiple domains.
On Mon, Feb 3, 2014 at 10:46 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
>> +/**
>> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
>> + * @dev: device node of the host bridge having the range property
>> + * @resources: list where the range of resources will be added after DT parsing
>> + *
>> + * This function will parse the "ranges" property of a PCI host bridge device
>> + * node and setup the resource mapping based on its content. It is expected
>> + * that the property conforms with the Power ePAPR document.
>> + *
>> + * Each architecture will then apply their filtering based on the limitations
>> + * of each platform. One general restriction seems to be the number of IO space
>> + * ranges, the PCI framework makes intensive use of struct resource management,
>> + * and for IORESOURCE_IO types they can only be requested if they are contained
>> + * within the global ioport_resource, so that should be limited to one IO space
>> + * range.
>
> Actually we have quite a different set of restrictions around I/O space on ARM32
> at the moment: Each host bridge can have its own 64KB range in an arbitrary
> location on MMIO space, and the total must not exceed 2MB of I/O space.
>
>> + */
>> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
>> + struct list_head *resources)
>> +{
>> + struct resource *res;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + int err;
>> +
>> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
>> +
>> + /* Check for ranges property */
>> + err = of_pci_range_parser_init(&parser, dev);
>> + if (err)
>> + return err;
>> +
>> + pr_debug("Parsing ranges property...\n");
>> + for_each_of_pci_range(&parser, &range) {
>> + /* Read next ranges element */
>> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
>> + range.pci_space, range.pci_addr);
>> + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
>> + range.cpu_addr, range.size);
>> +
>> + /* If we failed translation or got a zero-sized region
>> + * (some FW try to feed us with non sensical zero sized regions
>> + * such as power3 which look like some kind of attempt
>> + * at exposing the VGA memory hole) then skip this range
>> + */
>> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
>> + continue;
>> +
>> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
>> + if (!res) {
>> + err = -ENOMEM;
>> + goto bridge_ranges_nomem;
>> + }
>> +
>> + of_pci_range_to_resource(&range, dev, res);
>> +
>> + pci_add_resource_offset(resources, res,
>> + range.cpu_addr - range.pci_addr);
>> + }
>
> I believe of_pci_range_to_resource() will return the MMIO aperture for the
> I/O space window here, which is not what you are supposed to pass into
> pci_add_resource_offset.
>
>> +EXPORT_SYMBOL(pci_host_bridge_of_init);
>
> EXPORT_SYMBOL_GPL
>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 6e34498..16febae 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>> list_for_each_entry_safe(window, n, resources, list) {
>> list_move_tail(&window->list, &bridge->windows);
>> res = window->res;
>> + /*
>> + * IO resources are stored in the kernel with a CPU start
>> + * address of zero. Adjust the data accordingly and remember
>> + * the offset
>> + */
>> + if (resource_type(res) == IORESOURCE_IO) {
>> + bridge->io_offset = res->start;
>> + res->end -= res->start;
>> + window->offset -= res->start;
>> + res->start = 0;
>> + }
>> offset = window->offset;
>> if (res->flags & IORESOURCE_BUS)
>
> Won't this break all existing host bridges?
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2014-02-05 22:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 18:33 [PATCH] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau
2014-02-03 18:33 ` [PATCH] pci: Add support for creating a " Liviu Dudau
2014-02-03 18:46 ` Arnd Bergmann
2014-02-03 19:06 ` Liviu Dudau
2014-02-03 19:31 ` Arnd Bergmann
2014-02-03 22:17 ` Liviu Dudau
2014-02-04 10:09 ` Arnd Bergmann
2014-02-04 12:08 ` Liviu Dudau
2014-02-04 15:56 ` Arnd Bergmann
2014-02-05 22:26 ` Tanmay Inamdar [this message]
2014-02-06 10:18 ` Liviu Dudau
2014-02-08 0:21 ` Tanmay Inamdar
2014-02-08 14:22 ` Liviu Dudau
2014-02-09 20:22 ` Arnd Bergmann
2014-02-10 18:06 ` Tanmay Inamdar
2014-02-13 8:10 ` Jingoo Han
2014-02-13 8:18 ` Jingoo Han
2014-02-13 8:36 ` Tanmay Inamdar
2014-02-13 8:57 ` Jingoo Han
2014-02-13 11:27 ` Arnd Bergmann
2014-02-13 11:53 ` Russell King - ARM Linux
2014-02-13 12:15 ` Arnd Bergmann
2014-02-13 12:20 ` Liviu Dudau
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='CACoXjckKRQfR3CbC1JpgbhOumED+OqiMh1_Y73-h6q=ByMNanw@mail.gmail.com' \
--to=tinamdar@apm.com \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.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).