From: Arnd Bergmann <arnd@arndb.de> To: Andrew Murray <amurray@embedded-bits.co.uk> Cc: Liviu Dudau <Liviu.Dudau@arm.com>, linux-pci <linux-pci@vger.kernel.org>, Bjorn Helgaas <bhelgaas@google.com>, Catalin Marinas <Catalin.Marinas@arm.com>, Will Deacon <Will.Deacon@arm.com>, linaro-kernel <linaro-kernel@lists.linaro.org>, LKML <linux-kernel@vger.kernel.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, LAKML <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources. Date: Thu, 27 Feb 2014 14:58:34 +0100 [thread overview] Message-ID: <23116993.AhiSYlcnvx@wuerfel> (raw) In-Reply-To: <CAPcvp5EqcKEWoH_--azp+sMykmEWtY5whHG=c9t3sZVXZyAPUg@mail.gmail.com> On Thursday 27 February 2014 13:22:19 Andrew Murray wrote: > On 27 February 2014 13:06, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > The ranges property for a host bridge controller in DT describes > > the mapping between the PCI bus address and the CPU physical address. > > The resources framework however expects that the IO resources start > > at a pseudo "port" address 0 (zero) and have a maximum size of 64kb. > > Is this just in the case of ARM? (I've tried to keep up with the > conversation, but apologies if I've misunderstood). We are a bit inconsistent on Linux. The limitation cited above is indeed something we came up with on ARM to simplify the possible cases we have to worry about. In theory, each PCI host can have its own 4GB I/O space, but in practice limiting to 64KB is the most reasonable way to use it, and that still provides plenty of room for I/O registers since most devices don't use any, and at most a few bytes of address space. The limit we enforce on Linux is IO_SPACE_LIMIT, which is sometimes set to 0xffffffff, but I think most if not all of those cases are done so in error. > > + * of_pci_range_to_resource - Create a resource from an of_pci_range > > + * @range: the PCI range that describes the resource > > + * @np: device node where the range belongs to > > + * @res: pointer to a valid resource that will be updated to > > + * reflect the values contained in the range. > > + * Note that if the range is an IO range, the resource will be converted > > + * using pci_address_to_pio() which can fail if it is called to early or > > + * if the range cannot be matched to any host bridge IO space. > > + */ > > +void of_pci_range_to_resource(struct of_pci_range *range, > > + struct device_node *np, struct resource *res) > > +{ > > + res->flags = range->flags; > > + if (res->flags & IORESOURCE_IO) { > > + unsigned long port; > > + port = pci_address_to_pio(range->pci_addr); > > Is this likely to break existing users of of_pci_range_to_resource? > > For example arch/mips: IO_SPACE_LIMIT defaults to 0xffff and there is > no overridden implementation for pci_address_to_pio, therefore this > will set res->start to OF_BAD_ADDR whereas previously it would have > been the CPU address for I/O (assuming the cpu_addr was previously > > 64K). The function is used on MIPS, Microblaze and ARM at the moment. MIPS currently gets it wrong, by calling pci_add_resource_offset on the CPU address for IORESOURCE_IO, which is the wrong space. Limiting to IO_SPACE_LIMIT will fix it for the first host bridge on MIPS, and the second one will still not work, until IO_SPACE_LIMIT is fixed. On ARM, I believe we have a couple of drivers that make the same mistake, and others that at the moment override the address with range->pci_addr, so they won't change. Microblaze does 'range.cpu_addr = range.pci_addr;' for the I/O space window to fix it up. We should probably take a closer look there. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources. Date: Thu, 27 Feb 2014 14:58:34 +0100 [thread overview] Message-ID: <23116993.AhiSYlcnvx@wuerfel> (raw) In-Reply-To: <CAPcvp5EqcKEWoH_--azp+sMykmEWtY5whHG=c9t3sZVXZyAPUg@mail.gmail.com> On Thursday 27 February 2014 13:22:19 Andrew Murray wrote: > On 27 February 2014 13:06, Liviu Dudau <Liviu.Dudau@arm.com> wrote: > > > > The ranges property for a host bridge controller in DT describes > > the mapping between the PCI bus address and the CPU physical address. > > The resources framework however expects that the IO resources start > > at a pseudo "port" address 0 (zero) and have a maximum size of 64kb. > > Is this just in the case of ARM? (I've tried to keep up with the > conversation, but apologies if I've misunderstood). We are a bit inconsistent on Linux. The limitation cited above is indeed something we came up with on ARM to simplify the possible cases we have to worry about. In theory, each PCI host can have its own 4GB I/O space, but in practice limiting to 64KB is the most reasonable way to use it, and that still provides plenty of room for I/O registers since most devices don't use any, and at most a few bytes of address space. The limit we enforce on Linux is IO_SPACE_LIMIT, which is sometimes set to 0xffffffff, but I think most if not all of those cases are done so in error. > > + * of_pci_range_to_resource - Create a resource from an of_pci_range > > + * @range: the PCI range that describes the resource > > + * @np: device node where the range belongs to > > + * @res: pointer to a valid resource that will be updated to > > + * reflect the values contained in the range. > > + * Note that if the range is an IO range, the resource will be converted > > + * using pci_address_to_pio() which can fail if it is called to early or > > + * if the range cannot be matched to any host bridge IO space. > > + */ > > +void of_pci_range_to_resource(struct of_pci_range *range, > > + struct device_node *np, struct resource *res) > > +{ > > + res->flags = range->flags; > > + if (res->flags & IORESOURCE_IO) { > > + unsigned long port; > > + port = pci_address_to_pio(range->pci_addr); > > Is this likely to break existing users of of_pci_range_to_resource? > > For example arch/mips: IO_SPACE_LIMIT defaults to 0xffff and there is > no overridden implementation for pci_address_to_pio, therefore this > will set res->start to OF_BAD_ADDR whereas previously it would have > been the CPU address for I/O (assuming the cpu_addr was previously > > 64K). The function is used on MIPS, Microblaze and ARM at the moment. MIPS currently gets it wrong, by calling pci_add_resource_offset on the CPU address for IORESOURCE_IO, which is the wrong space. Limiting to IO_SPACE_LIMIT will fix it for the first host bridge on MIPS, and the second one will still not work, until IO_SPACE_LIMIT is fixed. On ARM, I believe we have a couple of drivers that make the same mistake, and others that at the moment override the address with range->pci_addr, so they won't change. Microblaze does 'range.cpu_addr = range.pci_addr;' for the I/O space window to fix it up. We should probably take a closer look there. Arnd
next prev parent reply other threads:[~2014-02-27 13:58 UTC|newest] Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-02-27 13:06 [PATCH v2 0/4] [RFC] Support for creating generic host_bridge from device tree Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau [not found] ` < 1393506402-11474-5-git-send-email-Liviu.Dudau@arm.com> 2014-02-27 13:06 ` [PATCH v2 1/4] pci: OF: Fix the conversion of IO ranges into IO resources Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:20 ` Arnd Bergmann 2014-02-27 13:20 ` Arnd Bergmann 2014-02-27 13:20 ` Arnd Bergmann 2014-02-27 13:45 ` Liviu Dudau 2014-02-27 13:22 ` Andrew Murray 2014-02-27 13:22 ` Andrew Murray 2014-02-27 13:56 ` Liviu Dudau 2014-02-27 14:08 ` Arnd Bergmann 2014-02-27 14:21 ` Liviu Dudau 2014-02-27 16:00 ` Arnd Bergmann 2014-02-27 14:30 ` Liviu Dudau 2014-02-27 13:58 ` Arnd Bergmann [this message] 2014-02-27 13:58 ` Arnd Bergmann 2014-02-27 18:19 ` Jason Gunthorpe 2014-02-27 18:19 ` Jason Gunthorpe 2014-02-27 19:12 ` Liviu Dudau 2014-02-27 19:12 ` Liviu Dudau 2014-02-27 19:12 ` Liviu Dudau 2014-02-27 19:36 ` Jason Gunthorpe 2014-02-27 19:36 ` Jason Gunthorpe 2014-02-27 19:36 ` Jason Gunthorpe 2014-02-27 19:48 ` Arnd Bergmann 2014-02-27 19:48 ` Arnd Bergmann 2014-02-27 20:07 ` Jason Gunthorpe 2014-02-27 20:07 ` Jason Gunthorpe 2014-02-27 20:22 ` Arnd Bergmann 2014-02-27 20:22 ` Arnd Bergmann 2014-02-27 20:22 ` Arnd Bergmann 2014-02-28 12:50 ` Liviu Dudau 2014-02-28 12:50 ` Liviu Dudau 2014-02-28 12:50 ` Liviu Dudau 2014-02-27 13:06 ` [PATCH v2 2/4] pci: Create pci_host_bridge before its associated bus in pci_create_root_bus Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:22 ` Arnd Bergmann 2014-02-27 13:22 ` Arnd Bergmann 2014-02-27 13:06 ` [PATCH v2 3/4] pci: Introduce a domain number for pci_host_bridge Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:22 ` Arnd Bergmann 2014-02-27 13:22 ` Arnd Bergmann 2014-02-27 13:06 ` [PATCH v2 4/4] pci: Add support for creating a generic host_bridge from device tree Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:06 ` Liviu Dudau 2014-02-27 13:38 ` Arnd Bergmann 2014-02-27 13:38 ` Arnd Bergmann 2014-02-27 13:48 ` Arnd Bergmann 2014-02-27 13:48 ` Arnd Bergmann 2014-02-27 13:48 ` Arnd Bergmann 2014-02-27 14:13 ` Liviu Dudau 2014-02-27 15:58 ` Arnd Bergmann 2014-02-27 16:20 ` Liviu Dudau 2014-02-27 16:45 ` Arnd Bergmann 2014-02-27 16:54 ` Liviu Dudau 2014-02-27 18:42 ` Arnd Bergmann 2014-02-27 23:32 ` Benjamin Herrenschmidt 2014-02-27 23:32 ` Benjamin Herrenschmidt 2014-02-27 23:32 ` Benjamin Herrenschmidt 2014-02-28 8:46 ` Arnd Bergmann 2014-02-28 8:46 ` Arnd Bergmann 2014-02-28 9:55 ` Liviu Dudau 2014-02-28 9:55 ` Liviu Dudau 2014-03-02 1:23 ` Benjamin Herrenschmidt 2014-03-02 1:23 ` Benjamin Herrenschmidt 2014-03-02 1:23 ` Benjamin Herrenschmidt 2014-03-02 1:25 ` Benjamin Herrenschmidt 2014-03-02 1:25 ` Benjamin Herrenschmidt 2014-03-07 18:58 ` Grant Likely 2014-03-07 18:58 ` Grant Likely 2014-03-07 18:58 ` Grant Likely
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=23116993.AhiSYlcnvx@wuerfel \ --to=arnd@arndb.de \ --cc=Catalin.Marinas@arm.com \ --cc=Liviu.Dudau@arm.com \ --cc=Will.Deacon@arm.com \ --cc=amurray@embedded-bits.co.uk \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.